Can confirm this, LLMs write almost exclusively in broken polars. However I convert pandas files to polars semi-regularly, and it's still a hell of a lot faster to get an LLM to write the first draft and correct the 4 or 5 attribute errors it makes
Exactly, unless you rerun with a "popular vote wins" election - it's not concrete at all. The campaigns would not have been run in the same way, and the people would not vote in the same way.
I say this every election when democrats play the "but we won the popular vote" card as well - that wasn't the game being played, so it doesn't really mean that much.
But what are you suggesting? It wouldn't be better if Venezuela had its language dictated by another country (e.g. Spain) - that would just be oppressive.
France has a mechanism to try to stop this: the Académie Française [1] that publishes the official French dictionary. Rather than simply recording language as its used, they do actively try to steer it. They're most well known for trying to suppress anglicisms, e.g. in the early 2000s they pushed 'courriel' instead of 'email'. That one did not work out - email is much more common, and finally entered the dictionary in 2009 (to this day labelled 'anglicism' and discouraged over 'mél').
FWIW the German equivalent is much less prescriptive, it only weighs in on grammar / punctuation.
'Courriel' was coined by French Canadian translator André Clas, not by the Académie Française. The Office québécois de la langue française successfully promoted its usage in Quebec in the 90s and the Académie Française unsuccessfully tried to do the same in France.
'Courriel' is still commonly used by French Canadians, but indeed it was never widely adopted by France. As a French Canadian, I usually use 'courriel", though the anglicism 'e-mail' is also quite commonly used. Can't say I've ever seen anyone use 'mél', tho.
I live near the 1.5m one, it's not really used by road vehicles (or at least I've never seen anyone try it), it's a path used by cyclists / pedestrians.
I think "incongruity theory", that the article is alluding to, does actually apply to most of these. You're focusing on the context rather than the actual underlying mechanism driving the joke. e.g. the first one "bullying, where the joke is not particularly funny..." Consider that the incongruity of a comedian laying into someone verbally, compared to the way we're primed for them to talk in polite-society interactions, may be part of the reason why this works. Similarly example two - "Otis Elevators: They'll never let you down!" - there is an incongruity in the usual usage of the expression 'they'll never let you down' to here, that could be what makes this work as a joke.
I agree there are examples that incongruity doesn't cover, e.g. slapstick I personally believe is something a bit different, but generally I do think it's a pretty compelling explanation for a lot of modern comedy.
One gift of my flavor of ADHD - the instant branching to a multitude of interpretations of some series of inputs and multiple degrees of related ideas - is always being primed to make stupid jokes where I intentionally misinterpret or make you misinterpret something obvious.
Like the other day my friend read "shrimp cargot" off a menu. I said "They taught a shrimp how to drive??" The other friend present thought it was the funniest thing ever while the first friend was in pain from it, which just made it funnier. We had the same 50% split relaying it to two more people later.
(It also relies a bit on knowing the "a shrimp fried this rice?" joke to be funniest but it's not required)
There was an italian phrase book I once ran across and have never seen since: its schtick was that all of the phrases were things one might find in a normal phrase book ("the lobster makes a good salad"), but the accompanying illustrations were of abnormal interpretations (in this case, the lobster in a toque tossing a salad).
Yeah I can relate! I've also heard Conan O'Brien say this before, he thinks that a big source of his comedy is just his brain outright not understanding things correctly.
YES. This is how I explain my brain. It doesn't understand correctly, and so it gets really great at exploring and making legible all the hidden dimensions and edges of thought. And from there, creativity is just taking those discovered dimensions and applying rote transformations: inversions or attenuations or extrapolations to absurd extremes ;)
But what's the alternative here? "We spent longer than was minimally viable but we still don't have a good idea if it has market fit"-product? In my experience the code usually gets binned whether the idea gets traction or not. Some companies misjudge when to rewrite, but that doesn't make the MVP part of the process wrong.
The absolute greatest wastes of talent and humanity I've ever seen in tech didn't come from tech debt, those efforts were almost always at least working on a product that people were paying money for. The biggest wastes were from over-delivering products that hadn't and were never going to succeed.
A portion of “product-market fit” failures are actually software quality failures. I think it’s easy to blame the ensh*ttification of software on corporate incompetence, but I think “minimally viable” is part of the story as well.
The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.
> The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.
Not every area in the software market is like this. For example, in ERP software often applications from the 90ies are still in use (maybe revamped, maybe not) by many customers. And the maintenance periods are measured in decades (typically not initially, but there always seems to be a maintenance extension).
The MVP shows if the idea would get traction. But what good is an idea that gets traction if it is unfeasible to scale, or the organisation is not willing to support it. I think this is what google does with many of its products that end up cancelled. They tested the MVP, people bought in, but the organisation already moved on, so there is no will to support and further develop it. We should be responsible and do an MVP only after deciding if the organisation would be able and interested to scale a product and support it. Otherwise, the downsides are a toxic crunch to support the product, customers are unhappy with yet another product dies, etc...
In my opinion, instead of searching for alternative we should use good programming languages that are extremely refactor-friendly and legacy-resistant.
That's why I love ELM as a front-end langauge (and hope to see a successor ROC succeed).
For back-end, that's why I love Rust, Haskell etc. All languages that are closer to Pure, FP. Because I can leave codebase to other devs and still know that it's not gonna turn into something which I've seen happening to Python, PHP and other OOP language codebases.
Nope, it's not really about the language - any mainstream language/platform can be used well or badly depending on who's guiding the design of the app (assuming somebody is, instead of falling into the "agile means no design up front" cult). You can create an elegantly structured, maintainable app in python, node, rails, .net or you can create a big ball of mud. Perhaps apps in Elm, Rust, Haskell et al have a bias towards better design because they themselves attract an elitist crowd who think more consciously about these things. If Haskell ever caught on enough to have an "eternal September" moment then the world would be littered with shitty codebases of pseudo-pure-functional code that somehow broke all the idioms that are supposed to make the language great.
I once had a client who'd had a shiny but disorganized MVP developed on .NET, and of course as the org tried to scale and ramp up new features, the devs had to fight more and more against the design (or lack of it in some parts, or overly complex over-design in other parts). At some point he met some dude at a networking event who had built a successful business on a Node codebase, and became convinced that we should rewrite from the ground up in Node because our performance problems were all the platform's fault. Wrong wrong wrong. But it's much easier to believe a sales pitch than to do the hard work of learning what good, performant design in your chosen language/framework looks like.
Who knows whether Haskellers are better, on average, at designing software. As a Haskeller I'd like to think they are! But I really have no idea. What I do know is that _I_ can design better software in Haskell than in Python, and I put that down to qualities of the language.
Help, I've seen bad elixir. Ecto queries spanning dozens of tables with the performance grinding to a halt as load increased, with models and logic so intertwined that you had little hope of untangling the ball of string so you could refactor and scale the database.
You can make bad things in any language. I like Go for the same reasons you like FP. And there too, people can do strange and unmaintainable things
If it didn't get traction someone defined badly what was the MVP. As it wasn't viable. The M gives the idea of a minimal feature set or low effort but it shouldn't, a MVP now that competition is high needs much more quality and features than a decade ago
reply