Hacker News Reader

Comment by Naac | Hacker News Reader

Another problem I've found for me with Nim and Crystal is the lack of editor support compared to other statically typed languages like Java and C++.

Arguably a really nice benefit of these languages is the inline error highlighting, which speeds up development. I've found for Nim and Crystal I have to run the compiler in the terminal, look where the errors were, and then find those lines in my editor.

LSP support is minimal ( especially when a language is starting out ). My ideal editor for Nim would be Pycharm-like ( open source edition ) with an LSP backend.

View on HN

> I've found for Nim and Crystal I have to run the compiler in the terminal, look where the errors were, and then find those lines in my editor.

I pretty much do this with any language I use, including C++ or even Java and Kotlin. I just use vim for everything, it makes it easy to switch around between languages without dealing with a new IDE, and I haven't used any autocompletion in any language in probably 10 years -- that aspect is over-rated.

In Vim I don't recommend running the compiler in the terminal, instead set makeprg and errorformat appropriately, and use the :make command and the quickfix list.

I’d appreciate a link describing this more fully if you have one handy.

Usually with Vim the manual is better written and more accurate than any external source of information, so I recommed using the command ":help quickfix". It explains usage of the quickfix list, the :make and :grep commands and how to configure the errorformat and makeprg variables.

True, though the VSCode Nim plugin "just worked" for me. The compile messages work too, I think using the Nim LSP [1].

1: https://github.com/PMunch/nimlsp

If the compiler is fast enough, you don't need LSP support; many editors can be configured to run any sort of compiler or linter for doing error checking, and can be configured to do so when saving or as you edit &c.

Vim, for example, has a plugin called "syntastic" that is kind of a meta-plugin aggregating lots of these, and indeed it seems to have support for nim error checking.

LSP is a nice step forward, but people had error highlighting for decades before it was invented.

[edit]

Doesn't change anything above, but someone pointed me at ALE which is a newer tool that can run lint engines asynchronously (using interfaces that didn't exist when syntastic was created). For vim specifically that may be a better tool, but I haven't tried it yet.

ALE is quite nice. LSP is nicer-still, but ALE is a good step up in usability from syntastic.

ALE will use LSP servers when they are available

>> and can be configured to do so when saving or as you edit

That's true, but being able to quickly click on the line that has the error and have your editor navigate to the file automatically is slightly more painful to setup, and is bespoke for whatever tool you are using.

My point was just that a tight integration between language and IDE/editor makes the overall language experience much nicer. For example:

Racket/Dr. Racket Python/Pycharm Java/Intellij Emacs lisp/Emacs

>> That's true, but being able to quickly click on the line that has the error and have your editor navigate to the file automatically is slightly more painful to setup, and is bespoke for whatever tool you are using.

In the event that the tool doesn't output in one of the common formats, it's usually just a regex; again I had this in Vim for several different languages back in the 90s.

>> My point was just that a tight integration between language and IDE/editor makes the overall language experience much nicer.

I agree (happy SLIME user here), but it often seems like I'm in the minority. I've literally never met someone in person besides me that uses pycharm, and you are about the 3rd person online I've seen mention it in a favorable light.

The LSP enables a lot more than diagnostic reporting

It sure does, but GP specifically mentioned diagnostic reporting as something missing when using the "new hot" languages

I don't get why more editors don't support parsing compiler output to get the file name and line for errors. Its dead simple, no need to run a server, just allow running the compiler from within the editor and have some way of configuring the parsing so it can work with different compilers. Gets you 90% of the value for 10% of the work (because you don't need to do anything to the compiler).

Emacs has been able to do this for a very very long time

"Turing-complete text editor can do anything" :)

To be fair, I dont actually know what percentage of editors have that feature, my impression is just that many people arent aware of the idea. Maybe Im wrong though.

You don't even need to configure it in many cases. I've been doing it with numerous languages in Emacs, and I think I had to configure it (with a regex) maybe once for a compiler whose output it didn't already recognise.

The syntax compilers use to indicate filename and error location are similar among compilers, and generally quite unambiguous anyway, so in many cases no configuration is needed. A small list of regexes built in to the editor is enough.

Indeed. Emacs and Vim have both supported this for a long time. I used it in vim in the late '90s and Emacs usually got features like this before vim.

I was working on integrating a language with a "programmers editor" <name omitted to protect the guilty> and asked how to extend the editor to indent a new language. The response was "it should already support all C/Java like languages with the configuration format." My response "this isn't a C-like language". The community response "Uh, I guess write a plugin that installs a hook on the carraige-return key and manually position the cursor?" It blew my mind that anything billed as a programmer's editor couldn't be customized for doing this already...

> which speeds up development.

Perhaps its because the product I work on is fairly mature at this point, but "speed" isn't something I really optimize my workflow for.

It's much more important that I solve the right problem than that I solve "a problem" quickly.

When the lifetime of the code you write is measured in years / decades, saving minutes seems much less relevant.

I should clarify that when I wrote "speed", in my mind I was thinking of code navigation.

I found that tight language integration to the IDE/Editor makes jumping into new code bases in the language much easier. I've found refactoring also becomes easier.

So I guess I agree with you that for the very common programming task of "Thinking about the problem" tight language integration doesn't help much. But in order for me to gather data points about the problem, I usually have to jump in and explore the code base, which is where I feel the advantage comes from.

> I've found for Nim and Crystal I have to run the compiler in the terminal, look where the errors were, and then find those lines in my editor.

Definitely setup your editor to run the compiler for you, and give you a list of errors that are links to the locations they occur.

In Vim, for example, you can configure the makeprg and errorformat variables and the use the :make command to run the compiler, which populates the quickfix list with the errors. From the quickfix list you can jump directly to the locations. In Emacs there is the M-x compile command with very similar functionality.

Reply on news.ycombinator.com