Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure: A Lisp that wants to spread

simongray.github.io

Post reply on HN
Print view View original

51–60 of 306 posts

Re: Clojure: A Lisp that wants to spread

#51

Post by slifin »

rubyn00bie wrote: post #32

Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph: > The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and…

A lot of Clojure libraries will be described as Clojure(Script) libraries which means they run on both Java and JS usually with no interface changes here are some examples: https://github.com/tonsky/datascript https://github.com/Engelberg/instaparse https://github.com/wilkerlucio/pathom

Interop with hosts is a core feature of the language so it feels natural to reach for it when you need it and it's easy to write code that handles multiple runtimes but 95% of the time maybe more you don't need explicit runtime features

Re: Clojure: A Lisp that wants to spread

#52

Post by codr7 »

ska wrote: post #25
lgessler wrote: post #16

Earlier quoted context omitted.

My personal take: CL is a multi-paradigm rummage bin that demonstrated to the world the greatness of many features (e.g. macros, CLOS), but is also beset by many design flaws--some due to genuine infelicity of conception, and some due to unavoidable limitations of software and hardware at the time. (For one thing, there are approximately 101 ways to test equality). The result is that you could be a career CL programm…

I'm not sure you've picked the right example here - far from being a gnarly wart, differences types of equality are a fundamental issue. Your language can choose to either a) hide it effectively (constraining some things) b) expose it to the user which means they have to think about it or c) try (a) but leak and give weird corner cases. It's not obvious that (a) is superior to (b), an (c) is often what you get.

I've had a lot of success in my own language designs with dividing the problem into two cases, equality and identity, or EQUALP and EQ in CL lingo. Despite having written a ton of CL over the years, I still fail to remember the specifics of EQL & EQUAL. Defaulting to full value equality does come with a performance cost, but I feel like we're mostly past the point where we should waste precious time on these kinds of micro optimizations for most use cases.

https://github.com/codr7/gfoo

Re: Clojure: A Lisp that wants to spread

#53

Post by vga805 »

slifin wrote: post #48
slifin wrote: post #47

Earlier quoted context omitted.

If all you want is a rails thing but with a Clojure twist I'd keep an eye on https://youtu.be/jkx9F-RIFiY I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting th…

The normal one true way for most commercial companies right now is reframe, there's a nice ecosystem there and it's teachable

reframe is just the front end though isnt it? i think this is not the crud/rails alternative the op is talking about

Re: Clojure: A Lisp that wants to spread

#54

Post by 7thaccount »

pron wrote: post #18

Can we please stop using the verb transpile? Compile is fine, thank you. When it was used only for certain kinds of "shallow" compilation it was bad enough (and it was really horrible even then), but this article uses it when describing compilation with whole-program analysis and optimization and machine code as the target.

There's absolutely nothing wrong with transpile. Yes compiler covers all sorts of things (code -> assembly or code -> different language code...etc). However when I hear "transpile" I immediately think of a language going to another language like when Nim gets converted to C or JavaScript or when Clojure gets converted to Java first. It is a specific form of compilation right?

Re: Clojure: A Lisp that wants to spread

#55

Post by codr7 »

armitron wrote: post #22
gentleman11 wrote: post #8

Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?

Many lisp fans do in fact use Common Lisp. Freenode #lisp, the term Lisp, Reddit lisp all primarily refer to and are about Common Lisp. Additionally, there are many Lisp old timers that do not consider Clojure a Lisp.

I'm curious, what features are missing that stops Clojure from being considered a proper Lisp?

From my brief experience it can do most of the same things except reader macros.

Re: Clojure: A Lisp that wants to spread

#56

Post by hcarvalhoalves »

gentleman11 wrote: post #8

Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?

I don’t think being a lisp is the primary reason for using Clojure, but it’s the added bonus of being a lisp designed for FP, concurrency, and host VM integration.

Re: Clojure: A Lisp that wants to spread

#57

Post by vemv »

My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic.

At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time?

I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so.

Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make.

That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there.

I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.

Re: Clojure: A Lisp that wants to spread

#58

Post by simongray »

codr7 wrote: post #55
armitron wrote: post #22

Earlier quoted context omitted.

Many lisp fans do in fact use Common Lisp. Freenode #lisp, the term Lisp, Reddit lisp all primarily refer to and are about Common Lisp. Additionally, there are many Lisp old timers that do not consider Clojure a Lisp.

I'm curious, what features are missing that stops Clojure from being considered a proper Lisp? From my brief experience it can do most of the same things except reader macros.

The common talking points are

* Clojure is based on seqs rather than cons cells.

* Clojure renamed certain common functions, like car and cdr, so 30 year old Lisp example code no longer compiles.

* Clojure doesn't have implicit tail call optimisation for recursion.

* Clojure reveals its host platform when it has runtime errors.

Re: Clojure: A Lisp that wants to spread

#59

Post by inferiorhuman »

tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it.

The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback hell.

Ultimately rust (and go to some extent) seemed to fit my use cases better.

If I had to do a web app from scratch I would think long and hard about going Clojure if only because it leverages such a widely used VM. Points 1 & 2 weren't issues for me, but #3 was (and there are similar problems with Elixir).

Re: Clojure: A Lisp that wants to spread

#60

Post by ska »

codr7 wrote: post #52
ska wrote: post #25

Earlier quoted context omitted.

I'm not sure you've picked the right example here - far from being a gnarly wart, differences types of equality are a fundamental issue. Your language can choose to either a) hide it effectively (constraining some things) b) expose it to the user which means they have to think about it or c) try (a) but leak and give weird corner cases. It's not obvious that (a) is superior to (b), an (c) is often what you get.

I've had a lot of success in my own language designs with dividing the problem into two cases, equality and identity, or EQUALP and EQ in CL lingo. Despite having written a ton of CL over the years, I still fail to remember the specifics of EQL & EQUAL. Defaulting to full value equality does come with a performance cost, but I feel like we're mostly past the point where we should waste precious time on these kinds of…

I agree at least separating identity and equality seem to be important in practice. I'm not completely sold on where the other lines should be.

I don't love the CL implementation, particular eql vs equalp on numerics seems fiddly, and it's hard to keep all the cases separate. Homoiconicity introduces the need for a "representation equality" i guess which isn't always needed, etc.

Post reply on HN