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.
Clojure in the Field [video]
11–20 of 20 posts
Re: Clojure in the Field [video]
#12Informative talk and I really like the vision he presents in the beginning of it. I started with Clojure from python and while a lot of good things are present in python, I really miss the whole notion of "let's step back a bit and ponder whether we are on the right track or not" that is present in the Clojure community. Especially the core team. If I could just get half of what's in Clojure trickle into the mainstre…
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 :)
Re: Clojure in the Field [video]
#13Earlier quoted context omitted.
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.
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.
Re: Clojure in the Field [video]
#14Informative talk and I really like the vision he presents in the beginning of it. I started with Clojure from python and while a lot of good things are present in python, I really miss the whole notion of "let's step back a bit and ponder whether we are on the right track or not" that is present in the Clojure community. Especially the core team. If I could just get half of what's in Clojure trickle into the mainstre…
> 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.
Re: Clojure in the Field [video]
#15Stu'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...
Re: Clojure in the Field [video]
#16Informative talk and I really like the vision he presents in the beginning of it. I started with Clojure from python and while a lot of good things are present in python, I really miss the whole notion of "let's step back a bit and ponder whether we are on the right track or not" that is present in the Clojure community. Especially the core team. If I could just get half of what's in Clojure trickle into the mainstre…
> 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…
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.
Re: Clojure in the Field [video]
#17Informative talk and I really like the vision he presents in the beginning of it. I started with Clojure from python and while a lot of good things are present in python, I really miss the whole notion of "let's step back a bit and ponder whether we are on the right track or not" that is present in the Clojure community. Especially the core team. If I could just get half of what's in Clojure trickle into the mainstre…
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)" becom…
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.
Re: Clojure in the Field [video]
#18Earlier quoted context omitted.
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.
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 JI…
What about being able to instrument applications? That seems to be a big thing that VMs should naturally handle better...
Re: Clojure in the Field [video]
#19Earlier quoted context omitted.
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 JI…
What about being able to instrument applications? That seems to be a big thing that VMs should naturally handle better... ( 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.
Re: Clojure in the Field [video]
#20I 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 :-)