synthc

I've worked with Clojure for years using the REPL driven approach and found I needed restarts quite often, for example when adding updating dependencies or other changes to the project file.

REPL driven development is great, but sometime you want to make sure that you are not using some function that was only defined in the REPL session but not in the source code. Also the REPL session sometime gets in a bad state when printing big outputs, blocking forever with some concurrency stuff or other mistakes.

To me it is kind off crazy when a build tools needs some 3rd party config library to make it usable.

I'd say 100% developer churn is the real problem here, no inherited 100kloc codebase is going to be a walk in the park if the original devs are not around.

However, I do think that it harder to keep a large code base understandable when using a dynamic language v.s. a statically typed language.

Having problems with understanding the shape of expected data is certainly a problem experienced in larger Clojure code bases, I guess this is just a disadvantage of using Clojure.

Documentation, tests, spec/schema and good naming conventions can mitigate this disadvantage to some extent.

I found some the advice in this blog post useful: https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-l...

Cute, but i'll counter with this one:

> Any sufficiently complicated Clojure program contains an ad hoc, > informally-specified, bug-ridden, slow implementation of half of Spring.

deps is more flexible, but I you just want to run a repl, build and deploy code then lein still works fine.

I usually default to leiningen: I can't be arsed to spend time configuring deps to do what lein does out of the box. (For example: building an uberjar)

Disagree about Java, I've worked on several large Spring applications and making small changes was not a problem at all.

With great power comes great responsibility.

When using the REPL you can quickly experiment until it does what you want, but you need the discipline to distill something maintainable from it afterwards.

No namespaces loaded is not a very good benchmark IMO, a real project will have lots of them.

I've worked on a large project with many namespaces and dependencies and it took about 20 seconds.

When you mess up the repl session somehow, for example by starting a http server on a port but not storing the server object. You now have blocked a port, and restarting the server does not work. Or if you run something like (future (while true ...))

There is some wierdness when redefining protocols and multimethods where a good 'ol restart is the easiest way to set things right.

Try working in an ecosystem with fast compile and startup and you will see why it is an advantage

This is just not true at all.

Everyone can join the Clojurians slack, it is a very welcoming place, also to newcomers, in my experience.

Everyone can create issues and patches, getting them accepted may take a long time, but the core team does a great job of maintaining high quality and not breaking things.

I'm very familiar with the live editing aspect of Clojure, and I like it a lot actually.

What I am saying is that Clojure's long startup time is still annoying if you want to restart, for example if you trashed your repl session or want to start with a clean slate.

If Clojure would start fast enough it could also be used for CLI scripts and we would not need Babashka at all.

All in all, I think Clojure is a great language, but the slow startup time is still a disadvantage.

I've used all combinations lein,deps,figwheel,shadow-cljs,cider and cursive, but haven't been able to reproduce the same frictionless setup I had then, something always breaks when switching between clj and cljs files.

I think one problem is that these days you use so many frameworks and libraries that is hard to get a good mental model of how software performs and where bottlenecks are.

Another problem is that performance often given lower priority in enterprisey software development. For example, i'm currently working on a project where two componenens share data through a message bus. The architects decided that all messages on this bus have to use json with a bunch of headers. For my project, it could literally be 50x faster with very little effort if we could use a more efficient format, but it is not allowed.

I feel your pain regarding ClojureScript.

A few years back there was a 3 month window where I had everything (lein,fighweel, emacs) configured just right, and I could reliably start a Clojure REPL, a Clojure Script REPL connected to a browser window, and switch between them from emacs.

It was really productive, I could work on the backend parts, frontend parts, and effortly switch between REPLS, but then there were some updates and I never got it working without friction again.

I also worked this way, I've had REPL sessions that ran for months, but IMO this is a workaround rather than a real solution. It's a good workaround, but fast startup would be a game changer.

If Clojure would start fast enough, projects like Babashka would not be needed.

REPL driven development is great, but there are still tons of situations where you want a full recompile and restart. Slow compile and start time really slow down development.

Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable.

Yeah it is too bad Incanter stalled, it could have been an great alternative to Python's data science stack (pandas/numpy/matplotlib) if it had gotten traction at the right time.

It lacks some polish and has some wierd conventions relative to modern Clojure, but I still use it occasionally.

I would not say it is dead at all.

There are still Clojure jobs and new companies using Clojure.

It is a niche language, and I think it will stay a niche language, but that is fine.

This the reason I use my own domain and a paid email service. I used Gmail before but got super worried about all the stories of accounts getting blocked with no way of contacting a human.

Sure domain registrars and email providers are not infallible, but it's a huge step up from trusting Googles customer service to do the right thing

They don't do sport or clubs, but still spend plenty of time on grading and preparation.

The same problem is happening in NL, it's a downwards spiral really that concerns me a lot. The government is trying to improve the situation by increasing pay a little, but with the current inflation it is probably too little, too late.

A relative of mine became a teacher after a career switch, and while she likes the work, there are many frustrations:

- Parents have a 'the customer is always right'-attitude, and complain about everything, but their kids are perfect of course.

- Some years ago NL decided to cut down on schools for kids with special needs, so every class now has a few very disruptive kids who have nowhere else to go. This is a very frustrating situation for everyone: the disruptive kids don't get proper guidance, the 'normal' kids get lower quality classes, and teachers have to deal with problematic behaviour.

- The shortage of teachers makes it hard to find replacements when calling in sick, plenty of teachers feel pressure to work when sick. This is of course a bad combo with the whole Corona situation.

- Teachers spend a lot of (unpaid) time grading and other administrative BS.

- Management is out of touch, they don't listen to their staff and think up time-consuming plans that are doomed to fail. (well, this is not specific to education) - Management is very unstable. The schools my kids go to had a different director pretty much each year.

Really cool! The repl is great for development, but static binaries are great for deployment, this may give us both.

babashka is great for scripting, but it is basically is a Clojure interpreter written in AOT compiled Graal-compatible Clojure.

Because is is AOT compiled is starts fast, but its much slower than JVM-Clojure for long running tasks.

A natively compilable Clojure would be great for other use cases, especially if it can be made more memory-efficient (Clojure is a memory hog)

Datomic is great but i think its missing some features that many enterprises need (access control and a query planner). Also it seems to be mostly built for DynamoDB/AWS.

SEEKING WORK | REMOTE (EU timezone)

I'm currently looking for part-time contracts or short consulting gigs in addition to my current assignment. My main assignment ends this fall, also happy to discuss longer full-time engagements starting from then.

Experience:

- 10+ years experience in developing and operating cutting edge software

- MSc in Artificial Intelligence

Skills:

- Modelling complex business rules, developing DSLs or tooling to make it accesible for non-technical users

- AI: OptaPlanner, Natural Language Processing.

- Languages: Kotlin, Java, Clojure, Haskell, some Javascript, some Python, some Rust

- Databases: MongoDB, Cassandra, Postgres, MySql, Datomic, ElasticSearch

- Cloud: AWS, GCP & Azure, cloud architecture, finding and fixing bottlenecks, efficient and reliable designs

See profile for contact details.

Sounds like Clojure would alo have been a good fit (STM, persistent datastructures, functional)

I think they would. Toyota already had very good hybrid cars for years, so plenty of experiences with batteries. Tesla made electric cars sexy, but I was always just a matter of time before electric would go mainstream.

jokes aside, this is all pretty much required functionality for mature applications

SEEKING WORK | REMOTE (EU timezone)

I'm currently looking for part-time contracts or short consulting gigs in addition to my current assignment. My main assignment ends this fall, also happy to discuss longer full-time engagements starting then.

Experience:

- 10+ years experience in developing and operating cutting edge software

- MSc in Artificial Intelligence

Skills:

- Languages: Kotlin, Java, Clojure, Haskell, some Javascript, some Python, some Rust

- AI: OptaPlanner, Natural Language Processing.

- Databases: MongoDB, Cassandra, Postgres, MySql, Datomic, ElasticSearch

- Cloud: AWS, GCP & Azure, cloud architecture, finding and fixing bottlenecks, scalable and reliable designs

- Modelling complex business rules, developing DSLs or tooling to make it accesible for non-technical users

Previous projects:

- automatic extraction of data from legal documents

- employees scheduling and route planning optimization

- data platform for IoT data

See profile for contact details.

BTC uses a lot of energy, some of it excess clean energy, but mostly just dirty energy. It is far from helping the environment.

Storing excess clean energy, now that would help the enviroment. Using excess clean energy for BTC means storage needs to compete with BTC, making storage economically less feasible.

So BTC not only uses lots of dirty energy, it also hinders innovation in using excess clean energy. BTC is just terrible for the environment.