Clojure in the Field [video](infoq.com)
infoq.com
Clojure in the Field [video]
http://www.infoq.com/presentations/Clojure-tips
5 comments
the whole notion of"let's step back a bit and ponder" - it has an official name: Hammock Driven Development. Presentation about: http://www.youtube.com/watch?v=f84n5oFoZBc
As to trickling from Clojure to the mainstream - I wonder how far this could go without the foundation work that went into creating Clojure as it is. You definitely need a clutter-free syntax for functions as data, otherwise "(alter ref inc)" becomes "alter(ref, lambda x: inc(x))". Bad. Macros help too but I don't want this to turn into a "turn all languages into Lisps" rant :)
As to trickling from Clojure to the mainstream - I wonder how far this could go without the foundation work that went into creating Clojure as it is. You definitely need a clutter-free syntax for functions as data, otherwise "(alter ref inc)" becomes "alter(ref, lambda x: inc(x))". Bad. Macros help too but I don't want this to turn into a "turn all languages into Lisps" rant :)
Your example turns into "alter(ref, inc)" in any programming language with first class functions. I think there are some great concepts in Clojure (multimethods e.g.) which are not tied to lispy syntax and macros.
> If I could just get half of what's in Clojure trickle into the mainstream languages I'd be a happy bunny
Why aren't you a happy bunny with Clojure?
I have two observations to contribute:
* I noticed that my clients stopped caring about languages a long time ago. It is now known that there are many languages and more than one "right" choice. If asked about technology, saying you write software in Clojure, which runs on the JVM and uses Java libraries is accepted as a perfectly valid answer.
* Certain concepts have a fundamental complexity and cannot be simplified any further. Clojure got a lot of things right. Trying to "trickle down into mainstream languages" sounds like a hopeless task: you will end up either dumbing things down or making them difficult to use because other supporting parts of the language aren't there.
Why aren't you a happy bunny with Clojure?
I have two observations to contribute:
* I noticed that my clients stopped caring about languages a long time ago. It is now known that there are many languages and more than one "right" choice. If asked about technology, saying you write software in Clojure, which runs on the JVM and uses Java libraries is accepted as a perfectly valid answer.
* Certain concepts have a fundamental complexity and cannot be simplified any further. Clojure got a lot of things right. Trying to "trickle down into mainstream languages" sounds like a hopeless task: you will end up either dumbing things down or making them difficult to use because other supporting parts of the language aren't there.
I am very happy with Clojure :). But every time I have tried to introduce it into a workplace it has been the effect of the alien spacecraft. Too alien, too little to hold onto for the average working programmer (by this, I don't mean they are average, it's only the experience I'm talking about).
For your second point I completely agree. But shouldn't say, multimethods be doable in most other languages? In some, who are very strongly leaning towards OO, it probably wouldn't make that much sense. But others who can be written in a functional style could certainly benefit from it.
For your second point I completely agree. But shouldn't say, multimethods be doable in most other languages? In some, who are very strongly leaning towards OO, it probably wouldn't make that much sense. But others who can be written in a functional style could certainly benefit from it.
What makes me happy about Clojure is that it has the potential to become mainstream, at least among the top 10%.
I know a couple of people who've secretly used Clojure at their Java jobs. I don't know what will happen to them when they go through code review, but it's pretty cool that they can do that.
I know a couple of people who've secretly used Clojure at their Java jobs. I don't know what will happen to them when they go through code review, but it's pretty cool that they can do that.
Stu's O'Reilly video "Clojure Inside and Out" (http://my.safaribooksonline.com/9781449368647) is fascinating -- the first chapter (free) shows how to compose music with Overtone (http://overtone.github.io/). I've been programming in Clojure for the last year, but I had yet to experience Overtone. So cool.
And until May 31th, you can get 50% on the video using promo code "WKCLJRE":
http://shop.oreilly.com/category/deals/clojure.do?code=WKCLJ...
http://shop.oreilly.com/category/deals/clojure.do?code=WKCLJ...
Here's another recent Halloway talk: Concurrency in Clojure.
http://www.infoq.com/presentations/Concurrency-Clojure
Great high-level explanation of the spirit of Clojure and how/why it transcends place-oriented programming.
http://www.infoq.com/presentations/Concurrency-Clojure
Great high-level explanation of the spirit of Clojure and how/why it transcends place-oriented programming.
I think that Clojure has a great future, but the learning curve is steep. I have been using Clojure professionally for several years and I still feel like a Rookie. I have a mentoring job right now getting a very bright guy up to speed on both Clojure and the semantic web for his projects. He has a long hill to climb with Clojure but he is motivated and I think it will change his life as a developer in a good way.
I little off topic, but I know that Clojure is not the perfect language for me because I keep looking for better languages. I have been experimenting hard with DART in the last week and DART has the same nice "one language on client and server" feature that Clojure + Clojurescript provide. DART may or may not have a great future, but worth keeping an eye on. Also on some days, I feel like going back to Common Lisp or Smalltalk, but that is just crazy thinking :-)
I little off topic, but I know that Clojure is not the perfect language for me because I keep looking for better languages. I have been experimenting hard with DART in the last week and DART has the same nice "one language on client and server" feature that Clojure + Clojurescript provide. DART may or may not have a great future, but worth keeping an eye on. Also on some days, I feel like going back to Common Lisp or Smalltalk, but that is just crazy thinking :-)
I'm just starting to listen to this particular talk, but I want to comment now so this talk doesn't get buried.
I have to say that I'm very impressed with the Clojure community's eagerness to engage the real world in a way that most of my favorite languages haven't, while at the same time holding fairly firm on the things that matter (e.g. code readability and simplicity, referential transparency as a default, avoidance of OO traps).
I have to say that I'm very impressed with the Clojure community's eagerness to engage the real world in a way that most of my favorite languages haven't, while at the same time holding fairly firm on the things that matter (e.g. code readability and simplicity, referential transparency as a default, avoidance of OO traps).
Would you say the Go community is similar in that regard?
I don't follow it much. The language is very good for its purpose (a compiled production language for large codebases that isn't painful to use) and the implementation is great, but I don't know much about the community itself.
When I worked at Google, I talked to a couple of the Go developers and they were really sharp guys, so that's a strong signal.
When I worked at Google, I talked to a couple of the Go developers and they were really sharp guys, so that's a strong signal.
The thing is most modern languages we use can be compiled to native code ahead of time.
The fact that most people tend to use VM based implementations, tends to be related to:
- not having the knowledge that implementation != language
- not willing to pay for third parties native compilers
- AOT compilation in some cases does not provide a proper optimizing compiler and ends up providing lesser experience than the JIT.
Finally being compiled to native code, instead of relying on a JIT, tends to be more beneficial to client and embedded environments. Not so much for server side, except for the initial startup time.
I was also using it in the beginning given its Oberon influence, but nowadays I am back to more CS friendly languages, given my background.
But I miss the fact that most strong typed languages nowadays don't compile directly to native code in their canonical implementations.
As for the community, yes they may have some strong opinions, specially in the most polemic areas around Go, but they are nice guys.
The fact that most people tend to use VM based implementations, tends to be related to:
- not having the knowledge that implementation != language
- not willing to pay for third parties native compilers
- AOT compilation in some cases does not provide a proper optimizing compiler and ends up providing lesser experience than the JIT.
Finally being compiled to native code, instead of relying on a JIT, tends to be more beneficial to client and embedded environments. Not so much for server side, except for the initial startup time.
I was also using it in the beginning given its Oberon influence, but nowadays I am back to more CS friendly languages, given my background.
But I miss the fact that most strong typed languages nowadays don't compile directly to native code in their canonical implementations.
As for the community, yes they may have some strong opinions, specially in the most polemic areas around Go, but they are nice guys.
What about being able to instrument applications? That seems to be a big thing that VMs should naturally handle better...
(http://metrics.codahale.com/)
(http://metrics.codahale.com/)
True, but you can also produce instrumented binaries for the same purpose.
http://software.intel.com/en-us/intel-vtune-amplifier-xe
The thing is many developers don't want to pay for such tooling in the age of free.
http://software.intel.com/en-us/intel-vtune-amplifier-xe
The thing is many developers don't want to pay for such tooling in the age of free.
Golang developers follow the suckless/plan9 (cf. Uriel) aesthetic which isn't concerned with immutability, referential transparency, or anything else from the FP world.
Fairly practical people though.
I used to write Go but found it intensely tedious, so I went back to Clojure. Been happily clojuring since '08.
Fairly practical people though.
I used to write Go but found it intensely tedious, so I went back to Clojure. Been happily clojuring since '08.
Where do you work that you use Clojure? It's a great language.
Self-employed, I'm the one working on that fashion thing.
If I could just get half of what's in Clojure trickle into the mainstream languages I'd be a happy bunny.