161–170 of 235 posts
Earlier quoted context omitted.
An evergreen conversation: "I love C++." —Alice "Oh? Which C++?" —Bob Every successful C++ team defines its own C++ subset.
This is why I can't figure out how for the life of me to learn C++ effectively for professional use.
Earlier quoted context omitted.
I wouldn't blame the language, I'd blame the people who chose Scala. The impression I always had was that Scala was a research project into how various programming language features could live together and interact, hence their everything and the kitchen sink approach. From an academic point of view I think Scala was a huge success. That people chose to use Scala in production speaks more to how badly people hate Jav…
Indeed, Scala looks like a language research project, more like Perl and Haskell. You definitely can use all of them in production and benefit from that, but you need both mastery and restraint in using such a language. Golang is the opposite: it takes the ideas from 1980s with some early 1990s (Pascal, Modula-2, Oberon; CSP; garbage collection) and executes them to near perfection. It even ignores some of the obviou…
As long as the platform is relevant everything moves along without extra layers of tooling and idiomatic wrapper libraries for platform APIs.
Might not have all the bells and whistles, not so shinny, but it works and I don't need to care about my replacement having headaches.
But Java had adopted about 75% of scala’s features from 5 years ago. Mostly with some quirky limitations and bloated syntax. What exactly makes it easier for people to understand is beyond me
I might be a bit biased, since I've been writing Scala professionally for years. While most of the article rings true, I wanted to share some counter-arguments: 1) A lot of the problems mentioned are only really noticeable if you use Spark, which really lags behind in Scala versions compared to the rest of the ecosystem. As someone who doesn't use Spark, I don't really feel much of the "Scala minor versions" pain. 2)…
> You need to open a JIRA ticket to get a namespace, create GPG keys, register keys in a keyserver, and add SBT plugins just to get a manual publishing process working. It’s a lot more work than publishing to PyPI or RubyGems.
It's a little annoying to have to go through that, but you only have to do it once per domain, and the turnaround from the people who manage the sonatype jira is usually pretty quick. In return the ecosystem gets a lot of protection from the kind of exploits you mentioned.
Earlier quoted context omitted.
That is exactly it. A company wide style and coding guide is a must with scala
A company wide style doesn't quite get it done. Is your style not to allow high kinded FP coding? (because it is too hard to understand). If so does that mean you don't allow libraries written in that style, like SLICK? We had PHDs and very senior engineers, and they thought debugging common libraries like slick would take them weeks of work and they opted for avoiding that entire type of scala. But that is hard to d…
Earlier quoted context omitted.
A lot of the problems with Scala echo many of the problems that people used to write about Perl codebases minus specific language quirks like typing and objects. The problem with complex, rich languages is that it doesn't guarantee anything about the wisdom of programmers to pick, choose, and abuse from the features that wouldn't be easily legible to future maintainers. Somehow Scala has a lot of the issues that I fe…
From a quick google search it looks like ts/js doesn't let you define custom operators like Scala does. Scalas implicit stuff is messy too. The original article mostly talked about libraries though
So I'm here scratching my head at the point issues denoted in the OP wondering if I missed something critical about what makes Scala so different in its ecosystem conventions that a community couldn't fix over years. Even Node.js managed to work something out via Yarn
Earlier quoted context omitted.
>Avoid inheritance. Once an object is instantiated, don't change its internal state. etc. Just embrace Clojure then. You get all that enforced for you, plus the entire Java eco-system.
I'm not a huge fan of the Java ecosystem. Clojure does look really nice and Diatomic looks pretty slick. Have you used Clojerl? https://github.com/clojerl/clojerl
Clojure's ecosystem is even better, it improves on the Java one a lot, simplifying most of the warts with the Java one, and like you've brought up, it goes beyond the JVM in having quite a lot of active dialects.
I haven't tried Clojerl beyond just REPL, but it seems quite complete, and the maintainer is very active. ClojureScript is also quite nice, if you prefer the JavaScript/Node ecosystem.
You can also use ClojureCLR if you like the .Net ecosystem better.
And finally there's Babashka which deserves a mention, if you want something more like Python.
You also get to play with Clojure derivatives as well: Janet, Fennel, and Ferret can all be picked up in a day if you already know Clojure.
For me Clojure was a great investment, and it's replaced all my needs in all areas: scripting, front-end, application development (mobile and desktop), command line tools, server side, big data, batch processing, ML, data visualization, etc. Only downside is you will exist within a niche, but that niche has everything I need.
On the other hand, yes - Scala is in many ways a research language. It's got a number of novel features, starting from the blend of FP and OO, through implicits, ending with metaprogramming. The dark side of introducing features that other languages don't have, is that they sometimes need polishing or complete removal. That impacts the compiler (which evolves as well - compiling Scala code is much more complex than the rather straightforward translation of Java to bytecode) and high-level language features alike.
The bright side is that software engineering is very far from being a "done field" (or at least I refuse to believe it is such). There's a lot to be discovered as to how we can write code that is readable, performant and - yes - maintainable.
"Wait, but if you said Scala is a research language, is it safe for business usage?" Yes - while Scala has a research side to it, it also is a language used successfully in many companies. It has a lot of libraries that are maintained, the language authors pay a lot of attention to binary compatibility (with well-defined limits - you know what to expect!).
Businesses have benefited from using the newest available technology in many fields, and I doubt software engineering should be different. Of course, you shouldn't be reckless - but using technology from 20 years ago "just to be safe" isn't always a recipe for success.
Yes, you can build great systems with Java and Go. Same is true for Scala. And yes, you can build totally unmaintainable systems in Scala, but in Java and Go as well.
Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free. You like the library, it solved your problem - great, you can use it for free. But if you want it maintained above what the library author donates, either through their time or through corporate sponsorship - well, you can't have any expectations here. I'm sure a lot of these migrations problems could be solved, given a reasonable business offer.
Earlier quoted context omitted.
Be honest and give a short list of experimental approaches that you wanted to do and couldn't be done on Java. What did you want to do and couldn't? And, let's ask Rich Hickey. What language was it he used to experiment with a new s-expression language? Why wasn't RH scared away? You want the brutal honest answer? Because he is smart and can grok the complexity of the Java in toto. What sort of experiments can you no…
> I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...