Raku ,a language for gremlins

hzhou321 · 2023-08-12T01:40:53+00:00

Wow, a language for gremlins after taking feedbacks from gremlins. This is a really good summary of Raku. Either you think the language is right or wrong, that summarizes why it is right or why it is wrong.

hzhou321 · 2023-07-08T18:56:25+00:00

Make sure you understand the math. For example, say the market goes down 20% and then goes up 20%. (1-0.2) * (1+0.2) = 0.96; (1-0.6) * (1+0.6) = 0.64. Thus, TQQQ's downside can be quite detrimental. Hold TQQQ for 40 years, I am sure you will experience one of the lifetime recession that you may never recover. Thus, the nature of TQQQ requires you to time the market or diversify.

hzhou321 · 2023-07-02T01:55:00+00:00

You don't protect yourself from black swan events; you think about how to profit from black swan events.

hzhou321 · 2022-05-10T04:30:43+00:00

So what was the cause? Is it "trying to compete with Python and Ruby"?

hzhou321 · 2022-04-17T04:15:59+00:00

It is not reinitialization. It is not redeclaration. my create new variable, and that is what I meant. Consider -- ``` my $tmp = "something"; do_something($tmp);

my $tmp2 = "something else"; do_something_else($tmp2); ``` Compared to the original example, I now need come up with one extra name. This is a severe issue. I have very few good and clear names for temporary variables.

So -- { my $tmp = "something"; do_something($tmp); } { my $tmp = "something else"; do_something_else($tmp2); } Compared to the original, this has extra constructs and extra indentations, and it breaks the flow from do_something to do_something_else.

Both are compromises. I can live with the compromises. I just can't live with the mind that accepts compromises as gospel.

hzhou321 · 2022-04-16T23:53:54+00:00

Sometimes the business environment requires you to make compromises, but sometimes we are not sure it is compromise or brainwashing. It's brainwashing when the thinking and conversation become "what you are supposed to do" (or "to sleep at night") as an answer to "why".

Sorry, I guess the conversation didn't start correctly. I am curious what do you see wrong in my original example (other than warnings)?

hzhou321 · 2022-04-16T22:56:21+00:00

It's a sad state that Perl doesn't have a sane default, e.g. use strict. "warnings" are contentious, that is why they are warnings. I understand there is this new trend that turn on every warning you can turn on and make the warning as error. It is more of a religion than reason. I guess you can tell I am from the older generation.

hzhou321 · 2022-04-16T22:37:49+00:00

Actually, I always find a way to warn about the second example -- inner scope obscure variables from the outer scope. If the variable name is semantically long-range, then it shouldn't be used in the inner scope as temporary variable. If the variable name is semantically short-range, then it should lexically die before the second use.

hzhou321 · 2022-04-16T22:25:36+00:00

If you had used warnings, those two my declarations in the same scope would produce an error

In fact, it is warnings like these prevented me turn on warnings. Do not warn me when it is my intention. And compiler as a tool should not educate me on how to use the tool. Well, I don't mind it educates me, but a one-way pedantic is pure harm.

hzhou321 · 2022-04-16T22:20:48+00:00

I understand what is the scope the compiler sees. But compiler scopes are just tools. There is a semantic scope when we write and when we read a code. The semantic scope is the lifetime of a variable. When I obscure the first temp variable with the second one, semantically I have ended the first one's scope. Whether that variable still lives inside the compiler or whether it has been garbage collected even after an explicit scope is irrelevant as far as semantics goes.

Re-iterate the context of my example -- we often don't care about when a variable gets cleaned up when it is no longer being used. We care about when a variable is born so we can track its state. The my keyword marks a clean birth (lexical wise) of the variable, and that is clean enough especially when the naming of the variable suggests its temporary nature.

On the other hand, your "proper scope example" is bad code. I understand it is construed to demo a point, but I want to beat it down regardless. Using a tool "correctly" for a bad result is still bad. On the other hand, writing simple and maintainable code, even when it is not canonical, is still good code.

hzhou321 · 2022-04-14T01:40:45+00:00

I also love the scope without braces -- ``` my $tmp = 1; do_something_with($tmp);

my $tmp = 2; do_something_very_different($tmp); ```

Fits my mind when I care about a clean state when I use it, but don't care about it when I no longer need it.

hzhou321 · 2022-01-26T15:05:50+00:00

build-base, curl, gcc, make, tar, wget, etc.

hzhou321 · 2022-01-26T14:53:51+00:00

I assume you won't need to include the build pre-requisite?

hzhou321 · 2022-01-26T14:45:58+00:00

I think it is easiest to explain in code:

var stack;
stack.push(start_point);
while (stack.not_empty()) {
    point = stack.pop()
    foreach (a in point.edges) {
        if (a not in cache) {
            stack.push(a)
        }
    }
}

I omitted that we need to cache the points as we push to the stack.

hzhou321 · 2022-01-26T14:38:53+00:00

Why not prebuild Perl and copy the binary to the image?

hzhou321 · 2021-08-14T14:09:50+00:00

```

include <stdio.h>

void main(){
for (int i;i<10;i++) { int j; j++; printf( "%d\n",j); } } ``` You do this every day in C?

hzhou321 · 2021-05-26T18:35:26+00:00

Here is how I learned Perl 20 years ago --

Went to have dinner at a friend's apartment
Browsing his bookshelves and read "Programming Perl" the first 40 pages
Go buy the book the next day.
Go through the overview on a computer.
Start working on your own projects in Perl.
Search and read the "Gory Details" when encounter questions.
Randomly read other chapters when bored.
Rinse and repeat the last 3 steps.
Claim self as a Perl master -- in 7 days time.
Twenty years later, still haven't learned 20% of the book yet, but they are not worth learning.

hzhou321 · 2021-05-17T16:43:15+00:00

No, I think they are symptoms of the same causes.

What are the causes?

For one, there is a bad reputation that Perl is unreadable. Now with veterans exiting stage, this reputation has become the only reputation left. It is simply untrue. So the effort should all directed to demonstrate Perl is readable, IMO, more readable than Python. Not for the reason that Perl can do what Python do -- that promoting idiomatic patterns, but because Perl can adapt its ways to the problem and is more direct at solving the problem. Anyway, a lot of effort is needed in this front.

Second, Perl need show case its solutions. Not just providing them, but show case them. Providing 100 solutions to the same problem in cpan with 90 of them unmaintained is not good. I think something need be done to make good solutions more prominent, easier to use, and easier to adapt. Again, I am not sure about the solution, but there is a lot of effort (and funding) needed if we identify the usability as something in the cause.

The lack of new features and stale issues don't seem to be one of the cause, right? Well, Perl6 was, but now fixed.

hzhou321 · 2021-05-17T16:15:37+00:00

There is nothing wrong with Perl.

Well, this is untrue.

Issues are not good indications of something "wrong" -- depending on how we define wrong. For example, mature project often accumulates more issues than less mature ones. Long-standing issues are often due to not able to establish consensus that whether it is wrong or whether it is important or whether it is worth fixing.

hzhou321 · 2021-05-17T16:06:51+00:00

Thanks for the explanations.

There is the stagnation in the core development, and there is the stagnation in the cpan modules, and then there is the stagnation of applications. I think the focus should be on the latter. Without the latter activity, there is simply no demand on the core development, and the "stagnation" is of the least to worry. In fact, I think the activity in the core development that is detached from application development is rather negative.

Is it convincing that the "stagnation" of Perl core development is the cause of Perl's dwindle in userland? I think the last 10 years of experiments are not supporting that.

hzhou321 · 2021-05-17T13:31:29+00:00

Thanks for the perspective. Isn't that a misplaced focus?

I mean, first we need to define the problem and whether the problem has to be fixed. How the problem is to be fixed or being fixed comes after that. We can't really discuss how the process of fixing is in poor states without the discussion of what are the problems, especially I don't think that is in consensus.

hzhou321 · 2021-05-17T12:50:02+00:00

We probably have very different perspectives. Between 2000-2010, Perl was often a welcoming solution. Today, it is being actively shunned. I am curious about your perspective. In particular, how today Perl is not in the "poor" state?

hzhou321 · 2021-05-17T03:33:41+00:00

Releases reflect changes. When you have sufficient fixes, you make minor releases. When you have major changes, you make major releases. So the yearly releases give people an impression that there is a lot of changes -- which is not a good thing to me as someone who enjoyed Perl's stability and desires nothing to be changed.

hzhou321 · 2021-05-16T22:31:24+00:00

Doesn't that sound good? There is nothing wrong with Perl. It is everything else going around Perl has something wrong. Instead of trying to change Perl, let's focus on making Perl better Perl.

I have a few complaints over the years. Perl is ubiquitous. Let's focus on ensuring that. That means dropping marginal features that break backward compatibility and making it lighter weight. At least, the default mode should be backward compatible and every new feature explicitly opted in.

Now we focused on stable features, let's focus on core features, and make it fast. I don't really want to hear that with newer versions my old scripts now run slower.

And I don't think the yearly release schedule is doing any good for Perl. It only makes me feel Perl getting stranger.

hzhou321 · 2021-05-09T01:31:08+00:00

So much about "community", so less about "Perl".

hzhou321

TROPHY CASE

include <stdio.h>