Scala Center
scala.epfl.ch
scala.epfl.ch
Edit: To clarify what I mean -- http://underscore.io/blog/posts/2015/06/10/an-introduction-t... exemplifies, to me, what is wrong in Scala-land. If Abstract Algebra is prerequisite knowledge for tools I 'really should be using', something has gone horribly wrong.
We heard the same thing with C++ 20 years ago and see where it went...
That's... actually simple stuff.
nobody is forcing you to use this wizardry in Scala
You can write it in a simple, matter-of-fact better Java style; or you can leverage the power of abstractions to create something advanced.
Part of the reason this issue pisses me off so much is that I have a degree from one of the top CS programs in the world. I was definitely more of a theory than a systems person. And yet it still feels like a pile of unnecessary ego-stroking gibberish.
I feel comfortable saying most people who make software are less-experienced in this area than I am. When I run into this, I can at least say: "This is bullshit", and not feel the imposter syndrome of "It's just me -- I'm not smart enough for this" that I imagine most people feel.
Beyond that, functional programming is, by and large, easier than imperative programming. I love writing Scala -- It's honest about side effects, honest about concurrency, and has one of the better type checkers around. And I'm sick of seeing people try to "fence off the riffraff" by raising the barrier of entry to the Scala community.
Beyond that, functional programming is, by and large, easier than imperative programming.
It's definitely is possible to go overboard with operators, making a codebase very confusing. Case in point: the lens library. Though those are optional, and the best practice is to just use the actual word functions.
Beyond that, it's very easy to go down a rabbit hole of terminology. Javascript programmers write functors all the time, but I don't know if I've ever seen the word "functor" written in a JS context by anyone other than raganwald. They're just functions, and the fact that they return functions is damn useful.
Being pedantic: functors don't return functions, functors let you map over structures.
I totally support @jowiar on this. I have about 4 years of experience of writing in Scala and I don't think there was even one day when I needed to know monoids, functors and monads :) I have a blurry idea what monads are about but, honestly, I could have done without it.
In my work, when I make code reviews, I emphasize simplicity and readability. And I wouldn't want to see anyone of my coworkers using scalaz or a similar library. It's not true that if you don't like it you don't have to use it. If in a team of developers one person starts to use them, it's eventually going to propagate: After some time someone will have to write code accessing the code written with scalaz, then another person will have write something using that, and so on, and so on. And then it is enough that an experienced developer goes to another project and a new one takes her place (and this is not a rare situation - it's just something that happens every few months). And then the new developer looks at the code and is unable to say what is happening there without learning what all those cryptic operators and weird classes names are about.
The strength of a programming language lies not in how few times you have to push keyboard keys in order to write an application. It lies in how practical it is for a team to collaborate using it. If a team decides that the language is hard to read and hard to learn, they will search for another one. If enough teams decide that, the language dies.
That's a slippery slope. When you are staring at a huge stack of accumulated knowledge, you need to decide when you can start ignoring the details past a certain level.
It's not required to know assembly to write code in a modern language, but it helps. It shouldn't be required to know category theory to write code in a modern language either.
And doing that has an effect, in that it increases the number of concepts that a person needs to grok to be a functioning member of the community -- to be able to dive into open-source code, discuss code with other participants, etc. Adding concepts should only happen when it's clear that the benefits are larger than the costs -- not just for the individual, but for the community. It requires far less knowledge to dive into a Ruby or JS codebase than it does a Scala codebase. And adding "category theory" as a necessary prereq for being part of the Scala community just makes things incredibly exclusive.
Easy to grasp for whom? A first grader? Sixth grader? Twelfth grader? College undergrad? Any specialty or only CS? Or grad level required?
You've forgotten how long it took you to get comfortable with abstract algebra, it's a lot more complex to grasp than you think.
i've read a lot of negative opinions on scala, that it's becoming too big and too complex
and honestly, i was kinda sorta, waiting for it to fail or fall out of favor
this doesnt seem to be happening, on the contrary, scala seem to be getting more popular, compared to language which i favored (like clojure or f#)
are the negative opinions wrong, overblown, or is scala really heading for failure, what am i missing, what did i see wrong
I was the newest dev on a team that had an existing code base that was built around Spray, Akka, and Slick. And they wrapped an Actor around Slick so it "fit better". I've written tons of asynchronous code (Java, C++, Linux, and Windows) so that wasn't what got me. It was just how the original devs spent so much time making everything was an actor. Even in areas that didn't need to be.
At that point having never seen Scala, I just attributed it to the language vs the use of libraries.
Having now spent time with just the language, I like it. Just my introduction was jarring because of all the "everything must be asynchronous" nature of the code base I "learned" on.
You should read Java Concurrency in Practice, the entire book is explaining all the concurrency methods they have. And thats already a very good book (one of the top in my list). In Scala, I just need to read through a few pages of documentation and the rest is simply practice in mixing and matching patterns and a few configuration settings.
The biggest problem with Mandarin is not the tones but the fact that you can't fall back on written language to help you out with anything at all. It's like learning two difficult languages at once. If you really want to learn it, though, it's entirely possible. All it requires is a human brain and consistent effort.
To give an equally sincere response: dynamic languages are dead, and languages without higher-kinded types are dying - they're too useful to do without, and Scala shows they're practical. We're still discovering more things you can do with Scala.
I think the language we'll be using in ten or twenty years' time won't be Scala - or it will be a Scala that's changed unrecognizably from the Scala we know today. But I think that whatever language it is will have a strong type system with type inference and higher kinds and some kind of typeclass functionality and probably also traditional-OO subtyping (failing that at least Go-style delegation), will allow method calls without brackets and concise lambdas with something like "_", will have a culture of not using C libraries via FFI, and will be strictly evaluated. If you wrote a clean new version of Scala today there's a lot you'd leave out (you might end up with something that looked rather like Ceylon), but I think those things are here for good. Maybe it'll be Idris, maybe something else.
That said, the Scala community seems to be moving away from many of the dumber ideas (mostly along the lines of respecting readability over 'expressiveness').
I don't think it's even that. I mean the symbolic method names are an unfortunate piece of community history that can't die soon enough, but other than that a lot of warts are just failed experiments or things that we now have a better way of doing or even things where a compiler flag gets you the right behaviour but the default is the bad backward-compatible way of doing things - Scala grew organically to reach the point it's at now, and it shows.
If anything I think Typesafe/Lightbend listened to the critics too much and put too much effort into backward compatibility. The best thing for the language would be to remove a lot of old features, many of which are barely used in any case. On the plus side they've taken the positive step of modularizing the standard library and moving pieces out of the core.
the core is sound
The core idea of ML is this: strongly typed with parametric polymorphism and full sum and product types, type-inference, first-class functions, first-class state, (almost) first-class modules. Exceptions as first-class non-local control mechanism.
The key innovation Scala have over its predecessors Ocaml and F# which also attempted this merger is that Scala recovers ML-style functional programming as a special case of OO programming, while the predecessors when the other way, which didn't work so well.
I think sequential programming won't be the deciding factor. Error handling becomes more difficult when concurrency is involved. It's unclear whether the monadic approach scales to concurrency. The Erlang experience seems to suggest that more complicated approaches might be appropriate.
I agree that that 1ML is interesting. Some of the warts come from JVM/Java compatibility. In what sense would you argue that OOP can be successfully encoded on top of a typed lambda-calculus? Finally, the relative simplicity of DOT [1] indicates that Scala's core is not that complicated.
[1] N. Amin et al., The Essence of Dependent Object Types. http://infoscience.epfl.ch/record/215280/files/paper.pdf
- The existence of a reasonably well-funded organisation (Typesafe/Lightbend) stewarding Scala was well-received.
- Typesafe/Lightbend's independence also helped, in the sense that I cannot see a Scala-like language succeeded if it had come from e.g. Oracle.
- Scala's open-sourcing of everything helped.
- The well-executed and well-timed Scala-MOOC also helped a great deal.
- Odersky's fame and track-record helped too.
None of those might have driven your Scala adoption (or mine), but they might have helped others to shift their dev towards Scala.
I expect Scala to gravitate more towards DOT in the future, as early mistakes in Scala's design will be ironed out.
It might be interesting to see how the form of OOP that you are interested in can be expressed in DOT, for example by removing subtyping form D_{<:}. Have a go at it!
1ML is based on F-omega, which has higher kinds but not dependent sums or products, while D_{<:} has path-dependent products but no apparent higher kinds, if I understand the paper correctly.
The "new" 1ML paper is already old, and nothing ever happened. (Which is the core issue of ML: Cool papers, but nothing ever ships.)
Since then, DOT has been proven to be sound, dotc can bootstrap itself, and large subsets of "Scala 2" can already be compiled with dotc.
Dotc also sports a very interesting design with its mini-phases + phase-fusion approach, denotations, less desugaring, and a more immutable AST. The speed improvements have been very promising even though no performance tuning has happened so far.
TASTY is on track as a standard IR to express code as an entity that can be produced by different compilers and compiled to different targets like (JVM, JS, ...).
SBT recently gained a compiler interface to drive compilation with dotc, and dotc gained support for producing Scala.js IR.
What happened to 1ML since the paper was published?
Of course it's a lot harder than building one side and then claiming that the other side sucks because the whole paradigm sucks (but we still wanted some research grants (looking at you, OCaml)).
Scala's OO+FP approach allows me to appreciate both sides where they have their strengths. This is in contrast to languages like Haskell which can declare that FP is the best thing ever (because that's the only way to write programs in Haskell ("but, but, you can do these terrible contortions and write things that look like OOP in Haskell" – let's just skip that point, it doesn't add anything to the debate)).
it's just the only currently known way where
both modular and functional sides are actually
useful without introducing completely separate
sub-languages.
would get a lot more funding
In case people were wondering, the 1ML project can be found here: https://www.mpi-sws.org/~rossberg/1ml. The key idea here is that ML-style modules (which in the past were though to need a separate module language) can be coded up into System F-omega (the "workhorse of modern compilation").
I don't think any of the 3 main guys behind it (Russo, Dreyer, Rossberg) works on modules all that much right now. That may explain the relatively tardy speed of development.
Maybe. Tooling is coming in leaps and bounds for dynamic languages. Codebases are also trending way down as companies move to "microservices". Both bode really well for dynamic languages.
I actually think the 10 year future is going to be dominated by languages where you don't need to think in terms of types at all but you get all the benefits behind the scenes.
Yeah, but it tends to involve reimplementing a type system - if anything this is a sign of how mature and easy type systems have become. I think we may see languages with optional/best-effort typing for a while longer, but there will be no more pure dynamic languages; every new language will at the very least have a python3-style language-level standard for how to record type annotations so that tools that work with types can interoperate. And once you have that, it seems stupid not to have the language check at least the simple cases.
> Codebases are also trending way down as companies move to "microservices". Both bode really well for dynamic languages.
I think that's effect rather than cause. If you're writing a big system in (say) Ruby, microservices become the only way to achieve the required level of isolation.
> I actually think the 10 year future is going to be dominated by languages where you don't need to think in terms of types at all but you get all the benefits behind the scenes.
I thought that for a while, but types a really useful tool for thinking with. In Scala I could write Python-like code that wouldn't need any explicit types (they'd all be inferred), but instead I use types to help express the design.
I think scala will remain a very favorable language for any team that needs all of the following three.
1, ability to do functional programming with a strong(ish) type system
2, ability to do actor based parallel/distributed programming
3, Java compatibility
Given my choice of options, I will choose to build new systems in almost any other JVM language, including stock Java 8. However, the language isn't going anywhere, and is worth learning. I find that feedback is fastest in Clojure. Your mileage, as always, may vary.
There are a variety of 'factions' in the Scala community, with very different agendas. They disagree about which parts of the language are useful, and which ones to outright cut out. Research language focus, vs practical use in the enterprise. From easy to learn to (here, to learn Scala, first learn category theory and Haskell). From wanting a large language with batteries included, to wanting a really tiny standard library. And many in those groups not only hate each other's guts, but will very happily claim that whatever other groups are doing is not worth using under any circumstances.
With a situation like that, it's very easy to find criticism about every single piece of the language, and every single company that has supported Scala in any way. Twitter Scala, Scalaz scala and Typesafe Scala are all different: I have never seen this level of division outside of the olden days of LISP. So of course everyone complains about it becoming too big: If you cut some features of the language, entire factions disappear. The complaints are purely political.
So it's very easy to get ideas of doom and gloom from Scala, when it's being used in production in a lot of places, to solve very real problems. Akka, Scalding, Kafka and Spark power a lot of things, but the infighting has to end, and that will take a lot of attitude changes everywhere.
That's one of the strengths of the language. You can be productive from day one writing 'java++' style scala, and slowly move to the functional side at the speed and level of 'purity' you desire.
I've seen many programming languages become popular (or fail to) over the years and this quote has always seemed to hold true.
With Scala there was the first wave of people working in it that claimed that it was a grand panacea for all the problems in software (as is always the case with new languages).
However, it wasn't until people started to really claim that the language was certainly doomed that it clearly was a success.
In general I have found that Stroustrups quote is, counter-intuitively, a good way to determine whether the next hot new language will really stick or not. Furthermore, I have to admit that even some of my favorite programming languages fail this test and honestly these languages are extremely unlikely to ever achieve mainstream success.
And if you really think about it, it's not so counter-intuitive. Programming languages don't show their real limitations until you are very deep in a large complicated project. The frustrations of the beginner are never the same as the frustrations of an expert and only an expert can really feel that a language is "doomed". This sense of "doom" is often just the realization of the once language X zealot who now sees that this new language is not a true panacea. But this moment of disillusionment is also the moment an idealized programming language has proven itself a practical one. The more people that feel this loss of faith in their favorite new language, the more people are building large, practical, real-world software projects with it.
Clojure is growing steadily. It just doesn't have rocket ship growth. It is certainly mature enough to use in production systems and many companies do.
It has a few adoption issues though. The strong typing crowd don't like its dynamic typing, it's not a c-like language, and it doesn't have a large company backing it.
F# has the perception in the industry as a testing ground for good ideas for C# and a second class citizen.
One of the greatest problem is compilation time, however since computers get better this will be reduced. And still the team is working to bring more Scala <-> Java interop and a newer compiler which will bring compilation times down, too.
Saying that, Scala 2.12 will still be relatively slow compared to say, C, Go, Java and similar languages not high up on the abstraction ladder. The real compiler speed up will be coming with Dotty (Scala 3). Martin Odersky estimates that Dotty will be up to 4X faster than present day Scala.
Improved incremental compilation of #scala in the
making yields 10-40x compilation speedups:
https://github.com/sbt/sbt/issues/1104#issuecomment-188529825
After turning on the java8 backend in Scala, our
bytecode size decreased by 50% and compile times
decreased by 75%. Amazeballs!
It's just been released, but I like the idea of adopting a tool in the likes of gofmt. Coding style discussions are such a bike-shedding magnet, it's good if you can just not think about it (and are able to follow it anyway, regardless of IDE).
Scalafmt is indeed new, just released 0.1.0 last week. However, it's already become useful for me with the IntelliJ plugin. Scalafmt is practically my full-time job for 2 more months so you can expect it to get more mature soon. Feature requests and bug reports are very welcome.
Many engineers I know would love to work near a farm, heck I'd even consider that a perk of the job. "Sick of twitter? Go look at some livestock."
This is subjective, obviously.
If you want something much more Haskell-like on the JVM, check out Frege https://github.com/Frege/frege
This sounds little odd. Has there similar efforts for other languages?
- Both Maven and SBT make it really easy to add third-party package repositories. Whether this is a good thing or not, this somewhat obviates the need for a centrally managed package registry.
- Many organizations run an internal "repository of repositories", such as Artifactory or Sonatype Nexus (which is the product that backs the OSS Sonatype repository). Such installations decouple management of package repositories from projects that use such repositories, which even further removes the need for a central authority.
- SBT can pull in packages directly from GitHub or any other Git-accessible repo. While this isn't used much, I suspect that in many ad-hoc setups (such as my personal projects) there's a lot to be gained from not having to bother with "properly" publishing packages that are not meant to be published.
- It is also incredibly easy to publish artifacts of Scala projects to Amazon S3, Bintray, even GitHub pages. There's a lot to be said about self-managing a small piece of infrastructure as opposed to handing over control to some other, possibly disinterested central authority.
I'm sure that not everyone will agree with all of the above, yet combinations of the above approaches all exist in the wild, making centralization less desirable and/or necessary.