hug the mods posted:

i have monthly contributions to rakudo core for over a year while programming stuff in it for over 3 years now

qntm posted:

Perl 6 intentionally confuses items and single-element lists:

code:

> (1, (2), 3)
(1 2 3)
> ((((1))))
1
> (1, 2, 3).elems.elems.elems.elems
1

A string, like any scalar, is a single-element list too:

code:

> "A".elems
1
> "string".elems
1
> "".elems
1
> "string"[0][0][0][0]0[0]
string

To get string length in Unicode code points, you do "abc".chars. Well, in the version I have installed that was the case anyway, but apparently that behaviour changed in the past month, so now you use codes to get length in code points and chars to get length in displayed graphemes. Substring operations also operate on graphemes. So:

code:

> "नि".codes
2
> "नि".chars
1
> "\r\n".chars
1
> "नि\r\n".substr(1,1).perl
"\r\n"

So string operations yield platform-dependent results.

If you call anybody in the Perl 6 community out on any of this, the standard defence is "Perl 6 is quirky! Why do you hate fun? Larry decided it one day and moved on, he has a degree in linguistics"

E: okay, that character was meant to be a special single character but apparently the forums dislike advanced Unicode characters in code blocks?

tef posted:

call it cool because i'm larry wall

quote:

"why is it called 'Cool'? that word is an adjective, but it's not a role. generally I would expect concrete data type names to be nouns. I'm willing to be persuaded otherwise but I found this quite surprising as a newcomer"

"well, actually it stands for 'Convenient Object-Oriented Loop'."

"huh? it's a data type, not a language construct. why is it called 'loop'"

"well, actually it stands for 'Convenient Object-Oriented Loopback'."

"the... the network address?"

"now you're just bikeshedding"

fritz posted:

quote:

Otoh, not all code needs to be maintainable.

fritz posted:

quote:

Otoh, not all code needs to be maintainable.

fritz posted:

quote:

Otoh, not all code needs to be maintainable.

fritz posted:

quote:

Otoh, not all code needs to be maintainable.

Cybernetic Vermin posted:

tons of stuff is best written with the attitude that if it needs to change it can be rewritten. basically

Gazpacho posted:

Cybernetic Vermin posted:

tons of stuff is best written with the attitude that if it needs to change it can be rewritten. basically

gently caress the mods posted:

all of these people are smart as hell but there really is no strong lead or direction beyond the parts Larry rules on.

quote:

I'm mad about new perl and wrote all of this

tef posted:

that said i am a-ok with making code easy to delete over easy to maintain

Vanadium posted:

How do I do this in practice, beyond my usual modus operandi of writing code no one actually needs

Vanadium posted:

How do I do this in practice, beyond my usual modus operandi of writing code no one actually needs

Vanadium posted:

How do I do this in practice, beyond my usual modus operandi of writing code no one actually needs

tef posted:

stuff

Vanadium posted:

How do I do this in practice, beyond my usual modus operandi of writing code no one actually needs

tef posted:

in return: i'm going to write an alternate universe fanfic where python 3 wasn't botched to gently caress

gently caress the mods posted:

I was pretty happy to see mst looking at tool chain code today

tef posted:

btw perl's "every list is flattened automatically" (well more that the comma is associative in perl) looks real weird, but i have encountered a poo poo ton of flatMaps in code and maybe larry was on to something when he explained why he did it : "it's useful sometimes"

Gazpacho posted:

This question will probably provoke laffs but does perl6 process perl 5 code as the original spec required (and which perl 5 lmao)

Inline::Perl5 posted:

code:

    use Inline::Perl5;
    use DBI:from<Perl5>;

    my $dbh = DBI.connect('dbi:Pg:database=test');
    my $products = $dbh.selectall_arrayref(
        'select * from products', {Slice => {}}
    );

code:

    use Data::Dumper:from<Perl5>;
    class MyDumper is Data::Dumper {
        has $.bar;
        method foo { say "foo!"; }
    }
    my $dumper = MyDumper.new([1], bar => 1);
    say $dumper.Dump();
    say $dumper.foo;
    say $dumper.bar;

chmods please posted:

because compile time is also allowed to be runtime in certain situations in perl

tef posted:

it isn't so much that perl 6 was a mistake but it wasn't even a fork to the language, it's a whole new language that's hoping some of the perl 5 programmers left and other people will jump in from python and ruby

quote:

Superscripts can now be used for integer powers
Non-digit unicode characters with a numeric value (½ and such) can now be used for that numeric value
There is a new “approximately equal” operator

b0lt posted:

did the perl6 people mix up christmas and april fools day?

gonadic io posted:

∼∼unicode compatibility∼∼

gonadic io posted:

∼∼unicode compatibility∼∼

tef posted:

let's try to make code easy to delete

step 0: don't write code

the number of lines of code doesn't tell us much on its own, but it's magnitude does 50, 500, 5,000, 10,000, 25,000 etc

a million line monolith is going to be more annoying than a ten thousand line one and significantly more time, money, and effort to replace.

this is facile, but generally the more code you have the harder it is to get rid of. saving one line of code saves absolutely nothing on its own.


step 1: copy paste more code

lines of code is a good approximation for the maintenance burden of code, but some lines of code cost more than others. it's sometimes to copy paste a couple of times before making code reusable.

when you avoid copy paste and go for code reuse, you introduce dependencies upon the library you have created. building reusable code is something thats easier to do in hindsight with a couple of examples of use in the code base, than foresight of ones you might want later.

it's much harder to delete code that's used in multiple places. it's much harder to delete code that's been reused, and the more it has been reused the more accidental and implicit behaviours will be relied on.


step 2: don't copy paste code

when you copy and paste something enough times maybe it's time to pull it up to a function. you know the code won't be going away any time soon: this is the "save me from my standard library" stuff, the "open a config file and give me a hash table", "delete this directory". a lot of this code is stateless, or at least the state they are relying on is things like environment variables. the stuff that ends up in a file called "util".

each of these things should generally stand on it's own give or take a couple of helper functions, so my advice is this sort of code should live in it's own file, rather than in one shared util file with a bunch of methods. make a util directory and stick them in there. a single file util will always grow until it is too big and yet too hard to move out, putting them in individual files makes it easier for them to grow as time goes along. some of the time this code is a wrapper around a third party library, or error handling code.

like the one shots, they are more about dealing with the computer than your application or business logics like file handles, or processes. stuff that is just going to be platform detail. other good examples of code you're not going to delete are lists, hash tables, and other collections. not because they often have very few methods, but because they don't grow in scope over time.


step 5: write more boilerplate

despite writing libraries to avoid copy pasting, with very simple interfaces we often end up writing a lot more code but we call it boilerplate as you usually change some of code in a different place each time, rather than the same bit over and over. it's like a more frustrating copy paste that's less obvious on how to lift out.

it is not that you are making code easy to delete, but you are consolidating something that is hard to delete and keeping it away from the rest of the code lest it be contaminated with business logic. stuff like network protocols, wire formats, parsing libraries, stuff where it's hard to interweave policy (what a program should do), and protocol (what a program can do) together without limiting the options.

like with copy paste, we are duplicating parts of code to avoid introducing dependencies, gain flexibility, and pay for it in verbosity. with these libraries, when you change your mind about what you want them to do, you can change one part and continue on. although the total lines of code never really goes down, it never really grows that quickly.

again, this is not an exercise in code reuse but trying keep the parts that change frequently from the parts that are relatively static. it's not so much deleting code but being able to replace parts of it without interruption.


step 5: don't write boilerplate

boilerplate works best when it's invoked for one off situations or to cater to all tastes, but sometimes you end up doing the same things over and over. despite urlib2 being flexible, it's still awful to use. you can layer on a library atop that handles the details for you. this isn't as uncommon as you'd think: requests is an successful example of providing a simpler interface for common tasks built over a complex library which can be assembled into shape (urllib3).

what we are doing is structuring our code into layers atop each other: starting at the bottom with the things that change the least (platform, runtime), and slowly adding a layer as we deal with a new concern, like protocol, or policy. i'm not advocating you go out and create a /protocol/ and a /policy/ directory but you do want to try and keep your util directory free of business logic, and build simpler interfaces out of wrappers around more flexible but verbose ones, and layer your software to manage change: things that don't need to change shouldn't rely on things that do.

it isn't a clean separation between "absolutely inflexible" "every project" and "this project" every time but it's a corner that's relatively expensive to cut in large code bases and one that's hard to fix later. layering is about not making your code easy to delete but making the most of what you have with the code you have got: the code you're going to change is the code you should focus on making it easy to delete, but a healthy system always has some redundancy.

it really isn't about code reuse.


step 6: write a big ball of mud

eventually you have to deal with your business logic somewhere, and once you've isolated the other parts of your code that are unlikely to change in scope you're actually going to have to make the program do something. remember that one big poop emoji vs 19 small tangled poop emoji? sometimes it's easier to delete one big mistake than try to delete 18 smaller mistakes one at a time.

this works well when your software is disposable but all of the moving parts look the same each time even if it does look a bit different. one off client sites, event web pages, homebrew content management systems. when you work in a factory line you don't really care about the lifecycle that far after release. i've seen mobile games companies operate around this principle: make a bunch of fire and forget demo games out of a shared toolkit and maintain the ones that people like. this often involves punching things into a template or framework, well the sort of framework that's a big ball of mud but it has handy gaps left for your things.

when you know what code is going to be deleted soon or easily replaced you can cut a lot more corners, especially when you've isolated the other parts. it isn't so much about code reuse but making it easy to prototype without too much investment.


step 7: don't write a big ball of mud

on the other hand, some of us are not so lucky and we must live with our mistakes for a lot longer. the problem with big balls of mud is that the short term gains are fantastic but eventually they become a very very big poop emoji. although the layers i've talked about above work with a very thin veneer of business logic atop a bunch of domain and platform specific things, this breaks down when you have an awful lot of business logic.

before we talked about layering state, logic, protocol, and policy above more simpler lumps of code, we change that and begin first with a shared layer. out software starts to resemble multiple processes sharing the shame file system. they don't care what filesystem it is as long as it as the files it expects to be there. another example is dependency injection, whereby a hidden namespace is populated with objects and hopefully most of the code to glue it together is handled for you.

other examples involve a twitter engineer wrote something about how they've introduced namespaces into their rpc toolkit, to let them control how the system in a similar means to how other people have used dns. the trick with having 18 small balls of mud is keeping the ways in which they depend on each other to simple contracts, although it's a rough ride even for well established things like filesystems.

uniformity of interface, like file systems or wsgi, is one thing that makes code easy to delete: there is code re-use in things like rack/wsgi/*, but what they enables you do is to pick and choose your http server and middleware and make it easy to change your mind and delete the code that made those choices.

it isn't so much that you can split your software into smaller parts, but a uniform interface makes it easier to delete the code you depend on and replace it. a uniform interface is not just how the system works, but how it breaks too. it can be better to have an honest interface (i might be slow) vs one that assumes (i will always return quickly) because computer networking is terrifying.


step 8: loose coupling

it isn't so much the size of your code base, or how cleanly you've split your software into layers, or how uniformly your components communicate and share with each other, these are just as much approximations of what it means to write code that is easy to delete. it is not having few dependencies, making them explicit or implicit, but how you isolate and compose these dependancies together, and how you can change them over time.

when your code is loosely coupled together, it's easy to delete it. a healthy code base has some verbosity, some redundancy, and just enough distance between the moving parts so you won't trap your hands in it.


tl;dr if you want to write code that is easy to delete, repeat yourself to avoid creating dependencies, but don't repeat yourself to manage them. layer your code apart to make it easy to change your mind and isolate the bits of your code that are fast moving and/or hard to write from each other. don't try to do all of these things at the same time. or just don't write so much code