« first day (4409 days earlier)      last day (732 days later) » 

19:00
ah
@Ginger The where module doesn't make it any cleaner
this syntax doesn't feel right to me tho
import 2.2 of module
import module (^2.2.0)
that feels good
@Ginger Metadata for sure
ooh, you know what I just realised? it's possible, using this system, for the standard library to be rolling-release
You want to specify the version on one place so it's easy to upgrade a dependency
Oh that's a good point. But maybe if you specify a version in one file, it'd be used as the default for the rest?
19:05
no no yall are overthinking this
each file can specify the versions it wants and then the packager resolves which version(s) to use
So you could do import image_recognizer (^2.2.0) in main.rbt and then goat_tail_recognizer.rbt could just import image_recognizer
if you're worried about redundant ones I'm thinking up a solution
@Ginger Yeah but that means if you want to change it for the whole project, you need to change it in every file
That's a bad thing
I also realized: since modules can be upgraded to the latest available version from any available source, including potentially untrusted bundles, Rabbit will probably have to include a system for signing modules, but idk how that would work and not be a pain in the ass
I don't think it's a good idea to have different files in the same project request different versions of a dependency
19:06
^
why?
If you tell it to use an untrusted bundle you're explicitly giving it permission to use an untrusted source
Signing doesn't seem necessary, and how would it get the public key anyway
well yes but what's stopping me from hiding a h4x0red version of a standard library module in a bundle
probably good design for the packager
a. you will get weird bugs trying to transfer data between parts of the project that might not match each other and b. if you refactor by moving any code to another file you might forget to check if dependencies align and get weird bugs from that
@Ginger Nothing, which is why you don't install your packages from random bundles
19:08
Version constraints can get quite complex
A bundle's main module would be fine to install, assuming you trust the bundle file, but the dependencies within that bundle should all be untrusted
Unless you explicitly permit it to trust those
For reference, a project I work on at my work has many in-house dependencies that need to be updated every day
idea: Rabbit releases can have codenames; modules can specify what codename they want to use and that would be the default version for all stdlib modules so you don't have to specify what version of threading you want every time you import it
If that was more chan changing a single file it would be incredibly tedious
okay, metadata
actually I'd probably end up doing that anyway lol
19:11
IMO either should be allowed
bleugh no
one or the other
and I like one
Simple single-file scripts shouldn't need a whole metadata file
@RydwolfPrograms Rabbit is not a language that is made for single-file scripts
Disagree with ^^
actually, lemme just clarify this right now: Rabbit will not work with single scripts; if you want to make a Rabbit program it has to be a module
I'm sure some people won't like that, but that's how I'm doing it
if you want to make scripts use Python
single-file modules, however, are fine
19:13
can you just run a module like a script?
what do you mean?
@Ginger What is the difference between a module and a single file script?
Modules have metadata files
Wouldn't a single file just be a single file module?
like rabbit myprogram.rabbit which runs it, no?
19:14
Oh well if you already have a gross metadata file then put your dependencies in that
Problem solved
will modules be installed per workspace like node or system-wide like python
@Jacob nope, you'd have to do rabbit mymodule (assuming you're in the same directory as mymodule or it's in the global library)
@hyper-neutrino you can choose
@hyper-neutrino I think node does it user wide now
there's a global module library, but you can tell Rabbit to also use another library somewhere else, like in a dev environment
@Ginger okay, but you can run it, pretty much the same as a script just in a folder instead
19:15
I know that npm i at least still does it in the deepest folder including a package.json though you can do -g to make it user-wide
@Jacob yes, assuming you also have a valid metadata file in the module's directory
oh, and just to clarify: a "library" is a directory containing any number of modules and some metadata files
could you tell me more about rabbit
also please put those little cute emojis in the readme 🐰
so in a hypothetical future where Rabbit is commonly used, each user would probably have their own library, there would be a global library for all users (probably containing the stdlib), and the OS might have its own private library for internal stuff
@Jacob uh, most of the "planning" I've done is in the form of long chat monlogues
but if you have specific questions I can answer them
is it fp?
hmmmmmmmmmm
it's Pythonic
19:19
ah i see
well i suppose that guarantees its mainstream success in the near future
I came up with it to fix a bunch of issues I had with Python's packaging system (and which I have written several rants about)
i thought you were just making a new package manager for python
pypackage right
yeah, that failed because of how sucky Python packaging is
so I'm making my own language because why not I can do whatever I want
darn i was rooting for u
well now you can root for Rabbit!
19:22
only if the log messages have emojis
if they don't i'm out
@Ginger I would...strongly hesitate to use that word for it :p
> Readability counts.
> Beautiful is better than ugly.
It's Python-diagonal
OOP will never be pretty
ok boomer
Especially not verbosity-oriented-programming of the sort Rabbit seems to be going with
19:33
it's not object-oriented programming, it's physical-construction-philosopy-inspired software development
Anyone who voluntarily opts for OOP in 2023 without taking it in a fairly unique direction is making an objectively wrong choice
rimshot.wav
OOP's just bad at achieving what it sets out to
you're the only person I know who doesn't like it, and I personally have never had any problems with it
And the way that most langs do it, with all the verbosity and poor choices Java set a precent of, makes it even worse
19:35
"OOP bad" isn't exactly an uncommon stance TBH
well good thing you can help me make fewer poor choices
It's kinda too late
I like objects, I like inheritance
it all makes sense to my brain
I can understand it easily
You can have both of those things without going overboard
19:36
hm
okay, how about this: what changes would you make to Rabbit's current syntax?
Thinking about things in terms of physical objects is nice...*sometimes*
I'll be quiet until you say you're done
First I would remove classes and all related stuff
And go with structs that can have methods, preferably with impl
And traits, which do everything inheritance does but far better
I'd examine every aspect of the syntax with minimalism and visual cleanness in mind
It takes ten minutes to update your parser now and ten years to do it a decade from now
I'd make sure it's very easy to iterate on existing code, but also easy to plan things out from the start
Which is higher level than the syntax, but the syntax should reflect those values by being quick to visually parse or modify
And you get a couple weirdness points; you can afford to do a couple of nonstandard things with the syntax. Do more than two or three and you'll alienate people, but do nothing new and you're failing to take advantage of the opportunity
That's pretty much it
alright
first: I don't like struct/impl
OOP with classes and stuff tends to be very big and very verbose for little good reason
@Ginger Syntax-wise? Or do you not like traits?
19:42
Traits are cool, but I don't like the syntax
You kinda need impl for traits to work, since you need to be able to define methods on a class after it's been defined elsewhere
it feels weird to me to have the structure and functionality of something be in two separate blocks
I like having them in one place, where they feel like a cohesive whole
@RydwolfPrograms its not objectively wrong
Separating the data fields from the functions does have some advantages tho, aside from being able to add more later. It makes it easier to remember that the data is really all that's being stored (assuming you're not doing it JS-style where methods are lambdas in properties).
were there a way to do traits but have structs and impls be one thing I'd love to do that
@RydwolfPrograms wdym "all that's being stored"?
19:45
Like with Rust Iterators, I keep catching myself thinking of the iterator as some sort of special thing
When it's really just a couple data fields, and some functions which I can apply to those data fields
I like thinking of them as a special thing
why? I don't know
Same here
The separation of data and functions helps counter that
but having a "thing", a solid object that I can interact with, makes more sense to my brain then a weird lump of data and functions that I can apply to it
it feels more cohesive
Because sometimes that's useful, but sometimes looking at it as a weird lump is more useful
But also...the function isn't stored in the object, it's something you do to the object. They're not as much a single object as we train ourselves to think
And while you can think of it as "Dog is barking", 90% of the time in actual code it makes more sense to think of it as "I am barking Dog"
maybe it's that having two "things" which only work with each other and are specifically made for each other feels weird to me because I'm like "why have them be separate? they're made for each other so they should be one thing"
19:50
Well, the impl is made for the struct, the reverse may not be true
You can add traits to structs you didn't define
Which is part of what makes them so cool
yeah, I don't like that
Why?
It allows for all sorts of incredibly useful things
why would I be modifying someone else's code? it's not my code
it feels weird to me
You're not modifying it, you're making your code apply to it
If you make a trait for things that bark, of course it should apply to std::Dog
yeah I guess, but it feels wrong to me
19:52
(worth noting you can't impl a trait you didn't define onto a struct you also didn't define; you have to define one of those two)
I'll do it if it's the best thing to do, but I just don't like it
Traits aren't just for adding functionality, they're also for classification
There's traits in Rust's stdlib with no methods
That's part of why it makes sense to allow implementing them on outside things
hmmmmmmmmmmmmmmmmmmm
how would this system work with something like GObject, which is very OOP-based?
I can't actually think of an instance of a library in Rust that adds methods to types from another library
do you plan to have operator overloading
19:54
because I am not doing anything that I can't make work with GObject
@hyper-neutrino yes
@Ginger Well let's say there's a Button class you'd normally inherit from to make a custom button type
would this (adding traits to others' structs / adding/changing methods) be able to be used to add op overloading to native types? like for example making list addition vectorize instead of concatenate
@hyper-neutrino AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
NOOOOOOOOO WHY WOULD YOU DO THAT
you can't just change how a critical part of the language works for no reason and then expect all the other code to be fine with it!
oh I don't expect other code to be fine with it
19:56
me omw to change how a critical part of the language works for no reason and then expect all the other code to be fine with it!
I did this for a library file for python for AoC cuz I wanted to be able to add stuff like using << to rotate arrays
@hyper-neutrino Wouldn't it be better to have separate operators for that? ++ for concat and + for add?
Traits can't be used to do that, ignore hyper
@hyper-neutrino No
you shouldn't leave out good features just because people can abuse them in bad ways
you would not take a hammer out of a toolbox just because it can be used as a blunt weapon
Usually you can only add a trait to an outside struct if you defined the trait
19:57
People can't abuse them anyway
^^
hmm okay
Like in Rust, you can't add the Sub trait to String
Since you didn't define either of them. Same here I'd assume
Maybe if you defined a new operator, you could add its trait to an existing type tho
I guess you could make a wrapper around vectorizable lists or something
@RydwolfPrograms Which would make sense
Rust doesn't let you define new operators, but it'd be cool if Rabbit did
19:59
okay, I've come up with some syntax that I like for structs and impls:
struct Something:
	int beans
	Display implementation:
		print(this.beans)
(this is a WIP btw)
@RydwolfPrograms Well, in a trait-based language, you'd make Button a trait instead
Done, simple
@RydwolfPrograms ...what
@Ginger How do I add a trait to an existing struct?

« first day (4409 days earlier)      last day (732 days later) »