zlacker

>>jnord+(OP)
I am the founder of a niche SaaS (https://partsbox.com/ — software for managing electronic parts inventory and production). While I am somewhat worried about AI capabilities, I'm not losing too much sleep over it.

The worry is that customers who do not realize the full depth of the problem will implement their own app using AI. But that happens today, too: people use spreadsheets to manage their electronic parts (please don't) and BOMs (bills of materials). The spreadsheet is my biggest competitor.

I've been designing and building the software for 10 years now and most of the difficulty and complexity is not in the code. Coding is the last part, and the easiest one. The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.

Sadly, as I found out, once you spend a lot of time thinking and come up with a model, copycats will clone that (as well as they can, but superficially it will look similar).

>>jwr+rQ
I have two tech q about partsbox. Why Clojure? Why not CL (lack of saas related-features)?

>>a2code+A71
Clojure is just better than CL in pretty much every respect. Excellent and well designed standard library, great concurrency primitives, core.async, built-in transducers (CL has SERIES which does a kind-of similar thing, but isn't as well designed and integrated) and the dominant immutability all let me write more maintainable code. Also, I can re-use model code on the client side (ClojureScript), so there is lots of code sharing, and I don't have to serialize to a crippled format (JSON), my data can pass from server to client and back intact (with sets, keywords, and other rich data types).

I used to love CL and wrote quite a bit of code in it, but since Clojure came along I can't really see any reason to go back.

>>jwr+g91
I did not try Clojure so I cannot comment on how well implemented the features you quote are, when compared to CL. All I can say is that CL also provides much of the same functionality with its standard, cl-async, lparallel, parenscript, while (im)mutability is a matter of preference (IMO correct decision by CL) rather than dominance. The way I see it, is that CL is superior (opinion) due to reader macros and native compilation, rather than bytecode JVM.

>>a2code+We1
I used CL for many years before I switched to Clojure. And by "used" I mean really used it, not just for applications, but I also dove into CL implementations, for example I added return-from-frame (also known as debug-return) to CMUCL.

So, I kind of know what I'm talking about :-) And I don't miss anything from CL: I honestly can't find a single reason to switch back to CL.