281–290 of 378 posts
Since they cite me (and my essay from 2014) as part of their decision making process, I want to throw in 2 cents here. They ended up deciding on Go, whereas I have ended up preferring Clojure, yet I agree with a lot of what they say, so I'll try to clarify why I ended up with a different decision than what they made. I understand what they mean when they write: I think the first time I appreciated the positive aspect…
Some experience to share: I studied Scala and FP on the side before jumping to a team that was using it in production. Most of the engineers on the team have an enthusiasm to learn about and use fp. Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others. We program as simply as possible but when a new technique is disc…
> all code is reviewed and unreadable code does not pass
Sounds quite nice.
Earlier quoted context omitted.
I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks. But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an…
"I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks." It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic buil…
It's not absolute. It's something to be negotiated at a particular shop.
Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type infere…
The only thing on your list on your blog [1] that's still true is that we care about PL research. Since 2.10, we've worked really hard on improving the migration between major versions, and the feedback has been very positive. We'll keep working on finding the right balance between ease of migration and fixing issues in the libraries. Scala 2.13 will be a library release, with further modularisation of the library (t…
Next is upgrading Lift to 3.0 which will be a nightmare (again).
"We've also invested heavily in incremental compilation in sbt."
Yes, I read this over and over again, and I see micro benchmarks posted.
Using SBT with continuous unit testing I can't feel a difference - or it is so slow with a major code base that it's still much to slow and I judge it having no progress. Either way, after years it is still too slow (newest Scala + newest SBT).
"I rarely have time for office chair sword fights anymore."
Today I expect Kotlins practically instant compilation. 10 seconds for compiling some changed files is already to much for rapid development with TDD/Web, it breaks my flow, but YMMV.
"We'll have some graphs to show you soon,"
See above, I've seen dozens of micro benchmarks that claim improvements, in the end it doesn't show up in my real projects - at least in mine and the person who migrated to Go in the linked article. And all the other blog post authors that moved away from Scala towards something faster (Kotlin, Java 8, Go, ...)
But as I've said, I've moved on to Kotlin for new projects because for me Scala is a lost course.
Since they cite me (and my essay from 2014) as part of their decision making process, I want to throw in 2 cents here. They ended up deciding on Go, whereas I have ended up preferring Clojure, yet I agree with a lot of what they say, so I'll try to clarify why I ended up with a different decision than what they made. I understand what they mean when they write: I think the first time I appreciated the positive aspect…
> If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement. This seems to be a widespread sentiment. In practice, I've found that prototyping anything remotely complex without types is so painful that I'd rather settle for an inferior design than trying to come up with the best poss…
Could you go into a bit of detail about this approach? Do you mock functions out and just specify type definitions, and fill in functionality as you go?
Earlier quoted context omitted.
IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do tha…
Your underlying assumption that everyone working on the code will be skilled is wrong in any large team. It's not like it takes a lot longer to read a 3 line if statement than a ternary operator. Terse code isn't much faster to read, the difference between a 300 and 400 line file isn't significant. Your attitude of "he isn't 1337 enough to understand my code" is the logic that leads to no comments and horrible to mai…
I remember when software development was a gentleman's game and we looked forward to sharing a half hour together in somebody's office or around the railing or coffee pot to exchange ideas and news while the build finished.
Scala is good. Its not perfect, its not appropriate for every situation, but its worth learning and using.
Go has an anachronistic feel about it that is just, well, ugly.
Earlier quoted context omitted.
> I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful Not sure I can think of too many situations where it would be otherwise.
In general context yes, but if you tell your top contributor that besides doing full day job work for entire year for free (while main author also has commercial offering) he should also babysit "dumb" users (making entire job not fun) and you get the tip multiple times that such behavior will alienate him from the project, you can be sure there is a way better approach to project management. Since I left it, the PRs…
Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type infere…
Is there something that you can express with Option that you cannot express with a nullable type?
- contrived example - it might make semantical sense to express Option[Option[A]] as a type, it does not make sense to have wrapped nullable types (except as a result of nested function calls).
Nullable types feel like a bugfix to null, Options fell like a concept to model business domains. Same as None expresses something different (not there) than null (usually e.g. in Java conflating not there with not initialized).
With Option it also makes sense to have flatMap, for comprehensions etc.
Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type infere…
> Now trying Kotlin for the faster IDE and compilation speed, sadly the Kotlin developers think Option is only about nullable Types and don't embrace it. Because Kotlin's native support for nullable types makes `Option` unnecessary.