Not to be too pedantic, but code is a kind of specification. I think making the blanket statement "Prompt is code" is inaccurate but there does exist a methodology of writing prompts as if they are specifications that can reliably converted to computational actions, and I believe we're heading toward that.
I worked on Dockside last year (https://hachipoo.com/dockside-app) — a small macOS app that makes use of the unused space around the Dock (especially nice on widescreens). It’s non-intrusive and lets you drag & drop files, jot quick notes, or add shortcuts right beside the Dock so they’re always handy without cluttering the desktop.
Right now I’m adding few of the most requested user-requested features (vertical Dock support etc.) and working on refining it for Tahoe release.
I completely agree with this.
I never understood how this became the new normal and mostly acceptable in the new generation vehicles (especially the EVs) in the name of progressive/futuristic design.
I hope the automobile manufacturers take a note of this, and bring back some of it that’s worked for decades. I believe few German manufacturers like the Mercedes-Benz to have a sense of this, hope they don’t get along with this trend too.
It's just cheaper to design and certificate one part and put it on multiple models than making dedicated analog controls for every new design. Touchscreens are just cost cutting measure. I wonder how many people died fiddling with car radios so one pencil pusher could get a bonus for skimming $10 off manufacturing cost.
I started my career with a first job in 2009 (not long time ago!) as a COBOL/JCL programmer (and went on to do TELON programming later) for one of the biggest retailer in the country.
The systems that managed the forecasting for replenishable and non-replinshable products, markdowns (i.e., discounts) on products in the stores, stock warehouse etc. across the country was completely built on COBOL/JCL+DB2 stack combined with TELON online screens for business to manage the solution/system.
This system practically worked round the clock with hardly any downtime, and in the peak season (like Christmas when the sales/transactions were at it's high) too worked without any major issues. I'm sure IBM still earns a big chunk of revenue from mainframes from these big customers.
I remember an attempt was made to migrate some (if not all) to a new generation data analytics platform and it didn't go very well, so they just stuck with what they had.
One of the main reason I can think of is the the cost of this migration was too high (vs. the realised benefit) as the system just worked for the business and was quite resilient.
I since then jumped ship to the very technology they were trying to migrate too and have never looked back really. I think I can still work my way out of COBOL/JCL + TELON/CICS, perhaps I will forget them very soon :)
I was part of a team that wrote a paper for a customer on replacing 5 million lines of legacy COBOL code with either hand-written or machine-generated Java for a major system. The cost was in the mid 9 figures.
Scala is unfortunately famous for having a toxic community as well. I've emailed with most of the "famous open source" Scala folks and they've all been really nice. But the subreddit seems to have some nasty folks, especially compared with other communities I've been involved with. It's a shame. It's a great language and the people producing the popular libraries are nice.
Because we're trying to turn people on to functional programming, not off
EDIT: Downvotes already? Look, Scala is NOT noob-friendly, and it's a rational argument, not a preference. Here's an example: There are at least 10 (TEN) different uses of the underscore character (_) in Scala. JFC. I can go on, such as the proliferation of bizarre operators everywhere that are impossible to Google (again, not noob-friendly), the reliance on JVM (ewww... so you end up having to be a Scala expert AND a Java expert... plus deal with JVM windup time and JVM stacktraces... Not noob-friendly), the consistent violation of POLS, etc. etc.
When is the last time you used it? I've been a full time scala developer for over 4 years now spanning versions 2.11, 2.12, and now heading into 2.13. There have been massive improvements across consistency and huge convergences happening across the scala FP community in terms of library usage.
> the reliance on JVM (ewww... so you end up having to be a Scala expert AND a Java expert... plus deal with JVM windup time and JVM stacktraces... Not noob-friendly)
This is just plain weird. This makes me feel like you spent zero time actually working with the JVM and it's incredible ecosystem. Being fully inter-operable with Java is a huge win for both adoption and usability. Not only that but the JVM is one of the most mature runtimes in existence with massive amounts of documentation and help available.
It might have some justification, but it's just your preference. Scala gained a reputation of being a "difficult" language early on, I suppose mostly by people coming from Java, and it has unfortunately stuck.
Singling out underscores in Scala as "difficult" is bizarre. There might be many, but in practice it's very easy to understand what you want, and I've never seen anyone seriously confused by them. What do you mean, "many bizarre operators"? Are you using ScalaZ maybe?
What do you mean, JVM stacktraces are not newbie-friendly? They are a useful tool to troubleshoot many problems. What problems do they have in your opinion?
What's wrong with relying on the JVM?
Scala type signatures are sometimes hard to understand in library code. You are not expected to write code like that unless you are writing general purpose libraries, which you are likely not doing.
It's that the user needs to learn not just Scala but also Java whenever they want to do anything "real". You might say this is a minor hangup, but for learners having to context switch back and forth between Java and Scala and dealing with interop issues can make for much more cognitive load than using a non-hosted language like Python or Go.
That Scala has a vast array of Java libraries is a strength, not a weakness. Interop issues between Java and Scala are not a big deal, anyway. It's mostly seamless.
Nothing’s noob-friendly if you begin with advanced features.
Scala is eminently beginner friendly when introduced to developers familiar with OOP. This approach was how I first experienced Scala and it ended up becoming a gateway drug into FP proper.
Regarding underscores in Scala, yes there are many technical terms for each thing it has the capability of representing... but in reality, you just use it wherever you want to ignore a value with a placeholder or pass a provided value through.
I learned Scala a few years ago and have some popular open source Scala libs. I like Scala, but wouldn't call it "eminently beginner friendly". Coming from Ruby, it was hard for me to learn SBT, Maven, Scalatest (much more complicated than Gemfiles, rubygems, and rspec in my opinion). With Ruby, you can easily make an Array.
Scala newbies find it hard to even perform basic Array operations. You need to dig into Array, Seq, and List, figure out the differences, try to see what's accepted by the community, etc.
The dominant OO+FP paradigm of Scala code is one of the most powerful, imo. Combining immutable objects with FP constructs is my favorite way of programming and something that only Scala can really do (well OCaml can, but no one uses objects).
Scala is probably the most flexible and powerful statically typed language currently in widespread use and I would probably choose the language for most non-scientific computing greenfield projects.
In my experience of on boarding developers who didn't know Scala or Java into a large Scala project, it's really not that hard to learn. Developers were writing okay code in the first week and completely idiomatic code after the first couple weeks.
The JVM does suffer from non-transparent performance characteristics, but the highly optimized and tested platform makes up for it.
Scala the language is getting better and better and Scala 3 will really be something special, I think.
The worst part of the JVM is dependency management. Upgrading the version of Scala you're using is unbelievably painful and in a lot of cases impossible.
My old Scala shop is still running on 2.10 because no ones bothered to put in the weeks of work to upgrade.
I wrote this simple SAS program/job scheduler (https://github.com/PrajwalSD/runSAS) using just bash script (with few utils) intentionally to allow for maximum adoption in projects and just made it more more colorful. In short 75% of the code in there is just handling the terminal (keys, scroll, progress bar etc.) and 25% is the actual load balancing logic.
And many of those apps end up with terrible performance. I'm sure it's possible to write a performant electron app, but I don't see it happen often and it's disappointing.
