> I suspect the hum obsession has something to do with LLMs “awareness” that their “physical selves” exist in data centers.
647 karma · joined July 28, 2009
> I suspect the hum obsession has something to do with LLMs “awareness” that their “physical selves” exist in data centers.
Apparently I and my fellow Clojure devs aren't real Clojure devs. Or perhaps you mean "true" clojure developers, or "good" clojure developers. (cf. https://en.wikipedia.org/wiki/No_true_Scotsman)
And even if we were Clojure devs we've inherited multiple big Clojure codebases that were apparently written by non-Clojure devs, and heavily refactoring is not on the to-do list.
With the right discipline (specs, obsessively normalising all data at the boundaries, good naming conventions) this wouldn't have been a problem, but that discipline is optional, and headbanging aggravation results.
(This is, of course, a generic "dynamic typing" problem, but that's a key feature of Clojure)
I get a lot of recruiter spam on Linkedin for roles at retail banks, outsourcers, consultancies, SaaS companies, startups, etc. etc. in the £90-110k bracket. I do also get a lot of recruiter spam for laughably underpaid jobs, in particular hardware/embedded roles, which is why I switched out of embedded.
They really are, if you're prepared to work for $BIGCO
(For the car that I also own, to be clear)
(* https://www.carmoola.co.uk/blog/cooling-off-period-car-finan...)
If you're really lucky, someone will have thrown in a bunch of 'specs' that make a bunch of assertions about the data, put them on the API entry points, and then scattered some slightly different specs with slightly more restrictive assertions on various 'internal APIs', resulting in random explosions in production!
And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
That's the point - if the C-level could go to prison then you'd find that mysteriously there were multiple overlapping systems of control implemented such that no one person could make a simple human error and expose reams of customer data: it would require systematic failure.
(At that point, when safety systems are in place but fail for complicated hard to predict reasons, malicious negligence is hard to prove and executives don't go to jail.)
(sorry)
That is to say the configuration eventually becomes a program in itself, with a few key values... which then get pulled out into a simple config file.
See: autotools, sendmail, etc.
https://reactjs.org/docs/integrating-with-other-libraries.ht...
Once I eventually figured out which of their indistinct products is actually the basic tool I then tried to follow their tutorials, which want me to install hundreds of megabytes of who knows what, set up heavyweight servers, watch video tutorials (!), and who knows what.
When I eventually slogged through all that to get to a minimally working setup trying to convert a few fairly trivial ansible plays for what I would have thought of as fairly standard stuff rapidly turned into "time to write some ruby"!
I gave up.