airless_bar | 9 years ago | on: Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video]
airless_bar's comments
airless_bar | 9 years ago | on: Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video]
Yeah, it's just that-if you look at every language ever designed-if the language ships with a built-in construct developers will use and abuse it on every occasion, and every other approach lingers in obscurity.
> Which is expected since these two constructs are not aimed at handling errors: they manage missing values.
Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate.
> Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).
That's not true in practice:
Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens.
That's the thing Scala got right, and many of the copy-cat languages got wrong.
airless_bar | 9 years ago | on: Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video]
Not really.
The main strength of the first approach is that Option is only one type out of many error-handling structures.
Not every error is handled appropriately by Option/?.
If you have a language like Kotlin where they hard-coded one way of handling errors, it feels very unidiomatic to pick a better fitting error handling type, while in languages where errors are handled by library code, it's a very natural approach.
airless_bar | 9 years ago | on: Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video]
> formal name
non-shitty
> a trend in newer languages
yes, only discovered a few decades ago
:-D
airless_bar | 9 years ago | on: Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video]
They preserve the structure of the computation.
airless_bar | 9 years ago | on: Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video]
Option[Option[String]] != String??airless_bar | 9 years ago | on: Help me pick the right web stack
I can recommend Scala.
The libraries are top-notch and unlikely to be found in other languages due to the superior typesystem.
It has broad tooling support, and Scala's JavaScript backend is stable, mature and actually works (unlike some other JVM languages' JS backends which currently exist mostly in marketing speeches).
airless_bar | 9 years ago | on: Android platform engineer on application architecture
Standard Googler behavior. :-)
airless_bar | 9 years ago | on: How I fell in love with a programming language
Ah alright. yes, I think it makes more sense to define the GUI with code. Typed resources help with it.
sbt-android-gradle has full support for Gradle projects, but to be honest: Gradle is utter shit. Just use the SBT plugin. it works so much better. The latest version even manages SDK and NDK for you.
airless_bar | 9 years ago | on: How I fell in love with a programming language
Which GUI tools do you have in mind?
airless_bar | 9 years ago | on: How I fell in love with a programming language
Android integration works fine, and the SBT builder is so much better and faster than Google's Gradle one.
In fact SBT + ProGuard is faster than Gradle + no ProGuard.
airless_bar | 9 years ago | on: Scala Native
The C++ comparison is great because it tells readers that that the person making it has no idea about C++, Scala or both.
airless_bar | 9 years ago | on: Scala Native
What Oracle does is cute, but I will put my bet on people who have a solid track record at shipping.
airless_bar | 9 years ago | on: Scala Native
Oh come on Cedric. You managed to troll better in the past.
As you surely know it already, the deprecate-remove cycle is pretty much how a) Scala works and b) C# doesn't work.
airless_bar | 9 years ago | on: Scala Native
There are worlds between Java 8 and Scala and the gap is widening with every release.
Of course you can write Java in Scala and then the benefits over Java aren't that high (but are still there), but Scala is so far ahead in terms of language compared to Java that most current Scala libraries just _can't exist_ in Java.
Adoption these days seems to be great and accelerating, and given the growth of the library ecosystem there are more and more reasons to leverage the benefits of libraries written in Scala especially compared to legacy stuff written in Java.
airless_bar | 9 years ago | on: Scala Native
Not parent, but I would reduce it down to
- C# with VisualStudio + JetBrains addon
- Java with IntelliJ
Why not the others you mentioned?
- IDE support for F# is not very good.
- VB is too dynamically typed to be reliable.
- C++ IDEs seem to be constantly fighting with constructs that manage to break the IDE's understanding of the code. It's gotten better with LLVM, but even VisualStudio is far away from providing a reliable experience.
- JavaScript is dynamically typed, so IDE support is not reliable.
airless_bar | 9 years ago | on: Scala Native
The difference is that Scala devs didn't push for immediate adoption while they were still working things out.
Apple's Swift message is more or less "Stop writing Objective-C if you can and start using Swift – oh and by the way – you will have to rewrite your code with every major Swift release which we will be releasing at a rapid schedule".
It will be very hard for Swift to get rid of all the cruft they accumulate.
In Scala every major release addresses one or two pain points and migration is very smooth – no "rewrite all your stuff".
airless_bar | 9 years ago | on: Scala Native
Scala has been vastly improved since 2.8. If the experience you stated comes from Scala 2.8 I think you will love the way things are working currently.
I wouldn't want to go back to 2.8 even if people paid me a ton of money.
I love ML, but think OCaml is a poor ML. That's why I love Scala. It's extremely consistent, and design decisions are very considerate.
It's an amazing language and I can express my intentions much better than in OCaml (no typeclasses, no higher-kinded types, etc.).
airless_bar | 9 years ago | on: Scala Native
Scala's versioning scheme is publicized and well-understood. Are you trying to blame Scala for not adopting SemVer before SemVer even existed?
Very silly.
airless_bar | 9 years ago | on: Scala Native
How do you plan to deal with the large amount of metadata required for some stuff? Like the timezone database for calendars, the CLDR for formatting stuff, or various Unicode tables for handling case folding/comparions/etc.?
Will you be using native libraries/the data blobs installed on the host system? Or will you ship these things with each binary?
It might not be very interesting in the Option[Option[String]] case but imagine Try[Either[String, Int]] or List[Future[Double]].
It's a very important distinction.
Collapsing cases is one of the primary thing why exceptions sometimes get a bad rap, and Kotlin (and Ceylon) do the same with ? (and |, &) at the value level.