The Raku Programming Language

pie_flavor

It should be noted that this ability to monkey-patch the language is used in things like Inline::Perl5 and Inline::Python, which let you load Perl 5 and Python modules directly without a compatibility layer. It just monkey-patches the language into one that parses Perl 5 or Python, and then executes the code directly in the interpreter. This means that it is the ultimate programming language, since you could not only write a parser for any other language in Raku, but could compile it with Rakudo too.

boomzilla

@pie_flavor said in The Raku Programming Language:

More on that: The * in $*TOLERANCE means that scoping follows the call stack, not the code outside the function.
sub foo { $^a =~= $^b }
sub bar {
    my $*TOLERANCE = 1;
    say so foo(1, 1.1); # true
}
If it were just $TOLERANCE, then the redefinition would not be in scope for foo. However, because of the *, it is.
my $foo = 1;
my $*bar = 1;
sub foo { $foo }
sub bar { $*bar }
sub baz {
    my $foo = 2;
    my $*bar = 2;
    say foo ~ ｢ ≠ ｣ ~ bar;
}
baz prints 1 ≠ 2.

Ouch. I had to stare at that a bit but now I have a headache.

pie_flavor

@pie_flavor said in The Raku Programming Language:

you can monkeypatch classes and objects with new variables.

oh, and you can do this too, just thought the other thing was more significant. Raku has, by the way, the best syntax for this I've ever seen: <value> but <class or role to add>. e.g. my Int $i = 1 but role :: { method defined { False } };

HardwareGeek

@dkf said in The Raku Programming Language:

@topspin said in The Raku Programming Language:

Is that global or thread-local?

This is Perl-ish so yes. Perl gets… strange there and Raku's probably inherited that.

Raku: All of Perl's strangeness ... and a lot more!

cvi

@topspin said in The Raku Programming Language:

Can't say I think that's a good idea.

Not to mention that an absolute error is a bit of a sketchy default if you don't know what regime of numbers you're working with. The difference between two consecutive doubles is larger than 1e-15 for numbers of magnitude 8 (yes, eight) and larger.

admiral_p

As a layman, I'll just chime in and say that I don't think there is a point in a language if it isn't its own thing in some way. If you wanted a language to be more like another language, just use that language already. After all, languages are free (today). And there is no shortage of "languages that are commonly considered to be good" (off the top of my head, Rust, C#, at least one of those fancy functional languages, maybe Python?).

dfdub

@admiral_p said in The Raku Programming Language:

maybe Python

Paging @dkf.

Benjamin Hall

@admiral_p said in The Raku Programming Language:

at least one of those fancy functional languages, maybe Python?).

This is probably not what you intended, but the juxtaposition here made me think that you thought Python was a "fancy functional language." Which made me for a second there.

topspin

@cvi said in The Raku Programming Language:

@topspin said in The Raku Programming Language:

Can't say I think that's a good idea.

Not to mention that an absolute error is a bit of a sketchy default if you don't know what regime of numbers you're working with. The difference between two consecutive doubles is larger than 1e-15 for numbers of magnitude 8 (yes, eight) and larger.

He said relative difference, though.

cvi

@topspin Apparently I need to read better.

Applied Mediocrity

@admiral_p As not quite layman, I'll just chime in and say I don't think there is a point in majority of languages, you can stop now, we have quite enough, TYVM. They're mostly products of people with specific bikeshedding tendencies. It's not entirely wrong to obsess over stuff like that, but other than that it's "could before should" sort of thing. Like shitty fanfiction, none of that monkeytypewriting should have ever been published.

Majority of them are a mess of arcane incantations, with tokens and way statements are written, the selection of keywords just changing places: type before name or after, array specifier before or after, auto or var, func or def, if endif or brackets, significant whitespace or not, statement terminated by newline or semicolon, string quoting with that symbol or another. And languages like Basic are neither friendly nor basic, they're just retarded. And languages like this Рак here are just painful to even contemplate.

World's spoken languages are quite different. Is anyone saying that one or another language has been an impediment or advantage to development and realization of things? I bet someone does. And they're full of shit. Any language put in isolation is so far removed from practical considerations that any number one may squeeze out of their ass is equally meaningless.

Regarding "its own thing" - how many different ways do you want to tell computer to add numbers together or something? In how many sufficiently different, but still useful ways you could possibly do it? Is Shakespeare better in Polish or Swahili or 普通話?

For me language alone itself means not quite but close to fuck all. It's the ecosystem that comes with it. How wieldy it is to use, how mature it is, how good are the docs, how good is string handling, how complete, reliable and up-to-date it is, are lights on, is anyone at the wheel. There are about ten languages that even qualify, pick yours and run with it. For extra trollery I might add that none of them are functional. Fucktional paradigm is garbage that neither general purpose computers nor general purpose humans readily talk, all academic gasbags can go back to their academies and assume ideal gas.

Signed, Catus Ignoramus.

admiral_p

@Applied-Mediocrity still, that doesn't stop people from trying. Just like all creative output, the vast majority is utter shit after all. Just like all creative people, most people are utterly clueless and also utterly clueless about being so. And even those who get it maybe get it once only (or maybe only appear to get it), or for a short amount of time before they become full of shit.

pie_flavor

@Applied-Mediocrity If you think that, you've never used Rust.

dfdub

@Applied-Mediocrity said in The Raku Programming Language:

As not quite layman, I'll just chime in and say I don't think there is a point in majority of languages, you can stop now, we have quite enough, TYVM.

That's a bad idea, especially since programming languages are so fundamental to the work we do. There have been advances in language design and compiler technology in the meantime and many popular languages are basically decades behind the state of the art. So why on earth shouldn't we try to take advantage of that to make it easier to write correct software?

Also, DSLs are never going to be unnecessary.

dkf

@dfdub said in The Raku Programming Language:

@admiral_p said in The Raku Programming Language:

maybe Python

Paging @dkf.

Python has a nice surface, but is absolutely shit underneath. The shit surfaces once you want to do anything more complex than writing simple classes.

boomzilla

@Applied-Mediocrity said in The Raku Programming Language:

I'll just chime in and say I don't think there is a point in majority of languages, you can stop now, we have quite enough, TYVM.

Here, you sound like you've earned this:

Applied Mediocrity

@dfdub said in The Raku Programming Language:

programming languages are so fundamental to the work we do

A programming language - implements ILanguage - not any particular language. Just like some sort of written language is fundamental to writing forum posts, but it doesn't quite matter which as long as others can read it. We can even switch between several, mostly to annoy people.

General program logic is largely portable the same way literary works are translated - it takes a professional eloquent in both, but it's entirely doable, if both languages can convey the ideas (for example, async). What matters is the environment (hardware constraints such as memory or input methods, operating system, if any) and complimentary libraries / class libraries / other work done for us by third parties (npm, nuget, pip, crates).

many popular languages are basically decades behind the state of the art

I would like to see some examples of state of the art, please. I cannot guarantee I will be able to understand them, of course, but it doesn't do harm to try.

But there are reasons state of the art is not being adopted, and it's not just the cost of re-training. Were it not for multitude of nasal demons and best practices that only come with experience, most languages in isolation (read and written in your favorite text editor) can be picked up in at most a week of not kneeling. Learning new tool chains and build processes, ensuring feature parity, and, most of all, ensuring interoperability with the existing code baggage, however, is what usually outweighs the advantages, if any.

take advantage of that to make it easier to write ... software

I would like to see the magic that enables me to avoid designing DTOs and APIs, performing validation, writing event handlers and handling errors. On second thought, no. I might be out of work if that happens in my lifetime.

These are just a few countable pillars of most complete programs. The rest is not (or at least should not be) in the requirements of the software project. Instead they are artifacts and boilerplate for compatibility, target platform (web), interfaces (event-driven GUI), chosen methodologies and patterns (OOP).

write correct software

Well, it clearly isn't happening. Software correctness is not so much a property of language as it is that of the process, enabled by strong discipline, unambiguous requirements, proper planning, independent reviews and acceptance testing that avoids bikeshedding at least until the logic itself is correct.

That it is has turned out not to be economically viable is the problem of the market. The market increasingly tolerates incorrect software and data garbage, so there is no incentive to bother.

The incentive to create new languages (just like new frameworks, sometimes with their own metalanguages), however, is clear: to have to write the same things over and over again until they reach parity with those already existing, haha money printer go brrr.

DSLs are never going to be unnecessary

DSLs are in large part orthogonal to the problem I'm raging about.

@pie_flavor said in The Raku Programming Language:

If you think that, you've never used Rust.

It does not follow. Also, Rust actually makes the cut.

I wonder why you feel attacked by my ragepost, though. If I didn't know you were total fucking Joseph Seed about our lord and savior Rust, I'd ascribe it to some guilty conscience.

Applied Mediocrity

@boomzilla said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

I'll just chime in and say I don't think there is a point in majority of languages, you can stop now, we have quite enough, TYVM.

Here, you sound like you've earned this:

It would be an honor, but I don't believe I have. At low thirties, I'm not an "old fuck", just the sort of a tired "old fart" always going "nyah-nyah-nyah". And not very smart one either. One can be like that at almost any age...

dkf

@Applied-Mediocrity said in The Raku Programming Language:

A programming language - implements ILanguage - not any particular language. Just like some sort of written language is fundamental to writing forum posts, but it doesn't quite matter which as long as others can read it. We can even switch between several, mostly to annoy people.
General program logic is largely portable the same way literary works are translated - it takes a professional eloquent in both, but it's entirely doable, if both languages can convey the ideas (for example, async). What matters is the environment (hardware constraints such as memory or input methods, operating system, if any) and complimentary libraries / class libraries / other work done for us by third parties (npm, nuget, pip, crates).

The complexity arises when the two languages have fundamental differences in the semantics supported. A classic example is the difference between a language mutable values and a language with immutable values; putting them in the same runtime without great care runs into problems with either massive inefficiency or values mysteriously going wonky at a distance when that's assumed to never happen. This makes doing mapping between the two really tricky, and something that's currently best left to people.

Applied Mediocrity

@dkf You're right about that. I thought I had foreseen that in the "both languages can convey the ideas" clause, but it's rather muddy babbling borne of partial ignorance. Perhaps I should have said "the same concepts". Or rather, belonging to the same semantic level.

But that's just one half of it, the direct sort. Suppose one is having a function that draws a primitive on screen passing the relevant parameters by pointer to a pointer to an object, but the other language doesn't quite support that. The logic part is to draw the primitive. How the other language manages to fake pointer indirection and screen buffer is implementation detail.

Let me put it this way. Couldn't you possibly port the code you're presently working on at WTF-U to any Turing-complete language? Such as, just for the sake of argument, PHP. Whoa, hold on, let me explain. It would not fly at all, it would be less than useless effort. First, PHP is not a systems language, the PHP interpreter sits two levels above raw C. But for the purposes of the point I want to make it only has to be able to describe the same logic. Effectively you'd have to first write a type 2 hypervisor, an emulator of your custom hardware.

Then suppose there's code that measures time taken by some operation Q and branches into A or B depending on the outcome. Because of inefficiencies the ported code may never hit the A path, but it doesn't have to. The only thing I need is to prove, using static analysis or simple deduction, that it could.

Is it possible? I don't see why not. Is it the language that prevents anyone from doing it? It's anything but. Should things like that be done? Bloody hell, no, we already got Windows 95 written in Javascript and such.

Some languages are more suitable for certain tasks than others. Is any area presently badly covered? I don't think so. You folks tell me. I mean, it would be nice not having to ever deal with nasal demons of C and C++ when writing close to metal code (yes, yes, I hear you... amazing Rust - tra-la-la - that saved a wretch like me), demons from other orifices when dealing with websites and Rube Goldberg's kitchen sink when dealing with GUI in general. Those are certainly noble goals. But a new language alone can do very little. If its ecosystem has not achieved parity with those already existing, I will have to do so much more work to implement common functionality that I'll lose the sight of what I'm actually doing. Look, Go didn't quite take off even with Google behind it...

... eh, you know, fuck it, I'm not good at this.

Gąska

@Applied-Mediocrity said in The Raku Programming Language:

World's spoken languages are quite different. Is anyone saying that one or another language has been an impediment or advantage to development and realization of things?

There's an entire chapter of the Bible dedicated to that

Applied Mediocrity

@Gąska said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

World's spoken languages are quite different. Is anyone saying that one or another language has been an impediment or advantage to development and realization of things?

There's an entire chapter of the Bible dedicated to that

Egad! Let's stack a bunch of crates and build the tower again.

Gąska

@Applied-Mediocrity said in The Raku Programming Language:

But there are reasons state of the art is not being adopted, and it's not just the cost of re-training.

Actually, it is just the cost of re-training. People strongly opposed OOP too at one point. And before lambdas became ubiquitous, people ignored them as completely useless. Async/await also spent most of its time as only an academic curiosity. Hell, to this day some people argue that scoped resources are stupid. Literally the only reason people refuse(d) to use these features was lack of training.

Basically every idea that's so obviously good that most programmers can't imagine not wanting them, has been initially rejected by nearly everyone. Also, a significant part of your posts is about Rust being one of the few exceptions from the general rule of new language being completely unnecessary and new ideas belong in academia and not real world programming. Are you aware that Rust was released just 5 years ago, and its revolutionary borrow checking algorithm was first conceived in the mid-90s?

Applied Mediocrity

@Gąska said in The Raku Programming Language:

Are you aware

Less aware than you and other folks more closely invested in the topic. I thought it was some 10 years (even though I first heard of it only when I switched professions myself, about 3 years ago). I'm presently very mildly curious how far Rust will actually go in the utterly fragmented industry. It wouldn't be the first time something believed to be good and enabling safe(r) practices is later scattered into the wind. Like Pascal and its Delphi dialect, for example.

Gąska

@Applied-Mediocrity I haven't written any Pascal or Delphi, but some light googling indicates that while they were somewhat safer than C and C++, they're not even close to Java in this regard. They don't even have garbage collection! So it's actually just another example of newer, safer languages replacing the old.

Mason_Wheeler

@Gąska What does garbage collection have to do with safety?

Gąska

@Mason_Wheeler it prevents memory leaks. It also avoids the problem of double freeing by not having the dev free memory even once.

inb4 pedantry about corner cases when GC can't prevent memory leaks

Applied Mediocrity

@Mason_Wheeler said in The Raku Programming Language:

@Gąska What does garbage collection have to do with safety?

If garbage collection had anything to do with safety, Java programs would delete themselves upon their first launch

Mason_Wheeler

@Gąska GC doesn't prevent memory leaks, it standardizes them.

Gąska

@Mason_Wheeler semantics. The point is, your program doesn't OOM and that makes it safer.

pie_flavor

@Applied-Mediocrity said in The Raku Programming Language:

close to metal code

This, it should be noted, is entirely bullshit.
https://queue.acm.org/detail.cfm?id=3212479

Applied Mediocrity

@pie_flavor said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

close to metal code

This, it should be noted, is entirely bullshit.
https://queue.acm.org/detail.cfm?id=3212479

Here, you forgot this -

Though TFA sounds more like a babblepost about x86-64 being a sort of concrete shoes than C not being low-enough level.

The entire point of programming languages is to abstract away some parts of the machine, trading away direct control for a more general approach, goddammit.

Can C programs run directly on hardware? Then it's a low-level language. Is there any lower level between C and pure assembly? Then it's a low-level language.

But then there would be this mysterious architecture where C is inadequate. Massively parallel requires a different approach, you say? No shit, cap'n! Academics do have a penchant of putting in 1000 words what could have been said in 10.

So, unless you're prepared to hammer assembly yourself (and sometimes one may have to, hence __asm__), it's as close to metal as you can get with an actual language (viz., one that does not just rename opcodes to a bunch of mnemonics).

topspin

@pie_flavor said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

close to metal code

This, it should be noted, is entirely bullshit.
https://queue.acm.org/detail.cfm?id=3212479

The same argument can be made for assembly, though. And saying that assembly is not "close to the metal" is certainly weird.
That the processor goes to crazy contortions to keep the appearance of sequential execution to make C programs happy is of course a correct observation.

PleegWat

@pie_flavor said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

close to metal code

This, it should be noted, is entirely bullshit.

C Is Not a Low-level Language - ACM Queue

I would suggest that perhaps low-level-ness is not a binary property.

pie_flavor

@Applied-Mediocrity I should note that I do not endorse the article's title, and think C is a low-level language. But it is not bare-metal because what it is doing and what the metal is doing are barely correlated.

bobjanova

@Gąska said in The Raku Programming Language:

They don't even have garbage collection!

Delphi actually did (at least effectively) have GC for almost everything you wanted to do. Its cover library over Windows Forms was great (indeed, most of its ideas got pinched for .Net) and hid all the low level crap nicely. (Some other things about the language, e.g. property declarations, got taken into C# as well.)

You could do low level pointer based things if you needed to, though it was (deliberately) less easy and transparent than in C.

Delphi was great, honestly, miles ahead of anything else at that time.

dfdub

@Gąska said in The Raku Programming Language:

The point is, your program doesn't OOM and that makes it safer.

Also not quite correct. You can still create memory leaks in garbage-collected languages if you keep references alive that you shouldn't. GC only helps you a little bit, it doesn't make thinking about memory management unnecessary. Way too many developers assume it does.

topspin

@dfdub said in The Raku Programming Language:

You can still create memory leaks in garbage-collected languages if you keep references alive that you shouldn't.

There is no magic that could possibly prevent this.

Watson

@Applied-Mediocrity said in The Raku Programming Language:

Academics do have a penchant of putting in 1000 words what could have been said in 10.

Minimum Publishable Units. If they have something to say, they break it down into MPUs and write a paper for each one. Because if you're not getting papers published why are we keeping you on again?

bobjanova

@dfdub said in The Raku Programming Language:

You can still create memory leaks in garbage-collected languages if you keep references alive that you shouldn't.

Can confirm, we had a serious memory problem related to keeping references as keys in a map that didn't get cleared. Event handlers are another classic way of accidentally keeping a reference to an object you don't use any more.

A good GC language will give you to the tools to not screw this up (weak references), but the developer still has to remember when to use them.

Mason_Wheeler

@PleegWat said in The Raku Programming Language:

@pie_flavor said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

close to metal code

This, it should be noted, is entirely bullshit.
https://queue.acm.org/detail.cfm?id=3212479

I would suggest that perhaps low-level-ness is not a binary property.

How times have changed! When I was a kid first reading about programming languages, C was considered a high-level language because it came with such luxuries built-in as a type system, a memory manager, and a call stack. If you wanted such things in low-level programming, you had to implement them yourself!

Applied Mediocrity

@Mason_Wheeler said in The Raku Programming Language:

How times have changed! When I was a kid ... C was considered a high-level language

Here, take the which awarded me upthread.

topspin

@Applied-Mediocrity said in The Raku Programming Language:

@Mason_Wheeler said in The Raku Programming Language:

How times have changed! When I was a kid ... C was considered a high-level language

Here, take the which awarded me upthread.

Hey, those are personalized and non-transferable!

Applied Mediocrity

@topspin said in The Raku Programming Language:

Hey, those are ~~personalized and non-transferable!~~ static thread_local constexpr!

boomzilla

@Gąska said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

But there are reasons state of the art is not being adopted, and it's not just the cost of re-training.

Actually, it is just the cost of re-training. People strongly opposed OOP too at one point. And before lambdas became ubiquitous, people ignored them as completely useless. Async/await also spent most of its time as only an academic curiosity. Hell, to this day some people argue that scoped resources are stupid. Literally the only reason people refuse(d) to use these features was lack of training.

Basically every idea that's so obviously good that most programmers can't imagine not wanting them, has been initially rejected by nearly everyone. Also, a significant part of your posts is about Rust being one of the few exceptions from the general rule of new language being completely unnecessary and new ideas belong in academia and not real world programming. Are you aware that Rust was released just 5 years ago, and its revolutionary borrow checking algorithm was first conceived in the mid-90s?

https://wiki.c2.com/?BlubParadox

topspin

@boomzilla said in The Raku Programming Language:

https://wiki.c2.com/?BlubParadox

Ah, so it's "Blub" and not some variation of "Foo". That was the name I was looking for.

@topspin said in The Raku Programming Language:

What was the name again of that hypothetical programming language ...

So either 1) nobody understood what I meant, 2) nobody read it in the first place, 3) you're all too to answer.

Gąska

@topspin 4) I knew what you meant but didn't remember the name either.

5‍) I was so distracted with broken raw string that I didn't read the rest of your post

error

@pie_flavor said in The Raku Programming Language:

@Applied-Mediocrity said in The Raku Programming Language:

close to metal code

This, it should be noted, is entirely bullshit.
https://queue.acm.org/detail.cfm?id=3212479

So what would a modern close-to-metal language actually look like?

The article seems to suggest it would look more like GPU code.

topspin

@Gąska I didn't know you're @Tsaukpaetra and I can break your parser with one mistake.

Gąska

@topspin it's more about having attention span of a troll.