Mikera

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.

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.

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.

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.

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

Also I would guess that people who like Clojure's philosophy are much more likely to build simple / loosely coupled / composable services than a big monolithic project.

Agree with everything you say, but it is worth noting that the insights you get from static analysis on desugared forms (which can be very large and complex!) is much harder to interpret than static analysis on the original forms.

So to make static analysis tools useful on macros, they really need some way to map back to the original source forms. Not all tools do this (either at all, or well) - and to the extent that they don't it is an big impediment for static analysis.

Also the killer challenge: macro expansion in Clojure can depend on a mutable environment at the time of macro expansion. This makes it impossible to do reliable static analysis, unless you are able to recreate the runtime environment at the time of macro expansion in your static analysis tool, which is hard/impossible in general.

This is part of the motivation for my little Kiss language experiment: with immutable environments you can keep the power of macros, but avoid the mutable environment problem. Ideally, macro expansion would be governed only by things that are provably compile-time constants (not sure how feasible this is while maintaining the dynamic flexibility of Clojure that we all love... but it's an attractive idea at least).

It makes a lot of sense in the context of programming when you look at the big picture. I think Rich Hickey articulates it best: http://www.infoq.com/presentations/Value-Identity-State-Rich...

The problem is the design paradigm where you enforce an arbitrary fixed hierarchy on real-world data.

This doesn't work for several reasons:

* In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.

* Your hierarchy will almost certainly have to change (you'll be wrong, or new requirements will come along). Frequent major code breakage / refactoring is the likely result. If you also need to persist data across versions, you're in big trouble.

Property / prototype based methods are in general much more flexible for real world data.

It concerns me when people confuse the idea of gender equality and rights (which I think most reasonable people agree is a good thing) with the idea that men and women's lives have to be the same in all aspects.

I think it is much more harmful to impose a dogmatic belief that forces everyone to lead identical, mono-cultured lives and denies individual choice.

What if I want to go to a single-sex school? Who are you to deny me that choice?

Erlang has a very nice concurrency approach, particularly if you are into distributed and fault tolerant systems.

But it's ridiculous to say that "only Erlang can do concurrency". Many other languages do concurrency very well in slightly different ways (Clojure, Scala and Go, for example).

The point about complexity is probably fair from the perspective of someone just getting started with Clojure.

Sure, the syntax itself is very simple and regular (like any Lisp). The complexity is in all the other stuff - macros, code-as-data, vars, namespaces, metadata, managed references, persistent data structures, leiningen, paredit etc.

Once you've got up the steep learning curve, I find Clojure is unbelievably productive. It's just a bit tough getting there. I think it's all solvable, but the Clojure community does need to listen and learn from constructive criticism.

vectorz-clj has sparse vector support.... it's bit of an hidden feature at the moment (you'll have to use Java interop to instantiate a SparseIndexedVector) but it works and is pretty fast for many operations.

You've just pretty much described the motivation for core.matrix: it's an API that wraps various other back end vector/matrix libraries (including JBlas etc.) with a nice, standard Clojure API.

core.matrix developer here :-) we're definitely looking at expression compilation. Also hiphip could be very useful for writing fast core.matrix implementations for the standard API. So definitely good room for collaboration.

I've been thinking about adding some IO features to core.matrix. Haven't got round to it yet, but linking this with hdf5 format could be very useful.

Refcounting?? I thought that idea died years ago.

Refcounting is an extremely poor choice for memory management on modern machines. Even putting aside the issue that it can't handle cycles: constantly writing to memory to modify reference counts can be a huge performance hit (you often have to do it even when you are accessing objects in a read-only fashion). Also it requires extra memory on a per-object basis. Also it doesn't play nicely with concurrent threads. Also it's not cache friendly.

I'd expect any halfway-decent modern GC implementation to be significantly more efficient than reference counting.

About the only valid justification I can see nowadays for not using a GC is a hard-realtime latency requirement. Yep, GC pauses suck. But for efficient memory management in nontrivial systems, GCs are definitely the state of the art.

The JVM isn't even that slow to start nowadays: a simple hello world app runs in about 0.1sec on my machine.

I'm the author. Yes I find it useful in various ways.

If the learning rate is too high, you can visibly see see weights flicker between different colours. In simple nets you can use it to identify the "meaning" of feature detectors by observing positive and negative links (green and red). You can debug learning algorithms by immediately seeing if something unusual is happening to the weights or activations.

As always caveats apply, but it is a useful technique (when used alongside a variety of other tools).

That chart is statistically meaningless.

It just shows % change since an arbitrary date in the past. Obviously, since different languages are on different parts of the growth curve, it results in a pretty unfair comparison. In particular, it will give very high values for any language that happened to be starting from a very small base at the beginning of the time period under consideration.

log of absolute values would be a much more interesting chart.

Java is a great platform to build on - and the sweet spot is definitely for server side applications like this.

You can safely ignore the people who bash Java - they are generally clueless. The Java language is perfectly fine: high performance, statically typed, OOP, relatively simple and maintainable. It may not offer the most concise code and it may not have all the "trendy" language syntax features but guess what - that actually doesn't matter much in the real world (i.e. outside the realm of language designers and fanboys). If saving a few characters of typing is your major concern when choosing a language, you have much bigger problems.

But the real strength in Java is not the language but rather the overall platform - the combination of the JVM (which is an amazing high performance feat of engineering), the library ecosystem (which is the best overall for any language), the tools (great IDEs, Maven, a host of other developer-focused tools), the fact that the OpenJDK itself and most of the libraries are open source and the portability (compiled JVM code is extremely portable, and importantly doesn't need a recompile unlike some other so-called "cross-platform" languages)

So overall you can't really go wrong with choosing Java for server side applications. Although I would also give Clojure or Scala a look - if you are after "powerful" languages then these two are pretty amazing and you still get all the benefits of being on the Java platform.