The problem is those are subjective axes. And things can both delight and horrify; I wrote some javascript once where I did document.write = function ... which is kind of delightful in that I was able to do what I needed as a result, but also pretty horrifying :)
Other people I showed it to felt it was more on the horrifying side, but like I said, it's subjective.
I think that this is the crux of the story for raku ... if you want you language to apply a standard discipline, then use Python: if you are happy with your team developing a dialect that balances usability with discipline, then try Raku
if you want you language to apply a standard discipline, then use Python
Wow, I hear this stuff all the time about Python. It is a myth. I have worked on multiple 500K+ line Python projects. All of them decay into a total mess due to weak typing. You can type hint until you are blue in the face, but it is never enough if it isn't guaranteed by a compiler or at runtime. So many times, I am 29-levels deep in a call stack, looking at a local variable that is incorrect typed, thinking to myself: "Oh fuck, this again." Yes, I will get 8,000 downvotes for that comment, but it does not detract from my personal experience. It takes super human talent to fight that trend. Have you seen what Dropbox did with that Finnish dude who got a PhD literally studying how to make Python more type safe with static analysis? Jesus fuckin' Christ: Amazing work, but it would be much easier to pick a different language for something that will grow to millions of lines of code! And, sadly, I write that sentence as an unashamed Python fan-boi. I truly wish there was some kind of "strict-er typed" Python mode -- or something.
> I have worked on multiple 500K+ line Python projects.
There were already several 1M+ Perl LoC code bases by the end of the 1990s, as Perl use exploded at places like Amazon.
One key driver of Raku's design was making it easy to write large, clean, readable code bases, and easy to enforce coding policies if and when a dev team leader chose to.
(Of course, as with any PL, you can write messy unreadable code -- and you can even write articles and record videos that make it seem like a given PL is only for Gremlins. But it's so easy to write clean readable code, why wouldn't you do that instead?)
> type hint ... is never enough if it isn't guaranteed by a compiler or at runtime
Indeed. Type hints are a band aid.
Raku doesn't do hints. Raku does static first gradual typing.[1]
The "static first" means static typing is the foundation.
The "gradual typing" means you don't have to explicitly specify types, but if you do types, they're always enforced.
Enforcement is at compile time if the compiler's static analysis is good enough, and otherwise at run time at the latest.
For example, in the Gremlins article only one example uses a static type (`Int`). But user code can and routinely does include types, and they are enforced. For example:
sub double(Int $x) { $x * 2 }
double '42'
results in a compile time error:
SORRY! Error while compiling ...
Calling double(Str) will never work with declared signature (Int $x)
(Int $x)
> total mess due to weak typing
I know what you mean, but to be usefully pedantic, the CS meaning of "weak typing" can be fully consistent with excellent typing discipline. Let me demonstrate with Raku:
sub date-range(Date $from, Date $to) { $from..$to }
The subroutine (function) declaration is strongly typed. So this code...
say date-range '2000-01-01', '2023-08-21';
...fails at compile time.
But it passes and works at run time if the function declaration is changed to:
sub date-range(Date() $from, Date() $to) { $from..$to }
(I've changed the type constraints from `Date` to `Date()`.)
The changed declaration works because I've changed the function to be weakly typed, and the `Date` type happens to declare an ISO 8601 date string format coercion.
But what if you wanted to insist that the argument is of a particular type, not one that just so happens to have a `Date` coercion? You can tighten things up...
sub date-range(Date(Str) $from, Date(Str) $to) { $from..$to }
...and now the argument has to already be a `Date` (or sub-class thereof), or, if not, a `Str` (Raku's standard boxed string type), or sub-class thereof, that successfully coerces according to `Date`'s ISO 8601 coercion for `Str`s.
And to finish that last bit, if an argument of a call is not a `Date` or `Str`:
* The compiler may reject the code at compile time for failing to type check; and, if it doesn't:
* The compiler will reject the code at run time for failing to type check unless it's either a `Date`, or a `Str` that successfully coerces to a `Date`.
Context is critical. Unless you're a beginner with the language, surprise in a production codebase is horrifying. The Perl philosophy has never been compatible with lack of surprise. Perl wants to be like natural language, and natural language has limitless surprises.
The problem with Perl (or, I assume, Raku) in production is that the responsible way to read it is like reading every single footnote in an annotated edition of Shakespeare. It sucks the joy out of it, and joy is the point. Production Perl is joyless and therefore pointless, unless you're some kind of prodigy who understands every obscure political reference and every 16th century pun without any help.
I don't think those are orthgonal though. For example, if a language lacks expressiveness, that can hinder its readability. But on the flip side, if it is highly expressive that can also potentially hurt readibility, especially if the reader isn't very familiar with the language. Although both are somewhat subjective (readability moreso than expressiveness), and context specific.
Exactly, they don't need to be orthogonal in my opinion. Every language should strive to be in the top right quadrant.
Keep in mind, this is just what I value in a language. The perfect programming language to me is one that is expressive while also being easy to read. I think Python is nice in that regard, and probably why it's so popular to this day. But there's always room for improvement!
I was a professional perl5 developer for years and when working through https://doc.rust-lang.org/book/, kept remarking to myself how similar the languages are, in terms of expressiveness, complexity, and implied developer disciplines.
Rust feels like an industrial version of Perl to me.
In this chart, sure. Not like, the same dot, but both in that quadrant. But those are my personal opinions, as I find both difficult to read yet very expressive. YMMV.
Having never written anything in Rust but read and “translated” some code (maybe 3k LOC?) from Rust to Ada, I can tell that I found Rust rather hard to read and harder than e.g. Ruby (which I also do not know how to write but translated to Java once).
Here is what I guess makes it hard to read for me: There are many terse keywords (fn, mut) and symbols (&, [], ->) along with some things that look like Java annotations and are equally hard to understand without knowing the language. Array slices look easy enough to understand [a..b] but surprise: b is actually exclusive? The definition of arrays is the most weird one I have ever encountered [u8; n]. To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :)
The documentation about language and libraries was solid for my cases and most of the time it seemed enough to ignore most of the tiny key words and symbols without losing much understanding of what the code intends to do. If I were given the choice I'd probably still prefer Rust's weird syntax with added safety over the clarity of C which offers no safety at all (not talking about obfuscated code contests here).
> To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :)
But would you put C++ next to Perl in terms of difficulty reading? I wouldn't have thought they were particularly close. (In terms of normal code at least, not the implementations of ultra-generic templates.)
The difficulty of reading Perl is probably overclaimed and overrepresented. Let's not forget that we are comparing a pretty darn low-level language to a fairly high-level one.
And regarding design principles, I think the comparison is clearly on point. These are languages where the motto is basically "if you can't do it (if you can do it but it's perceived too long that also counts) then the language needs to be horizontally extended to account for this use case".
My vague impression was that Rust is still a (significant) simplification over C++. (Ada is a funny case because it seems to be deliberately designed to be hard to read and hard to write, overall a pain in the arse, in the spirit of "if you never reach flow, you will always be very focused", I guess.)
Some of the dewrapping constructs can get a bit gnarly looking when there is something wrapped in a wrapper in a wrapper sort of thing. But it's probably largely author-dependant and you could write the same code more readably.
Other people I showed it to felt it was more on the horrifying side, but like I said, it's subjective.