I hate Scala, vol. 2
-
@Gąska yeah, Kotlin assigns a lot of importance to inline. For example you can do reified generics in inline functions, but nowhere else.
-
@pie_flavor It sounds like there are several use cases being overloaded into the same general area, especially:
- True functions as first class objects. Here,
returnshould only return from the function. - Inner blocks of code to make custom control structures. Here,
returnshould return from the enclosing function, andbreakandcontinuemay also be meaningful.
Both seem useful to me. However, I think that if they have behaviours that are different in this way, they should have different names.
- True functions as first class objects. Here,
-
@dkf Well, the other important bit is that in Kotlin the syntax is consistent. In a lambda,
returnalways returns from the actual method, andreturn@labelalways returns from the lambda labeledlabel- if you're not passing an inline lambda,returnis a compile error, you must use last-expression returns orreturn@labelreturns. To hear @Gąska describe it, in Scalareturndoes a functional thing when not inlined and a control-structure thing when inlined, which is awful.
-
@Mason_Wheeler said in I hate Scala, vol. 2:
So... they copied Ruby's behavior?
I don't know where the brain worm of Ruby following the "principle of least surprise" came from (not from the creator, apparently), but every time I learn something new about Ruby, it seems like the guiding light of the language is actually the principle of most surprise
-
@levicki said in I hate Scala, vol. 2:
@Gąska Just give up and start using C and goto.
In my minesweeper implementation I definitely ran into the lack of lambdas in C.
-
@Gąska said in I hate Scala, vol. 2:
@pie_flavor said in I hate Scala, vol. 2:
@Gąska That's why
inlineis important. It doesn't cross stack frame boundaries.Implementation detail. Conceptually it's still separate frames.
Not if you know what inline means.
-
@boomzilla inline means a friendly suggestion to the compiler that maybe perhaps it could see into whether a program may run better if the function code was copied into call side instead of actual call being generated, but it's perfectly fine if it doesn't happen for whatever reason. Anything else is descending into the world of madness. Especially if inlining causes the callee to perform hostile takeover of the parent call frame and do whatever the fuck it wants, including terminating it early - not as a codegen-time optimization, but as an actual part of function call semantics of the high-level language.
-
@hungrier said in I hate Scala, vol. 2:
@Mason_Wheeler said in I hate Scala, vol. 2:
So... they copied Ruby's behavior?
I don't know where the brain worm of Ruby following the "principle of least surprise" came from (not from the creator, apparently), but every time I learn something new about Ruby, it seems like the guiding light of the language is actually the principle of most surprise
Same here. Did you know that if you don't explicitly use return in a function it will implicitly return the last thing was set.... ?!?!?
-
@CodeJunkie it's like they've taken a weird side effect of C's calling convention and made it into full-fledged feature. How do those people even come up with stuff like that?
-
@Gąska said in I hate Scala, vol. 2:
@CodeJunkie it's like they've taken a weird side effect of C's calling convention and made it into full-fledged feature. How do those people even come up with stuff like that?
It's just laziness. Ruby advocates seem to think this is a great idea too... "It's one less line of code!!" ... as if it's not a bug waiting to happen. I tried to explain to the young kid that used to work for me why this was not a good idea and he didn't seem to understand. It makes sense however, since he hasn't had to maintain any software over long periods of time....in-fact I'm maintaining the stuff he wrote now because he left the company last year.
-
@hungrier said in I hate Scala, vol. 2:
@Mason_Wheeler said in I hate Scala, vol. 2:
So... they copied Ruby's behavior?
I don't know where the brain worm of Ruby following the "principle of least surprise" came from (not from the creator, apparently), but every time I learn something new about Ruby, it seems like the guiding light of the language is actually the principle of most surprise
when i figure out who decided that the idiomatic way to implement code features is to REPLACE library functions at runtime..... I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
Adding new methods to library functions is okay so long as the addition is scoped so that my
string.SuperAwesome()can't be overwritten by yourstring.SuperAwesome(), or visa versa, but once we can start overwriting each other then that's crazy town, and making it the idiomatic way to program in the language, not only for extensions to the standard library, but also the standard library itself....... yeah that's when i get all BofH on your ass.....
-
@levicki No, it's a sign to switch to ML or Haskell.
-
@CodeJunkie said in I hate Scala, vol. 2:
Ruby advocates
@CodeJunkie said in I hate Scala, vol. 2:
he hasn't had to maintain any software over long periods of time
But you repeat yourself.
-
@Vixen said in I hate Scala, vol. 2:
I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
Talk to @Lorne-Kates. I'm sure he can help you out; he's our resident expert on such things.
-
@HardwareGeek said in I hate Scala, vol. 2:
@Vixen said in I hate Scala, vol. 2:
I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
Talk to @Lorne-Kates. I'm sure he can help you out; he's our resident expert on such things.
i'll do that, thanks. :-)
-
@HardwareGeek said in I hate Scala, vol. 2:
@Vixen said in I hate Scala, vol. 2:
I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
Talk to @Lorne-Kates. I'm sure he can help you out; he's our resident expert on such things.
And if you need a fortuitous incident involving flammable materials, @Polygeekery is your
manpersyn.
-
@Captain said in I hate Scala, vol. 2:
@levicki No, it's a sign to switch to ML or Haskell.
Nah, those have some great features but try to cram stupid shit like forced immutability down your throat. Rust takes all the good parts from them without doing that, that's why it's the best.
-
@pie_flavor said in I hate Scala, vol. 2:
@Captain said in I hate Scala, vol. 2:
@levicki No, it's a sign to switch to ML or Haskell.
Nah, those have some great features but try to cram stupid shit like forced immutability down your throat.
Forced immutability is the best.
Rust takes all the good parts from them without doing that, that's why it's the best.
Huh? It has more immutability than all MLs and Haskell combined. (Edit: which is good.)
-
@Gąska No, I mean lack of mutability. Functional languages, even the ones that allow mutable variables, don't have a standard library and language features designed around mutability. Rust does.
-
@lolwhat said in I hate Scala, vol. 2:
@HardwareGeek said in I hate Scala, vol. 2:
@Vixen said in I hate Scala, vol. 2:
I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
Talk to @Lorne-Kates. I'm sure he can help you out; he's our resident expert on such things.
And if you need a fortuitous incident involving flammable materials, @Polygeekery is your
manpersynasshole.Get the preferred pronouns right!
-
@pie_flavor said in I hate Scala, vol. 2:
@Gąska No, I mean lack of mutability. Functional languages, even the ones that allow mutable variables, don't have a standard library and language features designed around mutability. Rust does.
ML's absolutely do have mutability-oriented features (meaning whatever container you need, nothing stops you from rolling your own). But yes, there aren't many mutable containers in their standard libraries. Although it's not about some aversion to it, but rather about their standard libraries sucking in general. OCaml, arguably the most popular ML variant in the industry, had its community rewrite and redesign the whole stdlib from scratch, several times - and one of them is currently more popular than the actual stdlib.
Of course, if you write in functional style, there's very little need for mutability anyway. Sure, you can gain performance from it, but who chooses functional language for performance?
-
@Vixen said in I hate Scala, vol. 2:
I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
I've read somewhere that adding quicklime is actually a bad idea. It dries out stuff around it, which helps hiding surface indications like smell, but that also means that it preserves whatever you've buried for longer. If you want it to degrade and not leave any trace, you should not add lime and let nature follow its course.
Not that I have ever needed that, of course
-
@remi said in I hate Scala, vol. 2:
@Vixen said in I hate Scala, vol. 2:
I'm going to need a six foot deep hole, a roll of old carpet, two hundred pounds of quicklime....
I've read somewhere that adding quicklime is actually a bad idea. It dries out stuff around it, which helps hiding surface indications like smell, but that also means that it preserves whatever you've buried for longer. If you want it to degrade and not leave any trace, you should not add lime and let nature follow its course.
Not that I have ever needed that, of course
For further reading on the subject: https://www.researchgate.net/publication/51748334_Effects_of_hydrated_lime_and_quicklime_on_the_decay_of_buried_human_remains_using_pig_cadavers_as_human_body_analogues
-
@Gąska said in I hate Scala, vol. 2:
Of course, if you write in functional style, there's very little need for mutability anyway. Sure, you can gain performance from it, but who chooses functional language for performance?
Well they do fit in that niche between compiled imperative (fast but dogshit stupid) and interpreted imperative (slow and even dumber).
And, much like the interpreted imperative, you always a foreign function interface to hook into the fast C etc libraries.
-
@Captain that niche is occupied by Java and C#.
-
-
@Gąska said in I hate Scala, vol. 2:
@Captain that niche is occupied by Java and C#.
Dumb, Dumber, and Java?
-
@Captain said in I hate Scala, vol. 2:
The
factor wasn't the topic. With functional languages, you pay for sensible code with performance.
-
@Gąska Yeah, but it's still cheaper than imperative interpreted like Perl or Ruby (especially Ruby, with it's huge dynamic dispatch stacks that put in a damn un-cacheable search for every single object at every single method call). My point being, you can do acceptable speed with FP relatively easily, and tuning isn't THAT hard.
-
@Gąska said in I hate Scala, vol. 2:
@CodeJunkie it's like they've taken a weird side effect of C's calling convention and made it into full-fledged feature. How do those people even come up with stuff like that?
Unifying expressions and programs like that is fairly common. What's more, if it is a defined behaviour, something that can be relied upon, then it is safe to use (unlike that C side effect, which is very unsafe).
-
@CodeJunkie said in I hate Scala, vol. 2:
@hungrier said in I hate Scala, vol. 2:
@Mason_Wheeler said in I hate Scala, vol. 2:
So... they copied Ruby's behavior?
I don't know where the brain worm of Ruby following the "principle of least surprise" came from (not from the creator, apparently), but every time I learn something new about Ruby, it seems like the guiding light of the language is actually the principle of most surprise
Same here. Did you know that if you don't explicitly use return in a function it will implicitly return the last thing was set.... ?!?!?
Yes, actually.
-
@levicki said in I hate Scala, vol. 2:
Real men write code in assembler. Case closed.
Real men use bots to write posts for them.
@discobot xkcd real programmers
-
@error_bot !xkcd real programmers
-
-
@levicki said in I hate Scala, vol. 2:
Real men write code in assembler. Case closed.
I encountered a program today that uses inline assembly (in C) to tinker with the stack pointer for no obvious reason. Or at least I chose not to look at it long enough to find the reason. Just pretend I never saw that, and hope I don't have nightmares.
-
@HardwareGeek said in I hate Scala, vol. 2:
@levicki said in I hate Scala, vol. 2:
Real men write code in assembler. Case closed.
I encountered a program today that uses inline assembly (in C) to tinker with the stack pointer for no obvious reason. Or at least I chose not to look at it long enough to find the reason. Just pretend I never saw that, and hope I don't have nightmares.
I happen to know the only inline assembler block in our codebase consist of only
rdtsc. Though I may have kicked it out at some point.
-
@levicki It appears to be error handling code. It's a test that appears (if the comments are to be believed) to intentionally trigger a fatal hardware error. The assembly code recovers from the fatal error, because a fatal error (at the right place in the test) is a passing condition, and no error (or one when the test isn't expecting one) is an error. So definitely hacky, but also valid, I guess, maybe.
-
@levicki The (always_inline) function was all of three instructions (twice, because #ifdef for different compiler syntax for inline assembly).
-
@Captain said in I hate Scala, vol. 2:
Well they do fit in that niche between compiled imperative (fast but dogshit stupid)
You have clearly never tried Rust.
-
@levicki said in I hate Scala, vol. 2:
Real men write code in assembler. Case closed.
Ending up with code that's actually slower than in a compiled language.
-
@pie_flavor said in I hate Scala, vol. 2:
@Captain said in I hate Scala, vol. 2:
Well they do fit in that niche between compiled imperative (fast but dogshit stupid)
You have clearly never tried Rust.
From the two attempts I have made at getting into Rust, I have to say that it seems to fit that description perfectly; way more than, for example, C++.
-
@pie_flavor said in I hate Scala, vol. 2:
Ending up with code that's actually slower than in a compiled language.
Maybe on Earth-73.
-
@ixvedeusi what about Rust is stupid?
-
@Zerosquare said in I hate Scala, vol. 2:
@pie_flavor said in I hate Scala, vol. 2:
Ending up with code that's actually slower than in a compiled language.
Maybe on Earth-73.
no? A compiler is way smarter than you are at creating optimized assembly code.
-
@ixvedeusi said in I hate Scala, vol. 2:
@pie_flavor said in I hate Scala, vol. 2:
@Captain said in I hate Scala, vol. 2:Well they do fit in that niche between compiled imperative (fast but dogshit stupid)
You have clearly never tried Rust.
From the two attempts I have made at getting into Rust, I have to say that it seems to fit that description perfectly; way more than, for example, C++.
It just got way better in recent months, thanks to new borrow checker implementation - WAY less false positives, which makes it actually usable in normal code. Also, they've just shipped anync/await!
@pie_flavor said in I hate Scala, vol. 2:
@Zerosquare said in I hate Scala, vol. 2:
@pie_flavor said in I hate Scala, vol. 2:
Ending up with code that's actually slower than in a compiled language.
Maybe on Earth-73.
no? A compiler is way smarter than you are at creating optimized assembly code.
Smarter? Hell no. But it is way more consistent. So unless your life depends on that bit of assembly (which it sometimes does), it's not worth it.
-
-
@pie_flavor said in I hate Scala, vol. 2:
@ixvedeusi what about Rust is stupid?
First time I tried, I abandoned because the
lifetime trackingborrow checker was just too fricking dumb to figure out even the most trivial of cases, forcing me to hold its hand and gently leading it through all the steps, vomiting pointless lifetime annotation noise all over the code in the process.Second time I tried, that part seemed to have gotten better, but then the type system was too dumb to figure out some just-above-trivial case; don't remember the details but it was some transitivity issue about trait A inheriting from trait B inheriting from trait C where A couldn't figure out that it had implementations for trait C's functions or something like that. I ended up in some chapter in the docs that basically said "we haven't gotten to implementing this yet, just duplicate all your code lol" so I went "yeah no, I might get back to you once you've gotten around to implementing a usable type system".
I'm not fond of traits type systems in general, they seem to result in messy non-localized code that's difficult to structure in a meaningful way; but I'll admit that may be because I'm not familiar enough with that approach yet and haven't figured out the best ways to make use of it.
I also hate the brain-dead "your app is in fact a library" nonsense, and more generally the fact that Rust appears to be too dumb to figure out any kind of project structure other than their holy One True Way Of Organizing Thy Codes, never mind how much sense that structure makes to your project. Also the error messages pretend to be all useful and informative, meaning they're very verbose and prosaic, but half the time they seem to point to the completely wrong section of the code and show a complete lack of even the most basic understanding of the program. At that point I much prefer C++'s honest vomit of standard legalese and compiler nitpicking, at least there's no pretense there and we can get right down to the facts.
Maybe I'll give it another try in a few years if I have a week or two to waste at some point, we'll see.
-
-
@pie_flavor said in I hate Scala, vol. 2:
@ixvedeusi what about Rust is stupid?
The fanboys it comes with
-
@ixvedeusi said in I hate Scala, vol. 2:
@pie_flavor said in I hate Scala, vol. 2:
@ixvedeusi what about Rust is stupid?
First time I tried, I abandoned because the
lifetime trackingborrow checker was just too fricking dumb to figure out even the most trivial of cases, forcing me to hold its hand and gently leading it through all the steps, vomiting pointless lifetime annotation noise all over the code in the process.I mean it only got really interesting two years ago. That part has been polished a ton.
Second time I tried, that part seemed to have gotten better, but then the type system was too dumb to figure out some just-above-trivial case; don't remember the details but it was some transitivity issue about trait A inheriting from trait B inheriting from trait C where A couldn't figure out that it had implementations for trait C's functions or something like that. I ended up in some chapter in the docs that basically said "we haven't gotten to implementing this yet, just duplicate all your code lol" so I went "yeah no, I might get back to you once you've gotten around to implementing a usable type system".
That was fixed ages ago. Are you sure that was 2017 and not 2016?
I'm not fond of traits type systems in general, they seem to result in messy non-localized code that's difficult to structure in a meaningful way; but I'll admit that may be because I'm not familiar enough with that approach yet and haven't figured out the best ways to make use of it.
The secret is that traits are both interfaces and typeclasses. Cromulent Rust code can best be described as 'functional except mutable'. Rust's type system is not the best thing for every application - straight-up OOP is still the best way to do GUIs - but for most things the problem is usually that you're just trying to structure it in a way you'd structure it in some other language, where ownership and lifetime isn't important. Rust's got a serious learning curve to it but once you get it everything becomes easy. This is especially true for lifetimes - I can't think of any language that does lifetime checking, so you're essentially learning a whole new programming concept. I'd imagine learning OOP if you only knew procedural is a similar concept.
I also hate the brain-dead "your app is in fact a library" nonsense, and more generally the fact that Rust appears to be too dumb to figure out any kind of project structure other than their holy One True Way Of Organizing Thy Codes, never mind how much sense that structure makes to your project.
I genuinely have no idea what you mean by this. Binary crates are not usable as libraries, and project structure is whatever you want.
Also the error messages pretend to be all useful and informative, meaning they're very verbose and prosaic, but half the time they seem to point to the completely wrong section of the code and show a complete lack of even the most basic understanding of the program. At that point I much prefer C++'s honest vomit of standard legalese and compiler nitpicking, at least there's no pretense there and we can get right down to the facts.
Again, something that's improved a ton.
Maybe I'll give it another try in a few years if I have a week or two to waste at some point, we'll see.
Really, the point at which it's a good time to start was when the 2018 edition was released.
I will also point out that a language as garbage as you describe would not consistently hit Most Loved on SO's survey several years in a row.
378: Real Programmers - explain xkcd
