I hate Scala

Gąska

Sometimes, it is just not worth trying to understand....

And sometimes, you really want this 300% raise.

ixvedeusi

I am providing corporate consulting services

Somehow I read that as "corporate insulting services". Not sure what's wrong with my brain today, I sure can't blame it on lack of

TheCPUWizard

@ixvedeusi said in I hate Scala:

@thecpuwizard said in I hate Scala:

I am providing corporate consulting services

Somehow I read that as "corporate insulting services". Not sure what's wrong with my brain today, I sure can't blame it on lack of

Those services can also be arranged...

dcon

@boomzilla said in I hate Scala:

I would add that of those who did go to college, many did not major in computer science.

And many of those that did, you don't want.
(Wait, I did... whatever, that was 1985 so doesn't really count anymore...)

MrL

@dcon said in I hate Scala:

@boomzilla said in I hate Scala:

I would add that of those who did go to college, many did not major in computer science.

And many of those that did, you don't want.

And there will be more such people, as programmer becomes more and more popular profession.

sockpuppet7

@gąska said in I hate Scala:

A video game is transforming a series of gamepad button presses/mouse movements/keyboard strokes into an array of pixels and a composition of mechanical waves. When you state it as such, you can do most of the game logic in functional paradigm. Are you saying video games are uninteresting?

When you're jumping the 🦈 you're transforming the chemically stored energy in your body into cinetic energy.

blakeyrat

@pie_flavor said in I hate Scala:

"If I had asked people what they wanted, they would have said faster horses."

C# does need faster horses.

blakeyrat

@boomzilla said in I hate Scala:

I would add that of those who did go to college, many did not major in computer science.

And many who went to college and majored in computer science are utterly useless at programming computers. I know, I've interviewed seemingly all of them.

blakeyrat

@thecpuwizard said in I hate Scala:

Those services can also be arranged...

https://www.youtube.com/watch?v=iRtBvo9grLw

Gąska

@sockpuppet7 said in I hate Scala:

@gąska said in I hate Scala:

A video game is transforming a series of gamepad button presses/mouse movements/keyboard strokes into an array of pixels and a composition of mechanical waves. When you state it as such, you can do most of the game logic in functional paradigm. Are you saying video games are uninteresting?

When you're jumping the 🦈 you're transforming the chemically stored energy in your body into cinetic energy.

Which isn't exactly a computation problem.

sockpuppet7

@gąska are you saying sharks are uninteresting?

Gąska

@sockpuppet7 I'm saying go fuck yourself.

gordonjcp

@gąska Okay, but I don't understand why working on a copy of the data while leaving the old data around would be good, or in any sense desirable.

Gąska

@gordonjcp the old data is garbage-collected, or modified in-place, or otherwise disposed of.

dkf

@gordonjcp said in I hate Scala:

Okay, but I don't understand why working on a copy of the data while leaving the old data around would be good, or in any sense desirable.

The language implementation is allowed to do something more efficient when it figures out that it can do so safely. That's not as difficult as it sounds as long as you're careful with threads; reference counting pretty much gives you this for free. Also, when you only have non-modifiable values you also have a guarantee that you don't have reference loops (as you can't insert a reference to an object inside itself, either directly or indirectly) making reference counting work very well indeed as a memory management strategy.

gordonjcp

@dkf Ah, that kind of makes sense. A lot of the time I'm not really working with types or memory allocation, but I can see on stuff destined for platforms with infinite RAM like phones, PCs etc that would be worth using.

Gąska

You know what would be nice when writing documentation in Scaladoc? Knowing Scaladoc syntax. You know what doesn't exists? Documentation for Scaladoc syntax.

pie_flavor

@gąska https://docs.scala-lang.org/overviews/scaladoc/for-library-authors.html

Gąska

@pie_flavor works every time.

Gąska

@pie_flavor oh and since you pointed me to that page already, here's a dumbass quote:

DRY - don’t repeat yourself. Resist duplicating the method description in the @return tag and other forms of repetitive commenting.

Oh, how I hate when I read the documentation for some function and the author doesn't explain what the return value is because it should be "obvious" from the general description! If anything, it should be the other way around - forsake summary if it's going to repeat @return!

pie_flavor

@gąska that implies you tried, though. I just googled 'Scaladoc' and pasted the second link.

Gąska

@pie_flavor there's a cautionary tale about the order of Google results for different people in my recent post history.

Edit: I saw that link in my search too but since I'm making a standalone app and not library I thought it doesn't apply. If they instead named it "documentation for Scaladoc syntax", it would certainly help.

dkf

@gąska said in I hate Scala:

@pie_flavor oh and since you pointed me to that page already, here's a dumbass quote:

DRY - don’t repeat yourself. Resist duplicating the method description in the @return tag and other forms of repetitive commenting.

Oh, how I hate when I read the documentation for some function and the author doesn't explain what the return value is because it should be "obvious" from the general description! If anything, it should be the other way around - forsake summary if it's going to repeat @return!

Hehehe. From depressingly many places in our code (and only very lightly anonymised):

def get_thing(self):
    """ Get the thing.

    :return: the thing.
    """
    return self._the_thing

Gąska

@dkf in Scala, such a "getThing" method usually does some weird mappings and stuff that makes it impossible to figure out what it is actually without precise documentation or diving through code.

pie_flavor

@gąska thank you for summing up the entire language in a nutshell. And that's without the bullshit that is implicit parameters.

Rhywden

@pie_flavor said in I hate Scala:

@gąska thank you for summing up the entire language in a nutshell. And that's without the bullshit that is implicit parameters.

Implicit parameters? Like, parameters which exist in the context of the called function but are not explicitly declared as such?

masonwheeler

@dkf said in I hate Scala:

Also, when you only have non-modifiable values you also have a guarantee that you don't have reference loops (as you can't insert a reference to an object inside itself, either directly or indirectly) making reference counting work very well indeed as a memory management strategy.

immutable class WTF:
   immutable WTF _selfReference

   constructor():
      self._selfReference = self

You were saying?

dkf

@masonwheeler said in I hate Scala:

You were saying?

OK, so you can stab yourself in the face with a rusty spoon if you insist.

pie_flavor

@rhywden said in I hate Scala:

@pie_flavor said in I hate Scala:

@gąska thank you for summing up the entire language in a nutshell. And that's without the bullshit that is implicit parameters.

Implicit parameters? Like, parameters which exist in the context of the called function but are not explicitly declared as such?

Parameters marked as implicit, meaning that they are passed in from implicit variables without being present in the call syntax. Sometimes they're not even declared as parameters, and are retrieved using the implicitly function.

Magus

@thecpuwizard said in I hate Scala:

I have not seen any evidence of specifically anti-Polish racism [side note: I used to live pretty close to "Polish Town USA" ].

It's a thing. There's an associated racial slur and lots of jokes. Mostly only among people my grandparents' age, though.

dfdub

@gordonjcp said in I hate Scala:

Most of the code I write these days is mutating a shitload of state, possibly tens of thousands of values every handful of microseconds, based on the previous state of those values And A Bunch Of Other Stuff. It looks like Functional Programming is designed to not let you do that kind of thing, which is why it doesn't really fit in my head.

Counterintuitively, that can be exactly the kind of problem where functional programming shines.

I'm assuming that the core of your program computes a new state from an old state and an event or a list of events that happened in the meantime. Then that would be exactly the part of your program that you could write with pure functions and in the process you'd probably vastly improve the code quality.

Functional programming forces you to model your state explicitly, so you'd have to create a dedicated object (or a bunch of objects) which holds all your program state relevant to this computation as a prerequisite. That alone might help clean up some code, since computations that involve a lot of state held in 1000 different places are incredibly hard to follow.

I'm not one of the FP fanboys, BTW; au contraire I'm convinced that it's only useful in some domains and that the idea of writing huge programs exclusively in a pure functional language is completely bonkers. I just wanted to note that if I'm understanding you correctly, then you're drawing the wrong conclusion here and that the exact opposite is true in your case.

Gąska

@dfdub can we go back to shitting on Scala now? For example, package objects. A completely useless feature that saves you typing like ten characters in import declaration which is most likely going to be autogenerated by the IDE anyway.

dfdub

@gąska said in I hate Scala:

can we go back to shitting on Scala now?

pie_flavor

@gąska said in I hate Scala:

@dfdub can we go back to shitting on Scala now? For example, package objects. A completely useless feature that saves you typing like ten characters in import declaration which is most likely going to be autogenerated by the IDE anyway.

you aren't serious?

pie_flavor

@dfdub Welcome to the forums!

Gąska

@pie_flavor said in I hate Scala:

@gąska said in I hate Scala:

@dfdub can we go back to shitting on Scala now? For example, package objects. A completely useless feature that saves you typing like ten characters in import declaration which is most likely going to be autogenerated by the IDE anyway.

you aren't serious?

Then tell me: what's the benefit of a package object over an object in the package?

David1

@blakeyrat said in I hate Scala:

For example, what if your complex data structure is the entirety of Tamriel in Elder Scrolls Online?

Random bit-flipping in a structure that has to be consistent between a vast number of servers and clients across the world? That seems ... ill-advised. Even non-online games don't just store everything in one data structure; that's why loading screens were created. I don't see why you would have that as an editable structure at all.

You can't just change a huge data structure if display is depending on it. You can't redraw an editor window holding 15 MBs of text everytime someone enters a character. You change one small structure and instruct the display to change just that small structure, or you create a series of change orders that can be accumulated to update the big data structure when it's convenient. If you're working on any sort of editor, you have to create a list of changes or copy everything anyway so Undo will work. At the top level, impure functional languages like Scala let you directly change the structure while keeping lower levels pure. But even in old-school Java and C++, a huge data structure isn't going to be a bag of bytes; it's going to be a set of pointers, and given a set of pointers a pure functional language can just copy the pointers to stuff that didn't change and copy the structure and insert a new pointer to stuff that did.

What's the functional language equivalent of Visual Studio?

Visual Studio? Visual Studio supports F#. I'm guessing Java IDEs don't impress you, but Eclipse and IdeaJ also handle Scala. Basically they use the exact same IDEs as their non-functional counterparts.

pie_flavor

@gąska You could simultaneously ask why people use packages instead of nested objects. The correct answer is 'proper structure'.

Gąska

@pie_flavor the benefit of packages over nested objects is that you can keep your code in multiple files. The benefit of package object over regular object is...?

homoBalkanus

@gąska said in I hate Scala:

The benefit of package object over regular object is...?

Having a single place to define your types that will be used by several objects in the package

Gąska

@homobalkanus fair enough. But I've seen people putting much more into package objects than that. Functions, mutable state, inheritance...

homoBalkanus

@gąska then they reinvented the God class. Just because a feature exists doesn't mean it should be used all the time for everything

Gąska

@homobalkanus said in I hate Scala:

@gąska then they reinvented the God class.

It has nothing to do with God classes. Regular objects and classes also can be God classes. The problem is name aliasing: suddenly a single identifier is both an object and a package. For what?

Just because a feature exists doesn't mean it should be used at all ~~the time for everything~~

FTFY

gordonjcp

@dfdub Okay, it's DSP, so there's a chunk of memory treated as an array, maybe a couple of hundred thousand bytes long, and the whole thing is read and updated maybe every couple of dozen microseconds. There are a couple of pointers to indicate where you're reading and writing within this buffer, and another couple of pointers to indicate where you're actually working.

Functional programming forces you to model your state explicitly, so you'd have to create a dedicated object (or a bunch of objects) which holds all your program state relevant to this computation as a prerequisite.

I don't really understand that bit. What does "model your state explicitly" mean? Why would objects be good? As I understand it, objects are great if you need to have more than one of something and expect to create more or delete them during the run time of the program.

Also, the entire binary really needs to fit in about 64kB, otherwise I need to buy a more expensive chip.

homoBalkanus

@gąska said in I hate Scala:

@homobalkanus said in I hate Scala:

@gąska then they reinvented the God class.

It has nothing to do with God classes. Regular objects and classes also can be God classes. The problem is name aliasing: suddenly a single identifier is both an object and a package. For what?

Another option for organising your code. It can also be a good place to store things that usually end up in a Utils class AKA RamdomShit/Other/Misc

Just because a feature exists doesn't mean it should be used at all ~~the time for everything~~

FTFY

I already have you one good use. Scala is not C++, yet.

Gąska

@homobalkanus said in I hate Scala:

@gąska said in I hate Scala:

The benefit of package object over regular object is...?

Having a single place to define your types that will be used by several objects in the package

Correct me if I'm wrong, but can't objects in package reference everything else in that package anyway?

homoBalkanus

@gąska sure they can. You don't get any extra functionality, just a different way of code organisation. I mainly found it useful for defining types and type hierarchies in one place.

Gąska

@gordonjcp said in I hate Scala:

@dfdub Okay, it's DSP, so there's a chunk of memory treated as an array, maybe a couple of hundred thousand bytes long, and the whole thing is read and updated maybe every couple of dozen microseconds. (...) Also, the entire binary really needs to fit in about 64kB, otherwise I need to buy a more expensive chip.

Yes, I agree it sucks to work in limited environment, where your tools choice is determined not by what you need, but what you can.

I don't really understand that bit. What does "model your state explicitly" mean?

Every function has all its inputs and outputs listed explicitly. When something goes wrong, it's either inputs or function body - no global state to be wary of.

Why would objects be good? As I understand it, objects are great if you need to have more than one of something and expect to create more or delete them during the run time of the program.

Objects are essentially tuples of primitive variables. You only create and delete objects at runtime if you'd have created and deleted those individual variables anyway. They provide a nice abstraction useful pretty much everywhere - that's why people tend to say objects when they really mean values in general.

Gąska

@homobalkanus said in I hate Scala:

@gąska said in I hate Scala:

@homobalkanus said in I hate Scala:

@gąska then they reinvented the God class.

It has nothing to do with God classes. Regular objects and classes also can be God classes. The problem is name aliasing: suddenly a single identifier is both an object and a package. For what?

Another option for organising your code. It can also be a good place to store things that usually end up in a Utils class AKA RamdomShit/Other/Misc

And the benefit of using package object over misc.scala is...?

Just because a feature exists doesn't mean it should be used at all ~~the time for everything~~

FTFY

I already have you one good use.

Turns out it can be done just as well without package objects. Or even better, since you don't have the name aliasing problem.

homoBalkanus

@gąska said in I hate Scala:

@homobalkanus said in I hate Scala:

@gąska said in I hate Scala:

@homobalkanus said in I hate Scala:

@gąska then they reinvented the God class.

It has nothing to do with God classes. Regular objects and classes also can be God classes. The problem is name aliasing: suddenly a single identifier is both an object and a package. For what?

Another option for organising your code. It can also be a good place to store things that usually end up in a Utils class AKA RamdomShit/Other/Misc

And the benefit of using package object over misc.scala is...?

For you? None. I prefer it in a specific case because the code is clearer for me that way. Again, this is more a matter of preference and if you cannot find a benefit then you shouldn't use it. Talk to your team and try to agree on a way of work that actually works for you