3 ms·

So I think it is clear this was a defensive response to valid criticism. The initial "Virginia" post claimed that if you don't program Scala like he does then y

by dkhenry 15y ago

So I think it is clear this was a defensive response to valid criticism. The initial "Virginia" post claimed that if you don't program Scala like he does then your doing it wrong and its too hard for you. He still makes the claim that Scala is too hard for most people and should be reserved for use by the talented and/or motivated developers. My criticism of this was that you don't need to program like him to have a great Scala experience. You can still program in a OO manner and get plenty of benefit out of Scala. As you get more familiar with it you will pick up some nice features that it gives you that Java doesn't. Everyone comes at things at a different level and I think its quite pretentious to claim that most people aren't smart enough to use your tools and they need to stick with simpler tools. If you give someone the tools they will learn to use it. The real problem is when you need to be an expert to use the tools at all. thankfully Scala isn't like that you can jump in with a hour or two of instruction and write perfectly good Java++ code. then as you learn how to use the tool you will pick up the nuances of the language and really unlock its power. I would say this post like the last overlooks some of the broader issue and really does the community a disservice.

barrkel 15y ago
Your argument sounds exactly like C++ - as you echo in Java++ - and it logically should come with exactly the same problems: different groups of Java-Scala developers will adopt subsets of the language, with coding standards etc., in an effort to institutionalize the simplification - but will come up with different subsets. I think it's too optimistic to expect most standard developers (normally employed by companies whose main business is not software) to "pick up the nuances of the language" - these developers typically learn by example and copy-paste-modify from other similar functionality to fill out the application. They see their jobs as implementing features, and understanding nuances is not typically the quickest way for them to get their job done.
- Flow 15y ago
  I see what you are saying, but feel that C++ is in a different league than Scala when it comes to why you avoid certain language features. If you don't know exactly what a feature does in C++ you might end up with memory leaks, excessive memory copy, having the wrong methods being executed or stupidly long compile-times. Your app will simply not work with these problems. In Scala(guessing a bit here since I've not done any large projects in Scala) you might have hidden performance costs, method signatures for your own library code that are insufficiently reusable because of lack of covariant et al specifications. But the rest of the problems for Scala seems to me to be style guide problems. For example, using or not using . and ()'s, how many classes per file.

by dkhenry 15y ago

barrkel 15y ago

Your argument sounds exactly like C++ - as you echo in Java++ - and it logically should come with exactly the same problems: different groups of Java-Scala developers will adopt subsets of the language, with coding standards etc., in an effort to institutionalize the simplification - but will come up with different subsets. I think it's too optimistic to expect most standard developers (normally employed by companies whose main business is not software) to "pick up the nuances of the language" - these developers typically learn by example and copy-paste-modify from other similar functionality to fill out the application. They see their jobs as implementing features, and understanding nuances is not typically the quickest way for them to get their job done.

Flow 15y ago
I see what you are saying, but feel that C++ is in a different league than Scala when it comes to why you avoid certain language features. If you don't know exactly what a feature does in C++ you might end up with memory leaks, excessive memory copy, having the wrong methods being executed or stupidly long compile-times. Your app will simply not work with these problems. In Scala(guessing a bit here since I've not done any large projects in Scala) you might have hidden performance costs, method signatures for your own library code that are insufficiently reusable because of lack of covariant et al specifications. But the rest of the problems for Scala seems to me to be style guide problems. For example, using or not using . and ()'s, how many classes per file.