These days, it’s mostly C#. It’s got one of the most sophisticated list processing modules of any language I know of, you can fairly easily write heavily immutable code. It’s a bit niche because Microsoft but it’s nonetheless solid.
My downsides compared to Clojure: no destructuring in parameter declaration. No immutable by default.
But it turns out I prefer typed languages. Which isn’t a thing I’m going to argue about!
I’m no longer in a professional engineering position and have a family and toddler so less time for learning about or playing with program languages. Clojure is what really made me first start thinking about programming languages and down the rabbit hole of scala and Haskell and idris and type theory books. Which are incredible and I can’t recommend more and also not remotely practical.
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison.
Sometimes I think I was happier before I learned Clojure.
I never understood this sentiment. Even if nobody on my team uses Emacs or Vim, or Clojure, Rust, Zig or Nix, or some browser extensions, or any other tool, nobody could ever directly deny me access or restrict the use of any of that on my machine, some vm-box or EC2. And once I prove their usability to me personally, I show that to my colleagues and typically people when impressed they start using them. Once you have more than three people, you can start discussing rolling it out for general use. Just this past year alone, I have convinced my teammates to use a bunch of tools they'd never heard of before.
It's more depressing if you work in a big organization where decisions come down from on-high instead of letting teams decide what's best. (Especially if one of those decisions is so-called Agile practices which were about empowering teams against on-high global decisions from management, but that's a digression.)
But yes, treat it as a job, and make time for "fun time" after work at home using your favorite tools and languages and OSes, and you can still be happy, especially because the bills are being paid. And even in restrictive corporations there still may be opportunities to introduce a little of your favorite thing... Clojure itself "snuck in" at a lot of places because it was just another jar, and it's not too hard to shim in a bit of Java code that then turns things over to the Clojure system. You can also try getting away with internal-only tooling.
If I had stayed at my last job a little longer I would have tried putting more effort into sneaking Common Lisp in. I had a few slackbot tools I wrote in Lisp running on my machine that I turned over (with pre-built binaries) to someone else when I left (but I doubt they're running still). The main application was Java, and there was already mandates from security people and others not to use other JVM languages.. at least in application code. I was thinking (and got a prototype working) of sneaking in Lisp via ABCL, but only for selenium web driver tests. It was a neat trick to show some coworkers a difference in workflow: write or edit a web driver test, one of your asserts fails or an action click on some ID that's not there fails, in Java you get an exception and it's over, you'll have to restart the whole thing, which for us was expensive because these test suites typically spun up huge sets of state before starting. But with Lisp, exceptions don't automatically go back up the stack, but pause at the spot they occurred: from there you can do anything in the debugging REPL that you can do normally, redefine functions, classes, whatever, and then resume the computation from where it left off (or at some higher part of the call tree stack if you prefer), thus no expensive restart.
There's also ways to introduce things you like that aren't just different languages. My team started doing "lunch and learns" at most once a week (sometimes less often); if anyone wanted to talk about whatever for 30-60+ mins during a lunch period we'd get together and do it. Sometimes that would be about specific work things being built, sometimes it would be about external stuff, ideas (e.g. the Mikado Method) or tools. Once I did a brief presentation about property testing and later on got the quicktheories library for Java into the codebase and handling some tests, and ended up not being the only one to occasionally make use of it.
uh... its fine. after 2 years i had to replace battery like i said and parts like the occasional burnt connector, cables, body is somewhat fragile but when my daily running cost is 0, these are small things.
i could use my car for my office runs but then it would cost me like inr 6-8k monthly in fuel+parking which is more than 0 what i currently pay so its fine.
its not a perfect machine, for inr 40k, i don't think it can be better. if i increase my budget to say 60-70, then there are more choices but this one is a good bet for now.
take ola for example. it is fine until it breaks. then its game over as their service is shit, same for others.
when a machine is more expensive, it is more complicated to repair and more expensive also. the simpler the machine, like mine, it has just body + lead acid battery + controller. nothing more. its easier to repair
There are key differences though. What tsonic offers: (0) broad data type support, stack allocated types etc (1) nodejs and js compatibility libs, (2) the availability (in tsonic) of the entire .Net BCL, Asp.Net and EF Core as d.ts files (for example, in @tsonic/dotnet) so that tsc would still run, (3) bindings generator (tsbindgen) for any .net dll etc.
What tsonic is missing: (1) interpreter, (2) compile to .Net IL. Tsonic will only do native code; and does so by converting ts to c# and then using the NativeAOT chain on generated C#. SharpTS is compiling straight to IL (I think), something I considered but decided not to for the time being.
I think these are two different approaches. With pros and cons for both.
reply