Earlier quoted context omitted.
For what it's worth, this isn't just an evolution of the language, but a complete rewrite of the compiler. I appreciate that they're taking the time to do it right. They probably could've pushed new, non-trivial features out faster if they weren't doing a total rewrite.
Pity that in this rewrite, they were unable to speed up compilation speed. From the latest reports, dotty appears to compile at about the same speed (if not more slowly than) scalac.
Towards Scala 3
331–340 of 383 posts
Re: Towards Scala 3
#332"Scala has pioneered the fusion of object-oriented and functional programming in a typed setting." What about Ocaml (1996, well before scala) and F# (2005, not too long after scala)?
OCaml users tend to avoid its object system, so while it attempted to fuse object-oriented and functional I don't think we can say it succeeded. F# is, as you say, later.
When we do need to use it, it is actually pretty elegant and well-designed. It's just that since we've tasted the power of the more functional abstraction techniques, OOP loses its allure.
Re: Towards Scala 3
#333Earlier quoted context omitted.
> I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them -…
What IDEs support this behavior?
Re: Towards Scala 3
#334Earlier quoted context omitted.
If " is very powerful when used correctly, but terrible if not": think long and hard before adding to a language.
Completely agreed. Implicits are the one place where Scala genuinely pushes the art of language design a bit beyond what's really possible; I expect future languages to come up with a better solution to the same problem. But in the meantime the things they enable - typeclasses, extension methods, the magnet pattern - are too valuable to do without, and we can't just sit around and wait for the perfect language to arr…
Extension methods: too much potential for confusion
Magnet pattern: no idea what that is
Personally I feel OCaml strikes the best balance :-) But we may be arguing about an inch here rather than a mile.
Re: Towards Scala 3
#335Earlier quoted context omitted.
Being brutally honest, compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose. I'm almost certain its creators chose the syntax in order to tempt curly-bracket programmers, not because they liked it personally. I really hope that future high-level languages will use better syntax and move on from the C/C++ influence.
> compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose I have never worked extensively with Haskell or ML, but what I can say is that Scala's syntax is better than that of most other mainstream languages. Three of Scala's syntax niceties are: 1) No semicolons 2) No braces required for one-line functions 3) No constructor required: instance arguments passed in…
Scoping is hard.
Re: Towards Scala 3
#336Is there any plans to include async/await on the language level?
async/await is a special case of monads (expressible with a for-comprehension); it comes out to: def asyncFunction(): Future[Blah] = for { foo
Re: Towards Scala 3
#337Earlier quoted context omitted.
For what it's worth, this isn't just an evolution of the language, but a complete rewrite of the compiler. I appreciate that they're taking the time to do it right. They probably could've pushed new, non-trivial features out faster if they weren't doing a total rewrite.
Pity that in this rewrite, they were unable to speed up compilation speed. From the latest reports, dotty appears to compile at about the same speed (if not more slowly than) scalac.
Re: Towards Scala 3
#338Earlier 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?
Scala, on the other hand, gives you a huge toolbox down to some really complicated to reason about features like implicit parameters, creation of completely arbitrary operators, etc.
[Insert some funny pun here about Java giving you a simple tool while Scala gives you an incredibly complicated one]. They're both great languages, but they serve very different purposes and audiences - Kotlin happens to fit Java's demographic better than Scala as a result, it doesn't have the magic and complexity to the same degree Scala does (the most confusing new constructs probably revolve around builders/lambda's with receiver types which aren't needed by most developers not writing DSL's).
Re: Towards Scala 3
#339Earlier quoted context omitted.
https://www.typescriptlang.org/docs/handbook/release-notes/t... > TypeScript 2.6 introduces a new strict checking flag, --strictFunctionTypes. > The --strictFunctionTypes switch is part of the --strict family of switches, meaning that it defaults to on in --strict mode. > Under --strictFunctionTypes function type parameter positions are checked contravariantly instead of bivariantly. > ...(etc.)
Contravariance then, right. Thanks! I haven't gotten into Typescript yet, and at this point it looks fairly large and a little daunting, so this is helpful.
Re: Towards Scala 3
#340As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow). Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.