Carabinieri are actually military-status police force in Italy, which is a different setup from the FBI in the US.
Calling them the Italian FBI, is ironically quite funny, because in Italy they’re the butt of a lot of jokes - "carabiniere" is a common stand-in for "someone dumb".
> Linux is still not user friendly enough. Products from two decades ago are more user friendly than modern "mainstream" disros.
> Gimp is an ugly beast with a bad name. Nobody's using that unless they're a Linux nerd.
It depends on the use case. The vast majority of computer users nowadays use only the browser and an office suite. Even email clients are a thing of the past.
It's true that Gimp doesn't have a great UX, but who spends time photoretouching on the computer, when one can do it in a few seconds on the phone?
It cuts both ways - in those environments, very unhealthy lifestyles (high stress, drug abuse…) are quite common, if not the norm, so even people starting with healthy lifestyles are under significant pressure.
"Zero cost abstractions" refers to some features of the language that provide functionalities with no runtime cost, e.g. (safe) iterators, not to a presumed simplicity of the whole language. Therefore, this is not mutually exclusive with the fact that certain concepts in Rust require more complexity than their counterpart in other languages (after all, the complexities of the borrow checker don't exist in C).
In general, and it applies to the referenced article, programming with a high level of control over the implementation is complex, and there's no way around it. This article explains the concept: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html.
> "Zero cost abstractions" refers to some features of the language that provide functionalities with no runtime cost...
In that case, all languages provide zero cost abstractions.
> programming with a high level of control over the implementation is complex,
> (after all, the complexities of the borrow checker don't exist in C).
The point of an abstraction is to _hide_ complexity.
> This article explains the concept
The article is only half-right. People complain both about the semantics and the syntax, because Rust's implementation of both presents (in some cases) a huge cognitive load that simply doesn't exist in other languages.
Very hard to estimate, depending on the domain, I'd say 1.5-2x as much.
When it comes to programming in languages and frameworks I'm familiar with, there is virtually no increase in terms of speed (I may use it for double checks), however, it may still help me discover concepts I didn't know.
When it comes to areas I'm not familiar with:
- most of the time, the increase is substantial, for example when I need a targeted knowledge (e.g. finding few APIs in giant libraries), or when I need to understand an existing solution
- in some cases, I waste a lot of time, when the LLM hallucinates a solution that doesn't make sense
- in some other cases, I do jobs that otherwise I wouldn't have done at all
I stress two aspects:
1. it's crucial IMO to treat LLMs as a learning tool before a productivity one, that is, to still learn from its output, rather than just call it a day once "it works"
2. days of later fixing can save hours of upfront checking. or the reverse, whatever one prefers :)
It really depends on what's being learned. For example, take writing scripts based on the AWS SDK. The APIs documentation is gigantic (and poorly designed, as it takes ages to load the documentation of each entry), and one uses only a tiny fraction of the APIs. I don't find "learning to find the right APIs" a valuable knowledge; rather, I find "learning to design a (small) program/script starting from a basic example" valuable, since I waste less time in menial tasks (ie. textual search).
If UI bugs are really the issue, then one just sends patches to the upstream project - I'm sure the maintainers will be happy to receive fixes for broken menus. A fork for this is useless, and guaranteed to be abandoned.
Not just useless but another fork that only confounds newcomers and users looking for help. We can be generally opposed to AI without making it a boogeyman.
This sentiment reflect the type of project worked on - small ones. As projects get bigger, more type information gets lost, and that's why it needs to be compensated, typically via automated (unit) testing.
After having worked with gradual typing, unless the application is very disciplined, IMO automated testing is not enough to document the code, as Ruby makes it very easy to use flexible data structures which very easily become messy.
> Many more elaborate projects exist. My favorite is the one that compiles something similar to Turbo Pascal to C64 6502
It depends on the purpose. The reference IDE is intended to produce real-world programs (it includes tools for sprites, music etc.), while high level language compilers are mostly academic, as they're not performant enough.
llvm-mos https://github.com/llvm-mos/llvm-mos seems to generate good enough code - more than competitive with other high-level languages for the 6502, though perhaps not so much with manual assembly coders.
Carabinieri are actually military-status police force in Italy, which is a different setup from the FBI in the US.
Calling them the Italian FBI, is ironically quite funny, because in Italy they’re the butt of a lot of jokes - "carabiniere" is a common stand-in for "someone dumb".
reply