3 ms·

I'm not sure off hand about this, I dunno what Odersky's level of involvement was in the libraries and tooling like SBT that grew up around it. I think the lan

by kev009 8y ago

I'm not sure off hand about this, I dunno what Odersky's level of involvement was in the libraries and tooling like SBT that grew up around it. I think the language spec of Scala is actually pretty orthogonal to complexity ignoring a few pieces like XML and Java interop https://www.scala-lang.org/docu/files/ScalaReference.pdf https://www.scala-lang.org/docu/files/ScalaReference.pdf -- it builds up continuously upon itself. Scroll down and look at the appendix with the grammar. These concepts compose very well. Because of the composability people end up extending the language, which is a powerful feature, but seemingly in practice in ways that add to the complexity without reciprocal reduction in cognitive load. I really enjoyed reading Odersky's book just for this lesson in composition even though I don't think I'll ever use the language again. Golang, a simple language in use, is basically a grab bag of concepts that implement a syntax people happen to be familiar with from ALGOL-like languages https://golang.org/ref/spec https://golang.org/ref/spec -- there's nothing particularly unifying or composable in that it just happens to work out ok. I'd be interested in a crossover language that has the reinforcing composition of something like Scala but a standard library and common tooling like Golang that are kept simple. Spending time in Rust is on my todo list, it may not be even close to that but looks more useful than Scala long term and retains the type stricture.

erikpukinskis 8y ago
I believe we are coming to a time where we will stop seeing languages as monoliths and we will name language subsets as first class citizens of our namespace. I personally program often in a strict subset of JavaScript. Liberals, function declarations, and function calls only. Of course I can’t do everything in this space. But many projects are just fine. Most code, at least code that’s pretty close to human-relevant vocabulary) is just names and calls when it’s truly properly refactoreded. Unfortunately this becomes untenable when I try to use third party packages. Almost all packages expose APIs in the most advanced sections of language syntax... promises, big rich configuration trees, weird chainable DSLs, objects, etc. So to work with a language subset you need to be able to carve out a namespace within your package management ecosystem. Essentially a fork of the namespace, with people able to “take over” the package and port it to the subset. In your case this would mean a subset of Scala with strict controls on composeability with the existing primitives. And you’d port at least high level scala packages to that API space.

by kev009 8y ago

erikpukinskis 8y ago

I believe we are coming to a time where we will stop seeing languages as monoliths and we will name language subsets as first class citizens of our namespace. I personally program often in a strict subset of JavaScript. Liberals, function declarations, and function calls only. Of course I can’t do everything in this space. But many projects are just fine. Most code, at least code that’s pretty close to human-relevant vocabulary) is just names and calls when it’s truly properly refactoreded. Unfortunately this becomes untenable when I try to use third party packages. Almost all packages expose APIs in the most advanced sections of language syntax... promises, big rich configuration trees, weird chainable DSLs, objects, etc. So to work with a language subset you need to be able to carve out a namespace within your package management ecosystem. Essentially a fork of the namespace, with people able to “take over” the package and port it to the subset. In your case this would mean a subset of Scala with strict controls on composeability with the existing primitives. And you’d port at least high level scala packages to that API space.