Comment by kronos29296 | Hacker News Reader

Comment by kronos29296 | Hacker News Reader

Parent Full thread

Haskell is the pureset functional language. If you want to learn the principles behind the functional programming paradigm learn haskell but its hard. The effort is worth it. But there are situations where the performance is worse compared to other languages but it is the best place to learn FP.

If you are hacking on stuff or doing it as a hobby, learn Scheme. Something like Chicken Scheme is good. Small concise language but a great scarcity of libraries. If you want a pretty ide for scheme or write your own scheme use Racket.

If you want production code in lisp with good library support use Common Lisp. Clojure is better because of better functional programming features than CL but debugging requires knowledge of Java as it runs on a JVM but the plus is you can seamlessly call java libraries which are numerous (more than what is in CL).

OCaml is functional programming with Objects. It it used where there is a need for performance like compilers with the advantage of a functional paradigm. But OCaml is a pain to work with for any Non Unix systems. F# is functional programming for dotNet. Then there is Scala which runs on JVM like Clojure and so has the same pros and cons except Scala is closer to OCaml and Haskell than to Lisp.(ML family)

Depending on your platform make your choice. OCaml is horrible for Windows. Haskell works. Scala and Clojure just need java so platform makes no difference. Schemes mostly have an interpreter for most platforms. Make your choice.

> Clojure is better because of better functional programming features than CL

CL now has [shameless plug] an excellent functional collections library, FSet [0]. Using FSet greatly expands the range of algorithms that can easily be written in a functional style. It's been a while since I looked at Clojure, but my impression is that FSet has a substantially richer API, including a bag (multiset) type and many more operations.

I don't know exactly which Clojure features you have in mind, but I suspect that FSet makes CL at least as good for functional programming as Clojure.

[0] https://github.com/slburson/fset

You seem to be the author (of FSet), is that right?

It's an interesting coincidence - just yesterday I learned about FSet while searching for something else and thought it's interesting. However, after arriving at https://common-lisp.net/project/fset/Site/Project.html and reading through the page I left it without installing.

For the very wrong reason, too: I just couldn't find the source code. Obviously, I didn't try very hard, but on the project page (which looks a bit too minimal, btw, some CSS wouldn't hurt) I didn't find a link to the repo. I think it would be great if you added it on top of the project page.

Okay, thanks for letting me know. I guess I should just move all the text to GitHub at this point.

Oh, I should have mentioned also, it's Quicklisp-loadable. Really, these days, whenever you're looking for the code for some library, Quicklisp is the first thing you should try.

Does Clojure predate FSet? If you hadn't written "now" here, I'd have guessed otherwise.

My only complaint about FSet would be map default values; not necessarily the fact they exist, but (1) when using defaults, that two maps can compare equal even though they have different defaults, and (2) when not using defaults, the way they nevertheless intrude upon the map-union protocol, necessitating handling of otherwise unused default values (usually NIL).

But I love FSet when using CL. Thank you for writing and publishing it!

I don't remember when I first released FSet. I did write it before Clojure showed up (2004-ish). Anyway, by "now" I just meant that FSet was a relatively recent arrival in the history of CL, not that it was necessarily newer than Clojure.

Agreed on both counts about map default values. I've been wanting to change how they work, but the change I have in mind would be incompatible. Here's what I'm thinking. Instead of every map (and seq) having a default, which defaults to NIL, we would distinguish maps with defaults from those without. Doing LOOKUP on a defaultless map at a key it has no mapping for would signal a condition (similarly for an out-of-bounds lookup on a defaultless seq). Then the defaultless versions could be used more conveniently with UNION (and COMPOSE, another place where I've tripped over this problem).

I was thinking that creating a map without supplying a default should give you a defaultless map, and that's how I wish I had done it from the beginning, but making it work that way now would break a lot of code. I could release it as a new major version (and call it "fset-2" in Quicklisp so people don't pull it down accidentally). Or, I could leave the existing constructor behavior unchanged and just add a new defaultless map (and seq) constructor. I think this is considerably less elegant, but it wouldn't break existing code. What do you think?

> What do you think?

I have no way of knowing how such changes would affect the wider installed base of FSet. All I can tell you is what I'd prefer myself.

I wouldn't mind, and actually prefer, if the default SEQ would signal a condition on out-of-bounds access (I'd also suspect that not a lot of existing code would break, but there's no way for me to know that.)

On the other hand, I don't think I'd get much besides having to rewrite code out of map lookups signaling a condition. I glossed over my uses of LOOKUP. For most lookups, the case of some element not being present in the map is normal behavior, expected and handled.

For a minority, an element not being present is an error, but for a majority of those, a specific error message is appropriate, so there'd still be explicit checking and no advantage from signaling within LOOKUP.

The smallest group of LOOKUPS expects the lookup to succeed without checking. In all of these cases, the lookup will succeed unless some code is buggy, and in all cases, a bogus NIL would be consumed immediately by a function that would signal a condition on getting a NIL.

So my personal favorite default kind of map would return (VALUES NIL NIL) for lookup failures but would not have a default for purposes of the MAP-UNION etc protocols.

An alternative (or additional) change that would work for me would be an additional optional function parameter to MAP-UNION and friends which, if present, would handle default values.

Don't forget Racket, it's a beautiful language and IMO pretty practical.

> If you want a pretty ide for scheme or write your own scheme use Racket.

Oops, somehow I overlooked that!

I'd argue that it's anything but practical. Great documentation, but discoverability is severely lacking.

Reply on news.ycombinator.com