It's a bad thing because it would prevent new players from entering that market.
How could anyone successfully create a new competing product once the majority of the market uses the cheap Netflix+Hulu-only package, locking them out from any potential competitors?
No, it's essentially a way to automatically map between manually written SQL and custom object types; you can use MyBatis with annotations only; no XML required.
The advantage is that, as you're writing and embedding actual SQL, you can take advantage of any database-vendor-specific extensions to SQL, plus you can easily run, debug and test such SQL from another tool. Having full control over the actual SQL also means you don't risk potentially horribly inefficiently generated SQL, or risk running into unexpected N+1 scenarios. At the same time, you don't have to deal with JDBC and instead get a DAO layer that uses strongly typed objects.
Of course the disadvantage is that you lose portability; moving for instance a MyBatis/SqlServer app to Oracle will mean verifying, testing and potentially rewriting every single SQL statement in your app. If you're willing to accept that risk though, MyBatis is a great lightweight library to manage your database access layer.
Due to backwards compatibility concerns, no existing Java APIs that may currently return null can ever be changed to return Optionals instead, so nulls need to be dealt with regardless. Also, there's technically nothing stopping an Optional value from actually being null itself, or from developers calling Optional.get() without checking isPresent(), just like they might currently use a reference without checking for null.
I personally really wish jsr305 had been adopted in Java8, and their existing APIs retrofitted with these annotations.
String version = computer?.getSoundcard()?.getUSB()?.getVersion() ?: "UNKNOWN";
With Java 8 Optionals, this instead becomes:
String version = computer.flatMap(Computer::getSoundcard)
.flatMap(Soundcard::getUSB)
.map(USB::getVersion)
.orElse("UNKNOWN");
which is not only much longer and arguably uglier, but also forces developers to suddenly have to worry about applying lambdas using flatmap vs map, where conceptually you're really just dealing with method calls.
New languages like Kotlin solve this much better in my opinion by introducing nullable vs nonnullable types. While Java can unfortunately never adopt this due to backwards compatibility issues, @Nullable and @Nonnull will do most of the time, and hopefully we'll see operators like ?. and ?: in future versions of Java.
While I've enjoyed the Elvis operator in Groovy, the point of optional is to make null go away altogether. In Groovy, you are never guaranteed anything isn't null, so the end result is that you will Elvis everything. While this is easier than the good old if statements, you are still paying for the penalty of a billion ifs in bytecode.
With option, you clearly declare what is safe, and what isn't, and the compiler won't let you screw up. You can decide which layer of your code handles the empty case, and lots of unnecessary ifs go away from the bytecode itself, so the app will run faster, and you know when you have to even consider the null case.
Now, doing that in Groovy is rather silly, because your language is dynamic and your types are optional, so all of this compile time safety would not provide any value anyway. Option is just the way you'd solve the problem in the strongly typed way. It's how you handle it in Scala, for instance, and how Haskell would deal with it.
As far as using flatmaps and maps to work with optionals, yes, it's a chore. I'd argue it's borderline abuse of the stream operators, as treating Option as a collection is ugly. That said, putting yourself in a situation where you chain 3 optional getters is also object design from hell, so one should avoid putting themselves in that position altogether.
In Scala, instead of flatmapping single optionals, we often getOrElse(), or use pattern matching as an extractor. Now that's a feature I would like to see Java 'steal' from the Scalas and Erlangs of the world, but I do not see that happening.
> in Groovy, the safe navigation and elvis operators
The elvis op is called the null coalescing op in other languages. [1] Groovy's promoter chose the elvis name to fit in with marketing the Groovy and G-String names.
PHP also uses the ?: symbol but other languages use different ones, e.g. C# uses ?? and Perl uses //
I would agree that greatness in part depends on a certain innate talent, and most of us, no matter how hard we may try, will never get there.
I think the difference between his categorization of "Good programmers" and its subcategory of "Really good programmers" is the more interesting one though. Too many programmers seem to lack (or have lost) that drive to continually improve themselves, having become content with treating programming as nothing more than a 9-to-5 job during which they do little more than apply past knowledge. Like the article states, doing this puts them "at risk of slipping into the lower grouping by letting their skills atrophy".
The "Really good programmers" on the other hand are the ones with drive, with motivation; the ones that at least aspire for greatness even if they might stall out at merely being "very good". Every great programmer was once just a "Really good programmer", but you can't go from good to great without that passion.
I'm on board with this statement. I've realized for quite awhile that there are some guys who are just on another level in terms of sheer ability. Sadly I am not one of them.
I've run across a fair number of the 9-5 guys who used to be really good/good & use that as motivation to never allow it to happen to me. Always gotta push forward.
I think you're confusing unit tests with integration tests.
In integration tests you should indeed run as close to real data as possible and execute your system's entire stack, including database calls. Unit tests on the other hand should be used to test small decoupled parts of the codebase.
If you have a class that implements certain business logic against data that would normally be retrieved from a database, a unit test using mocks can test this business logic in isolation, feeding a variety of data through the method to test a large number of scenarios and edge cases.
Speeding up this kind of testing is definitely important; test suites using mocks that can run in seconds can be executed after most changes to give immediate feedback to developers, whereas integration-type tests that might take an hour or more would slow down development too much to do this.
Integration tests are important as well, and should be run possibly nightly or at least prior to any release. They cannot be used to give the kind of immediate feedback that truly decoupled unit tests give though.
How could anyone successfully create a new competing product once the majority of the market uses the cheap Netflix+Hulu-only package, locking them out from any potential competitors?