This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html Set by lizmat on 8 June 2022. |
|||
CodeTortoise | Yeah, Raku has a lot going on. Sort of reminds me of Wolfram, in the sense that it is capable of returning precise results formatted well without too much fussing about, except it lacks the massive database to be able to compute whatever one throws at it. | 00:02 | |
00:52
jgaz left
01:17
NemokoschKiwi joined
01:50
NemokoschKiwi left
05:39
Kaipei joined
05:45
Kaipei left
09:11
lizmat_ left,
lizmat joined
09:41
Kaipei joined
11:05
Kaipei is now known as Kaiepi
13:36
jgaz joined
14:30
jgaz left,
jgaz joined
16:34
CodeTortoise joined
16:43
CodeTortoise left
17:26
jgaz left
17:59
jgaz joined
19:03
CodeTortoise joined
19:14
CodeTortoise left
21:03
CodeTortoise joined
21:04
CodeTortoise left
|
|||
p6steve | CodeTortoise: i have been into perl6 / raku for some years and still see pleasant surprises ... you are probably more knowledgeable about coding generally than I was, but I really enjoyed going fast through Think Raku (greenteapress.com/wp/think-perl-6/) in conjunction with the Tutorials in the docs (docs.raku.org/language.html#Tutorials) | 21:06 | |
21:34
NemokoschKiwi joined
21:38
NemokoschKiwi left
21:51
Manifest0 joined
23:06
CodeTortoise joined
|
|||
CodeTortoise | Thank you for the recommendation! I stumbled across it in the Resources tab... which totally answers my question about what books to read. I will definitely go through that. | 23:13 | |
I feel that my knowledge about anything is extremely shallow, which is a strange kind of existence to not really know anything to an intimate, expert level. I meander across difference interests, but I always come back to computing. So, I will go deeply into Raku. | 23:14 | ||
Nemokosch | Happy to hear that. Just today again, I was thinking that regardless where Raku will get on the "charts", it's a unique opportunity to learn about both various aspects of programming and an international community in general | 23:23 | |
A lot of the fundamentals are written in a high-level language: Raku itself and a subset of it, called NQP | 23:24 | ||
CodeTortoise | I looked into NQP, and that is neat! I have a lot to learn regarding this and MoarVM, and I hope to get competent enought to play with it. I am learning that building on top of a VM is incredibly advantageous. | 23:31 | |
Nemokosch | I am kind of a lay person when it comes to building systems and VM's but one thing is sure: having this frontend-backend distinction helps a lot architecture-wise. The kind of work that takes place at the runtime and at parsing and code generation are fairly different, hence the considerations are also different | 23:36 | |
MoarVM itself is written in plain C from all I know - but in theory (and some limited practice), one can implement a runtime on top of any technology. The JVM runtime is more or less functioning, for example, even if it's far behind from MoarVM these days. | 23:38 | ||
CodeTortoise | Yes, and the distinction seems to come with how much interactivity is desired when building a system. COMMON LISP seems to be the only language that bridges the gap between having a dynamic, introspective programming enivironment, and compiles to well optimized machine language. | 23:39 | |
The only other language that declared to run that spectrum is RED, but it seems to have derailed due to some crypto-venture. | 23:40 | ||
Nemokosch | Now, for example, we can hope that the more transparent the language is, the more possibilities open up for macro-optimization | ||
the biggest win is always what you just downright don't have to do | |||
CodeTortoise | That is a concept I have to explore more of, MACROS. Seems to have a different difinition for every language. | 23:41 | |
Nemokosch | the idea is that a rich vision of the code being generated can help you detect and eliminate unnecessary abstractions for the actual output | ||
what I really wish someone with related experience could "fix" in Raku is the regex/grammar engine itself, which is... very subpar regarding performance | 23:42 | ||
CodeTortoise | Ah, I think I understand. It is easy build functions that arbitrarily call to whatever many other functions, even to different modules, before finally dealing with the input. | 23:43 | |
Arent regex automata? My terminology is off, I think I mean state machines? | 23:44 | ||
Nemokosch | it's kinda too powerful for its own good. No doubt it could be done better but who can do it and when, is a big question | ||
CodeTortoise | Yeah. When people say Raku is a big language, it is really hard to graps what aspects of it are large. The syntax is definitely wide, but I suppose its regex is another dimension that makes it big. | 23:45 | |
Nemokosch | mathematically sound regexes can be processed with state machines. Now, programming languages tend to have more powerful regexes and Raku in particular has a regex system that is most similar to bare code with nice-looking sugar | 23:47 | |
CodeTortoise | I don't know if we will ever escape it, but I would love an alternative to only calling C when more "performance" is desired. Aside from Perl's history with UNIX, there are definitely other languages that offer improved performance... like FORTRAN and FORTH. Hah. | 23:48 | |
Nemokosch | If I were to guess, this is a factor why it's hard to precompile them into some straightforward bytecode | ||
CodeTortoise | Oh, I remember seeing that. You can name slices of regex and call them with <>. | 23:49 | |
I found that super cool. | |||
Nemokosch | I tried to learn Forth back in the day... it took me painfully long to realize it's just not really meant for PC's | ||
gForth itself mostly relies on C which is ironic | 23:50 | ||
CodeTortoise | Nah. The Charles Moore invented it to program a telescope. Definitely made for tiny machines. | ||
Nemokosch | The "natural inhabitat" of Forth could be microcontrollers, like you don't even need an OS, let alone virtual memory and stuff. | ||
If you can get the stack working on any hardware, plus maybe some sort of addressable memory, dang, you can start writing code that reads nice. This seems like a missed opportunity. | 23:52 | ||
CodeTortoise | I did not know that. THe spirit of Forth as I understand it is that is should be easy to build a programming language out of assembly in order to quickly gain control of a system/hardware. Thus, all forths would be bespoke to the machine. | ||
Concatenation is maybe just the simplest way to build a language. | 23:53 | ||
Nemokosch | I can imagine there were machines that "spoke Forth as their native language", like there were Lisp-based machines in the sixties-seventies maybe. But honestly, I'm not knowledgeable with microcontrollers | 23:54 | |
My guess is that nowadays one can just cross-compile code and flash it to whatever hardware that has a C compiler or something | |||
And hence probably the value to compile your program straight on the hardware inflated somewhat | 23:55 | ||
CodeTortoise | Well, there are. Green Arrays is the company of Charles Moore and they make stack based computers. They are like, a bunch of tiny computers <cpu, memory> in a grid that can send and receive data from other modules. | ||
Also, the OLPC had forth built in. So did this little device I had the was for having Wikipedia offline, readable on a monochrome LCD> | 23:56 | ||
Nemokosch | I suppose that's quite a niche though. If you think about it, most architectures vanished by these days | 23:57 | |
CodeTortoise | I think that is the beauty of modern computing, the target is irrelevant, so a programmer is free to explore their wildest dreams in whatever language they want. | 23:58 | |
Nemokosch | x86 just cannot die because of the humongous legacy and the rest is ARM or some legacy even older than x86 😄 | ||
CodeTortoise | Yeah, Raku for RISC-V when? | ||
Nemokosch | heh, Raku for FPGA | 23:59 | |
generate circuits from the code | |||
CodeTortoise | x86 is enormous. I don't care to ever even look at it. I have a couple of Raspberry Pis to learrn armsembly on. |