Engineering and product posts from Prismatic, a news recommendation startup, covering Clojure, ClojureScript, Om, and machine learning for feeds.
Commenters call Prismatic a favorite startup and praise its talks and its story-clustering post as an interesting piece of applied machine learning.
Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument:
"A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies."
There are at least 2 counter-arguments to this:
1.) in the simplest case, just restrict the use of macros. A team can easily adapt the rule that only the most experienced engineer on the team is allowed to write or approve macros. (And in my experience, the need for macros is fairly rare. I think my ratio is something like 100 or 200 normal functions for every macro that I write.)
2.) macros allow all kinds of interesting type checking, and data structure validation, and therefore they make it surprisingly easy to validate data and types as your data and/or vars get passed around your system. Consider all of these very interesting tools you can use in the world of Clojure:
Prismatic Schema which allows validation that a data structure matches a schema of (possibly nested) types:
https://github.com/prismatic/schema
and this now offers coercion, which makes this fantastic for importing JSON from other sub-systems or outside vendors:
http://blog.getprismatic.com/blog/2014/1/4/schema-020-back-with-clojurescript-data-coercion
(I assume you could easily validate before…
I'm just going to copy-and-paste this old comment:
When evaluating language tradeoffs the scala community values power more and the clojure community values simplicity more.
Scala wants to provide you with the most powerful language possible. Clojure wants to make it easy for you to mold your own language.
Scala language tooling works at compile-time and analyses the language statically. Clojure language tooling connects to a running environment and uses introspection. Scala has much better static checking and clojure has much better introspection. While both languages have a repl, the clojure community puts much more emphasis on live, interactive programming.
Clojures syntactic extension mechanisms are much simpler, being based on sexps. Scalas are powerful (eg can access the lexical environment) but much more heavy-weight.
Clojure has run-time eval. This makes it possible to do eg domain-specific jit (eg compiling DSLs -> clojure code -> java bytecode on the fly). Scala has a run-time interpreter which I haven't used but is reputed to be slow.
I haven't yet explored non-jvm backends for scala but I suspect that clojure will eventually dominate on that front for two reasons: 1) when clojure-in-clojure is finished porting clojure to a new platform will be far easier than scala and 2) clojure was designed from the beginning to be a parasitic language and delegates many features to the underlying platform.
Scala breaks backwards compatibility much more often than…
Here's a few:
- Walmart Labs - http://jobs.walmart.com/san-bruno/ecommerce/mobile-instore-software-(clojure)-engineer-jobs
- Staples - http://careers.staples.com/sanmateo/
- Climate Corp (now owned by Monsanto) - https://github.com/TheClimateCorporation
- RoomKey http://www.colinsteele.org/post/27929539434/60-000-growth-in-7-months-using-clojure-and-aws
- Puppet Labs - http://puppetlabs.com/blog/new-era-application-services-puppet-labs
- Soundcloud - http://blog.josephwilk.net/clojure/building-clojure-services-at-scale.html
- Netflix - https://speakerdeck.com/daveray/clojure-at-netflix
- eBay - https://www.linkedin.com/jobs2/view/26386571
- Two Sigma - https://www.youtube.com/watch?v=YHctJMUG8bI
- Consumer Reports - http://www.meetup.com/denofclojure/messages/boards/thread/47511532/
- LivingSocial - https://www.linkedin.com/jobs2/view/19995533
- Factual
- Thoughtworks - http://thoughtworks.github.io/p2/issue09/two-months-early/
- Daily Mail - http://www.pitheringabout.com/?p=1018
- MixRadio - http://dev.mixrad.io/blog/2014/10/19/Clojure-libraries/
- Prismatic - http://blog.getprismatic.com/blog/2013/1/14/bringing-functional-to-the-frontend-clojure-clojurescript-for-the-web
- Pivotal Labs - http://www.pivotaltracker.com/community/tracker-blog/generative-testing
- Beanstalk - http://blog.beanstalkapp.com/post/23998022427/beanstalk-clojure-love-and-20x-better-performance
- uSwitch
- CFPB (Credit Financial Protection Bureau) -…
Finally some comment explaining a specific problem involving macros.
First of all Clojure has a problem with Stack traces, other lisps are much nicer in that respect (but do not have to face the JVM).
Anyway, macros can be difficult to debug, I am sure you have heard and used of the tools that usually exist in lisps, macroexpand etc. Nevertheless macros are Transformations of the AST and thus not as easily traceable as function calls.
Nevertheless, when working with ClojureScript on a web-app, I grew really fond of the possibilities macros offer, possibilities that are hardly possible with JavaScript (HTML templating within ClojureScript code, etc.). http://blog.getprismatic.com/blog/2013/1/22/the-magic-of-macros-lighting-fast-templating-in-clojurescript
I wrote some macros to help with HTML5 canvas contexts and these made my code a lot more reliable and readable.
The problem with keeping languages less powerful is, that you often end up with something like Java: Surely quite understandable when you look at a few lines of code, but in the end you need a whole lot of complicated patterns and best-practices, now you get hit by a boomerang at the back of your head.
Take away message: Macros should not be used on every occassion, but they are really helpful in central places.
For Google Reader refugees coming here hoping for their salvation, some advance warning: Prismatic is not a straightforward RSS reader.
It's more similar in concept to Pandora - you tell it what content you're interested in, it tries to generate a content feed you might find similarly interesting.
This does not mean it's a poor source for information, quite the contrary - it's a very useful information discovery tool.
However, it will not show you every post (unread or otherwise) from RSS feeds of your choosing. It's just not that kind of tool.
Here's an (older) article on NYTimes regarding it:
http://bits.blogs.nytimes.com/2012/04/03/prismatic-hopes-to-offer-a-new-category-of-social-news/
This new entry page on their site seems to be an extension of their Google Reader integration they added last June, automating the import of your current RSS feeds as 'seed' interests to generate your Prismatic feed:
http://blog.getprismatic.com/blog/2012/6/1/prismatic-integrates-google-reader.html
No. It solves the problem of having to reason about data dependencies between functions at scale, typically in the service of doing the minimum amount of work required to get a certain result. As "Steve Wampler" points out in the comments, it's a bit like Inversion of Control/ Dependency injection, except for transient data between functions as opposed to services, connection pools, etc.
Other systems that solve similar problems, whose explanations might make more sense to you: Prismatic's Graph (http://blog.getprismatic.com/prismatics-graph-at-strange-loop/), Jane Street's Incremental (https://blogs.janestreet.com/introducing-incremental/)—and, though it doesn't nicely cover IO—the general concept of laziness in programming languages (https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf).