Hacker News new | comments | show | ask | jobs | submit | Mikera's comments login

Absolutely happy with my choice of Clojure as a startup (doing data science, analytics, some front-end work).

Biggest wins for us are:

- ClojureScript / figwheel as an awesome front end development combination.

- The combination of functional programming with immutable data structures

- Lisp "magical powers" (macros, interactive REPL etc.)

- Ability to exploit the Java library ecosystem whenever you need it

Biggest downside = Lack of types.

-----


Clojure on the back end and ClojureScript on the front end.

Some reasons:

1. It's a proper full-stack solution. You can share code between client and server if you need to.

2. There is some amazing front end technology (Om, figwheel etc.) that can change the way you think about front end development.

3. It is hard to match Clojure for productivity / interactive development. You can code almost everything at the REPL without restarting (no restarts or edit/compile cycle time needed)

4. You can use all the Java libraries very easily (although idiomatic Clojure wrappers exist for almost everything you are likely to need)

5. The usual Clojure reasons: functional programming, concurrency, immutability, Lisp macro etc.

-----


Note: you don't need to commit to Emacs to get the productivity benefits of Clojure.

Eclipse with the Counterclockwise plugin (and I believe IntelliJ with Cursive too) also give you comprehensive REPL, s-expr manipulation and paredit features.

-----


The benefit of CIDER (the Clojure Emacs development environment) is that it now has a s-expr based debugger, whereas Cursive's debugger is still call stack based. So you can traverse the AST like in any other Lisp debugger and evaluate and manipulate s-exprs as you go.

-----


vim with fireplace.vim and paredit.vim plugins are pretty nice as well.

-----


This is great stuff, but it should really be designed as a core.matrix implementation rather than providing it's own API.

The last thing the Clojure community needs is fragmentation with more incompatible libraries.

-----


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.

-----

More

Applications are open for YC Summer 2016

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

Search: