💾 Archived View for blog.schmidhuberj.de › 2022 › 02 › 10 › scripting-languages captured on 2024-05-10 at 10:44:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
Posted on 2022-02-10
This post is very opinionated. Note that this is my opinion only, do not generalize this. Furthermore, I am not trying to hate on any of the below mentioned languages, I just want to show the problems some scripting languages have.
A month or so ago, I read some gemini post (sorry, I cannot find who it was or what post it was) and he mentioned he wanted to learn the pretty new scripting language Raku this year. I noticed that I currently do not have any scripting language in my portfolio, so I wanted to learn one too, and I chose Raku, previously called Perl6 (on paper, I know how to write python, but I really dislike that language).
But the process was not as smooth as I hoped it would be. Below are some of the issues I found frustrating.
The first resource when learning Raku is probably the guide. The guide is pretty good, but it already shows some problems.
The guide contains one sentence in the Identifiers-Section that really bothers me:
You are free to name your identifiers as you like, but it is good practice to adopt one naming convention consistently.
Having no naming conventions is a really big no-no for me, there are just some rules that are needed to make the program compile. Having no naming convention means different naming conventions in different projects, and if you use different projects as dependencies in your project, the naming conventions will probably clash, making a giant mess.
Supporting Unicode in character sequences in the modern days is a must have for every programming language, but Raku does something really weird: It allows Unicode as code. You heard me right, you can for example use ≤ instead of <=.
This is (in my opinion) obviously bad. Some editors might support directly inputting these characters or replacing the normal syntax with Unicode, but most editors probably will not, making it difficult for persons to cooperate on projects with such conventions.
Another funny thing is, Raku accepts roman numerals and rations as numbers, for example
my $var = ⅒ + 2 + Ⅻ;
is valid Raku-Syntax, producing 14.1.
Having named arguments is great, I must confess. But having (at least) three different is a little overkill. All of the below code is value Raku-Syntax doing the exact same things:
foo(bar => 1); foo(:bar(1)); foo(:1bar);
I have also used some calls like
foo: 1;
but I cannot seem to reproduce it. There are some more examples of redundant syntax, but I think you get the point I am trying to make.
I must admit, this is probably a feature for most scripting languages. I think I am just a little bit spoiled of a compiler complaining about everything that is probably wrong.
I did not think I would ever complain about the speed of a programming language. I was always in the group "performance does not matter, modern processors are fast enough", but damn is is slow. A little one-liner printing out "Hello World" takes over 200ms. That might not seem much, but it is a huge difference compared to compiled languages, that are so fast even the time-program cannot time them.
Just one more comparison, I made a tui-interface for recursive grep-ing in Raku. Normally grep-ing takes about 10ms, my program (without the tui-interface) takes about 1.5 seconds (yes, there are some more things I am doing in my script, but it does not explain the huge difference).
The promising part is, that the language seemed to already have sped up by a magnitude of 3, with this seeming to be a important issue on their road plan.
Source for above mentioned claim.
This post speaks very openly about the bad things in Raku. But not everything is as bad as it sounds (as humans are probably more inclined to talk about negative experiences). Some good things for example are easy regex and simple I/O. And I must say, above written text probably is a little bit exaggerated. I will likely continue to use Raku if I want to throw together a little program in the future, even if there are many problems left.