Hmm, I mean I totally understand the overlap in functionality. Especially when you get into the Java Lombok situation where annotations are as structural as the modifiers themselves. But there are clear cases in things like Python and Rust where the modifiers are a clear meta-programming that are mostly outside the scope of the language itself.
Granted, Rust is a weird example where annotations tend to “graduate” to the language itself, like in the form of #[async], but that clear delineation of what’s in the language itself and what’s defined as post-processing still leaves it more readable than if we heaped a chunk of similar-looking-but-willdy-different-effect-wise tokens on top of our function/type definition. E.g.,
Like, I do get the similarity in function, but it’s almost like why we have capitalization in our natural languages. Making language-defined features “louder” and more ingrained in the language itself makes sense, even if the border is fuzzy.
I believe that if you start from an annotation-only stance, then you will look at the language, its defaults and possible extensions differently, because annotations are “visually” more expensive than slapping yet-another keyword on something.
I. e.:
“no visibility modifier” should probably mean “public”
defining the external API should move to the module-level altogether
we should probably use var instead of let mut
#[cfg(target_os = "windows")] is just bad design overall
instead put different targets into different folders: much easier, works better
async should not exist at all
(though not related to annotations vs. modifiers, but because the whole idea is a language design dead-end)
So the code from your example would literally be …
fun some_func: Unit = {var my_var = 3u2
// ...
… in my design.
Rust’s syntax with #[...] is not that great in this regard, as it triples the amount of symbol involved for simple annotations compared to something using @....
Jfc that’s a bit of a stretch. You basically just said “you are wrong to use those features, and if you don’t use those features then my solution is great”. Like yeah, no shit, if I wanted a toy language I’d go back to using Logo.
“no visibility modifier” should probably mean “public”
For-fucking-real?
instead put different targets into different folders: much easier, works better
Ahh, yes, file-based programming, the most usable and ergonomic pattern for cross-cutting concerns. /s
async should not exist at all
The most I’ll give you there is that it’s used more frequently than it should. But it is far and away the best abstraction for bare-metal concurrency without a runtime. Your “dead end” comment reeks of writing off an entire language feature because you don’t understand it or why it solves problems no other language feature solves as well.
Normally I’m open to discussing the merits and comparing drawbacks to certain approaches, but of course I’m going to be cross if you dump a bunch of confident horseshit on me. Like, wtf man??
I spent the necessary effort to experiment/work with the various approaches to form an opinion, and your main counter argument is largely … being sarcastic, trying the hardest to misunderstand things to ridicule them and being generally offended?
Let’s end this here, your comments are a poor use of my time.
Statements like “async is a language design dead-end” is the confidently correct misinfo that I’m talking about. You can’t expect anyone to take you seriously if you authoritatively present your opinions as gospel.
Should I instead have interpreted it as “async is a language design dead-end, and by dead-end I mean overfitted standard for the problem space?” Because I really have to be charitable and put words in your mouth to paint your argument in a good light.
Hmm, I mean I totally understand the overlap in functionality. Especially when you get into the Java Lombok situation where annotations are as structural as the modifiers themselves. But there are clear cases in things like Python and Rust where the modifiers are a clear meta-programming that are mostly outside the scope of the language itself.
Granted, Rust is a weird example where annotations tend to “graduate” to the language itself, like in the form of
#[async], but that clear delineation of what’s in the language itself and what’s defined as post-processing still leaves it more readable than if we heaped a chunk of similar-looking-but-willdy-different-effect-wise tokens on top of our function/type definition. E.g.,#[cfg(target_os = "windows")] #[pub] #[async] fn some_func() { #[mut] let my_var = 3u2; // ...Vs.
#[cfg(target_os = "windows")] pub async fn some_func() { let mut my_var = 3u2; // ...Like, I do get the similarity in function, but it’s almost like why we have capitalization in our natural languages. Making language-defined features “louder” and more ingrained in the language itself makes sense, even if the border is fuzzy.
Edit: even going the other direction, and we do:
pub cfg(target_os = "windows") async fn some_func() { let mut my_var = 3u2; // ...That homogenization is still a bit of a bitch to read
I believe that if you start from an annotation-only stance, then you will look at the language, its defaults and possible extensions differently, because annotations are “visually” more expensive than slapping yet-another keyword on something.
I. e.:
varinstead oflet mut#[cfg(target_os = "windows")]is just bad design overallinstead put different targets into different folders: much easier, works better
asyncshould not exist at all(though not related to annotations vs. modifiers, but because the whole idea is a language design dead-end)
So the code from your example would literally be …
fun some_func: Unit = { var my_var = 3u2 // ...… in my design.
Rust’s syntax with
#[...]is not that great in this regard, as it triples the amount of symbol involved for simple annotations compared to something using@....Jfc that’s a bit of a stretch. You basically just said “you are wrong to use those features, and if you don’t use those features then my solution is great”. Like yeah, no shit, if I wanted a toy language I’d go back to using Logo.
For-fucking-real?
Ahh, yes, file-based programming, the most usable and ergonomic pattern for cross-cutting concerns. /s
The most I’ll give you there is that it’s used more frequently than it should. But it is far and away the best abstraction for bare-metal concurrency without a runtime. Your “dead end” comment reeks of writing off an entire language feature because you don’t understand it or why it solves problems no other language feature solves as well.
Normally I’m open to discussing the merits and comparing drawbacks to certain approaches, but of course I’m going to be cross if you dump a bunch of confident horseshit on me. Like, wtf man??
I spent the necessary effort to experiment/work with the various approaches to form an opinion, and your main counter argument is largely … being sarcastic, trying the hardest to misunderstand things to ridicule them and being generally offended?
Let’s end this here, your comments are a poor use of my time.
Statements like “async is a language design dead-end” is the confidently correct misinfo that I’m talking about. You can’t expect anyone to take you seriously if you authoritatively present your opinions as gospel.
Should I instead have interpreted it as “async is a language design dead-end, and by dead-end I mean overfitted standard for the problem space?” Because I really have to be charitable and put words in your mouth to paint your argument in a good light.