Hacker News Reader

Comment by too_late | Hacker News Reader

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!

View on HN

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!

Reply on news.ycombinator.com