Regarding 3), you probably meant the Prague Castle, not Karlštejn, right? Karlštejn is far from Prague.
307 karma · joined January 5, 2019
The other use cases have been essentially removed:
* Extension methods are now its own feature, relying on completely different mechanism * Automatic conversions have been severely curbed and de-emphasized, although they are still there, but much more explicit
I would beg to differ. I think he's very much aiming at simplicity. Btw, the essence of Scala really is simple. Take for example DOT (Dependent Object Types is the theoretical calculus Scala is based on), it is simple
https://www.scala-lang.org/blog/2016/02/03/essence-of-scala....
as video https://www.youtube.com/watch?v=bZEWNKzhBoU
Or take his emphasis on simplicity in practical software engineering: https://www.youtube.com/watch?v=-qf8yteuxPs&pp=ygUObWFydGluI...
Than there is the question of practical concerns with Scala, like fitting onto the JVM, interoperability with Java, superficial features for programmer comfort (or lack thereof) and the tendency of some people to use the most powerful features for the simplest of problems that inevitably lead to messy codebases. And that certainly makes things complicated.
> the notion of "object-functional" itself, as a hybrid concept, lacks simplicity
I think this is misunderstanding about what Scala is all about. Scala is not supposed to be 50% functional and 50% object-oriented. It's supposed to be both 100% functional and 100% object-oriented (aka having powerful module system) _at the same time_. It's supposed to be a concrete proof that this dichotomy (FP vs OOP) is false and you can have both in the same language with the same features.
This is contrary to other languages which may have support for FP and OOP but have _separate_ support for each, like SML, OCaml or F#. Scala is in this tradition, but different, it supports FP and OOP with one set of features. And from this point of view it is _simpler_. Whether people find it _easy_ is another question.
But TruffleRuby is something different. It is another Ruby implementation (just like JRuby is a Ruby implementation) using the Truffle framework. And Truffle framework requires to be run on GraalVM.
Is there some other established Go library that contains these collections/containers?
* Distilling the Real Cost of Production Garbage Collectors
https://twitter.com/stevemblackburn/status/15196411576216576...
https://www.youtube.com/watch?v=OUZt0mo1xic
https://old.reddit.com/r/java/comments/udtdke/the_real_cost_...
https://old.reddit.com/r/ProgrammingLanguages/comments/udt2p...
https://news.ycombinator.com/item?id=31192261
* Low-latency, high-throughput garbage collection
https://twitter.com/stevemblackburn/status/15183861337467289...
https://www.youtube.com/watch?v=1TLmawuxHfY
https://old.reddit.com/r/ProgrammingLanguages/comments/ubp2d...
https://old.reddit.com/r/java/comments/ubgyva/lxr_a_new_java...
Also, some people say that it makes for easier (less ambiguous?) parsing.
But the -> part is a bit weird. It "shouldn't" be
def factorial(x: int) -> int:
def factorial(x: int): int =
Not in these exercises. They're focused on algorithms and their asymptotic complexity.
I'm afraid we don't have anything like ST in any Scala library that I know of :(
To be hones, I'm not sure.
> Everything good about objects that a pure functional programmer would want is captured by first-class modules.
I just know that in the talk I linked above, Odersky mentions 1ML, that it converts modules into SystemF (extended Lambda calculus, but you probably already know that) and that he feels this attempt is force fitting where some (important?) things get lost in the conversion.
From 2:56 to 4:55
> The internal mutable state
That is very strongly discouraged in the Scala community.
> subtyping
Yep, that is embraced quite a bit.
> inheritance
Used to some extend but still generally discouraged even though not as strongly as mutable state.
> ... relationships are much less useful
How can you say that subtyping is not useful? In Scala it is one of they key ingredients for modularity. You have signatures (aka interfaces or traits) and than you have multiple implementations (modules, objects, classes as partial abstractions) which you can swap one for each other. That is possible because they form these subtyping relationships. A side note: Scala code which embraces subtyping has better type inference.
> But please do take a good look at Haskell too, if only just for interest.
I don't want to make an impression that I want to offend the Haskell community. Haskell is where I learned FP and the languages is a great success in many regards. Over Scala it has many advantages, like better syntax, better type inference, better control over memory layout, better optimized which turns even advanced idioms into efficient code, etc.
But it also has some downsides compared to Scala. It is lazy which makes debugging more complicated. It doesn't have any satisfactory modularity story (last time I was around there was Backpack, but it hasn't caught on AFAIK). And Scala has all the advantages that come with the JVM and Java interoperability: great debugging, profiling, introspection, telemetry, etc, great IDE, huge gallery of libraries, etc. I'm a software engineer and all these things are _very_ important to me. Compiling to efficient JavaScript with Scala.js is also nice.
> Many leading Scala programmers ended up moving to Haskell, in order to get deeper into FP.
Sure, if you want to write Haskell programs, you'll have much better time in Haskell than with Scala. There were people like that, and so they eventually left. But note that you can be deep in Pure FP in other languages, like Scala or PureScript, Haskell is not the only game in town, each comes with its pros and cons.
That being said, with Haskell, Pure FP is built right into the language. With Scala, while easily possible, Pure FP is built on top of the language with library(-ies) and that comes with some disadvantages.
I would agree that Odersky wants Scala to be popular and wants to accommodate even programming novices. For example Python (and a little bit Haskell and F#) proved significant whitespace to be popular, so Scala 3 now has it. In times of XML's popularity, on Wadler's suggestion, XML literals were added to Scala. Today AFAIK using XML literals is now popular in many frontend/browser frameworks/languages (although XML literals have been dropped from Scala 3).
But that doesn't mean that Scala design is unprincipled. On the contrary, there are 3 pillars that make Scala what it is, all working together in a unified and coherent manner:
* Modularity (objects, interfaces, etc, sometimes called OOP)
* Functional programming (ADTs, pattern matching, preferring immutability, higher order functions, ...)
* Meta-programming (Scala 3 features powerful Macro system, AFAIK inspired from MetaOCaml)
> Folks are moving on from OOP. Scala is in danger of building what people once wanted, but don't want any more.
More and more languages are becoming more and more like Scala:
* Rich type system instead of unityped
* type inference vs having to manually annotate everything
* higher order functions instead of not having them
* preferring immutability instead of mutation everywhere
* ADTs, pattern matching instead of "OOP style" modelling
* module system (sometimes also called OOP) instead of non-modularity
* strict instead of lazy
* ...
It's interesting to see such convergence. New languages are more like Scala now than before. And already existing languages, even though starting are more different, are getting closer to Scala by adding more features. That is to say, Scala is not magical or prophetical, not even original (most, if not all, individual feature was done before in other language), but it's just ahead of the others with combining these features.
https://news.ycombinator.com/item?id=26101435
https://old.reddit.com/r/scala/comments/lerd3t/from_first_pr...
> 1ML paper
I will definitely check it out. Thanks for the suggestion. A quick research suggest that 1ML can't model objects and classes (in the OOP lingo), as per slide 6 in https://www.slideshare.net/Odersky/from-dot-to-dotty https://skillsmatter.com/skillscasts/8866-from-dot-to-dotty
In the meantime, I will continue enjoying Scala that allows me to do Pure FP in a modular fashion while getting paid for it because of its huge (relatively speaking) job market :)
You're technically correct, which is the best kind of correct. Scala is not based on the Lambda calculus. The DOT calculus (which is what Scala is theoretically built upon) is based on objects.
Yet, at the same time
> please do not judge functional programming based on how it looks in Scala
based on my research into the labour market, I would guess that Scala is the programming language where most of the Functional Programming takes place, both in the general sense and also in the Pure FP sense. It is more widely used than Haskell, F#, Clojure, Elixir, Erlang, OCaml, Racket, etc.
And it works rather nicely in my opinion. There are still areas that I'd like to see improved, of course, like the for-comprehension, but I'm already quite content.
> effects to be controlled, checked and reasoned about
Definitely! We have so called Functional Effect System libraries for that in Scala. Not just one, but two: Cats Effect and ZIO. Check them out. I would recommend anybody using Scala do use either of those.
But Odersky's point is that (at least in Scala) it is even simpler (and thus should be preferred) to do it with raw (but still local!) mutation.
My point here was that all "OOP" languages (that I know) allow you, with all their "OOP feautres", to work with objects which actually don't contain any mutable state.
I'll let you be the judge whether it is still "OOP", but I know from experience that it's very practical for Software Engineering.
KEYNOTE Simply Scala Martin Odersky
Of course they don't. These "paradigms" like OOP or FP are just human made up terms _without any basis in theory_. Sometimes they can be practically useful when communicating with other humans, like we do now. But more and more people are starting to realize how meaningless/nonsensical these categorizations are (and always have been): FP vs OOP, compiled vs interpreted, static vs dynamic, etc. We might as well categorize languages based on the colour of their mascot.
See this for more https://old.reddit.com/r/ProgrammingLanguages/duplicates/6xt...
The closest thing to the definition of an FP language that I was able to come up with is "based on the Lambda calculus". Haskell is, Scheme is, F# is. But e.g. Scala isn't, it's fundamental building block isn't functions but objects. But many people do consider Scala to be an FP language.
So let's all be aware of the limitations of these (pseudo-)concepts.
On the contrary, this helps with modularity, which is a good thing. You can then swap out the object for another object with the same interface, but where the functions (methods) have different implementations.
For example, I do _both_ Pure Functional Programming _and_ OOP (in the "module system" way) in Scala daily. And it works very nice IMHO, I encourage everybody to give it a try.
Use traits as interfaces for logical pieces of your business logic. Implement them in (case) classes which receive interfaces to other pieces of logic in their class constructor. Use a so called "Functional Effect System" like Cats Effect or ZIO to avoid raw side effects. And that's it, enjoy and profit.
F# (and other FP languages, like Scala) have standard libraries which come with (and are built around) persistent collections (immutable collections, but with smart structural sharing when doing copy-on-write). And all the other libraries and the whole community is designed for Functional Programming.
There are also other aspects, that FP languages like F# or Scala tend to have shorter and prettier syntax. And many of the FP idioms are easier to express in these languages. Good example would be ADTs (algebraic data types), or Computation expressions in F# and its analogue in Scala for-comprehension. But these are more subjective reasons than my former point.
https://lichess.org/@/thibault/blog/lichess-on-scala3-help-n...
https://old.reddit.com/r/scala/comments/zh3o6x/lichess_runni...
That's just something that Java, Kotlin, nor Clojure don't offer. And there is significant demand for Scala (and its pupose) in the industy (it just not may be as huge as Java or other more mainstream languages).
Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well.
Examples of this "better Haskell" are https://typelevel.org/cats-effect/ and https://zio.dev/ .
All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...).
None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure).
I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.