snapdaddy

How many editors can you think of that don't do any (strictly) unnecessary file operations, e.g. renaming files? The author's problem is that Emacs is just really good at it, so he wants to use it more.

I feel like this is a wild mis-characterisation. American isn't in danger of becoming a victim; America is trying to suppress academic pursuits and intellectualism. It is politically inconvenient, which means it needs to be eradicated.

to come up with and advocate for paired programming before the concept existed _is_ pretty brilliant. And you also don't understand how much those practices improved software engineering, presumably because when you started programming they were already entrenched ideas, and so all you see are their shortcomings.

Those ideas do have flaws, and most of us are looking to improve how we right code. So if you aren't blind to those flaws, please, write a book or a blog or whatever on the best ways to write software so that we can all learn.

Yo! What's wrong with chess?

;-)

FWIW (not a lot), I do believe in a lot of these principles.

For example, even with widescreen monitors, it is still useful to limit line length. Why? Because many people will have multiple source files side-by-side on one of those widescreen monitors, at which point it makes sense for them to not run on indefinitely.

And of course, that is just a guideline, one that I break regularly. However, if it's a method with many args, I'll break the args onto their own lines.

However, the overriding concern is that an organisation works to code towards a common style, whatever that may be, so that unfamiliar code is predictable and understandable.

It would be good if we could create a digital fortress around the US that stopped unwanted things from coming in. Like a firewall for the country.

. . .

As a senior developer of 30+ years experience, I agree and was going to post the same thing.

If code is difficult to understand, I consider that to be a bug. And if, for some reason, the section of code actually is difficult to implement, I would at least want a pretty good comment explaining the context around it and the reasons for the approach taken.

Not only will this help improve the code, but if it is a senior developer, it will help them to understand where they've become blind to a particular complexity. It is great feedback to have someone explain that they don't understand code that seems 'fine' to you.

That's a really interesting data point about your experience with TypeScript. I'm going to have to file that away as something that I'm not sure what to do with right now, but also as an interesting thought to keep in mind going forwards.

I acknowledge that there are passionate users of most programming languages, but I also 100% agree that the FP crowd are something different. I feel like most other languages have some nuance at least; if you're writing transpilers or kernel modules then hell yes, Rust makes sense. If, however, you are trying to churn out a web-based store-front, maybe don't look towards Rust.

But with FP, it seems like it is always the answer. And it's even better if your Operating System can be immutable too. And your build scripts. And, even if it take 10 times as long to write, at least we will be confident that it's type safe at the end.

As others have commented, most people have specialised knowledge. For example, I've been programming professionally for about 30 years; let me share my knowledge of game programming:

Most people use Unity these days. I'm pretty sure it's in C#, and there was something about the licence recently that they probably backed down from. You can still write in c with OpenGL, but you will probably have to create your own game engine(?). You will need a game loop where you track the milliseconds elapsed each frame. Try not to stutter in your game loop. 16 ms. Oh, and double-buffering the output is probably a good idea.

See? Don't sound so smart now, do I?

The opposite viewpoint is that you are being included in these meetings so that you can prevent bad decisions by management. What if you aren't in a meeting where it is decided that you should implement feature x because they imagine it to be low cost, not realising the complexity?

I agree completely. I tend to do 'UML light', where I don't worry about the finer details (e.g. marking fields public or private). The best solution is one where I can sketch out the outlines of a class and have some tool automatically generate UML which I can then edit.

And C4 diagrams are great for explaining software architecture, which wouldn't have been possible without UML and esp. class diagrams.

I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance.

For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification.

However, you could also rephrase that principle to be: 'you should always prematurely abstract your designs'.

I think if abstraction was viewed as a negative to be avoided unless necessary, software architecture would have been far better off.

To be fair, premature abstraction is a lot of fun for those that do it. It's just those that follow who aren't so keen.