Fogus

There have been some fantastic conversations on Hacker News about type systems. I've learned a lot about the different arguments for dynamic typing, versus strict typing, versus gradual typing. Java's type system may or may not have represented new thinking when it was under development in the early 1990s, but it certainly seems a bit dated in the year 2016. The limits of the Java type system have been discussed both here on HackerNews and also elsewhere, many times.

For those who want to consider arguments against Java's style of strict typing, 2 things I would recommend include "Agility & Robustness: Clojure spec, by Stuart Halloway":

https://www.youtube.com/watch?v=VNTQ-M_uSo8

He offers a chart that shows the strengths and weaknesses of strict typing versus unit tests versus the run-time checks offered by Spec. It's worth a look.

The discussions around gradual typing have been interesting, but to see how far the limits of this can be pushed, I would suggest everyone check out the Qi/Shen programming language:

https://en.wikipedia.org/wiki/Qi_(programming_language)

"Qi makes use of the logical notation of sequent calculus to define types. This type notation, under Qi’s interpretation, is actually a Turing complete language in its own right. This notation allows Qi to assign extensible type systems to Common Lisp libraries and is thought of as an extremely powerful feature of the language."

This next quote is from someone who has spent a long time experimenting with…

I agree that Clojure is continuing to rapidly gain mind share – among long-time Lispers, relative newcomers to programming, and also seasoned "curly bracers" that a few years ago never thought they'd see a day when Lisp would make it into mainstream dev shops. Personally, I like it a lot and use it on a daily basis. The excitement around it is in no small part due to the insightfulness and ongoing hard work of Rich Hickey[1], his close collaborators at Cognitect[2], and some amazingly dedicated community talent (e.g. Philip Hagelberg[3]). Not to be overlooked is the brilliant decision to have it be a "hosted language" that interoperates with non-Clojure code on the JVM with little to no hassle – that opens a lot of doors, better believe it!

That being said, I attended RacketCon 2014[4] last Saturday and was blown away by the work going on in that community. Michael Fogus[5], a well-known name in the Clojure community, even gave the keynote[6]. The language's creator, Prof. Matthias Felleisen[7], and his grad students have been doing truly cutting-edge work over the last 18+ years (what became Racket was "conceived" at Rice University in Fall 1995). It's a fair question, though, whether the Racket team even wants the language to "make it big," i.e. along the lines of Clojure's rapid rise in popularity. I got the impression they have mixed feelings about that prospect, and those concerns have certainly shaped (and will shape) their marketing of Racket.

My thought is that if,…

I love Clojure, and I use it in every project where I have control over the technology, but I do agree with the points raised by Ashton Kemerling.

Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined. In some sense, you could say this is what happened to Ruby, though there the allowance of "special cases" was more deliberate. I recall, back in 2003, reading the interview between Matsumoto and Bill Venners: http://www.artima.com/intv/ruby.html -- and I thought that Ruby had a beautiful philosophy. But having worked with Ruby for many years, I now see how much it is undermined by the many special cases it allows, and the wild ambushes that its most imaginative features allow (monkey patching).

I don't want to see Clojure go down that path. I want Clojure to remain beautiful, and that means the implementations must also be beautiful. There is a limit on how much the core team can say "That bug is only an implementation detail". If you take away all the implementation details, then Clojure is only a theory, not a real technology that can be used by real people to do real things.

In a truly ideal world, Clojure could be the practical Lisp that pushes itself to bring in as much of the experimental Lisp's beauty as is practical. I would love to see the best ideas from Racket and what Fogus refers to as the Fluchtpunkt…

Ah, thanks for all that, and I will try the new version of gambit. I don't remember for certain whether the looping I encountered was with the old version. It will be cool if Ribbit can become completely self-hosting.

I do know there have been some web sites (including I think HN) written in Scheme, that originally used continuations as sessions, but ended up switching away from that approach once things got more complicated. It's a cool idea though.

Ribbit reminds me of this article mentioning "Fluchtpunkt Lisps", in case you're not familiar with it: http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/

I guess it is an example of one.

Ribbit seems more interesting to me than Sectorlisp because of the issues you mention! I'll keep playing with it. Even if I don't find direct uses for it, its implementation methods are worthy of study.

I've been wanting for a while to make a Hedgehog Lisp back end for Purescript (purescript.org). Ribbit might be another interesting target.

Added: I think the Ribbit REPL needs some kind of exception trap. Otherwise saying something like (3) crashes the whole interpreter, which is not so great for an interactive environment.

Hedgehog has built-in functional AVL trees that substitute for hash tables, arrays, and other lookup structures. They are very useful, but are an example of functional style possibly requiring more ram than imperative style where you can mutate stuff.

tl;dr - you don't need to care, you can do perfectly well without it, but you're missing something.

Longer answer ...

There are several issues here, and many people conflate them. They are realted, and I'm not going to be able to do them justice in a quick reply here. It's Christmas Eve, and I have a lot to do.

So, briefly ...

Learning FP, really learning it, gives you a new insight into programming. It can change the way you work, and the way you think. If nothing else, it's mind expanding, and that's always a good thing.

There's a seminal paper "Why Functional Programming Matters"[0] (WFPM). It dates back to 1984, but it's still relevant. In fact it's so relevant that raganwald[1] wrote "Why Why Functional Programming Matters Matters." That's also a really good read, with many useful insights.

fogus[2] has included WFPM in his list of 10 technical papers every programmer should read twice.[3] There's also a StackOverflow discussion[4], probably several.

There are many, many programmers out there, capable, productive, useful programmers getting stuff done, but knowing nothing (significant) about FP. And that's fine. But personally, I think that if you want to be serious about your craft, you should learn about FP, what it is, what it's good for, how to think in it, when to use it, and when to avoid it. It's not the One True Style(tm), but it is

[0] http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

[1]…

I love Fogus's take on 100:10:1. As opposed to this highly linear ever-winnowing flow, Fogus uses 100:10:1 as a way to keep a list of spitballed ideas, a list of things he might want to work on that all have sincere promise, and one thing picked to focus on. Instead of being process driven, focusing on getting one thing done well, Fogus lets himself switch among his 10 picked items. The 10 is a way to swap out when interest wanes. 100:10:1, my approach to open source-
http://blog.fogus.me/2015/11/04/the-100101-method-my-approach-to-open-source/

This process speaks to me a ton (a whole lot more than Nick's rigorous phased development process). When my attention and care for an interesting, creative project wanes, I can either dig in my heels and try to make myself code, or preferably I can switch to some other promising piece of development. Having a deck of other ideas decreases the context switch time- when a project is in a lul, there's already other great gems prepped, and one of them can re-inspire me.

Quite the contrast. I wonder how much of it is due to Fogus's focus on developing open source software, versus Nick' focus working on physical board games.