Evolution v/s revolution

Evolution v/s revolution: “The fact that languages will improve over time, as software libraries already do, is exciting. It’s less scary than learning a whole new language.” — sorry, Nathan, but it’s not like that. Language is in a way a paradigm that a programmer accepts to build his software on. And paradigm shift is never evolutionary, so unless the changes to the language are small and backwards-compatible they can discourage innovation as software skills and libraries quickly become obsolete (try compiling a library from before 2000 on the latest GHC). Change and learning are necessary, but a stable foundation is also important.

Tags: ,

This entry was posted on Wednesday, March 5th, 2008 at 6:21 am by Jevgeni Kabanov and is filed under Uncategorized. You can follow any comments to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.

  • http://technically.us/code n8

    Are you really that worried about a “paradigm shift” happening frequently in Scala? The only big shift I’ve experienced is to functional programming, and after that it’s details. I appreciate that Odersky and others are continually working out the language’s kinks and breaking compatibility, which is a separate issue, when they need to. I wouldn’t reject more organization and a public roadmap, but even as things are a large codebase can be written against 2.x knowing that massive, client code breaking changes will not happen at this late stage. 3.x is anybody’s guess; personally I can’t wait to see what they come up with.

  • Jevgeni Kabanov

    Hell, when I came to Haskell it was hard enough. But then came arrows, functional dependencies, advanced type classes, templates, parametricity and a lot of smaller features. I gave up on the language largely because of that.

    I don’t know if Scala is going to change like that, and that’s why I posed my post as a question. Would be really nice to know that “at such and such point we will stop changing the language”. Scala is very tame compared to Haskell and has a very practical approach, I would want to see it succeed.

    Languages should never break backward-compatibility. Instead of Scala 3.x it is much better to make a completely new language in another 10 years, when CS advances enough that it is not feasible to evolve the old language anymore.

  • http://technically.us/code n8

    “Languages should never break backward-compatibility.”

    I don’t agree with that, and if it’s a requirement for you then Scala has already ruled itself out many times over. But if we play with semantics I think we can find common ground. Just think of the major version number number as part of the language name, then it’s a whole new language each time. :) What we can work towards I think is a commitment to only break compatibility across major version numbers, and to continue fixing bugs discovered in Scala n even after the central players have moved on to Scala n+1.

    What I don’t think we should do is take Java’s stability as an ideal. Java has peaked while less rigidly controlled languages, and I won’t name names, that came out around the same time still haven’t maxed out their potential. (On the other hand, $$$ blah €€€ blah.) I would like to see Scala to remain more like those languages than like Java. But if it doesn’t, that’s okay too. If Scala sells out to get inside The Enterprise (kidding! kind of) there are plenty of other cool languages on good VMs coming down the pike.

  • Jevgeni Kabanov

    In the end, as almost everything else, it’s a trade off. But it’s pointless to look at major versions as language name. The changes will still be incremental, so even if they break backward they will not most probably introduce something completely different from the original. Also, making a major version change usually commits all innovation to the newer version, so the users of the old version will be stuck unless they migrate.

    I don’t know of any positive examples of languages that broke compatibility. Visual Basic was broken when migrating to .NET, and it was a very painful process, which decreased VB popularity a lot. Before Scala didn’t really have much users outside academia, but now that community is picking up they should freeze the language.

    What I also don’t understand is why you even want to continue evolving one particular language forever? In 10 years the programming approaches might be so different that the conventions taken by Scala just don’t make sense anymore (like Java today). Why try to cram everything into it, instead of building a better language from scratch?

  • http://technically.us/code n8

    Not “forever,” but maybe a tad longer than Java. And it’s not like Java and its codebases will be going away anytime soon; they’ll trudge on, and the COBOL comparison is only going to become more apt. I’d like to see Scala avoid that fate for as long as is feasible–but I’ll try to be the first person to dump it when something inimitably better comes along.

    You’re right that Scala is just reaching the pivotal point of having a wide, non-academic community. I really have no idea what will happen next but I doubt it will be boring.

  • Jevgeni Kabanov

    For me, learning a new language is not that hard. Learning a new platform and ecosystem, with all new APIs, libraries and even documentation approaches is much harder. That’s why I think Scala is great, it can use Java ecosystem and build on it incrementally. Hopefully whatever comes after does the same. Both Sun and Microsoft have understood by now that language is not as important as the platform.

  • http://technically.us/code n8

    Agreed!