Amazon is hiring Clojure devs
lispjobs.wordpress.com
lispjobs.wordpress.com
I wouldn't be surprised if Clojure has more "industry" adoption than Scala at this point.
Give me Clojure semantics (anti-OO, maps, vectors, and seqs) with some optional typing and a Python syntax then I'm there *
* that's just my preference, no need to convince me of anything other.
Or use an existing, language provided parser - haskell-src-exts, for instance.
"it would need to be a extra step in your compilation pipeline"
I don't see what that has to do with syntax. Any compiler could have a hook where it hands off a parsed AST - many do.
I have jet to see compiler hooks that are as simple as to write as they are in lisp. Also, most of them are far less powerful then they are in clojure.
I see tons and tons of example were people use clojure macros in intressting ways but not that many people who write scala compiler hooks.
So in theroy you are right, in practice I have not jet seen tons of examples.
Clojure has a lot of great things going for it. I don't have any objection to Lisp syntax - I like it although I don't know that I prefer it - but I don't think we should be crediting it with things more properly deserved by other pieces. Proper support for macros is a biggie.
It has to do with the syntax. Working Lisp "plugins" is very simple because all the code is represented as plain datastructures. Rewriting program is like writing simple data structures manipulation code.
Strictly speaking, AST data structures are often full of junk, but that's not mostly a matter of the complexity of the syntax itself but of the variety of things being done with that AST - you can't report error locations if all you have is the nested lists representing your Lisp program.
The focus on making macros work well is absolutely a strength of Lisps. The syntax is a much smaller part of that than the lore would suggest.
More syntax makes things harder, compiler that have not been designed wit this goal make things harder. You can look at the papers trying to get this stuff in to other langauges and there are some problems, dylan [1] was doing it befor most others, now rust is coping that stuff.
Actually some of the coolest stuff was done by David Moon (Common Lisp, Dylan) he greated a langauge spec that he calls PLOT [2] and it has a very inovate macro system. For anybody that is intrested in that sort of stuff I highly recommand it.
[1] http://people.csail.mit.edu/jrb/Projects/dexprs.pdf [2] http://users.rcn.com/david-moon/PLOT/ and http://users.rcn.com/david-moon/PLOT/Moon-ILC09.pdf
That would be F#.
Both languages are very similar in way that they support lists, arrays and maps as first class citizens as fundamental types and provide expressive algorithms to operate over them 'out of the box' with more or less uniform syntax.
To me, as a novice, the main apparent practical difference between the two languages are the domains for which there is strong support and which have discoverable solutions. I.e. the platform and the community.
Scheme's SRFI 49 (2003-2005, Final): "Indentation sensitive syntax": http://srfi.schemers.org/srfi-49/srfi-49.html
Lispin (2008): So utterly dead, we have to resort to the Internet Archive: http://wayback.archive.org/web/20080517144846id_/http://www....
cl-2dsyntax: http://www.cliki.net/cl-2dsyntax (Annoying exclamation marks in this one, oops).
CGOL (1973!): http://en.wikipedia.org/wiki/CGOL
The last one shows you just how long people have been unsuccessfully trying to promote Algol-like syntaxes for Lisp.
I'm experimenting on this with Hype. It's barebones and does some whacky-don't-look-at-it macro "magic", but it works! Also trying to mimic core.typed's way of annotation.
Note: Just using python functions annotations with a typeannotation library to provide some runtime type checking. It's rather rad if i can say so my self.
https://github.com/Foxboron/Hype https://github.com/ceronman/typeannotations
If anybody on Arch Linux wants to give a Hy a try, I put together a PKGBUILD: python-hy.
Combine that with Scala's bewildering type system and I can see why companies move to Java or Clojure.
I was really into Scala and studying it and everything. I still remember all the scala bloggers I follow, Daniel, Tim MOrris, Paul Snively, etc...
Eventually I landed into a scala job role. Oh boy was it different. The other programmers were like type casting to Any or whatever that generalize highest type was (unified type theory).
The complexity is pretty high, it's great if you know it all but in all seriousness it was impeding...
As a Scala dev, that is absolutely terrifying. I can't even begin to think of a good reason for that.
(Ok, but in all seriousness... don't.)
Personally, I like the object + static typing + first class functions as it eliminates 90% of errors at compile time. If any error occurs at run time, am pretty sure it's logical. This is a huge plus. The only drawback - the ridiculous amount of type specific code you have to write for mundane changes/updates.
The Java community has its flaws (oh boy, does it) but it has adapted to the hordes of mediocrities. Give Scala to mediocre engineers (who typecast to Any, use null instead of Option[T]) and you have the Java hell with worse IDE support and 5x compile times.
I'm not directly in the dev space, but it appears as though the choice of languages that people use has far more to do with what Builder Tools will support than what people actually want to use. Teams only use Scala or Clojure if they are willing to build it using their convoluted Ant wrapper that doesn't make any sense.
Parenthesis are always offputting to me, even though I like a fair amount of clojure concepts. I often feel like functional programming has made a cottage industry around putting obfuscated names around relatively simple ideas (see transducers for example)
I would be very surprised if that was the case, based on what I've seen.
Amazon is building a competitor to Bloomberg?
coming soon...storm-as-a-service (built on clojure)Implemented a scheme in my undergraduate days (in C), had a small love affair with LISP in general (but none with girls ... probably related).
I'll be opinionated here:
It's not readable. It really isn't. You have to be in the thick of it to see the trees. Idiomatic doesn't cut it.
Operator heavy Haskell is more readable. Most of the modern functional languages read closer to the spoken word.
I'd rather be presented with a legacy OO code base, than an LISP one if the LOC was anything significant.
I hope I don't come across as disgruntled, I am but a mere man, and I know my limits.
And still have fond memories of bedding LISP.
I don't feel that there's anything particularly magical with the paren being on the left hand side of the verb that automatically makes it less readable than when it is on the right hand side of the verb.
Especially that alternating pairs business.
Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.
I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.
https://github.com/stuarthalloway/programming-clojure/blob/m...
https://github.com/tcltk/tcl/blob/master/generic/tclCompile....
Grabbed at random. I think the larger indentation and fewer parens do make a difference when you squint at things.
Of course, I also think as a professional programmer, if something does the job, get over it and get on with it. I use Erlang myself, which also gets lots of syntax complaints.
Just squinting at the code to see the shape of it rather than worrying about the contents, the C blocks look more distinct, to me.
C is more dispersive...
Thought I code way more clojure than C
The whole point of macros is that they are written in the same syntax as everything else (because of homoiconicity you can operate on your code as native data), you don't need to know what is a macro and what is not for 90% of the code you write. There are very little cases in Lisp languages in general where the difference between a macro and a function are evident, and in Clojure even less (compared to another dialect like, let's say, Common Lisp).
There are some times where that might be useful, but that's why we have a repl and macroexpand.
"that macro function is called and is passed the unevaluated operand forms. The return value of the macro is then evaluated in its place.
If the operator is not a special form or macro, the call is considered a function call. Both the operator and the operands (if any) are evaluated, from left to right." - http://clojure.org/evaluation
There are many macros and special forms in clojure where you have to understand that the arguments are not evaluated first - and if you try to reason about what happens as if they were eagerly evaluated you get the wrong answer or an error
That's why the pipeline operator (->>) is common. Then you just read it from up to down.
Also LISP (I assume you are talking about Scheme or Common Lisp and not the 60s langauge) is not the same as Clojure. It does share some syntax and some ideas but its also very diffrent in many ways.
You might prefer your legacy java in the simple case, buts lets talk again when that java code has to do concurrency or other complex problems.
> Most of the modern functional languages read closer to the spoken word.
Its actually a absolut non-goal of clojure to 'read like the spoken word'. Its a goal of clojure to write code in a simple way, simple meaning a speration of concerns were each part is easy to reason about.
For single-instance applications, sure. But for scalable systems, 90% of your concurrency is handled by whatever message broker you're using anyway. Tasks, Async processing, Blokcing Queues etc etc - they're all handled by your JMS provider.
However often you find that its not enougth for you and then you will have to write some costume code yourself. You might think one message passing system is enougth but then its more and now you have to manage message from three subsystems in your application.
Ill use a langauge that makes things easy when things are easy and not very hard if they are hard.
Why dont we ask Brian Goetz a Java Language Architect how "easy" it is, read his book [1] and then lets talk again how easy it is.
[1] http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...
Let's consider an example. One of the classic concurrency problems is managing a bank transfer. In this problem it's important that the debit and credit operations happen atomically. If one operation fails, then both operations should fail.
In Clojure, we'd write:
(defn transfer [from to amount]
(dosync
(alter from - amount)
(alter to + amount)))
A lot of the problems with dealing with concurrency are in communication between threads. BlockingQueues and Executors only deal with a small subset of concurrency problems, and blocked threads are a fairly inefficient use of resources compared to async solutions.
But if I may, I believe treating inanimate objects as women puts them off more than LISP.
Hang on. Your opinion is that Clojure isn't readable because you didn't find other Lisps readable when you were an undergraduate? But you haven't actually tried Clojure yourself?
I have tried Clojure, and my opinion is that it's easily the most readable programming language I've found.
Clojure has very strong opinions about complexity, which in Clojure parlance is a measurement of interconnectedness between components. The language is built around the idea of reducing complexity, about making things isolated and independent. Idiomatic Clojure code therefore tends to have a very flat structure consisting of isolated functions and data structures. It has a very high degree of code reuse, because it explicitly rejects encapsulation.
Clojure's syntax may be unusual, and individual forms are more information dense than many languages, however the structure of Clojure code is often much easier to understand, and for any non-trivial piece of code, that's the hardest part of comprehension.
When I come across a new Clojure library, I'll often find myself reading a bit of the docs, then heading into the source code to get an idea of how it operates. I rarely do this with an object orientated language, as OOP code tends to be deeper, more interconnected, and because of encapsulation, have more methods to understand. Java in particular is terrible for this.
Maybe Clojure feels odd for a few hours when coming from C-like syntax, but it becomes so obvious later on. I remember I felt terrified by the parens because I had not written anything serious in it.
I'd say the most natural pathways for Java programmers upgrading their language skills are:
* from Java, to Groovy, to Clojure
* from Java, to Groovy, to Scala
* from Java, direct to Clojure
* from Java, direct to Scala
Once someone reaches Clojure and Scala, they seem unwilling to give up what they've gained (the simplicity and macros of Clojure, or the higher-order typing of Scala) to switch to something else, even when that something offers more.
Syntax? Not seeing any syntax here.