rajinl

thanks for the reply. My concern was people writing services that available on the network for trivial use cases, where a class or function would be faster and as reusable. You have addressed that concern. In light of your answer, is Jolie similar to an actor based pattern like Akka, with services being the abstraction rather than actors?

Its cool that someone wrote this, but practically, this sounds like it encourages to microservice hell with many unnecessary services. A service should not be written to enforce separation of concerns. We have classes and functions for that.

I worked for a startup that built a no code platform. The experience you had, was the same experience that the majority of our customers had. Its a general problem with low code. We tried to make the software easily extendable so that developers could refactor away the complexity, by easily adding new tools to the design surface. The approach worked quite well for internal projects, but was at odds with the marketing approach to the product, so it was never pushed to clients. Clients were sold a utopia of business analysts dropping some components onto a designer and hey presto. Low code can work, but in the same way as traditional dev, where code should be refactored into components that's are easy to reason about. The problem is that this is hard to sell. There is a very nice balance to be had with combining low code with traditional dev. Its just very hard to find that balance. Its far easier to write good code in a traditional language that in a low code environment. If you add to that the expectations created from low code demos, its mostly a recipe for disaster.

Having worked a bit with KDB, my experience is totally different. The investment bank I worked at had a large and thriving KDB community of developers. In one particular project, we were able to replace a system consisting of 10's of thousands of fairly good but heavily abstracted java code reduce it to a few hundred lines of Q. The java application at took 7 hours to run its worst case query and the Q code that ran the same query in less than a second. The Q code was solved the business case better, it was more readable mainly because there were no unnecessary abstractions. There was still a OOP middle tier, but it was mainly pass through. Calling any technology a "pile of shite" should be done with great care. Most solutions solve a use case and KDB/K solves its use case exceptionally well. To be honest, understanding what the 'Rank' error means is not that hard. For the project I referenced earlier I personally found it much easier to debug Q than trying to find out what an an AbstractCalculationFactorybuilder was doing. There are very few poor languages, just poor developers.

As someone who has hired many developers at a large Investment bank, I always found that people that knew Haskell or some other functional programming language tended to be far more productive in standard OO languages. I know of many other technical leads and hiring managers that look at Haskell as a market signal. As someone who does code in F# and Haskell in my spare time, I don't expect to get job using either of these languages, but knowing these languages got me a foot in the door to do some of the most interesting work I have ever had (many years ago). From those in the Haskell community that I do interact with, most people do not expect to code in Haskell for their day jobs, and most of them would continue writing Haskell code outside of work regardless of whether Haskell becomes a commercial success or not. For me, Haskell is one of those languages that is just worth knowing, simply because it gives you a different perspective on the world and a new set of mental tools. If you haven't as yet played with a strict functional language, then you really should give it a try.Not because you expect to use it at work, rather because learning new things is fun and it will make you better at your job anyway as a side effect. If the logic you used in your argument holds, then we should really be coding in assembler.