Do Accounting in Clojure and Datomic | Hacker News Reader

Do Accounting in Clojure and Datomic

github.com

69 pointsmoomin19 comments

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.

Plug: Also checkout ERPNext https://erpnext.com

We just released a new version couple of weeks back.

I'm wondering when we will see an implementation of Datonic that has a more liberal license.

There is eventstore (https://geteventstore.com/) but I have never tried it...

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.

What is the difference to GnuCash? Why not contributing to it or the other numerous Free Software ERP systems?

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 ?

> What's not to like ?

Program startup times and JVM stacktraces, for one.

Nevertheless I am just getting started with Clojure and really like what I am seeing so far.

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.

Clojure at C/C++ speed would be a true wonder.

Actually clojure is been designed to be hosted, it should not be difficult to build a clojure (dialect) that compile into a system language...

Well of course it is difficult in the absolute meaning, but not so difficult...

When I was younger I tried to figured out every single interface that clojure use, and there weren't too much...

Some figure here[1]

It would be a really interesting summer project...

[1]: http://siscia.github.io/2013/11/28/visualize-hierarchy-behin...

There's a LLVM Clojure dialect called Pixie https://github.com/pixie-lang/pixie that has extremely fast startup

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

> What's not to like ?

When I tried it several years ago:

- 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.

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...

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.

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.

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.

Also for fun, probably.

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.

AGPL 3.0 - that is unfortunately a deal breaker for many.

Reply on news.ycombinator.com