Kotlin is a joke, but Scala's mismanagement and treatment of its contributors might be its undoing. Source: #1/#2 top active community contributor (depends on whether you count commits or locs in scala/scala) leaving Scala, because I'm tired of their shit.
Yeah, Scala's a bit of a mess right now, definitely not thrilled that the flagship web framework (Play) won't be supporting Scala 2.12 until the 2.6 release (i.e. 4-6 months from now), which is absurd given that pretty much the entire ecosystem has a 2.12 release at this point :\
As for typed alternatives, there's no substitute for Scala. Maybe Haskell or OCaml if you leave the JVM, but otherwise it's pretty much a language wasteland for anyone that's taken a dip in the ocean of Scala.
> because I'm tired of their shit
heh, think it goes both ways ;-) As an observer none of the powers that be took a liking to you calling them out, justified or not (agree that community contrib takes a back seat to Lightbend/EPFL).
Good luck wherever you've wound up (and thanks for the biased Either contrib in 2.12, finally!)
> As an observer none of the powers that be took a liking to you calling them out
The best way to avoid being called out for saying completely different things in public and private is not saying different things in public and private.
If me politely asking for clarification about this sudden change of opinion is "underhanded behavior", or "renouncing from future interactions" means "let's find some flimsy pretext to contact your place of work to tell them what an evil person you are" then Scala might have some issues attracting and retaining contributors in the future.
There's always Typelevel, sure you'd be welcome there as that's kind of the anti-establishment wing of the Scala community ;-)
It's also thriving/taking off, tons of contributions from myriad brilliant minds; for this reason I'm not too worried about Scala, it will continue on with or without Lightbend steering the ship.
They won't be able to prevent the language from being run into the ground by SIP/SLIP/SPP committees.
Anyway, getting told that I'm not qualified to tell people that their new language extension ideas tick all the boxes of "bad ideas that we are regretting and deprecating since years" after I have more or less managed deprecations and removals for four major versions of Scala ... I guess they need to find someone else to do my job now.
But given past experience, the people who are eager to add more and more features are seldomly the people who clean up after themselves.
Most upcoming language proposals have extremely poor quality, ignore years of lessons learned, repeat many mistakes of the past, reinvent things that have been tried without success elsewhere and have no respect for design principles that made Scala great.
So glad that my name won't be associated with this.
Well, will be interesting to see how Dotty plays out.
DOT may have been proven sound, but compilers are complex beasts; implementing DOT while preserving an upgrade path for Scala will likely be both difficult and limiting (since Dotty will inevitably be shackled by Scala's past).
For now we've got Scala though, in a couple of years maybe Dotty.
Dotty will inevitably implement the same features with the same fundamental issues. This is not about some old stuff we all regret having in Scala, this is about new low-quality proposals. When they get rubberstamped, they will end up in both Scala and Dotty.
I agree, which is why I started my own series, as lmm mentioned, with showing simple ways of (ab)using gcc to figure out how to do simple/primitive code-generation, and built up from that, instead of building down from lexing/parsing.
Lexing/parsing is important of course, but it's been done to death, and for most of the simple types of languages people tend to use for teaching, it's a simple problem.
Code generation, on the other hand, is still pretty poorly covered, in my opinion, and something people tend to struggle with a lot more, even if you resort to tools like LLVM (and that's fine if that's what you want, but I'd argue you should try a lower level approach at least once to understand some of the challenges)
Exactly. I'm in the pursuit of build one. My first questions? How make a REPL, a debugger, how implement pattern matching, type checking, if a interpreter can be fast enough, if possible to avoid to do a whole VM for it, etc...
Exist a LOT of practical questions that are left as "a exercise for the reader" that need clarifications.
In the end, the parsing steps can be summarized as:
- Do lisp/forth if wanna do the most minimal parsing and do a lisp
Or:
- Use a parse generator, if not care about the quality of this
Or:
- Use a top-down parsing by hand, if wanna some control
ANY OTHER OPTION is non-optimal, and will divert from the task, EXCEPT if you wanna do something novel.
If will let aside the parsing stuff, we can put more in the hard and more rewarding aspects.
I found http://hokstad.com/compiler a lot easier to understand than any other compiler tutorial I've seen. Writing a compiler the way you'd write any other program. It does end up with e.g. a distinct parser, but only when the reasons that might be a good idea become apparent.
Though in retrospect I think it should have been two separate series (and I need to write a few more parts; I'm very close to having it compile itself as of last night).
I think it'd have been better to evolve the initial simple language into an equivalently simple language to parse, and kept the long slog towards compiling Ruby as a separate thing.
Especially as that has complicated things enough to be in severe need of various refactoring (which I'm avoiding until it will compile itself, at which point I'll start cleaning it up while insisting on keeping it able to compile itself..).
The parser itself started out conceptually quite clean, for example, but the Ruby grammar is horribly complex, and I keep having to add exeptions that's turned it quite convoluted. I don't doubt it can be simplified with some effort once I have the full picture, but it's not great for teaching.
If I were going to write a programming language for myself, I would lay out the following challenge to myself:
> You are only allowed to store the AST and variable names found by parser. The input to the lexer is not allowed to be persistent.
To do this, your lexer would need to be in some sense invertible, capable of both producing a source-code-representation of an AST given some naming metadata, as well as converting that source-code-representation back to names+AST.
I think that would make the lexing + parsing task worthy of an 80% article.
How about making your comment useful by enlightening the community as to the relative unimportance of these aspects of contemporary PL design, and suggest some other aspects for would-be designers to focus on instead? Just imagine: you could even link to resources for the latter!
I think it's just because they run out of steam after doing the "first part", and there are backends like LLVM available.
The Red Dragon book has the same issue, except they spend 800 pages on basic parsing and only end up making it sound terrifying and mathy. Definitely recommend against reading it.
Maybe a different place to start would be making your own bytecode?
One problem is that syntax is just one (rather shallow) part of the design of a programming language, but it's one that gets a lot of attention because everyone who's used two programming languages can tell that it's a point where languages differ. Semantics (rules about what blobs of syntax mean) is a much more interesting way for languages to differ, but most "build a language" tutorials I (and probably GP) have seen don't seem aware that there are even decisions to be made there. The "your own" bit in the title is also a bit upsetting for a post that hands the reader a language and its implementation instead of talking about something of the reader's own design.
The article isn't very good, even the link to the 'official' page is outdated.
Just use sbt-android and skip all the other nonsense.
Compilation is impressively fast, as the plugin uses the information from incremental compilation to skip ProGuarding completely for things that haven't changed.
I don't think the Scala-on-Android devs have any plans of giving up, they just took a wait-and-see approach until Google ships their new Jack/Jill stack: http://get-scala.org/2.12#scala-on-android
There is no sense of hurry as 2.11 won't go away and will have a long life.
The sbt-android plugin is really amazing. It makes compiling with ProGuard enabled as fast as Gradle without ProGuard, due to the plugins integration of incremental compilation with ProGuard.
Plus, there are quite a few built-in features and "add-on" plugins which enhance the experience further (sbt-android-protify, sbt-android-gradle).
A bunch of people built an "official" website around Scala-on-Android recently, scala-android.org. If you have any questions drop by in the Gitter channel: https://gitter.im/scala-android/sbt-android
The official release is not yet announced, neither on scala-lang.org nor on the scala-announce mailing list. Your move seems overly aggressive. Why would you publish them before the maintainers?
I haven't announced anything and I haven't submitted this link to HN. I just added a comment to let people know that I might read and try to answer questions if they have any.
This submission's title at least reads "release notes" and not "2.12 released" like the submission yesterday, when people found the artifacts on Maven.
If I remember correctly, for 2.12 the compiler will generate additional forwarder methods, which mitigates the performance issues, but increases file size again.
It's still a lot smaller than 2.11, but for instance the standard library of 2.12.0-RC1 was 900kB smaller than 2.12.0.
