Scala Discussion

What are people's stances on Scala? I had to use it for work, and it's quickly become my favorite language to use in my personal time. I was entirely new to functional programming, but the new paradigm excited me, and Scala has greatly helped me start my transition. However, I recognize problems people would have with it, and I would value some discussion on the questions that arise. Is mixing functional programming with imperative programming the right move? Does being able to solve problems with both paradigms result in confusing project, where the code is split between the two at the whim of the developers? Or is Scala and other languages that fuse the paradigms the way FP will finally enter the main stream? Scala has always hovered just outside of the main stream, and hasn't made any considerable gain or loss in the last couple years. Scala 3 is on the verge of coming out and will address the major problem of comically long compile times. Is this enough to increase use; will Scala's popularity grow, decline, or maintain in the future? Is it really a good idea to have such free form syntax? Does allowing users to write logically equivalent things in several differing forms increase code readability, since you can write the line in the way that looks the most appealing? Or does this just result in style conflicts in large products that make it an over all con? Finally, are languages with a much higher learning curve reasonable to use in the practical world? Even if experienced Scala programmers are more productive then Java programmers, is it really worth the waiting almost a year (as has been shown for some teams) for their productivity in Scala to eclipse their Java productivity that they started with? Disclaimer, that despite my concerns, at the end of the day I'll continue to love it since I feel the language engages me intellectually. It also has a very clear use in Big Data, my field of choice, so learning it is more than just a hobby to me. FP seems to be much more common among lains, so I thought I could get deep answers here (although much of the flack towards Scala comes from FP purists themselves). I know the scope of my questions is rather wide, but I would also appreciate any general discussion of Scala in this thread.

>>3664 >paradigms paradigm is a stupid buzzword that doesnt mean anything. Smalltalk was the first mainstream language to use OO and was always focused on message passing over the idea of objects themselves, Alan Kay regrets that he referred to Smalltalk as object oriented the people who keep harping on the idea of paradigms are mostly C++, Java and C# programmers who subscribe to Bjarne Stroustup's use of the word when he refers to C++ as (((((multiparadigm))))) which is silly because OO in C++ is just an extension of imperative in how OO is implemented in C++, and generics in C++ is also very limited to mostly a precompilation step Go, D, Swift, Rust, Ruby, Python, Javascript, Julia and most any other modern language combines OO with FP, so this idea that Scala has some how invented the idea of mixing OO and FP is really stupid and a waste of time

>Is mixing functional programming with imperative programming the right move? Yes. Almost certainly. It's all computing and they both cover a little for the flaws of the other. More than that they really are analogous. It's not hard to do imperative stuff in lisp and C can be coerced into doing functional stuff, it's just that when you do these things it's generally a little bit ugly and verbose. >Does being able to solve problems with both paradigms result in confusing project, where the code is split between the two at the whim of the developers? No. Being dumb enough to split your codebase into two paradigms does this and people will do this a lot without realising it because they think Paradigm means whatever the language they're using has on the tin. Even within a single language you should have your way of doing things. It can be whatever you like really but, for business especially, it's best to pick something fairly common so that other people can work on it more easily. >Scala and other languages that fuse the paradigms the way FP will finally enter the main stream? They've been fused for decades now so I doubt it. >Does allowing users to write logically equivalent things in several differing forms increase code readability, since you can write the line in the way that looks the most appealing? Or does this just result in style conflicts in large products that make it an over all con? I feel this is very much an ideological dispute. To me, it's not the languages fault that it gave you three ways to do something. It's your fault for trying to use all three instead of having a consistent paradigm, but a lot of people feel differently. >are languages with a much higher learning curve reasonable to use I don't think they have a higher learning curve. If you start people out with functional languages they pick them up about as well as imperative ones. It's just hard to swap paradigms. You have to unlearn all your "mistakes." >>3665 >paradigm is a stupid buzzword that doesnt mean anything That's not true. If you can't see the fundamental differences between lisp and C, I don't know what to tell you. >the people who keep harping on the idea of paradigms Yeah people do take it too far. >he refers to C++ as (((((multiparadigm))))) I've never seen a language that wasn't. With enough time and vodka you could produce a scheme via which brainfuck can do functional code. It'd be the most unreadable verbose thing you've ever seen but it'd be a functional paradigm.

>>3665 >paradigm is a stupid buzzword that doesnt mean anything That's bullsoykaf. Saying Haskell is functional and Java is OO is an efficient way of describing those languages on a fundamental level. Then saying OCaml is also function but C isn't gives you a way to compare languages. Describing C++ and multiparadigm is also not "meaningless". It means that if you want you can write all your code with Classes or not have a single Class anywhere in your codebase. Your choice. Contrast that with Java which requires everything to be a Class whether you like it or not. >Go, D, Swift, Rust, Ruby, Python, Javascript, Julia and most any other modern language combines OO with FP, so this idea that Scala has some how invented the idea of mixing OO and FP is really stupid Those languages you listed are either not significantly functional or are not older than Scala. I think it's fuarrrking hilarious how you failed to beat up your own strawman

>>3665 Are you, like, a troll? Your post makes zero sense.

>>3667 >beat up your own strawman this whole OO vs FP is a strawman, let me show you once and for all the EXACT difference between these two ((((paradigms)))) data.method # OO function(data) # FP There, thats it, thats the entire difference between OO and FP, its just two ways of syntactically doing the same thing. The type system in a OO language connects specific functions to certain data types. The type system in a functional language attaches certain data types to functions, its two sides to the same coin. A functional language could use the data.method syntax and it would function exactly the same way, nothing would have to change in how the compiler is implemented other than this superficial syntax style. The fact that Haskell and Java forces you to use one of these types of syntax doesnt mean anything. Haskell is not a ((((pure functional language)))), Haskell has an environment that holds data, data is mutated in that environment.

>>3671 I think it's a chuuni not a troll. >>3673 It sounds like you're in a difficult phase of your development. Keep learning and keep an open mind. >There, thats it, thats the entire difference between OO and FP, its just two ways of syntactically doing the same thing. There is a lot more to it than that. OO is about encapsulating data and functions which operate on that data within the same data structure. Then you build up class hierarchies through inheritance to share common code. Functional programming is about composing programs from functions and minimizing side effects and state changes. They represent completely different styles of *thinking* and solving problems. I think you are not entirely wrong about significance of syntax. The reason that C++ is an OO language and C isn't is because C++ has the `class` keyword. There is nothing stopping you from writing OO code in C, only that the language will not help you in any way. >A functional language could use the data.method syntax and it would function exactly the same way, nothing would have to change in how the compiler is implemented other than this superficial syntax style. No, this is completely wrong. One reason is because an OO implementation will call a different function based on the type of the first argument (`this`, `self`, whatever) in order to support inheritance and virtual functions. It seems like your ego is much bigger than your knowledge at the moment. Keep learning and keep an open mind.

>>3673 In most OO languages, you can't really make a higher order function that generates a method without also generating a class. You can do that with functions in functional languages. The most important marker of "functional" imho is whether higher order functions are more convenient to use than loops or side effects, and whether function composition or bind operations are easy and convenient to use. The main marker of OO is dynamic dispatch and some set of tools to create dispatch rules (which can be interfaces, class-based inherritance, multimethods, prototypical inheritance, etc etc, though the term OOP usually is understood to mean inheritance). There can be a fair amount of overlap between the two, especially in dynamic languages inspired by Lisp that have multiple dispatch and don't focus too much on class taxonomies.

>>3673 > data.method # OO Where did referential transparency and immutability go? Where did thread safety go? In other words, the differences are more than skin-deep.

>>3687 >In most OO languages, you can't really make a higher order function that generates a method without also generating a class. You can do that with functions in functional languages. This is not really true, most OO languages allow you to make stand alone functions that you can pass around which is why Rust, D, Go, Swift all have high order functions with closure ability. Ruby tries to be a pure OO language which is why it has to use blocks instead of passing functions because the scoping in Ruby is very strict and prevents you from passing global functions to objects >The most important marker of "functional" imho is whether higher order functions are more convenient to use than loops or side effects, and whether function composition or bind operations are easy and convenient to use. Thats actually the only syntactical difference between a so-called pure functional language and a regular programming language is that they remove for and while loops from the 'pure' functional language. Elixir is a good example of this, its a pure functional language, but the syntax in Javascript, Ruby and Python is almost the same as you can do everything in those languages that you can in Elixir, there is really no syntactical difference between these languages except that Elixir removes for/while loops. In fact for loops in Python are really not for loops but rather a foreach-like mapping function which does not require any iterator variable to be maintained and so does not require the programmer to manage mutable state like a regular for loop. It should be mentioned that function recursion is just as difficult and error prone as for/while loops and that you avoid using recursion as much as possible by using mapping/iterator functions >The main marker of OO is dynamic dispatch and some set of tools to create dispatch rules (which can be interfaces, class-based inherritance, multimethods, prototypical inheritance, etc etc, though the term OOP usually is understood to mean inheritance). Its kind of funny that you identify dynamic dispatch as an OO thing when dynamic languages use it as duck typing or monkey patching all the time. Basically what this is doing is saying "I dont care what class this object is, as long as it can accept these methods then the methods will work" which sort of makes it act more like a functional language >>3690 >Where did referential transparency and immutability go? To take Ruby as an example, Ruby is a highly immutable language. Primitive objects like numbers and strings are immutable and cant change. Methods on arrays and hashes in Ruby almost always produce a new array/hash object and never change it in place. Variables on container types in Ruby are reference variables just like variables that hold objects in Java are reference types. Referencial transparency is not a big deal, people think this is a language feature and its not. Haskell has an environment that holds state and this gets changed by passing functions, so this idea that Haskell functions are like math functions is a lot of bull and hype. >Where did thread safety go? The main difference between a functional language like Haskell, Erlang, Ocaml, etc is that they use lists and tuples which are immutable data structures instead of arrays. Hash-maps are already immutable data structures so can be used by both.

>>3694 >In fact for loops in Python are really not for loops but rather a foreach-like mapping function which does not require any iterator variable to be maintained and so does not require the programmer to manage mutable state like a regular for loop. That's wrong. The difference between a for loop and what you call a foreach loop is that the former is mutating an integer index and the latter is mutating a pointer. Otherwise they work in exactly the same way and have nothing to do with map. >It should be mentioned that function recursion is just as difficult and error prone as for/while loops and that you avoid using recursion as much as possible by using mapping/iterator functions You cannot avoid recursion by using map because map is just syntactic sugar around recursion. >Thats actually the only syntactical difference between a so-called pure functional language and a regular programming language is that they remove for and while loops from the 'pure' functional language. This is not just a syntactic difference. Loops are essentially a conditional jump back to label until some local or global state changes the outcome of that condition and it stops jumping. A core component of FP is avoiding state and side effects so iteration is typically achieved with recursion instead. Which nominally means each round of iteration takes place as a new function call. These are two different ways to think about and solve the same problem. A Functional programming language will make it easier to use recursion (e.g. tail call optimization), and like you pointed out, in some cases will only support recursion. On the other hand non-Functional programming languages make it difficult to solve problems with recursion because you always risk a stack overflow. >The main difference between a functional language like Haskell, Erlang, Ocaml, etc is that they use lists and tuples which are immutable data structures instead of arrays. Hash-maps are already immutable data structures so can be used by both. Lists, tuples and maps are not "immutable" data structures. It is down to the implementation to give the appearance of immutability by making copies or deltas when changes occur.

I wrote a long response to this idiot's post, but then realized that it's probably better not to feed them and derail the thread any further. I really wish I could stop wasting time replying to the idiots screaming atop mount stupid, and I wish the rest of the people on this board would too, but I guess I just can't help myself. >>3664 >Is mixing functional programming with imperative programming the right move? I think it's the best way to do things. Functional should be the default, but being able to write imperative code to optimize internal parts of your application and to write the edges of it is very useful. >Is it really a good idea to have such free form syntax? I'm not sure about this. It's been proven time and again that having too much freedom while writing code can lead to unpleasant results, see The Lisp Curse or the bad reputation for readability languages like Ruby or Perl have. And take a look at the popularity of languages with strict guidelines on how to write code (Python) or which have so little syntax/few features that you can only write things well in a handful of ways (Go, Elm). I think free-form syntax is great for single programmers, because it enables them to write their solution to a problem in the most optimal way, but bad for groups of programmers, because then you have to spend time and effort defining a common sublanguage for everybody to work on rather than have the language itself define it for you; it essentially turns syntax into a human problem.

>>3701 Hah, yeah I just wanted a nice thread on Scala before the fp immediately derailed it. It's truly a poor post since I never made the claim or implied any special importance on a potential claim that Scala was the first to mix the two paradigms like >>3665 insinuated I did; I think the credit for that goes to Ocaml, perhaps? Either way it's irrelevant, Scala as a language focuses on and completes this multi-paradigm design. As far as I'm aware, besides Julia, all the languages he mentioned only have specific elements of FP, most since only recently too. I don't think any of those languages (again besides Julia) are to the point where you could write pure functional code in them without being heavily restricted. Part of being a true functional language is having the full suite of tools generally associated with one, that way you can tackle any problem that you could with imperative programming. Arguably to get that full set of tools with Scala, you need to use Scalaz or Cats (eg. Monads and Functors), which is of interest. I think it's fine Scala's core is much more ready for functional programming than any other language that has an external FP library. You can get by without having to use Scalaz or Cats in a lot of cases. I feel like it was also a conscious decision to leave these things as externally maintained libraries too. Recently Lightbend has separated parser combinators from the core to an external repo, and they plan to do this with many more features in Scala 3. This indicates to me that they like this model and are happy with the heavy FP content being separate, rather than not thinking the language needed these things. That was a lot, so perhaps I'll make another post further discussing peoples responses to my open end discussions in a bit. I guess for now is there anyone on /λ/ that uses Scala regularly? I

>>3722 >I think the credit for that goes to Ocaml, perhaps? Barely anybody ever uses OCaml's object system, I don't know about how it was in the past though.

>>3665 Scala deserves some merit as a true multi-paradigm language. Python claim to be multi-paradigm (OO, procedural and FP), but it is like kicking dead whales down the beach at FP. List handling in python is imperative, and wrinting FP code in Python is a pain in the ass. Scala mix OO and FP in a much better way than any language that ever existed.