Hacker News new | past | comments | ask | show | jobs | submit | johannboehme's comments login

Thanks god i live in the EU and not in a late stage capitalist hell hole XD


but there is. VSCode core may be open source, but the plugin marketplace certainly isn't. So if you for example use VSCodium, you don't have access to the plugin marketplace and eather have to use an alternative or manage your plugins completely manually on the filesystem.


So what? You use the plugins available on the platform you use, that's standard practice. Would you complain Sublime Text plugins are not available on VSCode? Or emacs plugins are not available on vim?

This is not lock-in, just a different feature set.


hmm.. but you also spent a lot of time to learn programming. Why not invest some time in the use of professional tools? If you master an editor like vim, you'll never need to spend time to learn additional IDEs. In the past i needed to learn VSCode, Eclipse, IntelliJ, XCode, Visual Studio and some other niche IDEs. All have very different menu structures and keybinds. Just to unify that was worth the time learning vim.


Because I don't need to? I honestly think it would be easier to follow along with a tutorial for whatever language I'm using in any of those editors you've mentioned than one for Vim or Emacs.


not really.. vim is easy to extend and adapt. You loose that with only vim mode in vscode. You also loose the ecosystem and relevant core functionality like most vim core functionality like :grep :vim :make, quickfix list, arglist etc..


I dont know.. The argument i read all the time is "i don't want to invest time in vim". But what kind of professional spends hours uppon hours learning his craft (programming), but is unwilling to invest some of those hours into mastering professional tools? What about sharpening the axe? The amount of time i saved by sticking to vim is definitly more that the time i needed to learn it.. IDEs are easy mode and waste of resources. Its ok to start with them as a noob, but down the line i want to customize every part of my toolchain. (And thats just horrible to do in VSCode etc..)


If someone likes to use vim, then so be it. If someone likes to use VSCode, then so be it. IDEs can also be called productive mode and use the right amount of resources necessary for large projects. They will get the job done, and for many it is the preferred option.

Vim doesn’t have to be the tool you use when there are others. If it was the only tool, I’d agree that people should know it better. Thankfully it’s not the only one.


Some hours is not what one should put into Vim, IMO. I've used it for many years and felt I got better at it very gradually (maybe I'm like that with most things). It's much more than hours! It's using it every day for a few years :)

To honor the many-years of vim, I relearned a new vim feature now: using :g to run a macro like this: https://stackoverflow.com/a/5292858


not just the children :D


It’s something people love to be, but in a world with recorded audio, you don’t need as many musicians as you once needed (and it was actually a fairly common job). > Well, and because people love it, many will still be passionate musicians / writers / language savants. They just won't make a living out of it. And thats ok. The intrinsic motivation to do those things is recreational and the focus on monetization contributed to the "content is plague" trend in the first place.


or when you want immutablity and a functional programming style. or if you prefer manipulating lisp ast instead of wrestling indentation. or if you need somewhat decent performance, or if you need somewhat decent multithreading, etc etc..


But clojure is not meant to be developed statically! It is supposed to be running while developing it. You don't need static analysis if the programm is running and inspectable.


Ah yes thanks for the elaboration. That's what I meant by the spirit of Clojure.


You are wrong. https://www.youtube.com/watch?v=YR5WdGrpoug Static typing only leads to devs trying to press the real world in stupid arbitrary categories.


Yeah and spec isn’t trying to press the real world into arbitrary categories? /s

The thing is, having some structure in terms of types or data shape constraints helps you model and understand your program. You can change them as your understand of your program changes or the need arises. You can be against static types because they force you to slow down and think about things before you can just get to coding, and it can be sometimes annoying to model your system using them (and sometimes not so useful), or other technical reasons like some type systems don’t allow you to model certain things, but to say it just leads to devs putting the real world into stupid, arbitrary categories when the real world (and your program!) primarily have data that can be trivially categorized because that’s what Rich Hickey said makes you sound like cargo-culting or parroting a point without diving deeper into the specific reasons and potential counterarguments.


IMHO, external schema to validate structures at entry point is the way to go.

We have to have both: types and external schemas in oo languages.

Plus, types make working with maps cumbersome and force you to maybe unnecessary data cages called dto-s


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: