Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem catches up and actually makes good use of what's introduced in Java 11+.
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.
> 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
True! but why Spark & Flink, which are backed with business, didn't bother themselves to catch up with changes in Scala! they delayed their upgrade to 2.12, not mention 2.13! and as far as I know the 3.0 hasn't been discussed yet! Am I right?
In general I'm happy and thankful that I learned Scala! it shaped my perspective to combine programming paradigms and pick best practices from each one rather than sticking to a single paradigm. But for work that I wanna last long enough, I can't accept it, as there is no realm of calmness in view. Software Industry is a young industry and complex, like any other profession, and a developer need to think about lots of other things as well, not just the language and possible pattern/syntaxes it has to keep up with!
I think the value that Scala brings into industry is what that prevents it from becoming the rival to others.
> Software Industry is a young industry and complex, like any other profession, and a developer need to think about lots of other things as well, not just the language and possible pattern/syntaxes it has to keep up with!
Dear friend, I don't know about your experience on the industry, specially with Scala. My experience on working with the language for more than 4 years and being responsible for more than 15 components written in Scala, wasn't delightful. I'm still maintaining some components in Scala, and I have a clear picture of it means.
Hope you'll have more successful experience with it.
Nicely done tool/site. Is there a play button to make the turtle start at the beginning and follow the path? Or pause and speed commands? I'm expecting that watching a turtle move is going to be key to getting my son into this.
1. the background should be almost-opaque, with very little transparency. Can you share which browser/OS? Probably some missing CSS :)
2. Ha :D Maybe a grace period? Did you mostly mind the squiggly underline errors, or the red box that appears at the bottom? Giving feedback soon enough but not being aggressive is a delicate balance, there's probably room for improvement here.
1. FF 77 on Arch, with ublock origin enabled. I'd still say almost-opaque is a bad idea for text-over-text. Were it an image, an opacity: 0.5+ value would be fine, but text is very distracting even at opacity: 0.8 or so.
2. Maybe that could work. A red underline is fine but the error at the bottom is the biggest thing. Instead of switching between neutral/error state, why don't you experiment with working/neutral state? If the code is fine, show a green tick at the bottom, else just show the error with grey color and a grey icon so it's visible but not attention grabbing. On the other hand, you'd get the advantage of getting people hooked with getting the code back to green. Positive reinforcement.
Thanks for the pointer, React-forms as well as React this looks very interesting, however I think the focus there is mostly on frontend, while we are trying to approach the problem both on the frotend and backend sides.
Otherwise there are some similarities between the projects.
We would be fine using existing frameworks and their form handling systems, but all of them feel very heavyweight. Either the backing objects need to be of some specific form, or the communication protocol between the server and the client is weird, or the generated markup is a mess.
With Supler, we want to make it easy to customise the form, the form's markup and associated Javascript (to add any dynamic behaviour), so that you don't have to hack the framework, but instead so that you can use our library to generate the base and then customise further.
One of the main points of Supler is that it takes care of both the frontend and the backend, so I don't think it would be possible to keep it entirely on the frontend. E.g. you define the form once, and you have partial validation on the frontend, and the same full validation on the backend (without having to repeat yourself).
That's on purpose, of course ;). But it's not only marketing: functional as in preferring immutable data structures, and reactive as in changing the form in response to user input.
I think the DSL itself is great. I have a project where I'd like to use something like this in anger and I'll revisit when I get to engage on that peoject.
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.