I agree that a good IDE experience is a core part of the language nowadays. And in my experience, VS Code + TypeScript is by far the best IDE experience, far better than Clojure + Emacs ever was. A significant amount of productivity that I thought that combination was giving me turned out to just be a feeling of productivity because of how ninja the stuff I was doing was. Similar to how I'm faster in Emacs than I was in Vim, but I thought I was faster in Vim simply because the complexity or cleverness of the commands I was typing in before I learned Emacs.
I am going quite in the opposite way. My IDE is getting more and more the shell, the VI(M) and the terminal based development tools (in my case mostly Haskell and Shell-Related). The more I work the more I am getting used to the terminal, get better usage of the tools. And strangely I find my screen more often to just have fullscreen terminal window.
I concede that I do not do any web or graphics development at the moment, this might help. But it's deeply satisfying to be able to discover new helpful functionality in the tools that are there for decades. And it's good to be able to use them almost everywhere, be it on a server over ssh or on a windows box with cygwin.
I know it’s java, I know it’s big and bloated and gross but at some point give IntelliJ idea a chance if you like the ide experience of vs code & ts! It’s mindboggling coming from editors & terminals
It has always been core part of the language experience on Amiga, PC and Mac platforms.
Just not on UNIX culture.
Re:Racket: Lisp for Learning
by layoutIfNeeded on Thursday August 08, 2019 @02:17PM
(#20647070)
On *nix the whole OS is your IDE.
That is an old one, except it isn't a match for the integration an IDE is capable of offering, including the graphical capabilities.
Interlisp-D, Lisp Machines, Smalltalk, Mesa/Cedar, XDE, Oberon were an OS as IDE.
UNIX is a poor imitation of their capabilities.
Smalltalk and Oberon especially are complete or near complete systems: they are described from top to bottom, and in some cases described in themselves.
Oberon is interesting because the 2013 book goes much further than any recent system in this regard. One of the (final?) chapters even describes how to implement the custom processor in an FPGA.
I used to write C and C++ code in (non-vim) vi, with only autoindent, and it was fine. I could also type the spaces, if I had to.
For s-expressions, like in a Lisp, you want autoindent a bit more, and some kind of of paren-matching/highlighting is also important.
Fortunately, editors have been doing autoindent and paren-matching for decades. And once your editor is formatting your code correctly, it's pretty visual, not textual.
And few people write any code in something like non-vim vi or notepad.exe anymore, so I see no reason to think less of a language for wanting an editor/IDE developed in the last couple decades.
There's no need for paredit, AFAIK, but paredit is another thing for which s-expressions are especially well-suited, relative to most other syntaxes. (You can also do paredit-like structural-based navigation and editing of JS, for example, but you have to have a clear model of the syntax structure, not only in the tool, but also in the programmer's head.)