Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

tooling for functional languages

Name: Anonymous 2019-01-16 8:13

one of the advantages of functional languages, especially typefaggy ones, is that it makes program analysis, proving shit and finding bugs at compile-time easier. this is all fine and good but why is there almost no tooling that takes advantage of it? IDEs and debuggers are years behind mainstream shit like Java, and that's even without getting into proprietary IDEs and code-reading tools for C or Lisp.

inb4 you don't need tools because the language itself, REPL and compiler are enough. not only is it bullshit because tracing the exectuion of even a mildly complex program is difficult regardless of the language (as it's the algorithm itself that is complex), it's also bullshit because compilers for dead dog and dead camel tend to spew out cryptic, overly-abstract messages that aren't trivial to connect with concrete bugs. IDE and debugger that understand your're are code are a big win for any practical programming task

Name: Anonymous 2019-01-17 7:37

>>3
emacs mode is a bare minimum when it comes to tooling, not comparable by itself with a good modern IDE, unless it's something like SLIME. but most emacs modes are not SLIME. a good example of an IDE for a functional langs would be Visual Studio for F#, and if we step outside of the typefaggy stuff: Dr. Racekt for Racket and LightTable for Clojure (if it wasn't abandoned).

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List