Earlier quoted context omitted.
Scala enthusiast Jon Pretty just announced `fury` as well!
Do you have a link to that? I can't seem to find it.
Towards Scala 3
351–360 of 383 posts
Re: Towards Scala 3
#352Re: Towards Scala 3
#353Earlier quoted context omitted.
Good point; I've mused before that dynamic languages will always be a ~generation ahead of static languages, due to what you point out, that type systems are hard, and very few people start working on a new type system as their hobby project (vs. hacking out a new syntax with an interpreter). But I hadn't appreciated the difference in difficulty between an unsound type system like TS and Scala's type system... I gues…
> I've mused before that dynamic languages will always be a ~generation ahead of static language Did you mean "behind"? The trend is pretty clear: dynamically typed languages are disappearing and all the popular modern languages are statically typed with type inference. Most dynamically typed languages are busy adding static safety through gradual or opt-in typing, but you don't see the other way around. Javascript w…
> dynamically typed languages are disappearing and all the popular modern languages are statically typed with type inference
It does seems that all the dynamic languages are learning what the systems people knew in the 70s: for the Enterprise, correctness counts.
A happy v1 is only 10% of the story... Getting to v225.5, warts and all, is just something else.
Re: Towards Scala 3
#354Earlier quoted context omitted.
Kotlin has many benefits that Scala has in terms of “being a better Java” without sacrificing the readability and usability benefits of Java itself. Scala is a fantastic language, but it’s not one your average Java developer can pick up in a day or two.
What readability and usability benefits are you claiming Java to have?
i am almost never surprised when I am reading java code. Its almost never about the code.
With scala I seem to have wtf moments about the language every once in a while. (eg: magnet pattern)
Re: Towards Scala 3
#355Re: Towards Scala 3
#356Earlier quoted context omitted.
Maybe a disagreement here is fueled by the power level difference in these two features. Beyond the superficial injection examples, Scala implicits also support injecting values constructed dynamically and also recursive/derived implicits.
> injecting values constructed dynamically You can also do this with default arguments, e.g. like so: let f x y = let g (a = x+1) b = ... ... For example the following is valid OCaml: let bump ?(step = 1) x = let waa ?( a = step+17 ) b = a * b in x + step + waa 666;; Here the function waa has a default argument whose default argument depends on bump's default argument. > recursive/derived implicits Recursion is quite…
Your example of nested functions with default arguments does not correspond to what derived implicits do. As a result of implicit resolution, an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves. Default parameters simply cannot do that.
The example you give to justify "recursion is quite restricted" is not a restriction on recursion at all, it's an ambiguity problem. Define `a` as `y` to shadow the function parameter, and it compiles.
Re: Towards Scala 3
#357Earlier quoted context omitted.
Also, no plans to get rid of implicits apparently. Sorry Scala, we're not gonna be friends.
What is your main complaint with implicits? If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits? Let me paraphrase M. Odersky's PLDI 2017 keynote: The essence of Scala is implicits You can find it at https://www.youtube.com/watch?v=br6035SKu-0
"If you don't like them, why don't you add "Use of implicits forbidden" to your coding style guidelines, and check in code-reviews, and add a "grep implicit" check to your CI setup that refuses to commit Scala code with implicits?"
Only someone who has never worked in a team before would suggest this.
Re: Towards Scala 3
#358Earlier quoted context omitted.
> One of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world, although this is not the only motive (thigh integration of OO and FP being another). I'm not sure why you would think that. Odersky has long claimed ML as his primary functional programming influence, not Haskell. It does have HKT, so there's that...but that's about it. Typeclasses aren't really a part of the language.…
From an abstract PL theory POV, Haskell's key innovation over ML was HKTs. It was an experiment at the time, but one that was successful beyond all expectation: I cannot imagine designing a new PL without HKTs. (Note that Rust is also trying to add HKTs, but has been running into difficulties with type-based lifetime tracking IIRC.) Implicits are a generalisation of default arguments (I don't know where they were pio…
> Haskell's key innovation over ML was HKTs
In fact, ML modules have had higher-kinded types [1] since before Haskell even existed. I guess Haskell's main innovation in this domain is really its very convenient higher-kinded parametric polymorphism with type classes.
[1] MacQueen, D B (1984). Modules for Standard ML. Conference Record of the 1984 ACM Symposium on LISP and Functional Programming Languages. 198-207.
Re: Towards Scala 3
#359Earlier quoted context omitted.
Would love to see a citation re: Odersky (or if he'd chime in here). My general assumption is that if Scala was intended to be category theory, implemented, something along the lines of scalaz or cats would have been built into the language -- the philosophy of the language does not include a JS-esque philosophy of small stdlib, big library ecosystem.
See this talk https://youtu.be/P8jrvyxHodU He mentions module systems fairly early on.
What does this have to do with the original assertion that "one of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world"?
AFAIK, Odersky doesn't particularly like people trying to replicate Haskell patterns in Scala. For example, he thinks using monads for most effects is inappropriate.
Re: Towards Scala 3
#360Earlier quoted context omitted.
> injecting values constructed dynamically You can also do this with default arguments, e.g. like so: let f x y = let g (a = x+1) b = ... ... For example the following is valid OCaml: let bump ?(step = 1) x = let waa ?( a = step+17 ) b = a * b in x + step + waa 666;; Here the function waa has a default argument whose default argument depends on bump's default argument. > recursive/derived implicits Recursion is quite…
Your example of nested functions with default arguments does not correspond to what derived implicits do. As a result of implicit resolution, an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves. Default parameters simply cannot do that. The example you give to justify "recursion is quite restricted" is not a restriction on recursion at all, it'…
> does not correspond to what derived implicits do
I did not claim it did. The first example disproved ionforce's claim that default values cannot be constructed dynamically.
> Define `a` as `y` to shadow the function parameter,
Whoops, yes that's correct. I didn't realise this was possible.