I like how Ledger is essentially just a system for doing arbitrary calculations on "buckets of quantities of stuff" a.k.a. accounts with various currencies and assets. I'm not going to say it's a walk in the park, but I've been able to get it set up so it spits out everything I need to do my Belgian taxes, and before that, everything I needed to do my UK taxes. It doesn't assume anything.
Of course, happy to see some competition in this space. Can only benefit users like me.
Not exactly the same idea - one of the main point of Datomic is consistency, and no guarantees are made here.
In fact, only the idea of immutable value seem to be shared.
Because Clojure. I've seen the phrase "I want to be programming Clojure all day" or "I program in Clojure for money !" many times. These people are enchanted by Clojure and I'm slowly becoming one of them.
Maybe only the Haskell crowd has such a deep infatuation with their language.
All other programming languages look boring and limited compared to it.
Scheme and other lisps are another era -ish, Java, C++ and other OO languages are totally entangled in hierarchies of mutable code-data structures, it has concurrency "done right", pure functions mixed with mutable constructs, etc.
So you have this 21st century functional lisp designed for concurrency with native interoperability with the Java and Javascript worlds.
What's not to like ?
- All the documentation assumed you knew and understood the Java world. You were supposed to know about the classpath, how com.this.that.foo.bar works, how Maven works, etc.
- Difficulty communicating with C libraries. This was an intentional choice of the Java creators. Not Clojure's fault, but still a problem nonetheless.
- The error messages made it hard for me to get work done and there was no way I'd expect someone else to use a language with error messages like that.
- Somewhat unstable tools. There would be major changes to the tools, like the Eclipse plugin, and they would not be documented. The contrib libraries changed dramatically with Clojure 1.3. While I'm sure it was fun making the new system, I wasn't happy being unable to use the contrib libraries, because they either didn't work or the documentation didn't exist. A language that introduces major breaking changes without a solid transition plan in place is not one that I want to use.
- The documentation was limited in places. This was a major issue with new releases. It felt to me as though there was a team of core developers that were in the inner circle, so they got to use all the features, but the rest of us got what they decided to share.
One way I think about Clojure is as a language for writing Java macros [in the Excel sense of "macro"]. Sure it's not exactly that, and it's much more besides. Yet. it helps to have a model of Java's type system in my head because the type system leaks into interactions with Clojure. Clojure also relies on Java interop to be 'more general purpose'.
Clojure's documentation reflects the decision to target Clojure at the big fat segment of software projects. Not fresh faced grads, but grey hairs. Not pythonistas but Lispers. Better than hyperspec, not better than Racket.
The reason it has grown is because it focused on solving real business problems rather than being beginners friendly. The tradeoffs are consistently in the direction of what will make Clojure better for experienced programmers.
I guess it was still very young when you tried it.
Things are better now, there are a couple of good books on clojure, many tutorials and the documentation is good (eg. clojuredocs.org).
I've started learning it about 2 months ago and the hardest thing for me was figuring out which editor/IDE to use. There's a bunch of options - LightTable, Emacs, NightCode, IntelliJ+Cursive, vi SublimeText and Eclipse.
Some work better than others, but eventually I ended up using IntelliJ+Cursive, which provides project integration, REPL and debugger.
Completely agree. Documentation is sparse, and blog posts outdated. The error messages don't help, either.
Why can't stack traces show arguments, for the love of God? Can I get only my namespaces' traces? I will assume that the language is ok - most of the users won't be capable of diving into it, so just hide it by default...
The idea is that you do most of your work using a REPL. The typical workflow for Clojure is to start the app once and work with it interactively.
Clojure editors have tight integration with the REPL, so you can send any code from the editor to be evaluated in the context of the running application image.
While stacktraces are long, the relevant information tends to be easy to identify. In most cases you just look for a the first occurrence of a namespace from your project and trace from there. There also tools for making reading stack traces easier such as https://github.com/venantius/ultra and https://github.com/magnars/prone
Yes, that question had a little bit of salt in it as well.
The startup times are one of the things, tooling isn't quite there yet (although getting better and better).
And I have an allergy to the JVM/Java, but am willing to live with it because of the language.
This seems like a good application for clojure - accounting with it "never delete or modify information, just add new entries" should map nicely to persistent data structures and immutability as a core philosophy.
Juxt (https://juxt.pro/) is a Clojure consultancy in London. I guess they're dog-fooding, and advertising themselves, and doing a fun side project, all at once.
I like how Ledger is essentially just a system for doing arbitrary calculations on "buckets of quantities of stuff" a.k.a. accounts with various currencies and assets. I'm not going to say it's a walk in the park, but I've been able to get it set up so it spits out everything I need to do my Belgian taxes, and before that, everything I needed to do my UK taxes. It doesn't assume anything.
Of course, happy to see some competition in this space. Can only benefit users like me.