Hacker Newsnew | comments | show | ask | jobs | submit | Mikera's comments login

Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language.

goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.

-----


What? No. You could not be more wrong. core.async does not support the first point in the least.

Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?

Clojure has this in Pulsar, which is a library...that happens to perform bytecode modification to support this (which I consider to be on the same level as special support from the underlying level). Pulsar is an absolutely amazing project and I'm not trying to take anything away from it with this comment, but merely trying to illustrate how far off you are.

-----


Silverline Mobile (http://silverline.mobi/) uses Clojure in production - managing data from sensors installed in the homes of senior citizens in Singapore.

-----


We're using Clojure in production at Datacraft (http://www.datacraft.sg).

Main usage is on the server side: for web applications, APIs and data analytics back ends.

-----


I'm actually trying to address this in my current language experiment: https://github.com/mikera/kiss

The idea: add static types to Clojure without compromising on the dynamism / flexibility / convenience

-----


IMHO Clojure's omission of reader macros is sensible: it prevents proliferation of custom syntax, which makes it harder for a human to read code and reason about reader behaviour. The Clojure reader also already has its own literal syntax for vectors and maps [] and {} (which eliminates the most common use cases for reader macros).

If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?

Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.

So Clojure rejects the former (unnecessary syntax sugar, potential for confusion, dubious value of reader proliferation) and accepts the latter (additional semantic power, proven utility). I personally think that's a good trade-off. YMMV of course.

Of course, there's nothing stopping you from implementing a custom reader in Clojure if you really want reader macros. So far, nobody (to my knowledge) seems to have cared enough to do this.

NOTE: I'm not bashing Common Lisp: just pointing out that language design has real trade-offs. For me, Clojure gets the majority of these design decisions right. For others, maybe reader macros are an essential feature and Clojure therefore doesn't work. No problem, use whatever works for you.

-----


The reader is first of all there to extend s-expression syntax to new datatypes - not for arbitrary syntax.

Btw., vectors are written as #(1 2 3) in Common Lisp.

Thus if I as a developer want to serialize my data structure to an s-expression, I can use reader macros.

New data type syntaxes does not make code much harder to read.

> If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?

Sure, Common Lisp has a standard reader. An extensible one.

> Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.

Custom control structures don't make the code harder to understand? Strange.

> For me, Clojure gets the majority of these design decisions right.

For me many of these Clojure design decisions look arbitrary and some I find just wrong. But that's just me.

-----


FWIW, I've been in the Clojure community for a few years and see almost zero FUD about Common Lisp. The atmosphere in the Clojure community is much more about pragmatism than zealotry.

Mostly, I see a healthy respect for other Lisps and a recognition that learning from traditions is a good way to build good things for the future.

-----


Being in the Clojure myself, I'd say the aforementioned "healthy respect" and "pragmatism" come from the fact that we all probably have migrated through at least a few languages before ending up at Clojure, which gives us a sense of perspective that keeps most of the zeal away.

-----


There's a pretty good argument that taking away features is what makes programming paradigms effective. You create restrictions (invariants, if you like) that enable the paradigm. Consider:

- Structured programming takes away GOTO - OOP takes away manual function pointer tables - FP takes away unrestricted mutation - Logic programming takes away explicit specification of execution order - etc.

None of this is about "forcing" you to do anything. It just appears that humans aren't very good at coding with unrestricted power over their machines, and it helps to simplify paradigms in a way that enables them to be effective at reading and writing higher level code.

If this wasn't the case we'd all still be programming in assembly.

Slightly tongue-in-cheek talk by Uncle Bob on the topic: - https://skillsmatter.com/skillscasts/2323-bobs-last-language

-----


One of the reasons that Clojure has so many libraries is that most things didn't have to be implemented from scratch.

Building Clojure on the JVM was a genius move by Rich Hickey - it meant that an advanced runtime platform (the JVM) and a huge ready-to-use library ecosystem was already there from day 1.

Backwards compatibility with Common Lisp was never a goal. The JVM ecosystem is bigger by far (and IMHO more valuable as a target).

-----


I don't think you can credibly describe Java/JVM as a small ecosystem.... there's nothing else remotely close in terms of the combination of runtime platform capabilities and the number of available open source libraries.

-----


I'm actually trying to prototype a language that gets you the best of both:

* Clojure style dynamic development * A Lisp (with proper macros, homoiconicity etc.) * Runs on JVM * Can use Clojure libraries unmodified * Static type system (similar to Typed Clojure, but as part of the compiler and driving real optimisations, not just as a separate static analysis tool)

Still an early stage experiment right now, but I think it is the right idea: https://github.com/mikera/kiss

-----


Nice work. Have you looked at Shen? It's highly praised by many.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: