5,761 karma · joined October 23, 2022
The obvious solution is doing what many large companies, as well as other governments are doing. Create your own Font. (e.g. https://styleguide.bundesregierung.de/sg-de/basiselemente/sc... https://www.ibm.com/plex/)
But they do not compete. They have totally different jobs.
Shifting the blame away from DB, who is responsible for creating the terrible track conditions and is responsible for the operations, to the train operator, who zero ability to influence what DB is doing is just totally unfair.
DB is at fault here, they lead the train onto the wrong tracks and they also caused the previous delays. Regional trains in Germany have many different kinds of operators. Taking any of them is always miserable in exactly the same way, which is in almost every case caused by DB, because they can not operate the train network.
What is worse is that these operators also get into conflict with the DB trains. E.g. they prioritize a DB train, which is already late, over a regional train, causing delays for regional trains.
I do not know and do not care what the "hypepeople" say. I can tell you that, by pure logic alone, LLMs will be superior at simple and routine tasks sooner, which means they will compete with outsourced labor first.
LLMs need to be measured against their competition and their competition right now is outsourced labor. If an LLM can outperform an offshore team at a fraction of the cost, why would any company choose the offshore team? Especially when the LLM eliminates some of the biggest problems with offshore teams (communication barriers, round trip times).
If LLMs take any programmer jobs they will at the very beginning make those outsourced jobs obsolete, so the only relevant question is whether they have done that or are in the process of doing so. If they don't, then their impact will be minimal, if they do, then their impact will be massive. I think that this line of thinking is a far better benchmark then asking whether an LLM gets X or Y question wrong Z% of the time.
>They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
>LLMs pretend to do this with big confidence and fail miserably.
This is true for most developers as well. The mean software developer, especially if you outsource, has failure modes worse than any LLM and round-trip time is not seconds but days.
The promise of LLMs is not that they solve the single most difficult tasks for you instantly, but that they do the easy stuff well enough that they replace offshore teams.
In all of the cases the main prediction that was made came true. The cost, especially the human cost, of developing some piece of software dramatically decreased. The only reason why the amount of programmers needed still rose was because the amount of software needed rose faster.
Clearly that trend will not hold forever.
>The hard part of computer programming isn’t expressing what we want the machine to do in code. The hard part is turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
And there is exactly one single technology which has ever been able to do this task, which is LLMs. Not addressing the elephant in the room, which is that an LLM can actually take such instructions and produce something meaningful with it, just makes the whole article worthless.
Everything in this article is just inverse special pleading. Since the last N times, the most enthusiastic predictions did not come true, this time only minor changes can happen. If LLMs are only a revolution on the scale of fast interpreted languages (which have significantly impacted what a small team is capable of delivering in terms of complexity), then they will drastically impact most of the software industry.
If these changes happen, and simultaneously the rate at which software is demanded does not also increase (why would it?), then the implications will be extremely serious. Especially if you are not a developer in an established position.
It is totally absurd how far Tesla has fallen behind legacy auto makers, who are now starting up their own battery production and are very close to actually releasing a 25.000 Euro car in Europe.
What does ZF(C) have to do with decidability? Decidability is a question in any sufficiently complex system (Gödel's first theorem). And exactly this distinction is what I made for the taxonomy of propositions, you can group them into true and false and also into provable and unprovable. What would be a fact and what would be a law?
Regardless of that, in neither case the empiricism the site uses to define a fact would play any role.
> and correctly taxonomising those propositions
The correct taxonomy for a proposition is true/false and proven/unproven.
I can not even fathom a mathematical model where distinguishing a "law" from a "fact" is meaningful.
And the idea of defining a "fact" as something empirically demonstrated is just ridiculous, I totally reject it.
But the first exercise is about judging statements based on nebulous definitions, definitely unrelated to mathematics?
Either the government acts justly and I support their actions or it acts unjustly and I will oppose that action. Whatever some piece of paper says or does not say I do not mind.
+ Of course I care about it in so far I have to understand how getting into conflict with the prevalent interpretation of it will have consequence for me or my family or my friends. I pay my taxes, after all.
>which means the immigrants with the most optionality of where to go (like researchers, engineers, and high value contributors in general) are disproportionately likely to seek other destinations.
>It would have the least deterrent force on those who are already criminal and otherwise lawless or desperate.
Completely agree. But I want the "researchers, engineers, and high value contributors" even less than the rest. Those groups are actually harder to remove, they often have institutional support in the form of corporations and other associations and might feasibly be positive fiscal contributors. With "the rest" the argument for deportation is far simpler and has far more support in the population. Also my labor competes with the "researchers, engineers, and high value contributors", while "the rest" only depresses the wages of the proletariat who now have to compete with black market labor.
Total nonsense. This only applies to the state. Individuals are totally free to believe that a person not convicted of a crime or even proclaimed innocent by the state, is in fact not innocent.
If your legalistic fiction of innocence was correct, then individuals would have to believe that the law is the infallible representation of morality, which is an abhorrent claim. What I meant by the quotes around innocent is that the state has not yet deemed them criminal, but I disagree with the state on that assessment.
One idea which should be explored, both in the US and the EU, is that all lawsuits against immigration decisions have to be paid, either ongoing or up front, by the person who would be affected by the immigration enforcement.
Right now I think these measures are extremely effective, especially at deterrence and I do not see what your arguments against this being an effective deterrence really is. One good step from the legislative would be removing the legal basis for the civil rights lawsuits, so they can be thrown out immediately.
>which actually has the effect of keeping dangerous people (always been high-priority) in the country longer.
I agree. The processing should be much faster. The detentions are so stupid, just get them on a plane.
Whatever beauty exists in engineering comes from the purity of it. A fighter plane or a microchip looks beautiful, not because it was designed to be so, but because of the purity of the functionality, the harshness of the requirements. If you turn a fighter plane into an art project, then it will be inherently ridiculous. It will make a mockery of its own purpose, looking at it will be like looking at a cripple.
>suits
shirts was what I said. Not suits.
What a terrible idea. Implementing mathematical functions is extremely hard to do well. And by well I mean "function properly at all". This isn't about speed, this is about the fact that if you haven't done actual research into what you are implementing, then your implementation is going to full of errors, many of them totally non obvious. Rolling your DIY numerics, without spending a lot of time on it is just asking for problems.
People like this make me hate everything to do with software. Software should be an engineering field, which exists to help humans, not as some personal art project for your self expression. I do not want to interact with these people at all. If you derive your identity from being a programmer you are actually harmful and I hope that I will never have the misfortune of having to work with you.
And yes, if you do not capitalize properly, then I do not see you as fully human. And if you keep swearing you sound like a twelve year old.
The question is stupid and I think Sandfall should be given the benefit of doubt that they interpreted the question not literally, but in a way which actually makes sense.
Putting essentially arbitrary limitation on which tools game developers are allowed to use is just nonsensical. Yes, the output of AI models can be really bad, but then a game obviously does not deserve an award. Especially for an indie game, with limited resources, AI can be a huge force multiplier. Gatekeeping awards based on these meaningless characteristics seems just very strange.
This is just a lie though. Non-Euclidean geometry is a mathematical model of how distances behave on non-linear spaces. Nobody ever believed it to be a "fundamental mistruth", even suggesting it would look ridiculous. It would be akin to denying linear algebra, even the meaning is unclear.
That the physical reality of space is not linear was a shocking revelation, since all human experience and basically every experiment done up until that point indicated otherwise.
>and if one has trouble modeling something, well, arriving at a solution is just a matter of learning the appropriate mathematics.
Which is the terrible thing about OpenSCAD. YOU need to derive the equations. In a modern CAD program you define the constraints on the object and the equations are derived for you.
>It's extremely easy to pick up if you have programming experience and it might even be a good thing to learn before moving onto more professional CAD software.
No, it definitely is not. OpenSCAD makes you think exactly the wrong way about CAD, because it forces you to reason explicitly about your model, when that is something which you need to let the CAD Software do for you. Modern Parametric CAD works by the user defining constraints, which the Software uses to derive the shape of the model, this is not something which conceptually exists in OpenSCAD.
>From a teaching perspective, being able to have almost immediately-useful output is priceless
Which is something which modern CAD does just as well.
The big distinction is that those work implicitly, while OpenSCAD requires you to be implicit.