3 ms·
Since there are a lot of questions regarding language choice for functional languages here, I think I'd be good to share my experience here. I've learned from
by adjkant 8y ago
Since there are a lot of questions regarding language choice for functional languages here, I think I'd be good to share my experience here.
I've learned from the ground up (since college) in a functional style through HtDP [1] and have used Racket (not just the teaching languages) and OCaml a good deal at this point. Some notes on my experiences with functional languages:
OCaml
The Good:
- Incredibly powerful data matching/construction
- Typing gives good runtime guarantees
The Bad:
- The actual type checking messages from the compiler aren't very fun to wrangle with
- Parens being optional but then sometimes being needed for data constructions adds to confusion along with types
- There are a lot of other quirks that I only see occasionally but pull me out of ever thinking "this is the language I want to code in mainly". Things like being required to define mutually recursive functions in the same define clause, chained together with "and". The ambiguity of the need for semicolons, similar to parens. I won't detail them all here, but the quirks sum to something just large enough to be quite annoying to use.
Summary:
It can be beautiful to work with until it snaps you right out of it. At this point I'm not thrilled to work in it, but I'm not mad either and will probably see the day I write more of it.
Racket
The Good:
- For me, the most readable. I'm not sure if this is a reflection of learning it first, but there's something so clean about it. While you can always drop into the more complex, the core basics read very well.
- Incredibly powerful macros. They are much more syntactically complex and resources for learning the ins and outs are hard to find, but once you get them, the world is your oyster.
The Bad:
For whatever reason, all of the practical packages you want simply don't exist yet, or if they do, break the cleanness bare Racket gives you in ways you probably shiver looking at. It's my only real negative, but the implication basically is that for any serious project, unless I want to write the tooling I want myself from the ground up, it's basically not an option.
What really sucks about this the most to me is that of all the languages, writing good libraries for Racket is the easiest given the powerful macro tooling. All the bare bones are there, they just need to be composed together ands abstracted the right amount while keeping the simplicity that makes Racket beautiful. When said aloud, it's a big ask. But IMO Python has done so well accomplishing this with things like requests, flask, etc - what's stopping Racket?
Oh, and the IDE (DrRacket), while deceptively powerful, still needs a competitor badly. I'd love to see a Jetbrains IDE for Racket, though of course I know that's not happening anytime soon.
Summary:
I wish I could write everything in it, but the tooling and IDE just aren't there. Currently my focus is actually now on that tooling itself [2].
Functional languages I've looked at but have not written anything serious in:
Haskell: I get the appeal from a theory perspective, but the readability for me is absolutely terrible. Things are more verbose where they shouldn't be and too terse in the reverse. I haven't spent enough time to comment any further, but that alone was enough to steer me to explore other functional language options.
Clojure: The community seems great and I am excited it's gaining traction (and building out that tooling that Racket is sorely missing), but I wonder why these two have to be separated from each other. At the core of the language, it seems to me on cursory glance that clojure's syntax is just ever so slightly worse than Rackets, though less annoying than the quirks of OCaml. I can't help but wonder what would be if the clojure community instead wrote tooling for Racket (and some do!). For everyone involved closely with Clojure, I'd love to hear more about why it needed its own language. I know being on the JVM was big, but beyond that I'm pretty fuzzy.
Functional Programming in general:
While there are cases where imperative and object oriented programming make sense, I truly wish a day comes where the word mutation is taboo, imperative style is used sparingly when needed, and code readability and library design is valued above all else in industry. And there are good developments with things like Clojure, Redux, and the big languages embracing functional style more. Still, the difference of how I program in each style is truly incredible, and while my code is objectively better in the functional style, I currently rarely get to use it for projects, professional or personal.
To anyone who hasn't tried functional programming, I couldn't recommend it enough. HtDP or this book both seem like good places to start.
[1] https://www.htdp.org/2019-02-24/index.html https://www.htdp.org/2019-02-24/index.html
[2] In an attempt to improve the tooling to Racket itself, I am working on two libraries: A web framework and a basic ORM for structures. Both are in highly unstable condition at the moment so it is not recommended to try and contribute to them at this point, but I am targeting May to have stable 1.0 releases. hopefully expect to see a Show HN :) They are loosely inspired by Flask / SQLAlchemy, meant to address similar things in Racket. Links at [3] and [4]
[3] https://github.com/adjkant/web-sourcery https://github.com/adjkant/web-sourcery
[4] https://github.com/adjkant/sql-sourcery https://github.com/adjkant/sql-sourcery
[5] Syntax Example for [3] and [4] together: https://github.com/adjkant/web-sourcery/blob/master/examples/0-0-1-example.rkt https://github.com/adjkant/web-sourcery/blob/master/examples...
- ernst_klim 8y ago>Things like being required to define mutually recursive functions in the same define clause, chained together with "and". This is not a quirk but a feature, just like rec keyword. It could be easily removed, but it's there for a reason, it makes code easy to reason about from the first glance.