Simple Made Easy (2011)(infoq.com)
infoq.com
Simple Made Easy (2011)
https://www.infoq.com/presentations/Simple-Made-Easy
7 comments
You forgot "Are We There Yet?", which blew my mind at the time ("with respect to other code, mutability is an immutable function with a hidden time argument") and which was MY introduction to this fanclub.
https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...
https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...
Hickey may be a brilliant software architect, but I'm wondering how high he ranks as a business leader. How is his company Datomic doing? Also in the light of the new database service Cloud Spanner just launched by Google.
Datomic is very different from the typical database in terms of the operations it supports. I don't think Google Spanner, or the other similar products, are direct competitors.
I don't know much about how they are doing financially though.
I don't know much about how they are doing financially though.
Didn't see anything about time-series features in spanner.
I would love to know how using Datomic is vs. rolling your own data-immutability solution via other mechanisms but using off-the-shelf SQL/big-data tools.
Anecdotal, but I've run into a couple of companies currently using Datomic in analytics and ML (with Clojure).
This is a classic. Definitely worth watching for everyone working within IT.
One thing I've found super helpful on my current project (which happens to be node) is using OSS concepts and npm as a unit of modularity.
Eg, everything is just a grab bag of functions in an npm module (sometimes with a closure holding some state - I either reject or don't understand FP people when they claim FP doesn't have state).
Each module has tests, dependencies, a README, and if it is reusable by other projects, is even OSSd and published. Writing software as if it's going to be published makes me be more modular. Being modular makes things easier to reason about and therefore has stopped by codebase from becoming complex to work with.
Eg, everything is just a grab bag of functions in an npm module (sometimes with a closure holding some state - I either reject or don't understand FP people when they claim FP doesn't have state).
Each module has tests, dependencies, a README, and if it is reusable by other projects, is even OSSd and published. Writing software as if it's going to be published makes me be more modular. Being modular makes things easier to reason about and therefore has stopped by codebase from becoming complex to work with.
"I either reject or don't understand FP people when they claim FP doesn't have state"
FP has state, but it makes it explicit avoiding side effects inside functions and using persistent data structures, that means, instead of mutating the state you create a new state. Without state basically any program is totally useless.
FP people have never claimed they don't have state. That's a straw man used to argue against something no one is saying.
The claim is that there is no hidden state - everything is made explicit.
The claim is that there is no hidden state - everything is made explicit.
I have no argument against FP, not am I making one here. But plenty of FP advocates claim FP "avoids state". It's not a straw man, it's just experience from asking people to explain FP.
> I either reject or don't understand FP people when they claim FP doesn't have state).
But that's not what state is, closures are just an easier way to define lots of functions with similar parts.
EDIT: Sure, you can call "whether or not f() or x are defined at the moment of calling (y) => f(x, y);" a form of "state", but this is called late binding and is simply not a thing in purely functional languages like Haskell; the existence of f() and x is checked at compile time.
But that's not what state is, closures are just an easier way to define lots of functions with similar parts.
EDIT: Sure, you can call "whether or not f() or x are defined at the moment of calling (y) => f(x, y);" a form of "state", but this is called late binding and is simply not a thing in purely functional languages like Haskell; the existence of f() and x is checked at compile time.
I think you might be confusing state and values. Pure functional programming has plenty of values. If you need a new value, you just return the new value, instead of reaching into an existing data structure and messing with it.
If a function closes over immutable values, then the resulting closure is an immutable value. If a function closes over mutable state, then its mutable state, often even uglier then mutable objects or structs which actually make the exact contents easier to identify at least.
If a function closes over immutable values, then the resulting closure is an immutable value. If a function closes over mutable state, then its mutable state, often even uglier then mutable objects or structs which actually make the exact contents easier to identify at least.
At some point it felt like Clojure was the future, the new thing, so amazingly better - was that just a feeling of novelty? Or something went wrong with its use case?
Of course, these days its about Rust, Swift and LLVM, but it doesn't have those lispy properties we love...
Of course, these days its about Rust, Swift and LLVM, but it doesn't have those lispy properties we love...
Clojure's first stable release was in 2009 so it's either very young or very old, depending on how far you zoom out.
Rust is exciting for use-cases that are very different from Clojure's, and the only thing I can say for Swift in this context is that I prefer it to Javascript, which I in turn prefer to other C-style languages.
I'm currently working on a single-person (but expected to grow) project in Clojure and really appreciate the concurrency and state primitives, the functional standard library, the ecosystem and community of high-quality standard tools and packages, and (while I seldom write them myself) macros, which enable you to you write amazingly readable code. The community has a strong preference to functions over macros, but used judiciously you can get things like Clojure's core.async. So you get the benefits of a Lisp without a lot of the drawbacks commonly pointed out regarding other Lisps. I enjoy it a lot.
Rust is exciting for use-cases that are very different from Clojure's, and the only thing I can say for Swift in this context is that I prefer it to Javascript, which I in turn prefer to other C-style languages.
I'm currently working on a single-person (but expected to grow) project in Clojure and really appreciate the concurrency and state primitives, the functional standard library, the ecosystem and community of high-quality standard tools and packages, and (while I seldom write them myself) macros, which enable you to you write amazingly readable code. The community has a strong preference to functions over macros, but used judiciously you can get things like Clojure's core.async. So you get the benefits of a Lisp without a lot of the drawbacks commonly pointed out regarding other Lisps. I enjoy it a lot.
Have been using Clojure in production for several years.
It is great language to work in. I have found it very suitable for solving a wide range of problems. Many companies are using it successfully.
Sounds like your view of reality is based on the HN hype cycle. As far as I can tell there are many more companies using Clojure in production than Rust. (nothing against Rust, but just as an example of the bias)
It is great language to work in. I have found it very suitable for solving a wide range of problems. Many companies are using it successfully.
Sounds like your view of reality is based on the HN hype cycle. As far as I can tell there are many more companies using Clojure in production than Rust. (nothing against Rust, but just as an example of the bias)
I think Clojure is doing just fine. I've seen it used in "real-world" proprietary software (custom-made for a client by a third party). It's just usually packaged as a jar file, so no-one notices unless you look for certain tells.
Currently using Clojure on a side-project. It makes me so much more productive -- a real win when I don't have a ton of hours to devote to a project due to also having a day job :)
If only I could find a day job using Clojure...
If only I could find a day job using Clojure...
I've been using it for 3 years and as I get my teeth further into my current project, I am grateful for Clojure every day.
It just got old. Those who wanted to check it out already have, those who liked it either got a job using it or have spent enough time with it to get bored, and those who didn't have probably forgotten about it already.
People just need a change every now and then, you can't get excited about stuff you see or use every day after a while.
People just need a change every now and then, you can't get excited about stuff you see or use every day after a while.
I felt like that, like Clojure was the future, around 2009/2010. But then Java libraries and their impossible stack traces got in the way.
I've been waiting for a native Clojure implementation (or on top of Python or the Erlang VM) ever since.
I've been waiting for a native Clojure implementation (or on top of Python or the Erlang VM) ever since.
There are few abandoned attempts.
Writing from scratch those Java libraries, including a good quality AOT compiler and GC is not something to do as hobby on the weekends.
Writing from scratch those Java libraries, including a good quality AOT compiler and GC is not something to do as hobby on the weekends.
Hey. My attempted is not abandoned just sleeping :).
The best chance to get it is to extend something that is ClojureScript based. I think you can get pretty close to it.
My implementation was never really targeting production use, but rather exploring some ideas in the VM.
I would love to continue working on it, but I simply do not have time for such a project.
See github.com/clojit if you are interested.
The best chance to get it is to extend something that is ClojureScript based. I think you can get pretty close to it.
My implementation was never really targeting production use, but rather exploring some ideas in the VM.
I would love to continue working on it, but I simply do not have time for such a project.
See github.com/clojit if you are interested.
Don't need all those Java libraries if you've got good FFI with C libraries.
Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM.
I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM.
I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
Lumo (https://github.com/anmonteiro/lumo) or Planck may fit your requirements, though they lack a C FFI. They're based off ClojureScript/Javascript, and startup way faster than the JVM Clojure. Could probably try the node-ffi library with Lumo.
There's the abandoned ClojureC project (https://github.com/schani/clojurec). There's also JVM-to-native compilers like gcj or ExcelsiorJet.
But at the moment, it doesn't seem like there's an established way to do all that.
There's the abandoned ClojureC project (https://github.com/schani/clojurec). There's also JVM-to-native compilers like gcj or ExcelsiorJet.
But at the moment, it doesn't seem like there's an established way to do all that.
For that I fail to see the point of why not use a Scheme or Common Lisp compiler instead.
Thank you. Though I really like having Clojure's:
* literal syntax for maps, vectors, sets, and regexes
* keywords
* clear separation of functional constructs (`for`, `map`, etc.) vs side-effecting ones (`do`, `doall`, `when`).
* large standard library of built-in functions, with overall fairly nice naming of things.
I've looked at Scheme, but it appears to be missing those things. I think some of them may be provided by srfi's, but upon a quick reading I couldn't make much sense of how to include and use them.
* literal syntax for maps, vectors, sets, and regexes
* keywords
* clear separation of functional constructs (`for`, `map`, etc.) vs side-effecting ones (`do`, `doall`, `when`).
* large standard library of built-in functions, with overall fairly nice naming of things.
I've looked at Scheme, but it appears to be missing those things. I think some of them may be provided by srfi's, but upon a quick reading I couldn't make much sense of how to include and use them.
Racket is probably something you should look at. Im not sure it has all these things, but it is also a modern updated Lisp language based on Scheme.
Yeah, for native executables, CL and Racket are much further ahead.
Yep, I'd love something like Clojure with an implementation/tooling like Go's.
I think that you are right that Rust, Swift, etc. have the hype now.
In my mind, this is a product of containerization. Java solved a lot of problems that we faced with deployment. Containers have made deployment even simpler, and suddenly the Java runtime is no longer as valuable as it once was. Furthermore, in a service-oriented architecture we don't really need too much interop with existing code.
I think that Clojure is a fantastic language, and I use it for my side projects as much as I can. But the promises made by Clojure dont sound as sexy as they did several years ago, hence the lack of hype.
In my mind, this is a product of containerization. Java solved a lot of problems that we faced with deployment. Containers have made deployment even simpler, and suddenly the Java runtime is no longer as valuable as it once was. Furthermore, in a service-oriented architecture we don't really need too much interop with existing code.
I think that Clojure is a fantastic language, and I use it for my side projects as much as I can. But the promises made by Clojure dont sound as sexy as they did several years ago, hence the lack of hype.
I feel like every new language has a honeymoon period. Clojure is still alive and well (and growing bigger consistently) but it doesn't have that new language hype anymore.
[deleted]
Other recommendations for early viewing are "Hammock Driven Development", "The Value of Values" and "The Design of Datomic".
[1] https://github.com/tallesl/Rich-Hickey-fanclub