Hacker News Reader

Comment by rusabd | Hacker News Reader

I have worked on fairly large Common Lisp project (around 500k lines of actively managed code). That was the most pleasant experience in my professional life. The refactoring was easy, introduction of new features was simple and clear. I attribute it partially to language itself and partially to the team culture. We had a lot of tests BTW. After this I had quite bad experience with a Clojure project in a different company, so I am not dogmatic about lisp supremacy anymore. Still, Common Lisp definitely can be extremely successful in production given proper environment.

View on HN

I’ve been programming lisp for a few years now (Scheme then CL) and write Clojure daily for my current job. I initially described Clojure as: the worst dialect of lisp I’ve used, but the only one I’ve been paid to write in. It’s grown a lot on me over the past few months, but I still end up missing CL every now and then at work (I think I mainly like CL’s Slime more than Clojure’s Cider).

What were some unsettling points about the Clojure project you worked on? One thing I’ve noticed is that since Clojure is a relatively new language, a lot of newer lispers will start off with it, and I imagine that companies are more likely to try Clojure than CL as a first lisp. Consequently, the Clojure code you run into on the job may be of lower quality.

Laziness is quite dangerous given existence of side effects in Clojure - this would the most common error for new developers. I missed LOOP even it has a bad reputation - nevertheless it covers almost all useful cases in practice. We were misusing AOT compilation, the behavior of that code was surprising sometimes.

But the main failure in my opinion was absence of good development patterns which leverage strengths of the language and mitigate weaknesses. Dynamic languages such as lisp absolutely need REPL as primary development mode, conventions has to be strictly enforced and consistency is much more important than in languages with rich static typing. Clojure can be and is successful in many projects. But if your team is trying write Java with parenthesis everything is hard.

Second that. I did write production Common Lisp code and loved it. I've used various languages over the years, including Perl, C, C++, C#, JavaScript and Python (and Pascal, Basic and x86 assembly to some degree, too), and I mostly write Go code nowadays (Kubernetes-related stuff). Still, none of these languages or their environments matched the Common Lisp coding experience with plain Emacs and SLIME.

> given proper environment.

I think a lot of languages will give a pleasant experience in a proper environment. The question then becomes, does a strict language like Haskell require less of a 'proper' environment?

That would be interesting to research -- though the amount of variables (team member's experience, team culture & hierarchy, company culture, financial interests, deadlines, project size, software development process, etc. etc.) would probably be hard to account for. All of them can have a very big impact on how software gets written.

I would gladly work on large scale Haskell project and make a fair comparison! I managed to write my code in Java like Haskell (using FunctionalJava) and it was very successful, so there is a big potential for Haskell in more traditional shops.

Thanks for the link to Functional Java, I had not seen it before. I added Functional Java to my programming notes for Java resources - might use it sometime when doing a Java project.

Could you describe your setup / workflow ?

Typing from my phone, so just keywords. Emacs, SLIME, single repo, pair programming, monolith applications, mercurial, PostgreSQL.

Most influential was pair programming which I personally hated but had to admit it works.

thanks a lot

Reply on news.ycombinator.com