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.
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."
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?
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.
> 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.
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.
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".
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.
> 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.
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!
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.
"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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
I've been banned from HN plenty of times before. It hasn't stopped me in years past and it won't now.
Anytime you try and suppress a rebuttal with "I know you're about to say..." it's basically a cop-out. I won't bother giving you a detailed response that you'll respond with something like "Yeah but your language was inflammatory"
If a guy doesn't 'agree' with what I've spent years studying as if his opinion somehow trumps the facts and research, that's fine. I hold the opinion that it's within my rights to break him down over it.
I don't get to be anything. I haven't attacked anyone in this thread yet, I've only used my words, and like I mentioned, I've been banned off probably a dozen other accounts here on HN, but it won't prevent me from coming back and making sure that my voice is heard.
Maybe political correctness isn't the right word, but the concept behind the phrase is exactly what it's about. Suppression of things offensive is a specialty of HN, demonstrable by many banned accounts and hidden conversations.
What you can't undo though is that a few people read what I had to say. I know that shadowbanning and the like goes on, and it doesn't really make a difference as long as a few people here and there see that stuff before it disappears.
60 comments
[ 2.7 ms ] story [ 113 ms ] threadA: 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!
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.
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?
In the case of a host language, any integration beyond the most simple with the host is going to require implementation specific code.
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.
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.
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.
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.
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".
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.
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.
On the other hand, Clojure runs on a platform that is supposedly implementable anywhere.
https://github.com/takeoutweight/clojure-scheme
"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.
https://github.com/MichaelDrogalis/dire
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.
[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.
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.
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.
So, it is not surprising that Clojure lacks continuations.
McCarthy, Steele, Gabriel, Fahlman, Weinreb, Moon, Stallman, Bobrow, Greenblatt, Moses, Norvig, Sussman, Brooks, Masinter, Pitman, White, ...
The all have been working on useful Lisps...
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.
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.
https://news.ycombinator.com/newsguidelines.html
And what's with the slide of an African American woman wearing a fast-food uniform, captioned "I know some of these words"
Is this presentation a representative example from the Clojure community?
No thanks.
That person is Kell Mitchell from 1997's Good Burger. He is now a man, but a boy at the time of the filming.
http://www.imdb.com/title/tt0119215/
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.
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
Would you like to see my papers?
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.
Anytime you try and suppress a rebuttal with "I know you're about to say..." it's basically a cop-out. I won't bother giving you a detailed response that you'll respond with something like "Yeah but your language was inflammatory"
If a guy doesn't 'agree' with what I've spent years studying as if his opinion somehow trumps the facts and research, that's fine. I hold the opinion that it's within my rights to break him down over it.
I don't get to be anything. I haven't attacked anyone in this thread yet, I've only used my words, and like I mentioned, I've been banned off probably a dozen other accounts here on HN, but it won't prevent me from coming back and making sure that my voice is heard.
Maybe political correctness isn't the right word, but the concept behind the phrase is exactly what it's about. Suppression of things offensive is a specialty of HN, demonstrable by many banned accounts and hidden conversations.
What you can't undo though is that a few people read what I had to say. I know that shadowbanning and the like goes on, and it doesn't really make a difference as long as a few people here and there see that stuff before it disappears.