5 ms·

It would be invaluable feedback if you could point out what you find so bizarre? I mean, the "let's define some ad-hoc postcircumfix operator" is a weird flex f

It would be invaluable feedback if you could point out what you find so bizarre? I mean, the "let's define some ad-hoc postcircumfix operator" is a weird flex for sure but otherwise? I could only see basic non-magic subroutine definitions and appropriately used operators.

throwanem 3y ago
Where would you like me to start? The apparent variance between list syntax accepted by the reader and emitted by the printer, the brambly thicket of special-case operators and grammars ('o' for function composition? Square brackets to reduce over an operator? Square brackets with a backslash to map? - I remember the "Periodic Table of the Operators", but even by that standard this is wild), function signatures as first-class values (...what?) But honestly, I don't think I can provide actually useful feedback here, because I'm pretty sure nothing I'm doing is similar enough to anything Raku is doing for the conversation to really make sense. Everything I've just described, and much else about the language, strikes me very much as needless complication for the sake of complication, the sort of thing that earned Perl 5 its "write-only language" sobriquet by encouraging, if not necessitating, the development of idiolects among its users - and Raku if anything seems to do much more of this than Perl 5 ever did. That's not actually a bad thing for a small codebase maintained by one programmer, for whom the high cognitive complexity imposed by the language design can be managed by mostly working within their idiolect. But my experience has been that the maintainability of such a codebase decreases as at least the square of the number of people working on it, and that quickly becomes a catastrophe in the sorts of very large codebases, shared among tens or hundreds of engineers, in which I've spent the bulk of the last decade working. That's not a world in which I see Raku being able to survive, and my experience there has led me to value languages and practices that are actively as un-clever as possible - because the cleverer something is, the harder to understand, which becomes a real problem when understanding it is necessary to resolve an outage denying service to millions of users. That's also not a world in which I would expect Raku to try to survive, because it's obvious to me that that's not what Raku is meant for. Nor should it be; that that's not the place for such carefree, freewheeling weirdness for weirdness' sake isn't the same as saying no such place exists. It's just that that's a place I'm glad I don't live any more.
- 2colours 3y ago
  > The apparent variance between list syntax accepted by the reader and emitted by the printer Could you provide an actual example for this? I suspect this is a simple misunderstanding. > 'o' for function composition? Square brackets to reduce over an operator? Square brackets with a backslash to map? I never used 'o' myself but YES, square brackets to reduce over an operator. Indeed, I see nothing wrong with that (okay, I actually do but not with the principle, rather the parsing). And "square brackets with a backslash" is NOT a map, it's a produce. The blog post got it right. > function signatures as first-class values (...what?) Okay, now give me a break... this... is a "what"? Are you real now? A perfectly sensible and useful feature, a "what"? To be able to investigate function signatures and pass them around appropriately without constant hacking, is that bizarre? I guess airplanes are also bizarre to some... So yes, I think what you present here might be the other extreme: rendering anything that might be slightly clever as "weird" or "complicated", even if it clearly reduces the custom tinkering each individual developer would have to do... The situation is a bit touchy because I think your characterization of the Perl mindset living on in Raku as well (C++ is a similar language in a way) is legitimate but it seems to be based on "fortunate" prejudices and stereotypes rather than a good understanding of the situation. You haven't seen the bad parts yet and you apparently called some of the good parts bad. Not sure if it can be helped. I don't think the language will be cleared up anyway but I also wouldn't want to go as "unclever" as you seem to find desirable. Languages like Python and Rust can thrive despite not being completely dumb. Opinionated yes, dumb no. Also, I have been thinking that maybe the way to find industrial use for Raku (or this broader mindset overall) is to outright reject this framing that all projects need to be monolithic. Yes, you may be right that Raku will never be a language where dozens of people work on millions of lines of code together, for decades. What if your services can be broken down into pieces that CAN be managed by a couple of people tightly co-operating? What if these services can be developed and deployed so efficiently that instead of maintaining them for eternity, you can just start anew and replace them cheaply? There is the common wisdom "what one person can't fully comprehend, definitely contains flaws". There is some truth to it for sure, and it does seem like with the rise of microservices, there would be place for software developed in a much more distributed manner. Now, there are practical reasons why Raku didn't catch up, at least not yet - but they are absolutely not language philosophy reasons.

throwanem 3y ago

Where would you like me to start? The apparent variance between list syntax accepted by the reader and emitted by the printer, the brambly thicket of special-case operators and grammars ('o' for function composition? Square brackets to reduce over an operator? Square brackets with a backslash to map? - I remember the "Periodic Table of the Operators", but even by that standard this is wild), function signatures as first-class values (...what?) But honestly, I don't think I can provide actually useful feedback here, because I'm pretty sure nothing I'm doing is similar enough to anything Raku is doing for the conversation to really make sense. Everything I've just described, and much else about the language, strikes me very much as needless complication for the sake of complication, the sort of thing that earned Perl 5 its "write-only language" sobriquet by encouraging, if not necessitating, the development of idiolects among its users - and Raku if anything seems to do much more of this than Perl 5 ever did. That's not actually a bad thing for a small codebase maintained by one programmer, for whom the high cognitive complexity imposed by the language design can be managed by mostly working within their idiolect. But my experience has been that the maintainability of such a codebase decreases as at least the square of the number of people working on it, and that quickly becomes a catastrophe in the sorts of very large codebases, shared among tens or hundreds of engineers, in which I've spent the bulk of the last decade working. That's not a world in which I see Raku being able to survive, and my experience there has led me to value languages and practices that are actively as un-clever as possible - because the cleverer something is, the harder to understand, which becomes a real problem when understanding it is necessary to resolve an outage denying service to millions of users. That's also not a world in which I would expect Raku to try to survive, because it's obvious to me that that's not what Raku is meant for. Nor should it be; that that's not the place for such carefree, freewheeling weirdness for weirdness' sake isn't the same as saying no such place exists. It's just that that's a place I'm glad I don't live any more.

2colours 3y ago
> The apparent variance between list syntax accepted by the reader and emitted by the printer Could you provide an actual example for this? I suspect this is a simple misunderstanding. > 'o' for function composition? Square brackets to reduce over an operator? Square brackets with a backslash to map? I never used 'o' myself but YES, square brackets to reduce over an operator. Indeed, I see nothing wrong with that (okay, I actually do but not with the principle, rather the parsing). And "square brackets with a backslash" is NOT a map, it's a produce. The blog post got it right. > function signatures as first-class values (...what?) Okay, now give me a break... this... is a "what"? Are you real now? A perfectly sensible and useful feature, a "what"? To be able to investigate function signatures and pass them around appropriately without constant hacking, is that bizarre? I guess airplanes are also bizarre to some... So yes, I think what you present here might be the other extreme: rendering anything that might be slightly clever as "weird" or "complicated", even if it clearly reduces the custom tinkering each individual developer would have to do... The situation is a bit touchy because I think your characterization of the Perl mindset living on in Raku as well (C++ is a similar language in a way) is legitimate but it seems to be based on "fortunate" prejudices and stereotypes rather than a good understanding of the situation. You haven't seen the bad parts yet and you apparently called some of the good parts bad. Not sure if it can be helped. I don't think the language will be cleared up anyway but I also wouldn't want to go as "unclever" as you seem to find desirable. Languages like Python and Rust can thrive despite not being completely dumb. Opinionated yes, dumb no. Also, I have been thinking that maybe the way to find industrial use for Raku (or this broader mindset overall) is to outright reject this framing that all projects need to be monolithic. Yes, you may be right that Raku will never be a language where dozens of people work on millions of lines of code together, for decades. What if your services can be broken down into pieces that CAN be managed by a couple of people tightly co-operating? What if these services can be developed and deployed so efficiently that instead of maintaining them for eternity, you can just start anew and replace them cheaply? There is the common wisdom "what one person can't fully comprehend, definitely contains flaws". There is some truth to it for sure, and it does seem like with the rise of microservices, there would be place for software developed in a much more distributed manner. Now, there are practical reasons why Raku didn't catch up, at least not yet - but they are absolutely not language philosophy reasons.