Clojure all the way down | Hacker News Reader

Clojure all the way down

bucharestfp.ro

86 pointsmariuz52 comments

What a terrible title. Lisp has been useful for a long time, and it's annoying to see so many Clojure programmers pretend that it's the revolutionary, useful Lisp we've all been waiting for.

I'll stick with Guile Scheme, which has tail call semantics, first-class continuations (both regular and delimited varieties), and other things that are absent from Clojure.

I wish Clojure had those features, too. But I don't miss reader macros for all the reasons that Clojure doesn't implement them, though you don't have to use them where they do exist.

In my experience, though, the lack of full TCO in Clojure actually makes people write more readable code in many cases (because you can only recur from a tail position in Clojure, you always know where to look).

On the other hand, does Scheme have STM? Agents? Refs? I'd miss those.

Aren't Refs STM? I haven't seen any clojure project use or leverage Refs, do you know of any? The feeling I get from community is that they are nice in theory but not so in practice.

The VM is the limit. Clojure appears to be a bunch of very nice syntactic sugar on top of that. But the VM will preclude tail call optimization, which will severely restrict you at the sugar layer.

It seems continuations are incompatible with try-catch-finalize (the finalize keyword), and with the unwind-protect special operator, used to make the with-* macros.

So, it is not surprising that Clojure lacks continuations.

Seems like a trollish title, considering people were building stuff in other Lisps for decades and still do.

Also (note that I only went through the slides), it seems like he misunderstands what "All the way down" traditionally means in the context of Lisp. Clojure is different than the lisp variants that embrace this philosophy BECAUSE it's implemented on top of the JVM/CLR. You have access to the core Clojure implemented parts of the language, but you eventually hit a boundary where you explicitly cannot go further -- precisely where the Java part starts.

I guess you could argue that most Schemes / Lisps have a similar boundary, but from using both it feels different in Clojure.

In short, I think you run out of turtles to jump down onto at a certain point in Clojure.

Clojurescript is the more "all the way down" of the two. It managed to self-host a few months ago so in theory you could write a backend and cross compile to your computing platform of choice. I know of a number of alternative targets but they all predate the self-hosting and none are actively maintained:

[1] https://github.com/takeoutweight/clojure-scheme [2] https://github.com/raph-amiard/clojurescript-lua

I think it'd be a fun project to get cljs-lua working and build a system for developing OpenResty apps but it's so low on my priority list I don't anticipate ever making it happen.

Has anyone tried to get a Clojure-in-Clojure on the JVM working? Similar to PyPy or something of that ilk... I think even Shen (or even some branch of arc, I believe) would be more along those lines?

I've heard people talk about it but I'm not aware of anybody actually trying it. I know that Rich has stated a number of times that he's not interested in working on Clojure-in-Clojure.

Yep. I am sure Paul Graham found Common Lisp "useful".

And most people only saw the tip of the iceberg. Lisp was the substrate on which many paradigm grew, prolog, ml, st.

The title of this talk is an act of friendly fire.

Considering Clojure would work better in SBCL I think that says a little something about Clojure and a little something about CL. Macros in ParenScript make Clojurescript seem like a bad rails library.

Care to elaborate?

http://c2.com/cgi/wiki?CommonLispConditionSystem

"When an exception is thrown in Java, the stack unwinds meaning all state in stack frames from the point of the throw to the handler gets thrown out."

"In Common Lisp, the stack does not unwind and high level logic can simply restart the computation (after fixing the error or trying different strategies) without losing any intermediate state. This killer feature is what makes interactive debugging possible."

Not enforcing a functional paradigm also makes prototyping easier.

Thanks! That's completely new to me. You got me looking into Dire, which looks like a similar pattern for error handling.

https://github.com/MichaelDrogalis/dire

Here is (imho) a good test to see if a language is sufficiently capable and worth considering for bigger projects: try to implement a memoization library in the language. By memoization library I mean a library that enables you to cache function calls. So calling f(x) twice with the same f and the same x should not trigger recomputation the second time. It is also a good way to quickly get to know the intricacies of the language.

So the early versions of javascript were great for you?

Well, Clojure has a memoize function built in.

That is considered cheating :) In that case, the requirement can be extended to storing the memoization cache on disk. Bonus points for using a mmapped file, for fast access after the program is restarted from scratch.

All: We took the trollish bit out of the title. Please let's focus on the rest of the content now.

Wasn't there a way to endorse flagged stories?

Yes, if they're dead.

Says the dwarf standing on the shoulder of giants:

McCarthy, Steele, Gabriel, Fahlman, Weinreb, Moon, Stallman, Bobrow, Greenblatt, Moses, Norvig, Sussman, Brooks, Masinter, Pitman, White, ...

The all have been working on useful Lisps...

You forgot Graham, the man who wrote the website (in Lisp!) that this article is posted on.

I'm not exactly the strongest advocate of political correctness, but the "documentation" slide is somewhat racist and offensive.

Q: Is Clojure bootstrapped on something other than JS or JVM or CLR?

A: No, and don't waste your time on this talk if you already have watched any of Rich Hickey's talks, this is an ego-stroke at best that introduces no new solutions to any problems. It's an hour and a half of 'Hey look what clojure can do', and 'Gee, our documentation isn't great'.

Maybe someday Clojure will have something like the Shen project has with KLambda. A tight, core language implementable in any language, and a language library built on top of that core language, agnostic of the implementation it's derived on.

If Clojure had gone this route, we could basically have Clojure on any platform capable of parsing and modifying S-Expressions.

Maybe someday!

Actually, from someone who has been writing Clojure for a living for the past 5 years or so: I'm very glad Clojure did not take that route.

The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.

It is because of the fact that Clojure and ClojureScript are not really exactly the same language, and are implemented in very different ways from each other, that we can take advantage of many platform-specific features that would otherwise be abstracted.

> The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.

If you can't implement C on a platform, I think you're in some pretty strange territory and you're probably having to invent your own language to match the platform.

You couldn't have given a better example. C as a language doesn't have a standard library, with the standard library being Win32, or whatever comes on POSIX/Unix systems these days. You even get a different libc on Android, which isn't glibc, so with its own quirks and bugs. Win32 doesn't do fork and I/O is very different. And on embedded systems you're going to work with a C subset. And each compiler has special extensions.

In other words what you call C is actually very different from platform to platform, people solving that with a crap load of ifdef statements.

No, what I call C is the same on every platform. Otherwise, all those "crap load of ifdef statements" wouldn't work. What is called the C standard library on each platform is different, because as you said C itself does not define a standard library. So yes, I did pick my example very appropriately.

What if the platforms are the JVM and Javascript, and you are chosing those platforms because of their extensive infrastructure and libraries?

It is possible to implement C faithfully on these platforms, including all of C's weirdness like pointer-arithmetic and unsafe casting. But you'd end up with something that departs far from the platform's runtime model and calling conventions.

> It is possible to implement C faithfully on these platforms, including all of C's weirdness like pointer-arithmetic and unsafe casting.

Of course it can. The two platforms you listed can both faithfully emulate an entire computer, upon which you can build your C runtime.

http://bellard.org/jslinux/

http://bellard.org/jslinux/tech.html

Now, if what you really meant was more along the lines of "can I faithfully cross-compile C to Java bytecode", the answer would be "not without a layer of abstraction".

"The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't."

Can you elaborate? Shouldn't VM just standardize EVERYTHING on the language level? Can you give specific examples when language NEED to be aware of the hardware?

Not the parent;

You always need to be aware of the hardware/target-platform. Some examples:

1. Bioinformatics 2. Data storage 3. Any soft real-time application 4. Any kind of constraint search with simulated annealing through large spaces 5. Operating systems 6. Compilers 7. Image recognition/analysis 8. Rendering 9. Basically any application where the user expects a responsive result

You ignore performance at your peril. The reason why we have super-fast computers and software with loading screens is because of this thinking.

If you do have a legitimate reason to run on a VM you should be aware of the burden its abstractions places on your ability to reason about the performance and costs your program will incur.

Sure, you can standardize everything. Just get the most common denominator of all your supported platforms and abstract that away. Problem is, it won't be useful for anything practical.

Someone mentioned C, and it's a good example. C is different on every platform. If your C code interacts with the world in any way, you won't write the same code. Libraries will be totally different, not to mention that pointer sizes are different, byte ordering is different, and even your lowly int might betray you. The reason why C is so practical and widely used is exactly because it doesn't try to force a platform abstraction on you.

This isn't talking about hardware, it is talking about host language.

In the case of a host language, any integration beyond the most simple with the host is going to require implementation specific code.

> The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.

True, but some people push the limit of what you can do much farther than others. Take a look at what the ceylon team is doing, to see what you can do if you plan for it from the beginning.

> The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed.

On the other hand, Clojure runs on a platform that is supposedly implementable anywhere.

I believe I heard something about Clojure on scheme.

https://github.com/takeoutweight/clojure-scheme

I haven't worked with it too much, but being on the JVM is one of the things I like about Clojure. The JVM has a huge standard library, but I don't really like Java so Clojure gives me a way to use all that existing code in a language I enjoy writing. There are definitely some downsides to the canonical implementation being on the JVM, but any move away from that is going to end up "wasting" a lot of effort reimplementing all of that library and I just don't see it being worth it, at least at this point.

I'm excited about the ClojureScript-in-ClojureScript work - apparently it will soon be true that you can run ClojureScript on top of any JavaScript environment, including node. That's very close to Clojure on anything!

You are the type of person I was hoping not to encounter!

The kool-aid drinkers.

I don't like Clojure or ClojureScript. They are both awful by virtue of the platform they exist on. I would like very much if Clojure had a core lisp KLambda, because I could abstract Clojure onto a platform that wasn't terrible.

Rich is a guy who (whether consciously or otherwise) hated writing Java and decided that functional programming worked, and that Lisp did too. Clojure is a strange abomination from the points of view of those in the pure-functional family, and those from the paren-dimension, but I find that Clojure code reads easily, and comes off far more expressive than that of Python or Ruby or other so-called expressive languages.

When someone who uses the JVM tells me that something I know to be true is 'fundamentally flawed' I become fearful for myself, that I might drown in irony.

> You are the type of person I was hoping not to encounter!

Personal attacks are not allowed on Hacker News. I'm sure you can express your thoughts about programming languages without them.

https://news.ycombinator.com/newsguidelines.html

I'm sure you can mind my own business for me, maybe I should even let you write my next comment?

Would you like to see my papers?

Let me try this again. There are rules here, and we ban accounts that break them. Please read them, and post civilly and substantively or not at all.

https://news.ycombinator.com/newsguidelines.html

To anticipate the objection, no, this hasn't a fig to do with political correctness. It's about trying to preserve HN as a place where people want to come for substantive discussion. I'm sure many of us agree with your views on Lisp; that doesn't mean you get to be an arsonist.

We detached this subthread from https://news.ycombinator.com/item?id=10432280 and marked it off-topic.

....................

This entire thread of backstabbing selfishness is why Lisp and Lisp people never accomplished anything.

Go lock yourselves in your own personal Orthancs weaving unreadable code and leave the rest of the world alone.

This comment breaks the HN guidelines. Please post civilly and substantively, or not at all.

https://news.ycombinator.com/newsguidelines.html

Quite frankly, the only reason this is a point of contention is because the author named their talk "Finally a useful Lisp".

If they had just said "A new awesome Lisp" or something, they wouldn't be getting so much hate.

Personally, I think Clojure is great. I like Common Lisp better. I also use Emacs Lisp and play around in Racket Scheme.

It's when people try to say that their Lisp is the only useful one that us lispers get pissed off.

Reply on news.ycombinator.com