here is your government-mandated recipe for healthy kraft dinner: https://www.canada.ca/en/health-canada/services/canada-food-guide/tips-healthy-eating/meal-planning-cooking-healthy-choices/recipes/mac-cheese-with-veggie-twist.html
god damn nanny state, at it again!
Farscape also had the highest Muppet quotient of any on air sf show. Clearly the choice of the connoisseur.
@ashfurrow In the first one, you can overload visit() all three times and polymorphism will work fine.
Most of the time, the only problem with Java is uneducated kids and consultants using it badly.
@mdhughes I have a difficult time judging people for not yet having internalized such a bizarre thing as a “programming language.”
@ashfurrow The problem is a kid's learned one hammer so that's all they apply to every problem. And the industry hires young inexperienced kids because they're cheap. And then none of our software works worth a shit.
Consultants are worse, because they should know better, but don't bother.
@mdhughes it makes me feel weird to see you call junior developers “kids” – and in any case, it was just a meme. I haven’t even written Java in nine years.
@ashfurrow I do call everyone under 30 "kids". It's very hard to distinguish them from this far side of the event horizon.
I mostly quit Java in 2008, but still maintain a few tools and it keeps those circuits active in my memory.
@mdhughes Aren't your interactions with junior developers then constrained by looking at them as children?
I learn a lot from the juniors I work with, and even in areas where I _am_ an expert, I consider newcomers to be peers.
@ashfurrow If they've specialized in something new, they might have had time to develop one useful skill, but generally the "kids" are literally where I was 2-3 decades ago.
I'm OK with teaching them, as long as I have time, but wouldn't trust their checkins without review.
I also don't have to collaborate a lot, just solve customer problems (often created and left behind by juniors) or work on my own things. If I had to be in a giant corporate machine again that'd be a different social problem.
@ashfurrow The language is simple enough. The ecosystem and API ("standard library") are pure insanity.
Every so often a new solution comes along that has everyone jump on a bandwagon and sing hallelujah! But it hides the fact that at its base language design level, java makes O.O.P. really, really hard and cumbersome.
@aeveltstra that's an interesting perspective. If I may ask, isn't that the goal of the JVM as a compile target? So that languages like Scala and Clojure can take advantage of Java's popularity without having to use the actual syntax?
(Not that Scala isn't a difficult language, too!)
@ashfurrow Yes, it is. And then these other JVM-targeting languages have to build their own API, via which they show, that they hadn't planned for that, and just wind up making a big mess.
It's like how creating a new language is fun. But the ecosystem around it, to male that language practical to use? That's hard work.
@aeveltstra gotcha, that makes sense. Do you think this is why we (I) hear more success stories with languages compiling to the .Net CLR than compiling to the JVM? Because it was designed to be agnostic to languages from the start? (Not that it doesn't have to be hacky about adding support for new constructs, too.)
@ashfurrow I have on-hands experience with several .Net languages. Yes: the CLR does not appear to suffer the exact same issues. It suffers whole other ones.
Inside Powershell for instance, we can mix paradigms in the same script: functional, o.o., procedural, and maybe event-driven too (legacy VB was event-driven and moved from procedural to o.o. over time) - 1/2
But depending of the version of your script engine and the source version of an invoked library, Powershell may force us to employ a different, unwanted paradigm. And apart from finding a different library to invoke, there's literally nothing we can do.
That is not Powershell's fault, as far as I could determine, but the CLR. - 2/2
@aeveltstra interesting – I hadn't realized the different paradigms targeting the same runtime would add such complexity!
@ashfurrow Oh, crud, I tried to write out a DynamicDispatchFunction implementation as a fifth alternative and realized I couldn't do dependent type parameters between the keys and values of a map easily, so I'd probably have to do unchecked casts instead and hmmmmm. (What I want is something like <S> Map<<C> Class<C extends S>, Function<C, R>> if that existed.)
(I bet the real version would be an appropriate response, it's just beyond my silliness attention quota right now)
@ashfurrow can we at least add some electric tape to insulate those contacts. Hate to see cats get hurt
@sturmflut haha, yuuuup. I thought about continuing last year's thread but decided to start a new one in 2019 to avoid crashing any software. Here's 2018's thread: https://mastodon.technology/@ashfurrow/101291161385779358
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!