I hate Scala

[dkf]

@gąska said in I hate Scala:

As far as I know, the only way to terminate it is SIGINT (Ctrl+C).

Does an EOF work? (That's Ctrl+Z on Windows and Ctrl+D on POSIX.)

Ugh; 'd

[blakeyrat]

@gąska said in I hate Scala:

It was in context of Blakey's statement that we as an industry shouldn't go full functional until we can expect average developer to code functional, and that as of 2018 an average developer can't be expected to code functional.

I'm not 100% sure we're all talking about the same thing.

My point was simply that a huge, huge, huge advantage of C#, Java, Python, etc. is that you can easily find people who are competent at it. That's an advantage that functional programming does not currently have, and until it does, it's impossible for me to see how it's superior to non-functional languages "in every way".

Or put more generically, writing software is not all about how concise your code is. It's not even mostly about that. That's like... number 10-12 on the priority list.

[ObjectMike]

@dkf said in I hate Scala:

@blakeyrat said in I hate Scala:

Scala's in the same bucket as the LISP people

That's Clojure. Scala is the one with the crazy type rules.

I'm curious what you consider the crazy type rules. Day to day coding is fairly bland as far as types go. Are you referring to the multitude of ways you can constrain generics?

[ObjectMike]

@blakeyrat said in I hate Scala:

@gąska said in I hate Scala:

It was in context of Blakey's statement that we as an industry shouldn't go full functional until we can expect average developer to code functional, and that as of 2018 an average developer can't be expected to code functional.

I'm not 100% sure we're all talking about the same thing.

My point was simply that a huge, huge, huge advantage of C#, Java, Python, etc. is that you can easily find people who are competent at it. That's an advantage that functional programming does not currently have, and until it does, it's impossible for me to see how it's superior to non-functional languages "in every way".

Or put more generically, writing software is not all about how concise your code is. It's not even mostly about that. That's like... number 10-12 on the priority list.

I've always thought it was a bad idea to exclusively look for developers who are already familiar with your platform. I'd rather train a bunch of good or great devs who only know Java in C# than hire a bunch of crap or meh devs who already know C#. Or instead of C#, whatever functional language is being used. I'm not sure I'd want to hire (if I'm ever in that position) or work with devs who are unwilling or unable to learn a new language or platform.

Or said another way, pick your tools for what you need for your products, features, reliability, maintainability, etc. I'd say it's a bad idea to base your technical platform on what's being taught in universities or what's currently popular. Students with a good education or devs with experience should have enough of a foundation to be able to adapt to whatever you're using.

An exception would be if you're under some sort of time crunch where you absolutely need the new person to hit the ground running. For that I guess I'd also expect you're using contractors and not so much full-time devs. Usually though, you don't have that need.

[blakeyrat]

@mikehurley said in I hate Scala:

I've always thought it was a bad idea to exclusively look for developers who are already familiar with your platform.

Maybe it is, but that doesn't change the fact that a programming language/environment with 200 unemployed experts in your area waiting in the wings is far better than one with zero.

Whether or not you decide to hire any of those 200 experts is orthogonal to my point. A car that comes with free roadside service is better than one that doesn't, even if you personally never call up the free roadside service guys.

[masonwheeler]

@gąska said in I hate Scala:

What I hate Scala for today: variable is introduced in scope (and shadows other variables with the same name) before initialization. In other words, val x = foo(); val x = bar(x) doesn't work.

You appear to be overlooking a bigger : how is that even allowed in the first place? In any sane language, declaring two variables of the same name in the same scope is an error.

[anonymous234]

@gąska said in I hate Scala:

@blakeyrat functional programming is better than traditional programming. And not just in feel-good sense - it has lots of very real, very practical benefits. There's a reason why every major language gets more and more functional features.

"Functional programming" is a really vague concept.

[Gąska]

@blakeyrat said in I hate Scala:

My point was simply that a huge, huge, huge advantage of C#, Java, Python, etc. is that you can easily find people who are competent at it. That's an advantage that functional programming does not currently have, and until it does, it's impossible for me to see how it's superior to non-functional languages "in every way".

Modern Java, C# and Python are much more functional than 10 years ago. Streams, lambdas, side-effect-free functions etc. That's what I call functional. I'm not talking about changing languages - I'm talking about changing paradigms. Functional programming means pure computation without side effects and without global variables. Output depends on input only. Also, long chains of data transformation functions, and playing a lot with iterators. This makes code much more readable (usually), easier to reason about locally, less buggy and easily parallelized.

[boomzilla]

@dkf said in I hate Scala:

@mikehurley said in I hate Scala:

I don't understand why many JVM languages felt the need to make their own

Because they were bitten by an XML file and it scared them;

I think it's a combination of NIH and, "but that old tool doesn't do this other thing that I want." Which is sometimes pretty major (e.g. ant maven dependency stuff).

I'm still happy with writing a Maven pom.xml. I've got really good tooling to help with that, including debugging inconsistent package versions and other annoyances that crop up once the dependency graph gets really large.

Bah. ant and build.xml are good enough me (though teeechnically we have it integrated with ivy for downloading dependencies).

[Gąska]

@masonwheeler said in I hate Scala:

@gąska said in I hate Scala:

What I hate Scala for today: variable is introduced in scope (and shadows other variables with the same name) before initialization. In other words, val x = foo(); val x = bar(x) doesn't work.

You appear to be overlooking a bigger : how is that even allowed in the first place? In any sane language, declaring two variables of the same name in the same scope is an error.

In any sane language, you can shadow variables freely so only the last one declared is accessible, nullifying to sone extend namespace pollution (especially function-local namespace pollution). Variables are only used once or twice on average, and naming is hard - shadowing makes it far easier to come up with names (you often have the same thing in 5 different variables, although in different forms).

[blakeyrat]

@gąska said in I hate Scala:

Modern Java, C# and Python are much more functional than 10 years ago. Streams, lambdas, side-effect-free functions etc. That's what I call functional. I'm not talking about changing languages - I'm talking about changing paradigms.

In that case I agree with you with the proviso that I'd say adding paradigms and not changing paradigms.

@gąska said in I hate Scala:

Functional programming means pure computation without side effects

The problem is what functional people call "side effects" normal people call "the things the program is actually supposed to be doing". Like, drawing text on the screen is a "side effect" even though the program's supposed to be drawing text on the screen. Yet it's like some holy rule that all programs should have no side effects, I don't get it.

@gąska said in I hate Scala:

Output depends on input only.

As someone mentioned above, this is not at all useful when dealing with UIs.

@gąska said in I hate Scala:

Also, long chains of data transformation functions, and playing a lot with iterators.

A.k.a. Linq, the best part of all of this, which of course the best programming language has had implemented for a decade.

@gąska said in I hate Scala:

This makes code much more readable (usually),

Meh. Linq's faster, because it can short-circuit in a lot of cases traditional code can't. I wouldn't necessarily call it more readable... it really depends on what you're doing with it I suppose.

@gąska said in I hate Scala:

easier to reason about locally, less buggy

Hmm.

@gąska said in I hate Scala:

and easily parallelized.

Well that's true at least.

[Gąska]

@blakeyrat said in I hate Scala:

Linq's faster

Linq's functional.

[blakeyrat]

@gąska said in I hate Scala:

Linq's functional.

Riiight?

Did I post otherwise, or... why did you reply with that?

In any case, it's not faster due to any magic, it's faster because it doesn't bother materializing any of the results of your operation until you've actually asked for them. You can do the same thing with traditional interators and yield return in C# forever, it just took a lot of boilerplate and was annoying to write.

[masonwheeler]

@blakeyrat said in I hate Scala:

The problem is what functional people call "side effects" normal people call "the things the program is actually supposed to be doing". Like, drawing text on the screen is a "side effect" even though the program's supposed to be drawing text on the screen. Yet it's like some holy rule that all programs should have no side effects, I don't get it.

Yes, the term is nonsense, used by dogmatic FP types to make visible effects sound scary by association with medical side effects.

[Gąska]

@blakeyrat because I read posts partially, react to them, and go back to read the rest and react more. I'm on mobile so that way is much easier for me.

[boomzilla]

@mikehurley said in I hate Scala:

I've always thought it was a bad idea to exclusively look for developers who are already familiar with your platform. I'd rather train a bunch of good or great devs who only know Java in C# than hire a bunch of crap or meh devs who already know C#.

Those are similar enough that it makes sense. Change to Lisp or other common functional languages and the odds of being able to treat devs as fungible resources plummet.

[boomzilla]

@gąska said in I hate Scala:

In any sane language, you can shadow variables freely so only the last one declared is accessible, nullifying to sone extend namespace pollution (especially function-local namespace pollution). Variables are only used once or twice on average, and naming is hard - shadowing makes it far easier to come up with names (you often have the same thing in 5 different variables, although in different forms).

Yeah, but declaring two in the same scope seems insane. I've always heard shadowing to refer to variables in different scopes.

[Gąska]

@blakeyrat said in I hate Scala:

The problem is what functional people call "side effects" normal people call "the things the program is actually supposed to be doing". Like, drawing text on the screen is a "side effect" even though the program's supposed to be drawing text on the screen. Yet it's like some holy rule that all programs should have no side effects, I don't get it.

No one says your PROGRAM shouldn't have side effects. It would be pointless. It's just that functions without side effects exhibit some very neat properties that let you make some really cool things with - kinda like prime numbers have some properties that make them much more useful for cryptography than other numbers. Making entire application purely functional is impossible - but a very large portion of it, especially business logic, can be written in almost purely functional way - which then lets you use all the cool tricks that only work on pure functions, like running them in parallel without any additional synchronization. The ultimate purpose of computers is computation, ie. transforming input into output; and pure functions literally transform input into output.

[Gąska]

@boomzilla said in I hate Scala:

@gąska said in I hate Scala:

In any sane language, you can shadow variables freely so only the last one declared is accessible, nullifying to sone extend namespace pollution (especially function-local namespace pollution). Variables are only used once or twice on average, and naming is hard - shadowing makes it far easier to come up with names (you often have the same thing in 5 different variables, although in different forms).

Yeah, but declaring two in the same scope seems insane.

Let's say you have a very long expression evaluating some value - say, some container you do a lot of mapping and aggregation on. You can make it more readable by dividing into several steps, like this:

val x1 = foo().bar()
val x2 = x1.map{case (a, b) => (a.size, b)}
val x3 = x2.groupBy{(a,b) => b.baz(a)}
// and so on and so on...

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance. You could write all of these as x = x.map(...) and it would be just as readable - or even more readable, since shadowing local variable makes it inaccessible, which gives a hint to the reader that this variable is irrelevant to code down the function.

[Gąska]

@blakeyrat said in I hate Scala:

@gąska said in I hate Scala:

Output depends on input only.

As someone mentioned above, this is not at all useful when dealing with UIs.

This is EXTREMELY useful for UI. Unless you love debugging issues like "why the hell scrollbar moves at different speeds when scrolling up and down?".

[Captain]

@gąska said in I hate Scala:

val x1 = foo().bar()
val x2 = x1.map{case (a, b) => (a.size, b)}
val x3 = x2.groupBy{(a,b) => b.baz(a)}
// and so on and so on...

Yeah, code like this is exactly what monads are for. Instead of making "temporary" variables, you just treat map {case (a, b) => (a.size, b)} as a function in itself, and pass the result of foo().bar() into it like so:

 x <- foo().bar()
  >>= x1.map{case (a, b) => (a.size, b)}
  >>= x2.groupBy{(a,b) => b.baz(a)}

finally storing the result of that chain of computations into x. Yes, this is what Linq does. Yes, it is good design, for algorithms you can express as chains of one-argument functions.

[masonwheeler]

@gąska said in I hate Scala:

Let's say you have a very long expression evaluating some value - say, some container you do a lot of mapping and aggregation on. You can make it more readable by dividing into several steps, like this:

val x1 = foo().bar()
val x2 = x1.map{case (a, b) => (a.size, b)}
val x3 = x2.groupBy{(a,b) => b.baz(a)}
// and so on and so on...

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance.

Spoken like someone who has never used a debugger before.

Giving every intermediate step a unique name makes it much easier to see how the computation is working step-by-step and determine where along the line something is going wrong.

[powerlord]

@pie_flavor said in I hate Scala:

@masonwheeler said in I hate Scala:

@mikehurley said in I hate Scala:

Maybe I'm the oddball, but I don't really want my build scripts to look like my application. I guess I want it to look like a build file.

I think you are the oddball in this case. Builds are a non-trivial process, and they frequently end up with enough complexity that you end up really wanting a scripting language, rather than a simple declarative "build file," to handle the edge cases.

That wasn't the question. It's not that the build file looks like a script, it's that the specific script language is the same as the language it's building. sbt builds Scala and uses Scala scripting, Leiningen builds Clojure and uses Clojure scripting, etc. I see no reason to use anything other than Gradle.

Gradle devs have this tendency to not add things that don't agree with their worldview.

For example, Gradle had an open bug for 8 years to add the equivalent of Maven's provided scope, which is used heavily in JavaEE development.

[boomzilla]

@gąska said in I hate Scala:

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance. You could write all of these as x = x.map(...) and it would be just as readable - or even more readable, since shadowing local variable makes it inaccessible, which gives a hint to the reader that this variable is irrelevant to code down the function.

Oh. I think I see the breakdown here (?). Because this is a functional language the x is really a constant not a variable? Which is actually implied by the fact that it's declared as val, not var.

So you should not be using the word, "variable."

[blakeyrat]

@gąska said in I hate Scala:

No one says your PROGRAM shouldn't have side effects. It would be pointless. It's just that functions without side effects exhibit some very neat properties that let you make some really cool things with - kinda like prime numbers have some properties that make them much more useful for cryptography than other numbers.

I don't understand why that's unique to functional languages, I guess is part of the problem. If I do all my computation in a specific instance of a specific class, it also has no side effects, yes? You could do the same thing in any object-oriented language, or even in a C struct if you want. About the only language I know of where it's difficult is old-school BASICs where your subroutines share global state with the rest of the program.

So I get the concept you're selling here, but what I don't get is why I don't already own it.

@gąska said in I hate Scala:

The ultimate purpose of computers is computation,

Wow.

I could not disagree more.

@gąska said in I hate Scala:

This is EXTREMELY useful for UI.

I don't see it. I mean, yes "easy multithreading" is great because UIs always require at least two threads in modern OSes, but UI programming is nothing but side-effects, and has tons of "global" state. (Global in scare-quotes because it's global to the UI but not necessarily to the entire program.)

Like a simple GUI operation is: "if this radio group is toggled to B, then enable button C".

How would a functional language help with an operation like that?

@gąska said in I hate Scala:

Unless you love debugging issues like "why the hell scrollbar moves at different speeds when scrolling up and down?".

Maybe you should switch to a UI framework that isn't utter shit. I can't even imagine how that could happen in any of the ones I use.

[boomzilla]

@blakeyrat said in I hate Scala:

I don't understand why that's unique to functional languages, I guess is part of the problem. If I do all my computation in a specific instance of a specific class, it also has no side effects, yes? You could do the same thing in any object-oriented language, or even in a C struct if you want.

Yes, the point is that the behavior is guaranteed in functional languages (or I suppose in functional parts of languages that provide it). You never have to inspect code or worry that any future derpsters will mess that stuff up.

[Gąska]

@masonwheeler said in I hate Scala:

@gąska said in I hate Scala:

Let's say you have a very long expression evaluating some value - say, some container you do a lot of mapping and aggregation on. You can make it more readable by dividing into several steps, like this:

val x1 = foo().bar()
val x2 = x1.map{case (a, b) => (a.size, b)}
val x3 = x2.groupBy{(a,b) => b.baz(a)}
// and so on and so on...

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance.

Spoken like someone who has never used a debugger before.

Step over is a thing, you know?

[masonwheeler]

@gąska Yes it is, but how is this relevant to what I described?

[Gąska]

@boomzilla said in I hate Scala:

@gąska said in I hate Scala:

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance. You could write all of these as x = x.map(...) and it would be just as readable - or even more readable, since shadowing local variable makes it inaccessible, which gives a hint to the reader that this variable is irrelevant to code down the function.

Oh. I think I see the breakdown here (?). Because this is a functional language the x is really a constant not a variable? Which is actually implied by the fact that it's declared as val, not var.

So you should not be using the word, "variable."

Every other word is more confusing than "variable". Even "constant" - it's usually something that doesn't change, and these x's are different in every call.

[blakeyrat]

@gąska "invariant variable" haha

[Gąska]

@blakeyrat 80s called, they want their C++ joke back.

[blakeyrat]

@gąska Your mother.

[boomzilla]

@gąska said in I hate Scala:

@boomzilla said in I hate Scala:

@gąska said in I hate Scala:

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance. You could write all of these as x = x.map(...) and it would be just as readable - or even more readable, since shadowing local variable makes it inaccessible, which gives a hint to the reader that this variable is irrelevant to code down the function.

Oh. I think I see the breakdown here (?). Because this is a functional language the x is really a constant not a variable? Which is actually implied by the fact that it's declared as val, not var.

So you should not be using the word, "variable."

Every other word is more confusing than "variable". Even "constant" - it's usually something that doesn't change, and these x's are different in every call.

When you say "these x's" are you talking about x1, x2, etc? They never change, do they? They are all different. And once you've assigned a value to one of them the value doesn't change. Otherwise you could do "normal" variable stuff with them like this:

val x1 = foo().bar()
x1 = x1.map{case (a, b) => (a.size, b)}
x1 = x2.groupBy{(a,b) => b.baz(a)}

Right? What am I missing?

[Captain]

@boomzilla said in I hate Scala:

@gąska said in I hate Scala:

@boomzilla said in I hate Scala:

@gąska said in I hate Scala:

Since each of the variables x1 through x5 is going yo be used exactly once, one line after it's declared, giving it a unique name is only a hindrance. You could write all of these as x = x.map(...) and it would be just as readable - or even more readable, since shadowing local variable makes it inaccessible, which gives a hint to the reader that this variable is irrelevant to code down the function.

Oh. I think I see the breakdown here (?). Because this is a functional language the x is really a constant not a variable? Which is actually implied by the fact that it's declared as val, not var.

So you should not be using the word, "variable."

Every other word is more confusing than "variable". Even "constant" - it's usually something that doesn't change, and these x's are different in every call.

When you say "these x's" are you talking about x1, x2, etc? They never change, do they? They are all different. And once you've assigned a value to one of them the value doesn't change. Otherwise you could do "normal" variable stuff with them like this:

val x1 = foo().bar()
x1 = x1.map{case (a, b) => (a.size, b)}
x1 = x2.groupBy{(a,b) => b.baz(a)}

Right? What am I missing?

Suppose foo().bar() tells you (or rather, depends on) the time of day . Every invocation of the computation you described is going to produce a different result.

Variables are just "place-holders" for values you bind. But once they're bound, they're fixed. This is how it works in math and functional programming, anyway.

It would be a big pain in the ass if x could change in something like f(x) = a bunch of steps involving x. You would need to carry around more context to keep track of what x is now. Yes, this is what you currently do (pretty much by simulating the state in your mind or following along with a debugger). Yes, it is a pain. :-)

So yeah, your summary is right.

[Magus]

@blakeyrat said in I hate Scala:

I don't understand why that's unique to functional languages, I guess is part of the problem. If I do all my computation in a specific instance of a specific class, it also has no side effects, yes? You could do the same thing in any object-oriented language, or even in a C struct if you want. About the only language I know of where it's difficult is old-school BASICs where your subroutines share global state with the rest of the program.
So I get the concept you're selling here, but what I don't get is why I don't already own it.

I don't actually think he said it was unique to functional languages, just that it is a functional programming approach, and a useful one.

[pie_flavor]

@masonwheeler said in I hate Scala:

@gąska said in I hate Scala:

What I hate Scala for today: variable is introduced in scope (and shadows other variables with the same name) before initialization. In other words, val x = foo(); val x = bar(x) doesn't work.

You appear to be overlooking a bigger : how is that even allowed in the first place? In any sane language, declaring two variables of the same name in the same scope is an error.

Why shouldn't it be allowed? In Rust for example, it's generally well recognized that if you transform something into something else, there's no problem keeping the name (e.g. let num = num.parse::<usize>();. It just shadows the other variable.

[masonwheeler]

@pie_flavor said in I hate Scala:

Why shouldn't it be allowed?

See above, re: making debugging needlessly difficult.

[pie_flavor]

@anonymous234 said in I hate Scala:

@gąska said in I hate Scala:

@blakeyrat functional programming is better than traditional programming. And not just in feel-good sense - it has lots of very real, very practical benefits. There's a reason why every major language gets more and more functional features.

"Functional programming" is a really vague concept.

It's a very simple definition: functions are constructible values just like numbers or strings and can be passed to or returned from other functions.

[Gąska]

@blakeyrat said in I hate Scala:

@gąska said in I hate Scala:

No one says your PROGRAM shouldn't have side effects. It would be pointless. It's just that functions without side effects exhibit some very neat properties that let you make some really cool things with - kinda like prime numbers have some properties that make them much more useful for cryptography than other numbers.

I don't understand why that's unique to functional languages

It's not. It's unique to functional paradigm. You don't need functional language to do functional programming.

If I do all my computation in a specific instance of a specific class, it also has no side effects, yes?

Depends on whether you treat the instance as an input to method or not. Both of these approaches are valid, but the consequences are different - for example, if this is an input, you can't run methods in parallel willy-nilly.

A common functional pattern for classes is that methods don't modify instances in place, but rather return a new instance in modified state.

Paradigms aren't religions, they are tools - they are used to solve problems. You pick one that is most useful in a given situation and lets you solve the problem in most efficient manner. You take the paradigm, model your program in a way that fits the chosen paradigm, and use the consequences of your paradigm to do cool things with your code. My personal opinion is that functional paradigm is the best tool for business logic (ie. parts of code that don't deal directly with IO, data encoding/decoding or interoperability with other libraries/processes).

So I get the concept you're selling here, but what I don't get is why I don't already own it.

You do. You just can't take advantage of it most of the time, because so much Java and C# code doesn't care about side effects - and because you can't do it in most places, you don't bother with doing it in places where you can, making it even worse for people who would like to try it.

@gąska said in I hate Scala:

The ultimate purpose of computers is computation,

Wow.

I could not disagree more.

Nearly every programming task can be expressed as a problem of converting some kind of input into some kind of output. Even if "computers are for computing" is bullshit from user's point of view, it is true from the theoretical point of view you can temporarily take in order to fit your design into functional paradigm. Points of view are tools, too.

@gąska said in I hate Scala:

This is EXTREMELY useful for UI.

I don't see it. I mean, yes "easy multithreading" is great because UIs always require at least two threads in modern OSes, but UI programming is nothing but side-effects, and has tons of "global" state. (Global in scare-quotes because it's global to the UI but not necessarily to the entire program.)

Like a simple GUI operation is: "if this radio group is toggled to B, then enable button C".

How would a functional language help with an operation like that?

It already helped. Functional approach to GUI is expressing every visible part as a function of program state - exactly as you did. Let's go back to scroll bar example: in imperative paradigm, you'd have some code like "when the user scrolls down, move the viewport X pixels down and move the scrollbar F(X) pixels down", and similar code for scrolling up. If, for some reason (arithmetic bug, rounding error), the scroll-down and scroll-up values don't match exactly, the scrollbar will get out of sync with viewport, which will be especially jarring when scrolled all the way up or down. I believe I've posted a GIF of Windows 10 Start menu having exactly this problem some time ago in one of Windows 10 hating topics.

In functional paradigm, you'd have essentially the same logic, but formulate it differently: "when the user scrolls down, add X to current position (N), set viewport to start at N-th pixel, and set scrollbar to F(N) position". Because the scrollbar depends on model data and nothing else (in particular, it doesn't depend on its own state from previous iteration), it will always be in the same place for the same for the same scroll amount. Even if it's wrong, it'll be wrong consistently.

[pie_flavor]

@masonwheeler That's not what I'd call "difficult". You would think of it simply as you would a mutable variable; the represented name and the underlying concept should stay the same even if the bytes don't. My example with shadowing the string with the number parsed out of it is a perfect example of that.

[blakeyrat]

@gąska said in I hate Scala:

Depends on whether you treat the instance as an input to method or not. Both of these approaches are valid, but the consequences are different - for example, if this is an input, you can't run methods in parallel willy-nilly.

You can in C#, except I'm not sure what you imply with "willy-nilly".

@gąska said in I hate Scala:

Nearly every programming task can be expressed as a problem of converting some kind of input into some kind of output.

... none of the interesting tasks can. Just the boring back-end shit you've written 3 billion times already.

@gąska said in I hate Scala:

Even if "computers are for computing" is bullshit from user's point of view, it is true from the theoretical point of view you can temporarily take in order to fit your design into functional paradigm.

If you're building something like Excel, sure that's sort of helpful while you're working on the engine that calculates the value of cells, but it's utterly useless when you're working with any of the user experience parts of the program. And the latter is the vast majority of the work, and virtually 100% of the interesting work.

@gąska said in I hate Scala:

Let's go back to scroll bar example: in imperative paradigm, you'd have some code like "when the user scrolls down, move the viewport X pixels down and move the scrollbar F(X) pixels down", and similar code for scrolling up. If, for some reason (arithmetic bug, rounding error), the scroll-down and scroll-up values don't match exactly, the scrollbar will get out of sync with viewport, which will be especially jarring when scrolled all the way up or down.

That means you're either working with a really shitty UI framework (like HTML5, where I've seen similar bugs when NodeBB or other "infinite scrolling" sites change the scrollbar length in real-time), or you're working at way too low a level.

[Gąska]

@blakeyrat said in I hate Scala:

@gąska said in I hate Scala:

Depends on whether you treat the instance as an input to method or not. Both of these approaches are valid, but the consequences are different - for example, if this is an input, you can't run methods in parallel willy-nilly.

You can in C#, except I'm not sure what you imply with "willy-nilly".

Any combination of methods, any number of calls, any number of threads scheduled over any number of cores in any order. Without any mutexes. When you have pure functions, you can do it just fine and not worry about any race conditions.

@gąska said in I hate Scala:

Nearly every programming task can be expressed as a problem of converting some kind of input into some kind of output.

... none of the interesting tasks can.

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?

Just the boring back-end shit you've written 3 billion times already.

Ironically, this boring backend shit is usually the only part that CANNOT be made functional.

@gąska said in I hate Scala:

Even if "computers are for computing" is bullshit from user's point of view, it is true from the theoretical point of view you can temporarily take in order to fit your design into functional paradigm.

If you're building something like Excel, sure that's sort of helpful while you're working on the engine that calculates the value of cells, but it's utterly useless when you're working with any of the user experience parts of the program.

It's not.

@gąska said in I hate Scala:

Let's go back to scroll bar example: in imperative paradigm, you'd have some code like "when the user scrolls down, move the viewport X pixels down and move the scrollbar F(X) pixels down", and similar code for scrolling up. If, for some reason (arithmetic bug, rounding error), the scroll-down and scroll-up values don't match exactly, the scrollbar will get out of sync with viewport, which will be especially jarring when scrolled all the way up or down.

That means you're either working with a really shitty UI framework (like HTML5, where I've seen similar bugs when NodeBB or other "infinite scrolling" sites change the scrollbar length in real-time), or you're working at way too low a level.

Or that everyone already adapted functional paradigm for GUI, it's just you didn't notice because they used different buzzwords. I don't know what's the hot thing currently, but in 2008 it was WPF and JavaFX with their XML-like languages where you just said what controls you want your window to have and how the data is filled in, and poof! A complete frontend that Just Works™!

I know it's not exactly how it worked and there were many problems with both, but the general principle was very nice, and very functional. XAML wasn't the ultimate solution to everything, but it was a huge step forward. I'd be very sad if you told me that the world went backwards in the meantime.

BTW Microsoft must be using a really shitty UI framework for Windows.

[boomzilla]

@blakeyrat said in [I hate Scala](/post/

@gąska said in I hate Scala:

Nearly every programming task can be expressed as a problem of converting some kind of input into some kind of output.

... none of the interesting tasks can. Just the boring back-end shit you've written 3 billion times already.

What are...the "interesting" tasks?

[ben_lubar]

I have a compiler for a subset of scala (it supports Go-style goroutines and channels!)

GitHub - BenLubar/coolc

Contribute to BenLubar/coolc development by creating an account on GitHub.

There's also no support for the "greater than" operator.

[dkf]

@gąska said in I hate Scala:

Any combination of methods, any number of calls, any number of threads scheduled over any number of cores in any order. Without any mutexes. When you have pure functions, you can do it just fine and not worry about any race conditions.

Not quite. You've still got the essential requirement of some functions (not all!) for the values that they operate on to exist before they can be evaluated. That imposes some ordering on evaluation, and that means that values have actually got to be synched into memory visible to the other threads, and that in turn requires more expensive CPU operations (memory barriers, etc). Only very unusual hardware doesn't need any of that stuff, and I'm pretty sure you're not running on it (because those systems have highly non-standard memory layouts).

Functional programming is a model; as with all models, reality sometimes kills itself laughing as it breaks the model. (I'm not saying it is a bad model, not at all; just that there's bits of implementation under the covers which are far trickier than the model would lead you to believe.)

[ixvedeusi]

@gąska said in I hate Scala:

in 2008 it was WPF and JavaFX with their XML-like languages where you just said what controls you want your window to have and how the data is filled in, and poof! A complete frontend that Just Works™!

IMHO this is not a "functional" approach, this is a "declarative" approach. Though I see how that might integrate with functional programming, it's still a different concept. It's also IME extremely programmer-hostile as soon as you want to do anything for which there is no pre-made out-of-the-box ready-to-use solution.

In spite of all your assurances, I still don't see how functional programming would apply to UI. By its very essence, a UI is an interface which allows the user to change the program's state by issuing commands; by it's very nature it's stateful and imperative. I can't think of a single UI which would not fit this description.

Both of these properties are exactly opposite to the functional programming paradigm. Sure, there's many bits which you can do in a functional style (such as calculating the viewport position as a function of scroll bar position), and these are what I thought of when @blakeyrat wrote "business logic"; but the essence of the UI is its state and the user's commands, which both simply don't exist in the functional paradigm.

[Bulb]

@mikehurley said in I hate Scala:

official plugin/module for gradle or for whatever existed before gradle

Because:

• They predate Gradle, or at least widespread support for it in other tools and
• What existed before are Ant and Maven, both sporting insanely verbose butt-ugly xml.

@dkf said in I hate Scala:

Maven (which continues to work really well even with obnoxiously complex builds)

What? I couldn't even find a way to do a conditional configuration section it it.

Yes, it's great in that it introduced the repositories and dependency handling so you can finally work on project with many components without having all of them checked out. But it's totally unscriptable.

@dkf said in I hate Scala:

Purely declarative builds, for all that there's things they can't easily express, are the most comprehensible by other programmers; it's better to write slightly longer descriptions if those descriptions are significantly clearer.

They are. But sometimes you need to at least define conditional variants and derive values from system or parameters in slightly more complex way than concatenation. Maven can't even do those (msbuid can) and they would help a lot without making the build that much more complicated.

[Jaloopa]

@pie_flavor said in I hate Scala:

functions are constructible values just like numbers or strings and can be passed to or returned from other functions.

By that definition, isn't JavaScript functional?

[pie_flavor]

@jaloopa Yes.

[Jaloopa]

@pie_flavor but Javascript is clearly nonfunctional, or at best barely functioning