Programming thread

  • Agree
Reactions: moocow
mmm, no that's not really what I'm talking about. Have you ever used jetbrain products before?
Forever ago. What do you want to search: file names, file content, function/class names?
All three are possible with vim.
 
Forever ago. What do you want search file names, file content, function/class names?
All three are possible with vim.
Updated my original post to include examples. They pretty much cover what I'm talking about.

I realize that thousands of extensions exist for vim, and I'm sure that if you put some large number of them together, you can approximate an IDE. However, the amount of potential fiddling, breakage and lack of polish, to me, is not worth over just paying $70 per year, which pays itself off in less than a few days. Also in my experience fuzzy search with vim was pretty slow. I don't know if it's indexing anything and might just be using raw grep.

And really, I'd be happy to be proven wrong because I like FOSS options, but I just don't think these extension solutions scale well.
 
Updated my original post to include examples. They pretty much cover what I'm talking about.

I realize that thousands of extensions exist for vim, and I'm sure that if you put some large number of them together, you can approximate an IDE. However, the amount of potential fiddling, breakage and lack of polish, to me, is not worth over just paying $70 per year, which pays itself off in less than a few days. Also in my experience fuzzy search with vim was pretty slow. I don't know if it's indexing anything and might just be using raw text find.
Sounds like vimgrep, you can also use external grep, which is as fast it gets for raw text.

For a nice combined interface that also searches tags you probably want a plugin like ctrlp.
 
  • Informative
Reactions: Bongocat
Probably correct, but I'd say that's less due to the autocompletion and more of them completely hiding the compiler chain from you. You just press a button and now you have a program. It's magic!
If we take languages like Java as an example would you say the compiler chain is the more significant part the IDE hides from you, or the compiler chain, abstraction, project structure, class hierarchy, etc?
It is my experience that IDEs can cause brain damage which becomes evident when the IDE can't be of much help or is non existent. Try bringing someone used to IntelliJ over to Lisp of OCaml, they'll have an anuerism.
IDEs hide too much and bombard you with useless information at the same time. When I'm programming I want to see text, not buttons, terminals, prompts, project tree, what have you. Too much visual noise instead of a text buffer and maybe some unobtrusive visual popups. When I see how my colleagues work I'm appalled at the actual code taking up the smallest part of screen real estate.
I don't think IDEs are bad, but I think programming shouldn't be taught with them and if you work with them take a couple of weeks each year without them just to reset your brain.
VIM can do that.
So can GNU/Emacs, with frameworks like Helm and Ivy.
 
If we take languages like Java as an example would you say the compiler chain is the more significant part the IDE hides from you, or the compiler chain, abstraction, project structure, class hierarchy, etc?
I'm unsure what you mean by hiding abstractions/project structure/hierarchy. The only thing i can guess is that the navigation tools make you not have to refer to them as often. They're still there and they're still important to maintain, though.

It is my experience that IDEs can cause brain damage which becomes evident when the IDE can't be of much help or is non existent. Try bringing someone used to IntelliJ over to Lisp of OCaml, they'll have an anuerism.
It can cause a mental hitch on the rare occasion when navigation breaks, but I haven't experienced that impacting my workflow. I'll grant that it allows your memory to be not as precise to get by, but I couldn't speak to the long term effects of that.

IDEs hide too much and bombard you with useless information at the same time. When I'm programming I want to see text, not buttons, terminals, prompts, project tree, what have you. Too much visual noise instead of a text buffer and maybe some unobtrusive visual popups. When I see how my colleagues work I'm appalled at the actual code taking up the smallest part of screen real estate.
That sounds like a config issue. On my setup, my screen is only code and everything else is hidden under context menus/hotkeys. Only there when I need it.
Granted, I went through some effort to get it like that so I may be an anomaly. I think a lot of programmers are jaded by Eclipse in that regard. It has one of the most intrusive and least space efficient interfaces I've ever seen.

I don't think IDEs are bad, but I think programming shouldn't be taught with them and if you work with them take a couple of weeks each year without them just to reset your brain.
I completely agree with that, for what it's worth.


Unrelated:
1616948298133.png
 
Last edited:
  • Like
Reactions: Strange Looking Dog
I think the best things about using an IDE is refactoring and code analysis. I'm not really sure what the capacilities are with vim when it comes to those but I can hit a few buttons and let the ide refactor for the next 15 minutes and grab a coffee. That combined with the autogeneration of boilerplate is pretty much the only reason I use an ide over anything else. Autocompletion is nice too but generally not needed when you can jump to source code with a hotkey. I would say the worst part about ides is the perpetual bloat they receive to justify their development team being employed.
 
  • Informative
Reactions: Full Race Replay
I'm unsure what you mean by hiding abstractions/project structure/hierarchy. The only thing i can guess is that the navigation tools make you not have to refer to them as often. They're still there and they're still important to maintain, though.
What I mean is that the developer might have no idea what some class is, what other classes use it, what interfaces it satisfies. IDEs are so sophisticated they allow you to narrow your scope of focus to such a degree it becomes disconnected from the rest of the code base.
It can cause a mental hitch on the rare occasion when navigation breaks, but I haven't experienced that impacting my workflow. I'll grant that it allows your memory to be not as precise to get by, but I couldn't speak to the long term effects of that.
It isn't just memory. It's understanding. IDEs save you some of the mental effort of thinking about how stuff fits together, because you don't even have to remember.
That sounds like a config issue. On my setup, my screen is only code and everything else is hidden under context menus/hotkeys. Only there when I need it.
And what does it say about IDEs that their default configurations are god awful and developers don't even bother messing with them?
Whether your text editor is part of an IDE or not is immaterial, but debugging without a graphical IDE (i.e. not some hack where you pipe gdb output into emacs) is a fool's errand.
Ofc you need a debugger where everything is mutable, things can pass by reference, and the method of abstraction is encapsulation. That sounds like a paradigm problem with procedural languages.
I think the best things about using an IDE is refactoring and code analysis. I'm not really sure what the capacilities are with vim when it comes to those but I can hit a few buttons and let the ide refactor for the next 15 minutes and grab a coffee. That combined with the autogeneration of boilerplate is pretty much the only reason I use an ide over anything else. Autocompletion is nice too but generally not needed when you can jump to source code with a hotkey. I would say the worst part about ides is the perpetual bloat they receive to justify their development team being employed.
Doesn't this strike you as a problem? Why do you even need such heavy refactoring tools? Why do you have to write so much boilerplate? It sounds like a problem inherent to the tools.
 
Doesn't this strike you as a problem? Why do you even need such heavy refactoring tools? Why do you have to write so much boilerplate? It sounds like a problem inherent to the tools.
It's a problem of the Java language itself in the case of intellij idea. Having encapsulation creates a getter/setter for every field you want to be "public" in your java api. Kotlin solves this issue by having properties like C# (with getter/setter creation which you can override) plus data class generating getters/setters, hashCode, toString during compilation. Kotlin is basically a bandaid solution to all the problems of Java, it supports a lot of things Java never could but it still is java/javascript.

You don't neccesarily need heavy refactoring tools but if you need to refactor or if you're working with some stone age shit refactoring tools will help you a lot. Not even mentioning finding usages sorted by new instance/read/write etc is a life saver. You don't really need any of this extra stuff, it just saves you time when you do need it. I tend to use regular text editors whenever I can (learning c atm and using gedit to manually type everything) but when programming in Java/Kotlin it's almost a requirement. Even if you nix the ide you will still need maven/gradle to manage your dependencies and build automation if you're not doing standard library things.
What I mean is that the developer might have no idea what some class is, what other classes use it, what interfaces it satisfies. IDEs are so sophisticated they allow you to narrow your scope of focus to such a degree it becomes disconnected from the rest of the code base.
An IDE doesn't hide anything from you except what you want it to hide. You have full access to browse source code of all your dependencies and any hierarchy. There are hotkeys and a menu to go to declaration/usages, type definition, superclasses, subclasses, etc.
And what does it say about IDEs that their default configurations are god awful and developers don't even bother messing with them?
Who exactly isn't messing with their IDE's window configuration?
Ofc you need a debugger where everything is mutable, things can pass by reference, and the method of abstraction is encapsulation. That sounds like a paradigm problem with procedural languages.
Everything isn't mutable and debuggers don't become useless because your program limits side-effects.
 
Last edited:
What I mean is that the developer might have no idea what some class is, what other classes use it, what interfaces it satisfies. IDEs are so sophisticated they allow you to narrow your scope of focus to such a degree it becomes disconnected from the rest of the code base.
That's a feature, not a bug. If the design of a program is so inherently wirecrossed that I have to think about the entire system every time I'm making a change, that's a really serious problem that needs to be addressed separately.

And what does it say about IDEs that their default configurations are god awful and developers don't even bother messing with them?
That's a problem with people in general. Most people never invest the few hours it takes to customize out the defaults on anything. I'd rather an IDE start me out with everything displayed on screen so I know what's there, then give me easy options to hide it.

Doesn't this strike you as a problem? Why do you even need such heavy refactoring tools? Why do you have to write so much boilerplate? It sounds like a problem inherent to the tools.
Because we don't live in a perfect world. Most code is 'legacy code' and needs to remain compatible with useful, real world applications. Industrial applications are a mess. That's a product of tight deadlines and limited resources. At some point you need to make it work and move on. Perfect code is useless code.

And no, you can't get an ought from an is. I am not arguing that this is how things should be. I'm saying it's how they are and that's not projected to change anytime soon no matter how much effort is put in to doing such.
 
Last edited:
I don't object to IDEs, but I do object to languages that make an IDE feel necessary for even for small projects. I also don't particularly like how modern IDEs work. I think they should be lighter and do more stuff that I actually find useful. For example, I'd like to specify custom syntax highlighting for different overloads. I'd like curly braces and parens to have alternating highlighting so it's easier to spot pairs. I'd like to get detailed reports about identifiers on demand, for example, I'd like to be able to select a type and get a window on the side that tells me about the struct's size and memory layout, what files use it, what functions take it as an argument, what functions use it in their body, the lines where it's used, etc. I'd like to be able to select a macro or template at its call site and see how it actually expands/specializes. I'd like these reports to include information from at least the last time the debugger was run. I'd like a tree-like undo system so I don't have to worry about deleting future work when going back in time to copy something I didn't realize I needed. I want multi-cursor support. I could go on, but you get my point. I know modern IDEs can approximate a lot of the behavior I want, but it's never as nice as I think it should be, and it's always so fucking slooow.

The last time I worked at a Java shop we were forced to use Eclipse, and I spent a day exploring the bowels of its menus so I could find and disable every feature that just got in my way. There's so much useless shit in there, and a lot of it caused Eclipse to randomly grind to a screeching halt when I was trying to do stuff. Breaking my concentration like that isn't acceptable, and I don't get how the Eclipse Foundation thinks any of this is a good idea. I don't like IntelliJ either, but at least it's not obviously retarded.
 
Last edited:
Just poking with some suggestions. I'm only drawing from the places I know best, but that can often be a springboard into finding equivalents for other platforms.

I'd like to get detailed reports about identifiers on demand, for example, I'd like to be able to select a type and get a window on the side that tells me about the struct's size and memory layout, what files use it, what functions take it as an argument, what functions use it in their body, the lines where it's used, etc.
I'd like to be able to select a macro or template at its call site and see how it actually expands/specializes.
I believe resharper can do all of those (except expanding templates).

I'd like a tree-like undo system so I don't have to worry about deleting future work when going back in time to copy something I didn't realize I needed.
I'm actually surprised this feature isn't in more places. A jank approximation is 'local history' extensions where it will make a copy of the file every time you save in an out of sight, out of mind location, and then you can recover whatever you want from those scrap files. That's far from elegant, but it does help me be less afraid to make "big undos".

I'd like curly braces and parens to have alternating highlighting so it's easier to spot pairs.
I've been using this for some time and it's a godsend.

it's always so fucking slooow.
The slowness is a valid complaint. Turning off code analysis (eg: clang) can help a lot, though.

The last time I worked at a Java shop we were forced to use Eclipse, and I spent a day exploring the bowels of its menus so I could find and disable every feature that just got in my way. There's so much useless shit in there, and a lot of it caused Eclipse to randomly grind to a screeching halt when I was trying to do stuff. Breaking my concentration like that isn't acceptable, and I don't get how the Eclipse Foundation thinks any of this is a good idea. I don't like IntelliJ either, but at least it's not obviously retarded.
Eclipse has an abomination of an interface and I think it gives a lot of people a bad impression of IDEs who would otherwise like them.
 
It's a problem of the Java language itself in the case of intellij idea. Having encapsulation creates a getter/setter for every field you want to be "public" in your java api. Kotlin solves this issue by having properties like C# (with getter/setter creation which you can override) plus data class generating getters/setters, hashCode, toString during compilation. Kotlin is basically a bandaid solution to all the problems of Java, it supports a lot of things Java never could but it still is java/javascript.
Java now introduced Records which are basically this feature, too, and fields are immutable by default
Everything isn't mutable and debuggers don't become useless because your program limits side-effects.
It eliminates about 95% of the use cases for a debugger when tests don't require elaborate set up and tear down for state. And I didn't mention side effects, I put more emphasis on immutable data. I rarely have to reach for a debugger most of the time, and I don't work on trivial code.
tree-like undo system
You an Emacs user?
 
  • Informative
Reactions: Jones McCann
Haven't tried it yet. My current code editor is Sublime. Tree-like undo is just the obvious way to handle the problem.
Emacs has undo tree. Saved my ass a few times.
That's a feature, not a bug. If the design of a program is so inherently wirecrossed that I have to think about the entire system every time I'm making a change, that's a really serious problem that needs to be addressed separately.
Forgot to reply to this one. My takeaway is that IDEs today are too powerful for our monkey brains. They make writing big-ball-of-mud too easy. Only by limiting yourself can you find enlightenment, or something gay like that.
 
I use Emacs pretty religiously, and the best development experience is when the language exposes a server to which Emacs connects, so that if my editor wants to autocomplete a symbol, it can send a request to the server and the big brains that's responsible for parsing/type-checking/compiling the code can give back an intelligent response. I believe the first example of this was Common Lisp and SLIME. Clojure took the same model with Cider. Scala has ensime. Ocaml has Merlin which is now a must for me, but honestly, its feature set looks pretty puny compared to Cider. Nowadays, the model is standardised in LSP, and I guess most folk writing new modes for Emacs look first to writing LSP clients.

If I end up Java coding again, I will certainly check out lsp-java, but this didn't exist when I was last full-time java, and I couldn't figure out an Emacs setup that came close to what IntelliJ offered. Some of the benefits of IntelliJ are, as has been said, just problems with Java. The amount of boilerplate makes it the most obnoxious language I've ever used, and the fact that I need an IDE to fix this is not a point in favour of IDEs. But IntelliJ does stuff that I want just as much in Emacs, like semantically aware autocomplete/renaming/goto-definition/find-usages/format-according-to-styleguide. For Java, and for other imperative first languages, I also want a solid integrated debugger, with the ability to set conditional breakpoints and evaluate code. All of this is possible in Emacs, and is available for some languages, but it's not universal.

Having a compiler toolchain abstracted away is normally dealt with outside of Emacs, and in compiled languages, I expect to be able to hit C-c C-c and have my project rebuilt. But exactly what I want here depends on the language. I quite like REPLs, and I want to be able to quickly switch to one with my current file reloaded. But better than REPLs is the sort of exploratory testing I can do in Emacs lisp, where I can just evaluate arbitrary expressions in my buffer. I assume this is standard in Clojure, and along with Cider, it's a real temptation to look more into that language.

For simple editing tasks, things like undo-tree are great, but just having an undo-ring is superior to the normal implementation of undo/redo. Ditto for copy/paste (kill/yank). I recall that IntelliJ had undo history, but I believe it had only 5 or so slots by default, which made it pretty useless for the way Emacs has accustomed me to using the kill ring. I have also used Elisp in anger to do nasty refactors on large code-bases, in ways that I'm not sure would be possible in IntelliJ, but it's not exactly stuff I'm proud of.
 
Last edited:
I use Emacs pretty religiously, and the best development experience is when the language exposes a server to which Emacs connects, so that if my editor wants to autocomplete a symbol, it can send a request to the server and the big brains that's responsible for parsing/type-checking/compiling the code can give back an intelligent response. I believe the first example of this was Common Lisp and SLIME. Clojure took the same model with Cider. Scala has ensime. Ocaml has Merlin which is now a must for me, but honestly, its feature set looks pretty puny compared to Cider. Nowadays, the model is standardised in LSP, and I guess most folk writing new modes for Emacs look first to writing LSP clients.

If I end up Java coding again, I will certainly check out https://github.com/emacs-lsp/lsp-java, but this didn't exist when I was last full-time java, and I couldn't figure out an Emacs setup that came close to what IntelliJ offered. Some of the benefits of IntelliJ are, as has been said, just problems with Java. The amount of boilerplate makes it the most obnoxious language I've ever used, and the fact that I need an IDE to fix this is not a point in favour of IDEs. But IntelliJ does stuff that I want just as much in Emacs, like semantically aware autocomplete/renaming/goto-definition/find-usages/format-according-to-styleguide. For Java, and for other imperative first languages, I also want a solid integrated debugger, with the ability to set conditional breakpoints and evaluate code. All of this is possible in Emacs, and is available for some languages, but it's not universal.

Having a compiler toolchain abstracted away is normally dealt with outside of Emacs, and in compiled languages, I expect to be able to hit C-c C-c and have my project rebuilt. But exactly what I want here depends on the language. I quite like REPLs, and I want to be able to quickly switch to one with my current file reloaded. But better than REPLs is the sort of exploratory testing I can do in Emacs lisp, where I can just evaluate arbitrary expressions in my buffer. I assume this is standard in Clojure, and along with Cider, it's a real temptation to look more into that language.

For simple editing tasks, things like undo-tree are great, but just having an undo-ring is superior to the normal implementation of undo/redo. Ditto for copy/paste (kill/yank). I recall that IntelliJ had undo history, but I believe it had only 5 or so slots by default, which made it pretty useless for the way Emacs has accustomed me to using the kill ring. I have also used Elisp in anger to do nasty refactors on large code-bases, in ways that I'm not sure would be possible in IntelliJ, but it's not exactly stuff I'm proud of.
You should definitely look more into Clojure. I think CIDER's at a point where it's richer than SLIME, among other reasons because it had to be to make up for features CLers like to brag about, such as conditions and restarts. It's the best programming experience I've had and writing production grade applications isn't complicated or requires much ceremony.
The REPL is very dominant in Clojure development and you're encouraged to live in your application and develop from inside it. It's common for REPLs to stay up for days and weeks in a project.
If you're missing static types you can use the spec library to write pretty comprehensive descriptions of your data, including "dependent types". You can also use them for generative testing.
The stepping debugger in CIDER is incredible, and the object explorer is great. 10/10 would recommend.
 
  • Informative
Reactions: cecograph
Back