Programming is still in this goofy phase as a profession/industry where lots of practitioners interpret suffering and complexity and difficulty as signals of underlying quality.
There are still large numbers of programmers who see advances in human-computer interaction and tools as basically childish, because what matters to them is the feeling of machismo they get while programming, rather than whether their efforts make their users more successful.
See the pushback against IDEs (as you said), syntax highlighting (“syntax highlighting is for children”), Rust (“_I_ know how to manage memory, everyone else is an idiot who needs to git gud”), types generally (“_I_ don’t make type errors”). Even high level languages and garbage collection were met with similar derision when they were going mainstream. There are so many examples of this throughout the history of programming.
If something is hard to do, or resulted in something impressively complex rather than something underwhelmingly simple, it must be good.
Basically, we’re still a very immature profession and it’ll take time before we shed the “the most important thing about programming is that I get to be a wizard” stuff. The users care that the bridge doesn’t fall down when they drive over it. The users don’t care whether designing the bridge made me feel powerful and wizardly because I used a crayon rather than Solidworks.
I hate with passion GUI's that stop be copying text and other crack that modern IDE's often do.
I don't avoid modern features at all and actively use pretty much all of them. If something like and IDE works for you that's great. But their is not some deep psychological need I am fulfilling, other then using tools that have less friction for me.
Additionally the post is about haskell a very high level language with the type system being the main feature, this persons choice in emacs is clearly different to the type that shun type systems and GC. Additionally I do not actually think the types that shun GC and shun type systems intersect as much as you make out, the types that shun GC are performance obsessed kinds of people in which type systems can improve performance significantly and those that shun type systems are (a dying breed) tend to be those who like scripting languages and hacking something together quickly. Most people recognize that both have their place I think.
Maybe the example of a carpenter who has a set of trusted tools and might like or a chefs set of knives, if we really need to look at other professions and measure are self against them. I think if you ask people why they use text editors (or IDE's) they will give their own valid reasons for each.
https://www.linusakesson.net/programming/syntaxhighlighting/
Here's one of the Go creators "explaining" why the Go website lacks highlighting.
https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...
https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ...
The behavior also isn't unique to programming at all. You can observe it in the various engineering fields. As a single example, in civil engineering you have the conflict between allowable stress design or load and resistance factor design. You even see the behavior in fields like medicine. Different doctors have different views on different methodologies, treatments, etc.
Ascribing it to the "youth" of programming as a field is strange, not just because of its observability in older professions, but because the things you're complaining about are things that emerged as the field got more mature.
I think there's a serious self-flagellation problem some programmers have for themselves after being talked down to by other fields that you're exemplifying here. There's nothing particularly unique about the social dynamics of programming.
Programming is a young field compared to basically all the others. It is immature. It is undergoing massive change quickly. It does have an immature, barely developed theory of practice. This has weird effects, just like how other disciplines had weird quirks when they were young too. What was young medicine like?
I have a great deal of empathy and respect for programmers. Same for engineers and doctors. None are infallible. Doesn’t change my read that our (programming) culture could be better than it is in specific ways, which could result in better decision making in the aggregate.
As for your last point, I agree! I’ve worked too closely with them for there to be any mystique left. I don’t want programming to become civil engineering or medicine but I think we can learn things from how they think about quality and systems. They’ve had more practice at it.
I don’t use LSPs with Haskell anymore. I work on multiple projects which use different versions of GHC and the base library which means having multiple LSPs installed for each one. Trying to get eMacs to reliably detect which project is using which version is not something I have been able to figure out. Plus it’s slow and uses way too much memory.
At current job I’m doing C# and man does the ecosystem there really push you to use an IDE. Most of my org uses Rider. I find it just as fascinating that people actually like using tools like it. Too bad it doesn’t have a decent text editor built in.
I have to agree with your comment about lsp in general they feel a little over engineered or old tags are nicer and feel less bloaty even if less powerful.
Not sure if you are on Emacs 31 yet, but another HNer told me the version issue was fixed for them, but I haven't tried.
> I’m doing C# and man does the ecosystem there really push you to use an IDE.
I had to stop using Emacs for C# dev for a similar reason. Well that, and being on Windows for work only further compounded the issue.
-IDEs are more resources hungry, I remember when trying to use CLion on a big C++ codebase, until increasing the garbage collector maximum heap size all I had was a blank screen, after it was just unusably slow...
-even when IDE work, LSP for C++ codebase aren't very good, for example the caller hierarchy is usually very incomplete..
-I remember having been asked quite a few times, about "how do I use the IDE's integrated debugger to debug a target which was available only through ssh and then you had to telnet from one board to another?" My answer? Use gdb.
That said, I use VSCode now because its multiple tab handling is very nice, but I use it mostly as a glorified text editor (not by choice but because C++ is really IDE's unfriendly).
The Java and C++ IDEs are separate packages built on a shared base.
Sometimes I work on my desktop, but most of my work is on a dev server. Some of my work is on my dedicated server at a budget host. I am not interested in an IDE that runs on my desktop and uses magic to edit files on my servers; properly configuring that with an eye towards security is not my idea of a good time. I'm not going to run an IDE on my server at hosting. I don't want to use multiple editors. The only sensible option is to use a terminal based editor for mostly everything. :p
Having used the same editor for programming for ~ 30 years at this point, I'm pretty good at it. When I use an IDE, it always feels more cumbersome ... sometimes it's valuable because I'm doing unfamiliar things anyway and the contextual assistance is sort of nice, but if I know what I'm doing, it gets in my way.
There's more than one way to do things, and if you want to use all the tools, go for it. I'm not trying to convince you not to, I'm just saying why it doesn't work for me.
If there was a high quality CAD server that was interfaced via plugins for programmable 3D editing software like Blender, then we can start making comparisons. Fact of the matter is that this isn't the case, not like what programmers have gotten in the last 20 years. It's absolutely not impossible for such a thing to exist, it just doesn't. Building things like high quality heuristics for the topological naming problem is quite hard.
It doesn't help that almost every IDE in existence these days is also not a real IDE. Visual Studio, Xcode, Jetbrains, etc. are just a more rigid programmable text editor, they lack the "I", and quite a bit of the "E". Compare them with things like LispWorks and Delphi, and the difference is stark. For the former category of "DE"s, there are often tools which are just as high quality, if not higher quality, elsewhere. Speaking as someone that uses a very wide variety of tools, including the ones mentioned, there's really not a lot of point to them unless you just really like their specific UI/UX.
Didn't Donald Knuth or someone of that era write about this effect in Pascal IDEs?
(The best feature though is that you can run a program containing semantic errors or even minor syntax errors; the body of any function that doesn't compile gets compiled as a throw-exception statement, so you don't have to comment it out when you're working on another part of the code)