You can try to blame lack of knowledge on anything you want, but at the end of the day Hacker News is for intellectual curiosity and even HN readers don't all know what monads are.
The incompleteness theorem doesn’t mean it’s impossible to formalize all of mathematics. It just means you’ll need to build out “various” mathematics from a landscape of axioms that are not necessarily all compatible with each other.
They are (quite obviously) saying that this could be changed to British people commenting on how all of the service jobs are Poles, or Canadians commenting how they are all Indian.
That American complaints of this form are not unique and therefore should be disregarded? That American complaints of this form are universal and therefore indicative of a global pattern that should be concerning?
I've had much better experiences with Haskell (well, mostly PureScript for now) than Python, but that might be because I am very hands-on with the design of the core types and abstractions I'm working with.
Having an effect system so that Claude is not tempted to throw in side-effects everywhere helps a lot too!
(For further context, I was comparing essentially vibe code across languages. Vibe-coded Clojure stood out as much less unpalatable than anything else I tried.)
I don't think the problem OP has is anything so metaphysical as the fact/value distinction. This is a business, after all. It has goals (e.g., making money) that the model surely can grasp. It sounds to me more like a breakdown of organizational control owing to a lack of transparency in the tools and a general ignorance among the management.
The parent comment is interesting, but ultimately I think in this case, the AI is actually revealing something about the true nature about their place of employment, a nature that has always been there versus some mutation caused by the prevalence of the AI itself.
A lot of money can be made purely algorithmically. Think market markers or other algorithmic trading. The ought vs is divide is quite narrow here. It's not a moral question, the "value" is in the money to be made. It's actually not a great example to invoke Hume's problem. Many companies essentially are chasing a similar spread, its just less obvious. Few people ever ask what "ought" to exist. If the power of AI makes more businesses operate more reactively and algorithmically, because of more data or processing power or w/e that really is probably in keeping with their alignment and goals. Because the ultimate ought for a company is we ought to be making more money. So, in many ways the ought is really not that interesting, the is is satisfactory provided the return on whatever their version of a spread is keeps improving.
The number of companies that actually "invent" useful things and thus ask even vaguely meaningful "ought" questions are extremely slim. The vast majority of employees are, at best, accessories to these questions, even in software where even before AI many of us were not doing very interesting work. There is a lot of essentially rebuilding your competitors same layers on top of common libraries and standards where the actual interesting work is done. Really not unlike asking AI to cook you up a boilerplate by leveraging the vast work of a fraction of SWEs who maintain OSS tools. It's the same pattern and the same sort of behavior, just now your "layering" is becoming automated to the point of irrelevance.
What the parent misses - the real promise of AI is paradoxically, that it will allow more people to ask actually interesting ought questions as AI owns more of the spreads. In the same way a human does not compete with an algorithmic trader, and at some level, really doesn't care. The more algorithmic your business becomes, the less any individual human "value judgement" matters. And really this is desirable, because again, most companies are not asking interesting value questions anyway. The end state of this you are missing is these companies are going to cease to exist. In the optimistic case this will free you up to ask more interesting value questions - like how do I value all my UBI enabled free time. In the less optimistic case your value judgments will be more dire - like who do I sacrifice given the Terminators are at the door and we only have x quantity of supplies left.
This is the other paradox. When questions of what ought to happen are of paramount importance, you are probably finding yourself in a very undesirable situation. It's easy to valorize the ought problem from a distance, it is much much harder to actually engage with it when it actually matters. In many ways, the relative luxuries of society and civilization are derived from taking such questions out of most of our hands. This is (perhaps surprisingly) true even as you climb the ladder of power:
I used to think that if there was reincarnation, I wanted to come back as the President or the Pope or as a .400 baseball hitter. But now I would like to come back as the bond market.
I love how there’s even errors in the article. Timestamps and time zones are so subtle and nuanced, and people assume they are WAY simpler than they really are. Even smart engineers.
I was kicked out from the MD programme at Université de Sherbrooke due to a procedural failure. The school covered it up, I was devastated.
Six years later after filing the equivalent of a FOIA I realized something didn’t add up. I filed for judicial review, it was denied on prescription grounds (delay) so the court had no need to examine the case on its merits. I appealed, the judgment held.
So yeah, delay/prescription is a real and super serious thing, especially in administrative law. Very strict.
Depends what you're doing, but it really can have C-comparable speed. [0]
Unoptimised/naive Haskell might be that slow. But that's true of a lot of languages and isn't particularly interesting to me. Java is slow if you do everything the naive way, too.
Java ain't slow even if you do really stupid stuff. Hell, I would even argue that java is the most resistant to stupid code. Some way over-abstracted everything linked data structure will be faster in java than it is in C.
Haskell's most badly optimised type, is the String.
Java's most badly optimised type, is the String.
Both of them need a string-builder pattern, the default operators don't work around things to do the right thing for you. They expect you to understand how data works.
The phrase “tends to” is doing a lot of work here. Inexperienced Haskellers tend to use the singly linked list for everything and that data structure just doesn’t perform in any language.
reply