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. |
|||
01:17
Chanakan joined
01:28
Chanakan left,
Chanakan joined
|
|||
pelevesque | I realized a few days ago that the split between Perl and Raku was an inevitable meta manifestation of TIMTOWTDI. | 07:16 | |
antononcube | Read some the interviews with Larry Wall, say, in the book “Masterminds of programming”. Perl and Raku are the “same effort” for the “same mission”. (Well, obviously.) But the language creator(s) are more mature with Raku. | 09:07 | |
More mature in computer science and programming sense. I am not sure otherwise … | 09:08 | ||
For me, Larry’s interviews are very inspiring about using and knowing Perl (and Raku), but then, I actually see code of those languages and my enthusiasm diminishes. | 09:19 | ||
I blame Larry’s fascination with English. If Larry’s native language was more consistent, Perl and Raku might have been nicer languages. Although, we can argue will Larry-the-language-creator would have existed if he was not born in a country where English is a native language. | 09:24 | ||
librasteve | @antononcube ... I have coded in a range of languages and imo, raku and perl share a common approach that is born from natural language and embodies the core theme that HLLs are there for humans, not for computers | 10:14 | |
in contrast, the recent history of coding (because it is driven by the needs of large teams) has driven towards"one best way" (ie Python), "safe code" (ie Rust), "strict code" (ie. TypeScript) and "functional code" (ie. Clojure, Elm) ... which are all variations on the theme of your language is there to limit what you can do in the interests of the team or of ease of learning or of memory safety without GC | 10:20 | ||
(ie. machine speed) | |||
there are many English terms in raku <has is does but WHICH WHAT> adverbs and so on, but, as linguistics demonstrates, the underlying concepts are common across most natural languages and I believe that Larry's natural language approach can also feel good to those with other native languages | 10:23 | ||
so, what is being lost in the professional coding community is a sense of freedom to use the tools that you prefer and of responsibility that we all share to make our code legible and maintainable | 10:24 | ||
it maybe harder to write shit code in Python than raku - but it is still all too easy and in a way when the language papers over this it obscures the underlying problems | 10:26 | ||
so raku is more like "you want [Multiple Inheritance], you got it and we made it with a really nice syntax" rather than "you can't have it because it could break things" and it's up to the coder to make sure it's the right tooll and to understand the limits ... where [xxx] can be many things | 10:28 | ||
nijmegenzuigt | why is Raku needlessly complex in the way to use functions from scripts in the same folder? It's very arcane and the docs are terrible at it since it starts wit packages, modules, classes, grammars, roles and whatever else are ways to encapsulate and I'm like, please just tell me in 1 sentence how to call other function in another script without explaining lexical scoping and 7 levels therein | 11:23 | |
needing like 3 use lines or import/need and possible versioning to it just tells me that it's designed for single-file scripts only and for larger programs use another language like Nim instead | 11:26 | ||
librasteve | hi @nijmegenzuigt ... thanks for your question - the idea with raku is that there is a script myscript.raku that can call functions from other files - which are called modules | ||
nijmegenzuigt | yes I've read the documentation, it's still needlessly complex | 11:28 | |
librasteve | the simplest module file can be something like class A { has $.x } and the simplest script can then be something like use A; my $a = A.new: x => 42; dd $a | 11:29 | |
you do need to tell the script where to look for module files via raku -I. myscript.raku | 11:30 | ||
I am not sure what documentation you are looking at ... there is a whole section on packaging and modules but I don't think that you are looking for that ... but tbh I don't think that the boilerplate I just stated use A; and -I. is very much overhead ;-) | 11:32 | ||
C has lib and Python has import right? | 11:35 | ||
nijmegenzuigt | how many other languages have you also add folders to the LSP so it knows about scripts in the same dir that you want 🙂 | 11:37 | |
and where is easily explained what you just said | |||
because I have that in my makefile obv | |||
what you tell me is what I found from an answer on Reddit | 11:38 | ||
not in an introduction to Raku page 😉 | 11:39 | ||
whether you feel it's much overhead or not, it doesn't say "beginner friendly" | |||
antononcube | There should be RakuGPT similar to the PerlGPT project. | 11:41 | |
librasteve | docs.raku.org/language/modules#Loa..._importing | ||
antononcube | Then, hopefully, questions hard to answer using Google / docs.raku.org would be easily answered. | 11:42 | |
nijmegenzuigt | GPT is the solution to nothing, it contradicts itself quite easily and how would it find answers to questions that are barely answered in the first place | 11:43 | |
librasteve | I think it is true that the link I shared is quite buried in docs.raku.org and I just cheked the beginner intro docs (raku.guide) and that is "too easy" in that it only describes how to install and use modules | 11:44 | |
please tell me where you think this information should be - if I know the part of the docs that you are lookng at, then maybe we can improve that | 11:45 | ||
nijmegenzuigt | how about | 11:46 | |
Raku by example 101 | |||
how to use subroutines from another script in the same folder 😉 | |||
seems like the most logical one; and coming from an Object Pascal background seeing "unit module" is even more confusing | |||
librasteve | OK - good idea | 11:47 | |
nijmegenzuigt | sorry if my tone comes across as a bit whiney | 11:48 | |
antononcube | Wirthy | ||
librasteve | you can always ask here - no question is a bad one | ||
github.com/Raku/doc/pull/4497 | 12:06 | ||
OK - I have made a PR for this change | |||
18:54
soverysour joined
19:07
soverysour left
19:08
soverysour joined
20:39
soverysour left
|
|||
_grenzo | Supply/tap/emit question. The docs indicate that a supply is thread-safe. Can I assume that means that when things are being emitted the code in the tap can't stomp on itself? i.e. I have multiple threads running and each will emit a value and in the tap I keep a accumulator of the emitted values, is that safe without using atomicint in the accumulator? | 20:47 | |
I've been trying to get it to fail and haven't so far, but that's not necessarily proof | 21:07 |