|
The problem isn't whether the conclusions you draw are favorable or not, it's that they are not legitimate. It's getting tiresome that I have to repeat it: I'm not at all arguing either in favor of Perl, or against the "write-only" narrative that imo applies to other languages as well, including C++, Scala, Common Lisp, Ruby and whatnot, and I quite clearly know what it means when somebody says Raku is a "write-only" language. Newsflash: it's not about visual appeals, it's about mental portability across people. > You do realize, I hope, that saying stuff like this doesn't really make the "write-only language" cavil that's dogged Perl throughout its history seem any less fair... Surprising, right? I frankly cannot parse that sentence but yes, by now I really hope it's clear that I'm not arguing with the "write-only" narrative. I'm arguing that there is a world of things where software doesn't have to be about sticking to the same monolithic code base for decades and pass it around across dozens of people. That there is a world where it is indeed more important to write code than to read it. > And once again I am saying you have failed as yet to convince me those possibilities might offer productive benefit, especially when I have yet to see the theoretical advantage of language flexibility in microservices materialize in practice. I hope I suceeded in convincing you about factual things about signatures, reflection and the existence of accumulation. I don't have research studies about the productivity of various programming languages in a microservice-based architecture; if you have something like that, I will be happy to read it. > Instead you seem to plead language flexibility in microservices more or less as an excuse, on the idea that niche languages for which knowledgeable engineers are rare as hen's teeth face no barrier here because, after all, you can always throw the code away and write more. And that is not convincing This is not convincing because it's a strawman. Let's throw the "niche language" part away and let's replace "after all, you can always throw the code away and write more" (which is true but indeed no argument) with "a small, single-purpose, well-tested tool of any sort is best replaced when that single purpose wears out". Which is what I stated. And it makes sense, given that it was designed and tested around one single purpose. Maintenance is not a virtue but a common technical necessity. If you don't know when to let go of software, then ironically enough, you might as well have been exposed to too much Perl. Anyway, considering the topics you did not respond to, one can deduce what points I did nail. Also, it seems we are getting away from the insult motive, that way it may be more useful for somebody who just reads. |