That seems to be the point. Proper or idiomatic scala code uses tools only available to scala.
I used scala for a while. It has some neat tricks that I grew to like, but I think it ultimately had a problem I noticed in Ruby: there are many "right" ways to do things and each team has its own culture. This makes learning foreign codebase pretty hard--especially with how dense scala code is.
Kotlin 1.1 + Reactor (http://projectreactor.io/) has erlang style messaging passing paradigms, world class tooling and is gradually replaceable (class-by-class) for Java.
It's going to be interesting comparing the adoption curves of both these languages especially after Java 9 and most importantly Graal (http://openjdk.java.net/projects/graal/) .
Guards, pattern-matching (even down to the structural level) and typespecs cover a lot of the ground that static typing would, without forcing the type rigidity. Although Haskell seems to have admittedly cornered the static typing market
Wow this is cool. I always preferred Kotlin to Scala and have used it for Android dev. It was extremely easy to get it working compared to writing an app in Scala and the language was more similar with a modern syntax.
This project looks neat and if you had to use JVM tools but wanted some of the benefits of Erlang style development I could see it being a perfect fit.
Now the really puzzling question is: How would someone learn about this particular saying without seeing it in writing? Are there actually people still using "hear hear" in everyday speech?
Ironically, I've have an English bachelors degree,and I've never seen it in writing before, till now! Language is active learning. There's no real way to avoiding these pitfalls, besides reading and engaging with others. I'm OK with it aslong as those offering corrections do it kindly.
I've learned German, too. German is 'difficult', not because of its grammar, but because how mistakes are handled. Which is often with harsh commentary, ridicule or confusion. Not sure why that is the case, but English speakers are often kinder when offering corrections!
As a defense I'll say this: I'm arab, grew up mostly on online and speak and write four languages. Their grammars do intertwine, and I can't help it much. my colloquialisms and vernacular are not on paar with that of a native speaker's - my academic work had a higher quality of writing due to proof reading and tight work with a thesaurus.
And it's been a while since I was a student. Cut me some slack :p
And I know I should've written 'i have' instead of 'i've' - in Arabic we say 'ill efforts blacken the face'
To disprove your last point: I'm curious as to how you achieved such a degree while using "till" as shorthand for "until". Are you sure your Bachelor's wasn't in agriculture? ;)
Joking aside, I think it's a consequence of English being a very complicated language with all sorts of borrowing from different language families. There's almost no such thing as "correct" English, and attempts to reason about it in a prescriptive rather than descriptive manner will almost certainly fail. Whether that's a good or bad thing is up for debate, but mistakes happen either way, and I reckon the average English speaker to be a bit more cognizant of that, recognizing that nobody - oneself included - really has a perfect understanding of the English language.
Oh god I remember reading so much about till and until. covers face in shame
I think I even forgot the difference between conjuncts and adjuncts, too. Grammar 1/2/3 were tough courses.
I'm leagues below the level of a native speaker, I'll admit that! But I did still do a ton of reading, which did improve my English, but won't protect against common pitfalls :P it could've been worse. At least I don't make those "your" "you're" mistakes, too often :D
Yes there are. If you tune into House of Commons debates they still shout "Hear, hear" from time to time as a way to indicate their support with what current speaker is saying. So in UK you can still hear this phrase used in a speech, granted not everyday speech.
I hear this quite frequently in day to day speech. e.g. somebody makes a proposition in a meeting and another agrees. Also - have seen this a few times in Whatsapp chats, albeit often misspelled this way (-:
the sbt config has been the worth part for me. I could never fully understand the syntax (or let say API because it's scala, but really those operators ...).
It is way simpler than that. You can specify version of sbt's jar your project needs right in your build files. When you run any against your project it will download the version you specified if different from the one installed. It is not by any means a circular dependency.
Gnu make does not need make to build (it includes a build shell script for that), gcc can be built using any C compiler via a 3-stage bootstrap. But sbt, it seems, can only be built by sbt.
XML syntax is very simple, has very good IDE support (navigation, autocompletion - thanks to xml schema, etc.. can any IDE autocomplete dependencies from repository in .sbt files?). Maven itself provides good easy ways to reuse the configuration across multiple modules.
If you exclude dependencies than for more complex projects the no of lines in pom.xml build files is somewhere between 50 - 100 % more, so it is not like .sbt (or gradle - which I find superior to both) is 10 times less verbose.
Assembly is also very simple. Basic is also very simple. Why don't we program in these "simple" languages?
> has very good IDE support (navigation, autocompletion - thanks to xml schema, etc.. can any IDE autocomplete dependencies from repository in .sbt files?
Just like .sbt sources, since it's Scala + the SBT API + some operators.
> If you exclude dependencies than for more complex projects the no of lines in pom.xml build files is somewhere between 50 - 100 % more, so it is not like .sbt (or gradle - which I find superior to both) is 10 times less verbose.
SBT is a dsl in Scala. It's at least 10 times more powerful compared to java & xml. Even the dependency system is far simpler in .sbt files. XML is just bloated, full with noise and primitivity. Just like java.
> or gradle - which I find superior to both
Why?
> Here is a list of few glyphs from there: ._ := () ++ ++= ]( % target := target.value / "sbt-routes-compiler",
If you don't have a clue what's "++" and such operators and you're too lazy to search for it then you're not a programmer just a joke. Seriouly, how can you complaing about a few operators in a dsl?! "](" isn't even an operator, "[]" is the generic parameters' syntax while "()" are just parens. This is the problem with you java devs, you're too lazy to learn. And that's what hits your quality.
What appeals to me about Scala is that is expressive and concise. It also encourages some healthy patterns like such as making distinctions between mutable and immutable containers, using futures/promises for asynchronous functions, using option types to prevent null pointer exceptions and many many others.
It influenced my programming style a lot and I try to prefer those patterns when I use other languages as well.
Some people like more advanced aspects of Scala, and like to flirt with category theory and hardcore functional stuff. Personally I find it hard to express myself in terms of higher order kinds, monoids, functors, semigroups and such. You can learn them but it's a bit like switching from qwerty to dvorak... if you have to look at the keyboard each time it doesn't make things simpler for you.
It is also about tooling and libraries. I find Scala ecosystem to be behind Java ecosystem couple of years (SBT versus Maven/Ant/Gradle, collection libraries...).
That's completely not true because Kotlin has something near zero adoption. I have a Kotlin fanatic coworker so I know all about the manifold benefits of Kotlin -- it sounds awesome.
Never had a project OK'd to use it, probably never will. They obviously need a PR and marketing department; otherwise they end up being the CouchDB to XYZ's Mongo.
If you work with other teams, especially onprem or offshore teams, they use netbeans or some other piece of shit IDE. It's just a fact. They know J7, can be convinced to try J8, once read a blog that mentioned Scala, and don't know what the fuck Kotlin is.
On the other hand, if you decide to use Kotlin, you'll post a job listing, get only a handful of candidates, and nearly all of them will be outstanding and the type of curious, driven engineer that you'd normally have to sift through a mountain of dime-a-dozen, uninspired Java hacks to find.
It's not until you've had to hire Java devs that the mystery of why so many people feel the need to ask a question as facile as FizzBuzz becomes clear.
android development could well be kotlin's killer app. i'm seeing a lot more buzz about it there than anywhere else, especially since it promises a very low overhead over plain java, as contrasted with clojure and scala.
This is hyperbole, Kotlin has fine adoption considering it only went 1.0 a year ago. Exactly how many times could you have tried and been denied the ability to use it within a year?
Spring is adding dedicated Kotlin support in 5.0 which is likely to give it a huge amount of credibility and make companies running on Spring more comfortable with adopting it.
That's a strange point to make about Scala. First of all you can choose if you build your Scala project with SBT, Maven or Gradle. Actually I know quite a few people who switched from SBT to Gradle.
And the collection libraries is where Scala shines comparing to Java. Handling collections in Scala is just so much easier and more fun than in Java. Please try it out if you haven't done it yet.
If you use Gradle with Scala, you are using it as 'better Java' (point from article.
I worked with Scala collections for 9 years, last 5 years I implement collections for living ;-)
Scala collections are behind in implementation. JSR166 (java.util.concurrent) made large performance progress in Java 8 and 9. It was never back ported to Scala.
Nothing like `ConcurrentNavigableMap` is in Scala. Or Set with weakly referenced keys?
I really wanted to love Scala, and for the first few days I did. But it was a never ending story learning this language. It is so complicated and feature rich that there's just too much to learn. I couldn't just read someone's code without stumbling on some special syntax or language feature that handles a once in a lifetime use case that I didn't know about. Eventually I gave up on Scala.
I agree it doesn't have strong opinions and every developer has a different flavor of writing it making it difficult to code review without a ton of personal opinion type comments. That said it is a fun language because of how flexible it is too. It just, at times, does not seem practical for projects that have a ton of hands on them compared to other more opinionated languages.
As others have mentioned in top-level comments, definitely give Kotlin a try, as it is specifically designed in response to your conclusion about Scala. I've been using Kotlin full-time for over a year, and I've really enjoyed it.
My impressions after a month spending working in it were somewhat similar. But it's not that there's much to learn (a necessary thing in a powerful tool) - it's that after that month, the language still felt like a totally inconsistent mix of every feature they could find in other languages (beside maybe sane macros, conditions and call/cc).
I suppose, though, that after spending enough time immersed in a language, even such inconsistency stops being a real obstacle to anything.
I echo "oelang"'s request: please explain why you think scala is inconsistent.
As far as I an see Scala has achieved something no other language before did:
1. For the first time, achieves a successful marriage between ML-style functional programming and class-based object-oriented programming (OOP) with subtyping a la Java. Scala achieves this by building functional programming as a special case on top of class-based OOP. Previous attempts at unification (e.g. Ocaml) tried instead to base OOP on top of typed λ-calculus.
2. Scala even improves on ML in that it fuses the language of programs with the language of module systems and brings type-inference to both (albeit partial). It fuses the two without any real compromise on each, indeed one could argue that both were improved since ML's module system doesn't have type inference.
3. Smooth integration of higher-kinded types with OO programming.
4. Having an advanced language running on the stable and well-libraried JVM eco-system. Usually languages with as much novelty as Scala, remain in academic obscurity.
The unity of Scala is witnessed by the fact that it can all be compiled down to a rather simple calculus, namely "dependent object types" (DOT) [1]. I'd say that DOT is to Scala what lambda-calculus is to Haskell. I find it hard to think of another language that combines so much expressive power with being simple and coherent.
Yeah, the problem is that the theoretical underpinnings of DOT do not represent Scala as we know it; that would be and is a different compiler (Dotty).
If Dotty works out then we will, for the first time, have a fully specified Scala on sound theoretical footing. Along for the ride: much faster compiler, better tooling, streamlined type system, and nice-to-haves like union types and implicit function types, among other useful features.
It's certainly true that today (3 March 2017) there is still a gap between DOT and the current Scala compiler (version 2.12.1) -- just as there is a gap between Haskell and the lazy lambda calculus. However, as a conceptual guide what Scala is, DOT is quite helpful. With time DOT will become even more helpful
In general, it's OK for there to be a gap between a real programming language, and its theoretical toy model. That's the gap between theory and practise. Why would you care about theory if it was as complex as practise? The ideal case (embodied in the lambda-calculus) is that the theory is much easier, but looses only a modest amount of precision.
I didn't say Scala was inconsistent, only that it felt as such. I've lost access to that codebase since the end of my participation in the project, so I won't provide you with code examples, but the project was using most of the language features available to date (2015). Maybe "inconsistent" is a wrong word. "Messy" would be better. I've been familiar with many of the concepts in Scala from other languages, and here it felt like they were glued together with gratuitous use of syntax and implicit type conversions.
I apologize if my previous comment didn't state it clearly enough, but I'm talking about my impressions of the language here. I'm convinced that after enough time, the whole package starts to make sense and becomes a very powerful tool in one's hands (I have a reverse situation with pre x11 C++ - it was the first programming language I really learned, so all its idiosyncrasies people like to complain about felt completely obvious and justified to me).
One day I hope to immerse myself in type theory deep enough to actually understand the underpinning of Scala better.
If you found C++ natural, then Scala should be even easier, because C++ is orders of magnitude more complex and messy than Scala (speaking as somebody who's comfortable with both languages and has written both professionally).
In 1994, when I started my carrier, the state of computer languages was bad (IMO) and I imagined that one day I would create a new language. I had many ideas. Some of these ideas appeared in java (interfaces). I was very pleased to discovered that almost all my ideas were present in scala (the single exception is a fast compiler). It seems like a perfect language. I have tried to learn it, but failed. It takes too much time (I have 3 childs and a job). I gave up. Maybe it was caused by the complex collections system needed to support immutability. I will try again to learn it when I will have more time (??? ;-))
To me this seems like much the same malady that C++ suffers from. Is it something that established best practice could be brought to bear on? Scott Meyers' Effective C++ seems to be the bible on this topic for that language, I wonder would something similar for Scala help things a bit?
I guess in Java we are spoiled - though sometimes stifling, the rigid structure and syntax help prevent people doing "bad things". It has struck me once or twice these restrictions may have been derived in part from established C++ best practices ...
More than 10 years ago I was asked to provide some insights about Java and Python for internal use in our lab.
Despite IBM involvement in Java at that time, both Java and Python were see as possibibly immature by my boss.
My own conclusion was exactly what you wrote.
In fact during the Internet bubble there was a recruiting crisis, and Java (Python was not mature enough at that time) was exactly what was needed: A language for undergraduate people that produces good results, was easy to read and maintain, while forbiding "innovative" but often buggy code.
And these days its also about the tools that a strongly typed well structured language enables. I can refactor many things in IntelliJ in a trice. I've heard Bjarne Stroustroup bemoan the fact that the C++ community "can't have nice things" like this because so much of the community still holds on to legacy kludgy practices like cpp macros.
Not knowing C++, what are the types of changes in practices? Which are the most burdensome? I can imagine some accompanying changes in the language (as often best practices are there to cover infelicities in the language that are corrected in future versions). Are these of a scale that require large rewrites? Like, past best practices are now actual flaws (as opposed to just not the peak optimizations)?
I first used C++ around 1990, when it didn't have much of a standard library. Then came the Annotated Reference Manual with its crazy talk of templates and namespaces and what not, which weren't implemented by any compiler I had. Somewhere around here is a copy of PJ Plauger's book on the standard library that doesn't mention templates at all. The standards committee pulled a fast one on Plauger: between the publication of his book and the finalization of the draft, the STL took over the world. Then came C++11, with move constructors, anonymous functions, and a couple of new smart pointers (which was good). C++14 introduced type deduction. And there's Boost's smart pointers (and everything else).
Nothing requires a rewrite, but five year old code looks nothing like what people say is "best practices" now.
I've been to multilanguage conferences and every time someone throws a slide up with Scala code on it, I look around me and every damn developer has this sourpuss look on their face. (Almost like when anyone brings up Node in casual conversation, but I digress...)
Guys... if only experienced Scala people enjoy reading Scala code, then you kinda have an adoption problem
Um, Scala "in the small" (for example, in a slide at a conference) is never a problem. It's 100% guaranteed to look cleaner than the equivalent Java snippet, with less boilerplate. I suspect it's snobbery if people get that look in conferences.
Of course, Scala frameworks and its use in large systems might be different things -- though, having used Scala for my day job, I'd also disagree with that.
Fair enough. And to be honest I have not worked with it, and am probably biased by the conventions used in most other popular languages which do not carry over to Scala. It does seem like a disorganized kitchen-sink of ideas, though. And any time you allow mutability in any form (which would pretty much implicate any JVM language), you introduce the possibility of mutation bugs (one of the reasons I went over to functional langs to begin with... I once spent a month tracking down an irreproducible intermittent logout bug which ended up being based on a mutation bug).
Agreed about the kitchen-sink of ideas. Also agreed about the mess of mutability and compatibility with JVM. But that's hardly something you'd notice looking at a slide in a conference :)
I also prefer cleaner languages. But, in practice, I must choose between Java and Scala, and I'd choose the latter any day, with my eyes closed!
> And any time you allow mutability in any form ...
Odersky often says that the mutability should be as 'contained' as possible in what is otherwise a largely immutable codebase. If you can reason cleanly about a black box and are sure that the mutable variables within are not going to 'escape', you get the benefits of both
1. easier to implement, imperative algos which have been around for decades. (the alternative in pure FP is to convert stuff to tail recursion, which is not always the easiest thing to do, let's just say.)
2. easier reasoning about state not leaking to the rest of the system.
I've found following these guidelines to be very helpful.
> Odersky often says that the mutability should be as 'contained' as possible
He's 100% correct (at minimum).
> the alternative in pure FP is to convert stuff to tail recursion
It's a challenge but not THAT difficult, once you get the hang of it. :) I've found conversions fun, actually. Especially when you (of course) have to learn how to trigger TCO. The irony here of course is that at the machine language level, the recursion is converted back to imperative via TCO. But IMHO the resulting recursively functional TCO code is, eh, "more beautiful"
I don't really understand all those complaints. I am using it professionally since 8 month and I only had problems the first two month, then I felt good, even if there is always something else to learn.
For the complexity problem, here is how I manage it : the functional programming scala is scala, everything else is garbage included for java compatibility. It works like a charm.
I can't think of a language I could feel better with.
There are some pains associated with Scala, though. Sometimes self-inflicted by people who want it to be like Java: for example, most ORMs for Scala suck. A team at my office tried to use Hibernate to disastrous effects (Scala and Hibernate's hostile takeover of collections don't play well). Even some DSLs like Scalike tend to also be painful and unwieldy. I also dislike Play and its multitude of quirks and incompatible versions.
It used to also be the case that both Eclipse (ScalaIDE) and IntelliJ IDEA were almost unusable with Scala, in particular constantly resulting in spurious compilation errors. I've no idea if Eclipse got better -- completely got rid of it after decades of using it with Java -- but IntelliJ did get better and mostly works (though it still cannot always compile Scalike DSLs).
But even with all of the above, when I have to work with Java code again I cringe. Even with all the pain, Scala is simply better to work with for new code.
Ever asked yourself why it's taken so long for Scala IDEs to be minimally useful? The complexity of the language makes it difficult to optimise compilation and the language is still suffering. Paul Phillips left Scala because of this and he said it was impossible to rectify without re-inventing the language. This shaky complexity is why I refuse to build valuable projects with Scala.
and yet Paul Phillips still, to this day, writes Scala. Think about that, he's one of Scala's biggest critics; still Scala all day, everyday.
There's nothing "shaky" about Scala's complexity, it's quite stable, and not going anywhere until Dotty lands circa 2020.
Despite everything (slow compiler, average tooling, implicit/operator overloaded "magic" code bases, etc.) Scala will draw library creators (like those behind Spark, Kafka, Akka, Play, etc.) which in turn draws developers, resulting in the thriving ecosystem backing the language.
Scala will live on despite itself; the ecosystem is what will carry the language to the Dotty land and beyond.
I don't think it was really about Scala's complexity (or it wasn't the main reason, at least), for multiple reasons:
First, IntelliJ is quite decent nowadays. So it's demonstrably possible to build a decent IDE for Scala.
Second, Eclipse itself has imploded in my opinion. Eclipse used to be a usable and reasonably fast IDE. Then, some years ago, there was noticeable increase in bloat and a downgraded performance for Java. I remember reading some major release of Eclipse, which required a refactor of its UI, didn't have any automated tests because the refactor broke them and there was a lack of volunteers willing to fix the tests. Nowadays I've stopped using Eclipse even for Java, because I cannot stand its slowness and random freezing/crashes.
Yeah, developing in Scala is great. My whole team (including me) had never used Scala before, we set up a weekly study group, had no problems becoming productive in the language in a few weeks.
I understand that not everyone has this experience, and would love to see more/better tutorials for Scala come out, but I've definitely seen several people pick it up without any problems.
In my opinion, the tough part is that you need to truly understand each feature. Not just one use case.
Although, once you do, you can really get to work composing the features in interesting ways to get really useful effects. Like implicits + higher-kinded types to get ad hoc polymorphism. Or subtyping + pattern matching to achieve incredibly self-descriptive business logic. I would certainly agree that Scala appeals to people who like to be able to experiment and engage with more theoretical concepts while getting things done.
But let's not pretend that most languages don't have this issue. Programming with major Ruby and Python libraries tends to eventually require you to learn what's going on under the hood in the same way. I would argue that once you start digging under the surface, Scala is much more elegantly designed than those languages.
Go is about the only language that seems to say, "forget theory, we're simply about getting things done". Not my thing, but I understand the appeal!
My follow-up question would be: Is Scala still competitive to modern languages like Swift and Rust?
I experienced several drawback according to library quality and code-safety. There are too many small details that left me with an unpleasant feeling (I would take ScalaNLP/Breeze for example).
But my central issue is the VM/GC dependency. In times of GPU computing, native interface programming becomes a burden. The knowledge of object ownership improves code readability. I feel uncomfortable leaving object lifetime to a background process.
It depends how you define "competitive". If you are trying to collect hipster points then Scala is not going to help you but let's be real. Nobody is writing big systems in either Rust or Swift, these are playgrounds for people at the moment.
I am big fan of Swift and Scala... and, to be honest, for Swift there's a long way ahead before a big system can be deployed... tooling and libs are not there, also not considering that the lack of ABI stability makes the source code necessary for any external dependency.
After doing this shit professionally for more years than I could care for anymore, when I see programming language or framework comparisons I immediately think of something like[1]:
"Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver".
And then I imagine myself going back to using my shitty old Phillips screwdriver set to screw in a few screws in a non-optimal fashion and someone might say "Wow, thanks for hanging my door!" and I imagine the surprise on my face as I realize that people want functioning doors and are not too bothered about which brand of screwdriver was used to achieve that.
To counter with an alternative tool comparison: drills and impact drivers look very similar. I'd bet that most of my friends don't really know the difference. But for some situations, an impact driver is an entirely more capable tool.
If you use a drill all day, professionally, you'd be a fool not to take a serious look at an impact driver and see if it makes your life easier.
I don’t think using different tools (which a drill and impact driver really is) is what the OP mean’t. He was more along the lines that must people don’t care whether you picked a Bosch impact driver or a DeWalt impact driver to fix their problem.
And if you explain to someone the difference, they usually get it. Even my daughter when she was five could understand why I had two similar looking things when I was working with them..
That may be the point the OP was making, and if that's so, I'd counter that the point is irrelevant to make. Sure, the user of your software doesn't care what it's written in. Duh. Why should they? If they did, it'd be weird. But the people actually writing the software should care about choosing tools that fit the problem. Not because the end-user will care, but because choosing a more appropriate tool will allow them to build software that gets to market faster, and has fewer bugs and is easier to maintain.
Indeed. Maybe the original point is better analogized as saying "shovels are better than screwdrivers" rather than comparing two brands. Of course, it's even more meaningless to debate the merits of shovels vs screwdrivers than it is to debate the merits of two different screwdriver manufacturers.
What a crap, supercilious comment. Yes laypeople want functioning doors, but this is not an article for laypeople, it's an article for engineers. What we want are tools that allow us to build performant, maintainable, reliable code.
Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.
When you're building a 'tower', what is more important? The strange new hammers and screwdrivers you're using, or the architecture, algorithms and data structures?
Please don't compare a programming language to a hammer. They're not similar in complexity, and it makes a really bad metaphor. Besides, unless you write entire applications in assembler, you DO care about programming languages.
I completely agree. Bricks would be a better metaphor and still completely contrived. And turns out, you can't build skyscrapers without concrete and steel :)
And just to be pedantic: When I bought my first SwissTools Insider[1], I realized that it's actually still possible to innovate in screwdriver design. That doesn't make them better for every task, but hey, that's the way it is.
Do u care about what language Amazon uses to write S3? Do u believe it is the language that make S3 succeed, or fail?
Even as a programmer, as to the other services I am calling, things I do care about involving their stability and correctness that affecting my work. I care shit about what how they write their service underneath, may it be cool or dumb.
If we're going to insist on the carpentry tools metaphor ... hammer vs nailgun; a hammer can do everything a nailgun can do and more ... but if you're banging together a timber-frame for a house the nailgun will let you get through the task far far more quickly. If you're running a business, and time is money, which tool would you want your carpenters using for this task?
If I'm running a business that lets say develops an ecommerce platform I won't be too impressed if my developers are using assembler. Java good, but if Scala gives them an edge and cuts my costs so much the better!
Yeah, so choose what works best for u, not assuming the same thing for others without understanding the specific problems they are trying to solve. Maybe they need a hammer, not a nail gun, because they work in specific environment that don't have sufficient power supply? or for the work they are doing, hammer is good enough, it is better for them to invest elsewhere.
I'm kind of making the point that in many environments you'll need both? A nailgun (battery or gas powered) for the "bulk" jobs and a hammer for the finer work. I can't imagine anyone being effective in Scala without first having a good knowledge of Java. Or at least without having Java expertise near to hand.
I used to think so too, but at work I've met programmers who code in Scala without having learned Java first, and it's enlightening. They are proficient in Scala. Whenever they touch Java code, they are upset that the niceties and modern features of Scala aren't there -- whatever we thought was reasonable in Java or "not mainstream" in Scala are exactly the opposite to them. "Why do I have to write all this needless code in Java?", they ask (for example), nicely countering the common but unwarranted notion that Java's verbosity somehow makes code more understandable to regular joes.
It's enlightening to me because a lot of what we consider "hard" or "too academic" is actually our own prejudices speaking. Of course it looks like that to us, coming from Java, but try talking to someone who learned Scala first :)
I also find it encouraging. Maybe some day we will be able to finally take advantage of the JVM without the weight of Java-the-language.
You've met programmers who know scala but not java but tell me this: Were they in an environment without java expertise "to hand"? To me scala is more akin to a skin over java. Particularly when using 3p libraries that were written in java (this ecosystem is one of scala's key advantages over other fucntionalesque programming environments). When you work with scala you'll always need some java guys nearby to deal with the "nitty gritty" details.
No, that's precisely the thing -- I've met programmers who learned Scala as their first language for the JVM (some guys I'm thinking about coded in C and PHP before that), they are pretty proficient, and they absolutely do NOT need Java programmers "at hand". It's interesting that they "get" Scala; they don't try to use it as if it was Java++ (in my experience, this attitude you describe that Scala is merely a "skin" over Java is mostly due to prior knowledge of Java). When these people eventually need to learn some Java, they do so on their own -- and curse the language!
I think we're starting to see a new phenomenon: people who don't start on the JVM with Java. It's interesting because it shows (in my opinion) that the whole "Scala is too difficult" thing was mostly a misconception. What it was truly all about was: it's hard to give up old ways of thinking :)
I honestly can't see the point in scala if you're not integrating with the the javaverse ... I'd have thought you'd be far better off cutting a clean break and using a "proper" functional language like Haskell or Go
Obviously, one big draw of Scala is that it can interoperate with Java and take advantage of existing libraries. But that's a far cry from saying it's mostly a wrapper around Java. New code, including libraries, should be written entirely in Scala. The JVM is itself a valuable target, regardless of Java-the-language.
That said, I love Haskell and would definitely enjoy using it at work, but it's a no go for "political" reasons, which is sort of reasonable even if disappointing. Scala scares management way less than Haskell!
I don't personally care what S3 is built using, but that doesn't mean the people who built S3 shouldn't care. Java, Scala, etc. are all tools with different strengths and weaknesses. Use the best tool for the job, considering the experience and capabilities of the team you have.
_I_ don't care what they use to write their platform, because it's a black box to me. But _they_ care and spend a lot of time debating it, and that's when discussions like the one in the article are important and shouldn't be dismissed.
> unless you write entire applications in assembler, you DO care about programming languages.
That's true, but we've been in the region of diminishing returns for programming languages (I'm not talking about runtimes) for a long, long time now. To go back to the (bad?) tools metaphor, it's like saying that unless you're using nothing but your fingers, you DO care about tools. Well, yeah, but once you have a decent screwdriver, innovation in screwdriver technology -- short of a revolution -- is likely to yield diminishing returns on investment, especially as the cost of adoption remains high. Switching from, say, Java to Scala is not much cheaper (if at all) than switching from, say, assmebly language to FORTRAN or C. This does mean that the effort spent on switching languages (or screwdrivers) should decline.
Just cause one thing is more important than another, doesn't mean the other thing is unimportant. You appear to be arguing against discussing tools, because they aren't as important as other things.
Modern skyscrapers would certainly not be reasonable to build without "strange new hammers and screwdrivers" (read: tower cranes, super-powered concrete pumps, etc).
Algorithms and data structures will be mostly the same regardless of what language you use.
Architecture will generally not be. Scala and Java encourage building applications in different ways. That doesn't mean one is better than the other (though I'd argue you could make that claim), but some problem domains are better modeled with Scala, and likely some with Java. And some programmers work better tending toward a pure, immutable, functional style, while others work better with OO, side effects, and mutable data.
While choice of language/framework may not be as important as many other choices you need to make when building an application, but it's not something that should be dismissed as irrelevant, either.
I used Angular Material to build a website. I dunno if you've ever been to the Angular Material website *https://material.angularjs.org/latest/), but check it out if you haven't. You see that nifty looking navigation bar on the left? You can't actually build that using Angular Material given all those wonderful components they list there. There are entire blog posts created so you can make a similar looking navigation menu [1][2]. There are so many things missing or incomplete in this framework that you'll only realize when you try and build a "real" application with it. Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2. Yay for the people who just want functional doors.
Let's talk about Material Design Lite. Go check that website, especially the components page (https://getmdl.io/components/index.html). It's really nice and responsive, try changing the size of your browser window and see how the navigation bar collapses to the top. Damn this looks like a great framework, I'd like to do the same thing in my app. Imaging the surprise when you can't actually do that using the framework out-of-the-box. Oh by the way, forget about MDL, all the developers have moved on to Material Components for the Web (https://github.com/material-components/material-components-w...). So much for the guys who just want to hang a door, there's a new brand of screwdrivers on the block.
It would be great if the so-called "engineers" could spend some more time creating a complete toolbox instead of reinventing new screwdrivers every month.
In my experience, this is a much bigger problem in web programming than elsewhere. Take the JVM, for example, since it's the subject of the article- it's been around for decades and while things have changed, you can still pretty just just keep using whatever you're using without fear of the developers jumping ship for something shiny.
Indeed. Also, in more sane / stable areas of the industry, the code doesn't rot so fast. Java is relatively backwards compatible down to version 1.5 or so. In Common Lisp world, the code written more than years ago works perfectly fine without need for any change.
I get that this is the easy way to see it from the outside, but:
- You don't have to learn every new framework. Google has 10k+ Angular 1 projects, this stuff doesn't go away after hitting critical mass.
- This constant iteration has lead to multiple production-ready UI paradigms that were just relegated to FP research. Try using Angular 1 or vanilla React, and then do something with vanilla Android. Or GTK+. Do we want GTK to be our baseline for UI work? Qt is nicer, but it's definitely playing catch-up.
You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.
Is JavaFX okay? Or maybe even good? What's wrong with it? (Not polished enough, not maintained enough? Not updated fast enough?) RxJava seems pretty okay.
Don't know about the OS X problems much, but on Linux it's workable with FX (our product is actually used on both Windows and Linux). OTOH, Electron achieves its portability by shipping the whole Chromium browser with your application...
There is actually one issue JavaFX has on Linux: It uses Gtk to determine renderscale, so it can’t handle HiDPI at all (Gtk only scales in integer amounts, so everything is either 96dpi or 192dpi)
Could you talk a little bit about these problems? I was not aware of any serious issues on non-Windows platform, and would like to hear about them. As Java/Kotlin is generally my go-to language for making things in my off time, that would be helpful to know about.
Off the top of my head: misses some UI elements / widget types (spinner / numeric entry). UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).
And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).
> UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).
You can use String.valueOf, but usually don’t want to do that. And how do you want to represent the float? With Scientific notation, Engineering notation, or purely decimal? This is not simple.
> And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).
Or you use the FXML bindings for creating them from XML?
The constant iteration has definitely led to more production ready UI platforms. But once they are in production they are largely abandoned in favour of "shiny new thing 2.0". The rate of change on the web development side is simply too fast to keep up with especially with regards to tooling.
> You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.
I'm not convinced it's particularly good reasons. I think ignorance of native GUI coding and the old, "When all you have is a hammer, every problem looks like a nail" mentality has a whole lot to do with it.
Wouldn't really say that I am seeing it from the outside. Have done some web frontend projects last couple of years and also used Electron for a project. Starting an Angular 1 project now is comparable to doing Windows desktop applications in MFC, and Angular 1 is what, 6 years old?
And the only satisfying thing about Electron, is hitting package and getting three platform-specific binaries. Otherwise, it is still web frontend development. In contrast, I have had the pleasure of doing desktop development in Qt and WPF, which was quite enjoyable (and the ecosystem has not changed a lot since I left it years ago).
Also, MVC and MVVM were UI paradigms before web frontend development. And I am quite sure I heard about ReactiveExtensions before Facebook React.
The primary reason to learn new web framework all the time is that current are still not quite there yet. It needs more maturation till it can stabilize into something good enough.
It's a free and open source project and you're still complaining. And browsers and the web, JS and a lot of things changed between Angular 1 and Angular 2.
Yes, Google could have handled those projects better, they could have put up big warning signs that they are "deprecated".
I think it was a good move to recognize how unmaintainable things (can quickly and usually) become with angular1 (or with anything that is a mess of a hundred semi-external JS libraries), hence TypeScript.
You're not wrong. I am an Angular 1 dev who's in the process of moving to Angular 2 and even that is an up-hill battle. However, I think it's about picking the right tool for the job in that the batteries-included / opinionated nature of Angular is great for once you start scaling a team AND/OR you have a product that you need to keep shippable at all times.
I've done a few projects with Angular Material, and I actually ran into that exact same issue of trying to re-create the documentation's sidebar, only to realize the components weren't in the framework.
> Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2.
I think an important lesson from this is to be careful about the tools you use. If a particular company puts out great tools but changes them in incompatible ways, you might end up having to go back and rehang a lot of doors.
what a crap, self-centered comment. performant, maintainable, reliable code is 90% about general code architecture and coders discipline+skillset and 10% of the language/framework used.
it seems plenty of people with attention span of 5 mins that just want to have fun creating new tools and then moving on to something else. which means either somebody else picks up the evolution and maintenance or the tool should be abandoned (ideally not picked up to begin with)
Not really at all. A sufficiently expert programmer may be able to switch between Java and Scala with the same ease of switching between brands of screwdriver. But that same programmer would certainly not use Java and Scala in the same ways, as they would with two different brands of screwdriver.
Not to put words in the parent's mouth, but I think he is suggesting that we (developers) should spend less time creating / analyzing / debating / choosing frameworks and more time thinking about actual end user functionality.
If this is what parent meant, than that's true - we do bicker too much about it in the industry (I'm guilty of it too). Discussions about tools are important, but ultimately what's important is what those tools are used to build.
> Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.
The screwdriver analogy is right on a lot of levels. Is it so hard to accept that software developers is not some unique snowflake position that cannot be compared to any other job?
>What we want are tools that allow us to build performant, maintainable, reliable code.
Virtually any mainstream language is capable of building performant, maintainable, reliable code. Virtually no developers are capable of creating performant, maintainable, reliable code. After decades in the industry and generations of new whizbang tools, libraries, and languages I've come to terms with the fact that the problem is "us." I've seen exactly one significant sized application keep those 3 qualifications for more than a couple of years. Once all the original core developers on the project moved on, it was less than a year before the code base was a total mess.
I think what you're really asking for is a tool that forces you to build performant, maintainable, reliable code. I'm not sure that's entirely possible until we get AI writing and maintaining its own code. Humans suck.
Plus, we have to pad our rèsumès so we can move on to another job before anyone realizes how bad this pile of horse-dookey is and we have to figure out how to maintain it.
Your example is looking at it from completely wrong way. Computer software users don't care about programming languages and frameworks either, because they know even less about them than they do about screwdrivers. Imagine your surprise if I came to you after you hung my door and said to you "thanks, but no thanks - that screwdriver of yours totally sucks!".
On the other hand, if you worked as a carpenter (or even did some more door hanging on the side), you'd find yourself debating the tools and techniques of your trade with your fellow craftsmen, maybe even engaging in heated debates about their relative performance. The same is true about programming languages - they're tools of our trade. They have different performance characteristics. The discussion about that (and the flame wars) are between the craftsmen, not between the worker and the buyer.
In my experience, no they don't spend much time debating the tools with their fellow craftsmen. And if you look at the tools themselves, they don't change much. They do tend to spend money on good quality versions of the same old tools though and just get on with it. It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week.
To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.
> To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools.
That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now.
That's why I like hobby projects - you get to choose problems that are interesting.
I like the idea behind your post because it's true for lots of people - when you're so close to it, you don't realise that you're arguing over maybe 10% efficiency in lots of cases.
But i think programming is kind of unique in this respect too.
The tools sometimes let you approach a problem in a different way; sometimes "just getting on with it" means you're wasting a lot of time dealing with stuff that wouldn't be an issue in a better language.
To give you a concrete example, it's like when you do a CRUD application with a properly normalised database and then you need to add auth. And then you realise a transaction made at a certain date has messed up all later transactions. And then you realise you need to add an audit trail. And then you realise that needs to scale its services independently and you have to add micro-services. And then you realise you've got yourself into consistency issues because your services are sharing state through your db, etc etc.
Or you just implement CQRS and all those problems go away (yep you have different problems).
But i'm just saying that tooling matters, and picking the right tools can be worth hundreds of thousands of dollars.
I think the C / C++ argument is a strawman, it's not using all the features of a language that matters, it's picking the right ones.
Your point about "picking the right ones" is fair enough and of course the language can make some difference but not anywhere near the difference the architecture makes. Which is exactly what your point about CQRS outlines.
Google and Amazon built businesses on Java, a tool that is as boring as a hammer. It was the architecture that mattered.
"In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice."
Yep I agree that architecture plays the largest part.
But I really don't think it's about a language being boring vs not!
Pure functions are easier to reason about. So it makes sense that a language that encourages their use will be easier to reason about - which will help with maintainability.
Same goes for concurrency patterns - the closer they are to the language, the less room for mistakes.
I think the same for testing, but a lot of the time it's up a layer of the stack with a framework.
"It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week."
That seems to depend on the language. Django seems to be the established framework for Python, Rails for Ruby, there are plenty of choices if you have some special need.
This is exactly how I feel. Too many developers lose sight of what they actually valued for. Sure there are a subset who we need to be at a higher level to do the leg work on building tools etc, but 95% of developers really are far too involved in issues and obsess over things that distract from their actual role.
Despite what a developer is mostly valued for (delivery), his professionalist on picking the best tools for the job (obviously to his knowledge) should also be expected, so that his client has the best outcome from his work: Deliverable suitable for the use case, performant, scalable if required, maintainable, etc
> They also sell a step-up model whose main difference seems to be that it is made of stainless steel. What will the Germans think of next?
Only stainless steel tools on stainless steel work pieces and vice versa. Don't mix stainless/non-stainless tools and non-stainless/stainless work pieces. Hence stuff like screw drivers will be needed in both variants.
Comparing the decision of a type of screwdriver to use with a programming language is disingenuous at best, given the vast differences in complexity, switching costs and effects on productivity.
A more honest comparison would be screwdriver choice vs whether to use 80 or 100 character column limits.
Sure! And people want functioning software, too. The biggest difference between the two worlds being that maintenance is an exceptional event for a door while being the essence of its lifetime for software.
As someone who used to put in dozens or hundreds of screws in a day, sometimes:
Yeah, if you're hanging one door maybe you don't care so much. But on door #100, when your hand is covered in blisters, and your screwdriver has rounded off to the point it can no longer put in screws, maybe you'll care which screwdriver you're using.
The language as physical tool metaphor is meaningless as far as I'm concerned. Physical tools and programming languages have very little in common. The reason so much is written about programming languages on HN and Reddit is because a language shapes the way you think and anything that alters your way of thinking is a serious matter. Some are expressive, others are not. In that sense a programming language has more in common with a political ideology or religion than something found in a garden shed. That's why programmers - at least those with a soul intact after x years in a Java shop - often obsess over the pros and cons of a programming language. To a craftsman it matters.
DHH once made an excellent defence of programmers as writers rather than engineers and it's perhaps no coincidence that the language he was referring to has ancestry with Perl which was designed by a linguist. Try Clojure/Lisp sometime if you haven't already. Then you'll experience programming as closer to expressive linguistic art than engineering.
My first programming language was Perl and I had to choose between Java and Perl at the time. If you haven't read Larry Wall's "Programming Perl" I recommend it regardless of the status of Perl in the current scene. It's a classic, written in a warm, witty style. 5 minutes with Deitel and Deitel's turgid Java tome and I was sold on Perl. The point I'm making is that choosing Perl over Java as my first language made a huge difference to how I programme today having learned many languages since. I still keep my use of objects to a minimum, prefer functional over OOP and love Clojure with a passion.
"Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can't represent the information that the users need, the application doesn't do what what the users need it to do, and instead of writing code, the "engineers" are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they'd leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet."
http://blogs.harvard.edu/philg/2003/08/12/
I don't think this a fair analogy, or that it plausibly explains the wage gap between programmers and doctors. I'm sure doctors discuss the merits of different medical techniques at conferences. In a similar "emergency" situation (e.g. customer demands bug fixed by tomorrow) I have not see anyone agonize over the right tool for the job. In both industries there is a time and place to discuss best practices and how we can improve them. I admit that the programming world seems to have these discussions more frequently.
In theory, you're right, Java versus Scala is just small difference in how you express the same things in two different languages. In practice, you're wrong. Choosing Java or Scala makes a huge difference in style and culture.
The mere existence of Scala (and Clojure, and Go) as a viable alternative has intensified the bad tendencies in Java culture, the tendencies responsible for the stereotypes of overabstraction, OO overkill, framework bloat, and gratuitous "enterprisiness." In the past, large numbers of people who did not have a high tolerance for those things worked in Java for good pragmatic reasons. They served as a loyal opposition that called out and pushed back against excesses, saying things like, we can't make every call over CORBA, it's asinine to need reams of XML to configure a simple web application, and Hibernate is harder to get right than the thing it's supposedly protecting us from.
The loyal opposition are dwindling as more developers choose Scala and Go for application development. More and more the people sticking with Java are people who were perfectly happy wiring their applications in XML and learning "best practices" from Sun's marketing department. The Java ecosystem isn't going to regress overnight back to those bad old days, but that's the culture you adopt when you adopt Java as a language for application development.
I have used Scala to build the backend of https://huu.la for years, which is not a small codebase anymore, I love the language itself, it's fast, typesafe, productive, and gives access to the rich Java ecosystem. The only thing I dislike is the tooling, especially whenever I open eclipse, the fan just screams to hell and it's still slow as a snail.
You should definitely give Jetbrains free community edition of Intellij Idea together with the scala plugin a try. [0] It feels much better to use than Eclipse.
Regarding json serialisation, at the time I was using scala, I found quite "unusual" that the play library could not deserialize a json with more than 26 fields (or something like that). I hope they fixed it in the newer versions, but still I don't get why to rewrite all the libs from scratch, when java has good ones available.
It was 22 fields and the problem was not serializing/deserializing, but it was a problem with the Scala functions and tuples system not supporting case classes with more than 21 fields. This limitation has been removed since Scala 2.11.
As asked (and answered) here[0], it used to be a Scala case class limitation. There are tricks to do it anyway, like manually mapping fields by writing your own JsReads or JsWrites for your object.
Scala appeals to those who love programming languages. Java and a few other languages appeal to those who love making software, something that Scala is terrible at.
Actually not true. If you love making software you will probably use Scala without its esoteric features (for the better, imho) and you have a powerful and useful tool, yet very pleasant to work with.
The point I was trying to make is that it does not have to be cryptic at all!
I worked on a play app where it was really easy to go around and even JS front-end developers made small contributions.
Maybe some teams need to set up rules, or do more code reviews idk.
Every teams ends up with different subset of features through. When you take over after different team with different culture, the deciphering problem gets back.
Also, through I did not seen it in Scala but in different language, the part of coding I personally enjoy the least was the prolonged fight over which features are going to be used with code reviews being primary tool to force other team members into submission. Seriously, I like following team standards, but new rules suddenly appearing during code review were pretty annoying - giving me a choice between not meeting deadline and following other dude random opinions whether I agree with them or not.
Scala is a language of compromises. That's part of its success! I think it appeals to people who want to try out many different types of language styles, but the programming language purist in me hates it because it's not opinionated and is such a mish mash.
Scala tries to be everything at once, it's hardly a language of compromises. It was successful because when it was created Java sucked and now of course people are stuck with Scala deployments as nobody can decipher all that code. Java still sucks but less that it used to be. It needs type inference for like yesterday. The biggest drawback of the language is the slow toolchain.
Java still sucks a lot along with every JVM based language. Scala sucks less compared to others due to its flexibility. Only beginners can't read Scala code.
I am opinionated and my opinion is that the more features in the language the better - as long as they're sanely organized, and not a mishmash of things hidden behind arcane syntax inventions. So right now I'm not too fond of Scala because of how messy it seems.
The only language I know of that has a scope comparable to Scala is Oz...a language designed to teach beginner programmers the superset of programming paradigms.
And compared to Oz, I'm quite happy with how neatly unified it has turned out to be. It's not perfect, but as someone who regularly uses both OOP and FP, I'm pretty happy with it. I'm really looking forward to Dotty, because a lot of the cruftier things about Scala can start to go away.
Why? I assume you are making a joke that Akka is overly complex or?
Akka is clearly a very successful project, being used widely for very high volume systems. Apache Spark removed Akka because so many users were having version compatibility issues between the version of Akka they were using and Spark was using. Enough people want to use both in the same application that the Spark guys rebuilt Spark without Akka.
> Java and a few other languages appeal to those who love making software...
Now, replace "software" with "bloated, dysfunctional garbage" and you're good to go. Java devs are pretty much terrible at making software and arguing about technology.
But I think it is complete BS to say that Scala isn't good for "making software". The two most successful projects of my career were relied heavily on Scala to deliver robust product on aggressive timescales, with teams largely composed of first-time Scala users.
The very first example is about DI and advocates MacWire to do that in Scala:
lazy val userDao = wire[UserDao]
I come from Java and when I moved to Scala I wanted to use DI to mock dependencies in my unit tests. The logical choice for DI seemed to be MacWire, however it did not help me with the mocking at all.
In Java you have Mockito and annotations such as @InjectMocks that inject all your mocks into your SUT automagically. In Scala, regardless if I used MacWire or not, I had to override my SUT's implementation and its dependent fields by myself, or use constructors that take all the dependencies as arguments so I could override them in my tests.
Luckily this is much easier in Scala than in Java, but to me MacWire was a disappointment.
Eventually you learn not to need mocks. It's a long road though. An important first step is making your dependencies very very simple functions that are trivial to define on the fly.
Yes I agree, in Scala mocks are not as useful as in Java and the Scala language has some features that make it easier to work around them.
However what I don't understand is what is so great about MacWire. Maybe I'm missing something but I always believed that the main advantage of a DI framework was that it facilitated mocking. If this is not needed in Scala, then what is so great about MacWire?
You're right. The biggest thing that DI frameworks have historically done for me is make mock injection easier.
There are other benefits, however.
- Manual wiring generally has quite a lot of boiler plate (even in Scala, especially if you use free monads)
- DI frameworks enforce a pattern of behaviour. This can be especially helpful when navigating a project.
Having said that, whether these benefits are worth the cost of a DI framework is debatable. My current weapon of choice is FreeK...
There are at least two things more important than Scala being a cleaner Java:
1. The IDE
2. Oracle's claims on Java IP
A good IDE is more important than Java being verbose, and the only way Scala will displace Java is if Oracle win suits and makes Java expensive to use.
Scala is compiled against the jvm, so you're able to e.g. compile a scala jar and call it directly from java.
A couple of caveats, though.
- collections are different. You'll need to use helpers from JavaConversions, etc. to e.g. turn a Scala list into a Java list.
- scala methods with default arguments are irritating to call from java.
- avoid the more esoteric scala features
What "better java" means? It means I can build the same stuff but in a better way. Easier to read, to maintain, and at least with the same performance.
Scala has a big plus on asynchronicity, but the article doesn't even try to go there. Libraries like Akka, FS2, Monix, ScalaZ etc are not mentioned either.
In Scala I can use everything from Java and much more, and this is why is better.
I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.
> In Scala I can use everything from Java and much more, and this is why is better.
You can use everything but it's not always very nice. For instance one of my biggest source of frustration is dealing with XML and SOAP (yes I know...) Scalaxb is good but limited, and using Java libraries means dealing with Java POJOs. I can definitely see Kotlin's potential in the "perfect Java interop" space.
That said, I agree with you, and I enjoy those high-level libraries too much to switch back to a less powerful language.
A "better Java" means keeping the same concepts and paradigms as Java, but fixing some of the design issues. That's what Kotlin is.
Scala on the other hand is a completely different beast, but some people use is as "a better Java" because it doesn't force you into its paradigms. You can code in Scala without using case class, with var everywhere, etc.
It can be handy to fallback to "Java style" when you don't know how to do it in idiomatic Scala, but at the end of the day if you don't want to embrace the key paradigms of Scala it's better to use a different language.
Even though Scala might not be the answer, I still think we need a replacement for Java.
All the Java enterprise projects I know suffer from the same problems; incredible complex project structures, a lot of "dead code" (e.g. empty Java interfaces), XML, money being burned for engineers fighting with Tomcat or Glassfish, slow database operations because of an ORM centric development and so on.
I am not sure, what's going to be the solution but from my perspective Java as a language needs to be replaced.
Java 8 is much better for programmer's sanity. If you could force people to jump to that, and completely burn down some areas of the ecosystem (like XML overuse), maybe Java could actually be saved.
Alas, I think backtracking on parts of the ecosystem is a hard thing, and I don't see it happening soon.
I'd say, in the end it comes down to two problems; Java's verbosity and the fact, that a lot of frameworks do "magic", things happen without explcitely asking for it (the JPA is a nice example for that).
Adding: I was messaged by someone who interpreted my comment as if I was saying "Java 8 is better than Scala". That's not what I meant. I mean that with Java 7 and 8, Java the language is more bearable than it was in the past, so Java the language is in less dire need of being replaced by something else.
I don't see anything in your list of complaints that is about the actual language, not meekly about the culture surrounding it. The established perceptions of "best practices" are much more in need of a shakeup than the language itself. Maybe replacing the language is the only way to achieve that change, but then it would be more like a necessary sacrifice than a goal on its own.
That's a true point. Maybe it's more about the culture.
What I actually don't like about Java the language is the boilerplate; it's a very verbose language. I don't like that anymore. I am infected with LISP now.
Not surprisingly, this approach has become very popular in
recent years and made the Play team consider promoting it
as the default in the upcoming version of the framework.
It's not really the default. It's just another reasonable choice without adding guice as a dependency.
Even the Starter templates include guice: https://github.com/playframework/play-scala-starter-example/...
Play! also does not enforce somebody to the Scala Ecosystem, it doesn't come with many functional patterns (but they can be used with it).
The overall goal of the last versions was getting a DI approach, so that the testability of an Applikation can be greatly improved and also the testability of Play itself.
393 comments
[ 2.9 ms ] story [ 204 ms ] threadWell, perhaps not "a better Java" but at least "better than Java".
It's going to be interesting comparing the adoption curves of both these languages especially after Java 9 and most importantly Graal (http://openjdk.java.net/projects/graal/) .
Or you could, you know, go directly to the source while experiencing a pretty nice language on its own http://elixir-lang.org/
This project looks neat and if you had to use JVM tools but wanted some of the benefits of Erlang style development I could see it being a perfect fit.
Im new to scala and I love it.
Also sbt > maven!
I've learned German, too. German is 'difficult', not because of its grammar, but because how mistakes are handled. Which is often with harsh commentary, ridicule or confusion. Not sure why that is the case, but English speakers are often kinder when offering corrections!
I'm going to give you the benefit of the doubt and assume that was a clever and subtle joke.
And it's been a while since I was a student. Cut me some slack :p
And I know I should've written 'i have' instead of 'i've' - in Arabic we say 'ill efforts blacken the face'
Joking aside, I think it's a consequence of English being a very complicated language with all sorts of borrowing from different language families. There's almost no such thing as "correct" English, and attempts to reason about it in a prescriptive rather than descriptive manner will almost certainly fail. Whether that's a good or bad thing is up for debate, but mistakes happen either way, and I reckon the average English speaker to be a bit more cognizant of that, recognizing that nobody - oneself included - really has a perfect understanding of the English language.
1 A cash register (noun)
2 In very poorly constructed resumes
3 In the farming sense (verb)
4 In internet forums alongside poorly written English
5 Shakespeare and other literature from several centuries ago.
So my advice: unless you're a time traveller, use "until".
I think I even forgot the difference between conjuncts and adjuncts, too. Grammar 1/2/3 were tough courses.
I'm leagues below the level of a native speaker, I'll admit that! But I did still do a ton of reading, which did improve my English, but won't protect against common pitfalls :P it could've been worse. At least I don't make those "your" "you're" mistakes, too often :D
Honestly, I don't see it as a problem.
Gnu make does not need make to build (it includes a build shell script for that), gcc can be built using any C compiler via a 3-stage bootstrap. But sbt, it seems, can only be built by sbt.
I get you would enjoy deciphering hieroglyphs...
XML syntax is very simple, has very good IDE support (navigation, autocompletion - thanks to xml schema, etc.. can any IDE autocomplete dependencies from repository in .sbt files?). Maven itself provides good easy ways to reuse the configuration across multiple modules.
If you exclude dependencies than for more complex projects the no of lines in pom.xml build files is somewhere between 50 - 100 % more, so it is not like .sbt (or gradle - which I find superior to both) is 10 times less verbose.
Look at play https://github.com/playframework/playframework/blob/master/f... Here is a list of few glyphs from there:
._ := () ++ ++= ]( % target := target.value / "sbt-routes-compiler",
Seriously?
Assembly is also very simple. Basic is also very simple. Why don't we program in these "simple" languages?
> has very good IDE support (navigation, autocompletion - thanks to xml schema, etc.. can any IDE autocomplete dependencies from repository in .sbt files?
Just like .sbt sources, since it's Scala + the SBT API + some operators.
> If you exclude dependencies than for more complex projects the no of lines in pom.xml build files is somewhere between 50 - 100 % more, so it is not like .sbt (or gradle - which I find superior to both) is 10 times less verbose.
SBT is a dsl in Scala. It's at least 10 times more powerful compared to java & xml. Even the dependency system is far simpler in .sbt files. XML is just bloated, full with noise and primitivity. Just like java.
> or gradle - which I find superior to both
Why?
> Here is a list of few glyphs from there: ._ := () ++ ++= ]( % target := target.value / "sbt-routes-compiler",
If you don't have a clue what's "++" and such operators and you're too lazy to search for it then you're not a programmer just a joke. Seriouly, how can you complaing about a few operators in a dsl?! "](" isn't even an operator, "[]" is the generic parameters' syntax while "()" are just parens. This is the problem with you java devs, you're too lazy to learn. And that's what hits your quality.
It influenced my programming style a lot and I try to prefer those patterns when I use other languages as well.
Some people like more advanced aspects of Scala, and like to flirt with category theory and hardcore functional stuff. Personally I find it hard to express myself in terms of higher order kinds, monoids, functors, semigroups and such. You can learn them but it's a bit like switching from qwerty to dvorak... if you have to look at the keyboard each time it doesn't make things simpler for you.
And Kotlin makes this debate irrelevant anyway.
Never had a project OK'd to use it, probably never will. They obviously need a PR and marketing department; otherwise they end up being the CouchDB to XYZ's Mongo.
Kotlin is bundled with Intellij Idea. And Kotlin has smaller adoption barrier.
It's not until you've had to hire Java devs that the mystery of why so many people feel the need to ask a question as facile as FizzBuzz becomes clear.
Android is arguably Kotlin's killer app and it is seriously good. The PR for Kotlin is /r/androiddev ;)
OTOH Scala does not have a killer app.
Most spark projects that I have worked on have been in pure java or pyspark. And kafka has been .. well, everything from python to php to ruby.
Spring is adding dedicated Kotlin support in 5.0 which is likely to give it a huge amount of credibility and make companies running on Spring more comfortable with adopting it.
And the collection libraries is where Scala shines comparing to Java. Handling collections in Scala is just so much easier and more fun than in Java. Please try it out if you haven't done it yet.
I worked with Scala collections for 9 years, last 5 years I implement collections for living ;-)
Scala collections are behind in implementation. JSR166 (java.util.concurrent) made large performance progress in Java 8 and 9. It was never back ported to Scala.
Nothing like `ConcurrentNavigableMap` is in Scala. Or Set with weakly referenced keys?
But that hasn't stopped people from writing amazing software in it, which to me says a lot about the power of the language.
I suppose, though, that after spending enough time immersed in a language, even such inconsistency stops being a real obstacle to anything.
As far as I an see Scala has achieved something no other language before did:
1. For the first time, achieves a successful marriage between ML-style functional programming and class-based object-oriented programming (OOP) with subtyping a la Java. Scala achieves this by building functional programming as a special case on top of class-based OOP. Previous attempts at unification (e.g. Ocaml) tried instead to base OOP on top of typed λ-calculus.
2. Scala even improves on ML in that it fuses the language of programs with the language of module systems and brings type-inference to both (albeit partial). It fuses the two without any real compromise on each, indeed one could argue that both were improved since ML's module system doesn't have type inference.
3. Smooth integration of higher-kinded types with OO programming.
4. Having an advanced language running on the stable and well-libraried JVM eco-system. Usually languages with as much novelty as Scala, remain in academic obscurity.
The unity of Scala is witnessed by the fact that it can all be compiled down to a rather simple calculus, namely "dependent object types" (DOT) [1]. I'd say that DOT is to Scala what lambda-calculus is to Haskell. I find it hard to think of another language that combines so much expressive power with being simple and coherent.
[1] T. Rompf, N. Amin, Type Soundness for Dependent Object Types (DOT), http://lampwww.epfl.ch/~amin/drafts/dot_oopsla16.pdf
If Dotty works out then we will, for the first time, have a fully specified Scala on sound theoretical footing. Along for the ride: much faster compiler, better tooling, streamlined type system, and nice-to-haves like union types and implicit function types, among other useful features.
In general, it's OK for there to be a gap between a real programming language, and its theoretical toy model. That's the gap between theory and practise. Why would you care about theory if it was as complex as practise? The ideal case (embodied in the lambda-calculus) is that the theory is much easier, but looses only a modest amount of precision.
I didn't say Scala was inconsistent, only that it felt as such. I've lost access to that codebase since the end of my participation in the project, so I won't provide you with code examples, but the project was using most of the language features available to date (2015). Maybe "inconsistent" is a wrong word. "Messy" would be better. I've been familiar with many of the concepts in Scala from other languages, and here it felt like they were glued together with gratuitous use of syntax and implicit type conversions.
I apologize if my previous comment didn't state it clearly enough, but I'm talking about my impressions of the language here. I'm convinced that after enough time, the whole package starts to make sense and becomes a very powerful tool in one's hands (I have a reverse situation with pre x11 C++ - it was the first programming language I really learned, so all its idiosyncrasies people like to complain about felt completely obvious and justified to me).
One day I hope to immerse myself in type theory deep enough to actually understand the underpinning of Scala better.
http://www.scala-lang.org/blog/2017/02/28/collections-rework...
I guess in Java we are spoiled - though sometimes stifling, the rigid structure and syntax help prevent people doing "bad things". It has struck me once or twice these restrictions may have been derived in part from established C++ best practices ...
Nothing requires a rewrite, but five year old code looks nothing like what people say is "best practices" now.
Guys... if only experienced Scala people enjoy reading Scala code, then you kinda have an adoption problem
Of course, Scala frameworks and its use in large systems might be different things -- though, having used Scala for my day job, I'd also disagree with that.
I also prefer cleaner languages. But, in practice, I must choose between Java and Scala, and I'd choose the latter any day, with my eyes closed!
Odersky often says that the mutability should be as 'contained' as possible in what is otherwise a largely immutable codebase. If you can reason cleanly about a black box and are sure that the mutable variables within are not going to 'escape', you get the benefits of both
1. easier to implement, imperative algos which have been around for decades. (the alternative in pure FP is to convert stuff to tail recursion, which is not always the easiest thing to do, let's just say.)
2. easier reasoning about state not leaking to the rest of the system.
I've found following these guidelines to be very helpful.
He's 100% correct (at minimum).
> the alternative in pure FP is to convert stuff to tail recursion
It's a challenge but not THAT difficult, once you get the hang of it. :) I've found conversions fun, actually. Especially when you (of course) have to learn how to trigger TCO. The irony here of course is that at the machine language level, the recursion is converted back to imperative via TCO. But IMHO the resulting recursively functional TCO code is, eh, "more beautiful"
For the complexity problem, here is how I manage it : the functional programming scala is scala, everything else is garbage included for java compatibility. It works like a charm.
I can't think of a language I could feel better with.
There are some pains associated with Scala, though. Sometimes self-inflicted by people who want it to be like Java: for example, most ORMs for Scala suck. A team at my office tried to use Hibernate to disastrous effects (Scala and Hibernate's hostile takeover of collections don't play well). Even some DSLs like Scalike tend to also be painful and unwieldy. I also dislike Play and its multitude of quirks and incompatible versions.
It used to also be the case that both Eclipse (ScalaIDE) and IntelliJ IDEA were almost unusable with Scala, in particular constantly resulting in spurious compilation errors. I've no idea if Eclipse got better -- completely got rid of it after decades of using it with Java -- but IntelliJ did get better and mostly works (though it still cannot always compile Scalike DSLs).
But even with all of the above, when I have to work with Java code again I cringe. Even with all the pain, Scala is simply better to work with for new code.
There's nothing "shaky" about Scala's complexity, it's quite stable, and not going anywhere until Dotty lands circa 2020.
Despite everything (slow compiler, average tooling, implicit/operator overloaded "magic" code bases, etc.) Scala will draw library creators (like those behind Spark, Kafka, Akka, Play, etc.) which in turn draws developers, resulting in the thriving ecosystem backing the language.
Scala will live on despite itself; the ecosystem is what will carry the language to the Dotty land and beyond.
First, IntelliJ is quite decent nowadays. So it's demonstrably possible to build a decent IDE for Scala.
Second, Eclipse itself has imploded in my opinion. Eclipse used to be a usable and reasonably fast IDE. Then, some years ago, there was noticeable increase in bloat and a downgraded performance for Java. I remember reading some major release of Eclipse, which required a refactor of its UI, didn't have any automated tests because the refactor broke them and there was a lack of volunteers willing to fix the tests. Nowadays I've stopped using Eclipse even for Java, because I cannot stand its slowness and random freezing/crashes.
I understand that not everyone has this experience, and would love to see more/better tutorials for Scala come out, but I've definitely seen several people pick it up without any problems.
Although, once you do, you can really get to work composing the features in interesting ways to get really useful effects. Like implicits + higher-kinded types to get ad hoc polymorphism. Or subtyping + pattern matching to achieve incredibly self-descriptive business logic. I would certainly agree that Scala appeals to people who like to be able to experiment and engage with more theoretical concepts while getting things done.
But let's not pretend that most languages don't have this issue. Programming with major Ruby and Python libraries tends to eventually require you to learn what's going on under the hood in the same way. I would argue that once you start digging under the surface, Scala is much more elegantly designed than those languages.
Go is about the only language that seems to say, "forget theory, we're simply about getting things done". Not my thing, but I understand the appeal!
I experienced several drawback according to library quality and code-safety. There are too many small details that left me with an unpleasant feeling (I would take ScalaNLP/Breeze for example).
But my central issue is the VM/GC dependency. In times of GPU computing, native interface programming becomes a burden. The knowledge of object ownership improves code readability. I feel uncomfortable leaving object lifetime to a background process.
Of course it is... swift is a mobile PL, and Rust is barely used non-academically (and also takes a long time to be productive in).
Scala let's java devs immediately hit the ground running, for better or worse, and it's hugely popular in the real world.
"Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver".
And then I imagine myself going back to using my shitty old Phillips screwdriver set to screw in a few screws in a non-optimal fashion and someone might say "Wow, thanks for hanging my door!" and I imagine the surprise on my face as I realize that people want functioning doors and are not too bothered about which brand of screwdriver was used to achieve that.
[1] http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-...
If you use a drill all day, professionally, you'd be a fool not to take a serious look at an impact driver and see if it makes your life easier.
And if you explain to someone the difference, they usually get it. Even my daughter when she was five could understand why I had two similar looking things when I was working with them..
... for whatever reason ...
Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.
And just to be pedantic: When I bought my first SwissTools Insider[1], I realized that it's actually still possible to innovate in screwdriver design. That doesn't make them better for every task, but hey, that's the way it is.
[1]: http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/...
Do u care about what language Amazon uses to write S3? Do u believe it is the language that make S3 succeed, or fail?
Even as a programmer, as to the other services I am calling, things I do care about involving their stability and correctness that affecting my work. I care shit about what how they write their service underneath, may it be cool or dumb.
If I'm running a business that lets say develops an ecommerce platform I won't be too impressed if my developers are using assembler. Java good, but if Scala gives them an edge and cuts my costs so much the better!
It's enlightening to me because a lot of what we consider "hard" or "too academic" is actually our own prejudices speaking. Of course it looks like that to us, coming from Java, but try talking to someone who learned Scala first :)
I also find it encouraging. Maybe some day we will be able to finally take advantage of the JVM without the weight of Java-the-language.
I think we're starting to see a new phenomenon: people who don't start on the JVM with Java. It's interesting because it shows (in my opinion) that the whole "Scala is too difficult" thing was mostly a misconception. What it was truly all about was: it's hard to give up old ways of thinking :)
That said, I love Haskell and would definitely enjoy using it at work, but it's a no go for "political" reasons, which is sort of reasonable even if disappointing. Scala scares management way less than Haskell!
That's true, but we've been in the region of diminishing returns for programming languages (I'm not talking about runtimes) for a long, long time now. To go back to the (bad?) tools metaphor, it's like saying that unless you're using nothing but your fingers, you DO care about tools. Well, yeah, but once you have a decent screwdriver, innovation in screwdriver technology -- short of a revolution -- is likely to yield diminishing returns on investment, especially as the cost of adoption remains high. Switching from, say, Java to Scala is not much cheaper (if at all) than switching from, say, assmebly language to FORTRAN or C. This does mean that the effort spent on switching languages (or screwdrivers) should decline.
Architecture will generally not be. Scala and Java encourage building applications in different ways. That doesn't mean one is better than the other (though I'd argue you could make that claim), but some problem domains are better modeled with Scala, and likely some with Java. And some programmers work better tending toward a pure, immutable, functional style, while others work better with OO, side effects, and mutable data.
While choice of language/framework may not be as important as many other choices you need to make when building an application, but it's not something that should be dismissed as irrelevant, either.
That's something that holds across all fields of engineering and art.
[1] http://blog.vizuri.com/creating-your-own-angular-material-na... [2] http://stackoverflow.com/questions/28389671/create-a-menu-li...
Let's talk about Material Design Lite. Go check that website, especially the components page (https://getmdl.io/components/index.html). It's really nice and responsive, try changing the size of your browser window and see how the navigation bar collapses to the top. Damn this looks like a great framework, I'd like to do the same thing in my app. Imaging the surprise when you can't actually do that using the framework out-of-the-box. Oh by the way, forget about MDL, all the developers have moved on to Material Components for the Web (https://github.com/material-components/material-components-w...). So much for the guys who just want to hang a door, there's a new brand of screwdrivers on the block.
It would be great if the so-called "engineers" could spend some more time creating a complete toolbox instead of reinventing new screwdrivers every month.
- You don't have to learn every new framework. Google has 10k+ Angular 1 projects, this stuff doesn't go away after hitting critical mass.
- This constant iteration has lead to multiple production-ready UI paradigms that were just relegated to FP research. Try using Angular 1 or vanilla React, and then do something with vanilla Android. Or GTK+. Do we want GTK to be our baseline for UI work? Qt is nicer, but it's definitely playing catch-up.
You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.
And I’m just sitting here, using https://github.com/ReactiveX/RxJavaFX
And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...
> UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).
You can use String.valueOf, but usually don’t want to do that. And how do you want to represent the float? With Scientific notation, Engineering notation, or purely decimal? This is not simple.
> And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).
Or you use the FXML bindings for creating them from XML?
I'm not convinced it's particularly good reasons. I think ignorance of native GUI coding and the old, "When all you have is a hammer, every problem looks like a nail" mentality has a whole lot to do with it.
And the only satisfying thing about Electron, is hitting package and getting three platform-specific binaries. Otherwise, it is still web frontend development. In contrast, I have had the pleasure of doing desktop development in Qt and WPF, which was quite enjoyable (and the ecosystem has not changed a lot since I left it years ago).
Also, MVC and MVVM were UI paradigms before web frontend development. And I am quite sure I heard about ReactiveExtensions before Facebook React.
Yes, vanilla Android is terrible.
Yes, Google could have handled those projects better, they could have put up big warning signs that they are "deprecated".
I think it was a good move to recognize how unmaintainable things (can quickly and usually) become with angular1 (or with anything that is a mess of a hundred semi-external JS libraries), hence TypeScript.
> Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2.
I think an important lesson from this is to be careful about the tools you use. If a particular company puts out great tools but changes them in incompatible ways, you might end up having to go back and rehang a lot of doors.
it seems plenty of people with attention span of 5 mins that just want to have fun creating new tools and then moving on to something else. which means either somebody else picks up the evolution and maintenance or the tool should be abandoned (ideally not picked up to begin with)
The screwdriver analogy is right on a lot of levels. Is it so hard to accept that software developers is not some unique snowflake position that cannot be compared to any other job?
Virtually any mainstream language is capable of building performant, maintainable, reliable code. Virtually no developers are capable of creating performant, maintainable, reliable code. After decades in the industry and generations of new whizbang tools, libraries, and languages I've come to terms with the fact that the problem is "us." I've seen exactly one significant sized application keep those 3 qualifications for more than a couple of years. Once all the original core developers on the project moved on, it was less than a year before the code base was a total mess.
I think what you're really asking for is a tool that forces you to build performant, maintainable, reliable code. I'm not sure that's entirely possible until we get AI writing and maintaining its own code. Humans suck.
On the other hand, if you worked as a carpenter (or even did some more door hanging on the side), you'd find yourself debating the tools and techniques of your trade with your fellow craftsmen, maybe even engaging in heated debates about their relative performance. The same is true about programming languages - they're tools of our trade. They have different performance characteristics. The discussion about that (and the flame wars) are between the craftsmen, not between the worker and the buyer.
To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.
That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now.
That's why I like hobby projects - you get to choose problems that are interesting.
But i think programming is kind of unique in this respect too.
The tools sometimes let you approach a problem in a different way; sometimes "just getting on with it" means you're wasting a lot of time dealing with stuff that wouldn't be an issue in a better language.
To give you a concrete example, it's like when you do a CRUD application with a properly normalised database and then you need to add auth. And then you realise a transaction made at a certain date has messed up all later transactions. And then you realise you need to add an audit trail. And then you realise that needs to scale its services independently and you have to add micro-services. And then you realise you've got yourself into consistency issues because your services are sharing state through your db, etc etc.
Or you just implement CQRS and all those problems go away (yep you have different problems).
But i'm just saying that tooling matters, and picking the right tools can be worth hundreds of thousands of dollars.
I think the C / C++ argument is a strawman, it's not using all the features of a language that matters, it's picking the right ones.
Google and Amazon built businesses on Java, a tool that is as boring as a hammer. It was the architecture that mattered.
- Peter Norvig
https://news.ycombinator.com/item?id=1803815
But I really don't think it's about a language being boring vs not!
Pure functions are easier to reason about. So it makes sense that a language that encourages their use will be easier to reason about - which will help with maintainability.
Same goes for concurrency patterns - the closer they are to the language, the less room for mistakes.
I think the same for testing, but a lot of the time it's up a layer of the stack with a framework.
That seems to depend on the language. Django seems to be the established framework for Python, Rails for Ruby, there are plenty of choices if you have some special need.
JavaScript on the other hand....
Only stainless steel tools on stainless steel work pieces and vice versa. Don't mix stainless/non-stainless tools and non-stainless/stainless work pieces. Hence stuff like screw drivers will be needed in both variants.
A more honest comparison would be screwdriver choice vs whether to use 80 or 100 character column limits.
Sure! And people want functioning software, too. The biggest difference between the two worlds being that maintenance is an exceptional event for a door while being the essence of its lifetime for software.
Yeah, if you're hanging one door maybe you don't care so much. But on door #100, when your hand is covered in blisters, and your screwdriver has rounded off to the point it can no longer put in screws, maybe you'll care which screwdriver you're using.
DHH once made an excellent defence of programmers as writers rather than engineers and it's perhaps no coincidence that the language he was referring to has ancestry with Perl which was designed by a linguist. Try Clojure/Lisp sometime if you haven't already. Then you'll experience programming as closer to expressive linguistic art than engineering.
My first programming language was Perl and I had to choose between Java and Perl at the time. If you haven't read Larry Wall's "Programming Perl" I recommend it regardless of the status of Perl in the current scene. It's a classic, written in a warm, witty style. 5 minutes with Deitel and Deitel's turgid Java tome and I was sold on Perl. The point I'm making is that choosing Perl over Java as my first language made a huge difference to how I programme today having learned many languages since. I still keep my use of objects to a minimum, prefer functional over OOP and love Clojure with a passion.
Sorry, "just a tool" is meaningless.
"Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can't represent the information that the users need, the application doesn't do what what the users need it to do, and instead of writing code, the "engineers" are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they'd leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet." http://blogs.harvard.edu/philg/2003/08/12/
You COULD write a website in pure ASM[0], but should you?
https://asm32.info/fossil/repo/asmbb/index
The mere existence of Scala (and Clojure, and Go) as a viable alternative has intensified the bad tendencies in Java culture, the tendencies responsible for the stereotypes of overabstraction, OO overkill, framework bloat, and gratuitous "enterprisiness." In the past, large numbers of people who did not have a high tolerance for those things worked in Java for good pragmatic reasons. They served as a loyal opposition that called out and pushed back against excesses, saying things like, we can't make every call over CORBA, it's asinine to need reams of XML to configure a simple web application, and Hibernate is harder to get right than the thing it's supposedly protecting us from.
The loyal opposition are dwindling as more developers choose Scala and Go for application development. More and more the people sticking with Java are people who were perfectly happy wiring their applications in XML and learning "best practices" from Sun's marketing department. The Java ecosystem isn't going to regress overnight back to those bad old days, but that's the culture you adopt when you adopt Java as a language for application development.
[0] https://www.jetbrains.com/idea/features/editions_comparison_...
[0] http://stackoverflow.com/questions/20258417/how-to-get-aroun...
Also, through I did not seen it in Scala but in different language, the part of coding I personally enjoy the least was the prolonged fight over which features are going to be used with code reviews being primary tool to force other team members into submission. Seriously, I like following team standards, but new rules suddenly appearing during code review were pretty annoying - giving me a choice between not meeting deadline and following other dude random opinions whether I agree with them or not.
Scala tries to be everything at once, it's hardly a language of compromises. It was successful because when it was created Java sucked and now of course people are stuck with Scala deployments as nobody can decipher all that code. Java still sucks but less that it used to be. It needs type inference for like yesterday. The biggest drawback of the language is the slow toolchain.
And compared to Oz, I'm quite happy with how neatly unified it has turned out to be. It's not perfect, but as someone who regularly uses both OOP and FP, I'm pretty happy with it. I'm really looking forward to Dotty, because a lot of the cruftier things about Scala can start to go away.
Apache Spark supports 4 languages: Scala, Java, Python and R. Most Spark applications are written in Scala.
Akka is clearly a very successful project, being used widely for very high volume systems. Apache Spark removed Akka because so many users were having version compatibility issues between the version of Akka they were using and Spark was using. Enough people want to use both in the same application that the Spark guys rebuilt Spark without Akka.
I might agree with you regarding Akka Streams ;-)
Now, replace "software" with "bloated, dysfunctional garbage" and you're good to go. Java devs are pretty much terrible at making software and arguing about technology.
But I think it is complete BS to say that Scala isn't good for "making software". The two most successful projects of my career were relied heavily on Scala to deliver robust product on aggressive timescales, with teams largely composed of first-time Scala users.
You can read one of the stories here: http://artsy.github.io/blog/2016/08/09/the-tech-behind-live-...
I'm not going to tell you that it's an easy language to master. But I do believe it is a fantastic language for making software.
lazy val userDao = wire[UserDao]
I come from Java and when I moved to Scala I wanted to use DI to mock dependencies in my unit tests. The logical choice for DI seemed to be MacWire, however it did not help me with the mocking at all.
In Java you have Mockito and annotations such as @InjectMocks that inject all your mocks into your SUT automagically. In Scala, regardless if I used MacWire or not, I had to override my SUT's implementation and its dependent fields by myself, or use constructors that take all the dependencies as arguments so I could override them in my tests. Luckily this is much easier in Scala than in Java, but to me MacWire was a disappointment.
However what I don't understand is what is so great about MacWire. Maybe I'm missing something but I always believed that the main advantage of a DI framework was that it facilitated mocking. If this is not needed in Scala, then what is so great about MacWire?
There are other benefits, however. - Manual wiring generally has quite a lot of boiler plate (even in Scala, especially if you use free monads) - DI frameworks enforce a pattern of behaviour. This can be especially helpful when navigating a project.
Having said that, whether these benefits are worth the cost of a DI framework is debatable. My current weapon of choice is FreeK...
1. The IDE 2. Oracle's claims on Java IP
A good IDE is more important than Java being verbose, and the only way Scala will displace Java is if Oracle win suits and makes Java expensive to use.
A couple of caveats, though.
- collections are different. You'll need to use helpers from JavaConversions, etc. to e.g. turn a Scala list into a Java list. - scala methods with default arguments are irritating to call from java. - avoid the more esoteric scala features
I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.
You can use everything but it's not always very nice. For instance one of my biggest source of frustration is dealing with XML and SOAP (yes I know...) Scalaxb is good but limited, and using Java libraries means dealing with Java POJOs. I can definitely see Kotlin's potential in the "perfect Java interop" space.
That said, I agree with you, and I enjoy those high-level libraries too much to switch back to a less powerful language.
Scala on the other hand is a completely different beast, but some people use is as "a better Java" because it doesn't force you into its paradigms. You can code in Scala without using case class, with var everywhere, etc.
It can be handy to fallback to "Java style" when you don't know how to do it in idiomatic Scala, but at the end of the day if you don't want to embrace the key paradigms of Scala it's better to use a different language.
All the Java enterprise projects I know suffer from the same problems; incredible complex project structures, a lot of "dead code" (e.g. empty Java interfaces), XML, money being burned for engineers fighting with Tomcat or Glassfish, slow database operations because of an ORM centric development and so on.
I am not sure, what's going to be the solution but from my perspective Java as a language needs to be replaced.
Alas, I think backtracking on parts of the ecosystem is a hard thing, and I don't see it happening soon.
What I actually don't like about Java the language is the boilerplate; it's a very verbose language. I don't like that anymore. I am infected with LISP now.