stripedpajamas has quit [Remote host closed the connection]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
kevsmith has joined #zig
daurnimator has joined #zig
<fraktor>
Is there a set of design documents that talks about the future plans for polymorphism? I'm mostly thinking about traits/interfaces/whatever.
<fengb>
#130
<fraktor>
How likely is the `@implement` syntax to be adopted? It seems like a pretty cool and Zigish idea.
* shakesoda
would prefer such things stay away forever
<pixelherodev>
andrewrk: have time to discuss the issues you brought up on 6009?
<pixelherodev>
6007*
<andrewrk>
yes
<pixelherodev>
I think the best example is double-referencing an arg
<andrewrk>
fraktor, at this point, language-supported polymorphism is looking unlikely
<pixelherodev>
If we have an intCast in the IR which casts an arg to BLAH, and we reference the intCast twice, it'll reference the arg twice
<andrewrk>
however restrictions on @Type are being relaxed
<pixelherodev>
Since args are implemented as indices, this will end up using the wrong index on the second access
<pixelherodev>
Hence what I brought up after - intCasting correctly from function scope, storing the value as an anon (`const SIZE ANONNAME = blah`) and mapping the inst to the ANONNAME
<pixelherodev>
That way, future references to the intcase reference the casted value instead of referencing the casted values again
<andrewrk>
I'm not following at all. the C backend should be able to do exactly the same thing that codegen.zig does except emit .c instead of machine code. we don't have this problem in codegen.zig
<pixelherodev>
Hmm, that's a good point; I'll have to take another look at how codegen.zig handles it
<pixelherodev>
It could be that I misunderstood the ZIR
<pixelherodev>
IR*
<pixelherodev>
Not ZIR, it's the processed IR
isolier has quit [Quit: Ping timeout (120 seconds)]
isolier has joined #zig
wjlroe has quit [Read error: Connection reset by peer]
wjlroe has joined #zig
teqwve has quit [Ping timeout: 260 seconds]
teqwve has joined #zig
<pixelherodev>
andrewrk: is there a convenient IR dumper, or only a ZIR dumper?
<pixelherodev>
... I need to stop asking questions I can answer by popping open the source again
reductum has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
reductum has quit [Quit: WeeChat 2.9]
waleee-cl has quit [Quit: Connection closed for inactivity]
mattmurr has quit [Ping timeout: 256 seconds]
mattmurr has joined #zig
ronsor has quit [Ping timeout: 256 seconds]
chivay has quit [Ping timeout: 256 seconds]
ronsor has joined #zig
neptunepink has quit [Ping timeout: 256 seconds]
andrewrk has quit [Ping timeout: 256 seconds]
redj has quit [Ping timeout: 256 seconds]
chivay has joined #zig
[RMS] has joined #zig
][_R_][ has quit [Ping timeout: 256 seconds]
redj has joined #zig
andrewrk has joined #zig
neptunepink has joined #zig
<sqwishy>
hi, am I doing something wrong if I cImport but get '.cimport:7:15.struct_iphdr' does not support field access
<andrewrk>
open up that .zig file and see what struct_iphdr looks like. my guess is it's an opaque type
<andrewrk>
if you use --verbose-cimport it should print the path to it
<sqwishy>
oh cool; it is, "has bitfield" :<
<sqwishy>
Yeah there's some malarky with the C definition having to do with endianness or something. It's weird. If there's no easy way to deal with this in cImport I can probably define the type in zig easily enough.
<daurnimator>
sqwishy: alternatively, you could add bitfield support :)
<sqwishy>
I saw the issue for that on github; looks complicated
<daurnimator>
you're not wrong
_whitelogger has joined #zig
Ashpool_ has joined #zig
Ashpool has quit [Read error: Connection reset by peer]
hspak has joined #zig
rzezeski has quit [Quit: Connection closed for inactivity]
craigo has joined #zig
dermetfan has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
nmeum has quit [Remote host closed the connection]
nmeum has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
cole-h has quit [Quit: Goodbye]
<andrewrk>
daurnimator, xor list doesn't apply to the stage2 use cases because the other prev/next pointers are not available when we need to access them
gazler has joined #zig
FireFox317 has joined #zig
<daurnimator>
andrewrk: dang
dermetfan has quit [Ping timeout: 246 seconds]
ur5us has joined #zig
Ashpool has joined #zig
Ashpool_ has quit [Read error: Connection reset by peer]
Ashpool has quit [Remote host closed the connection]
Ashpool has joined #zig
Ashpool has quit [Remote host closed the connection]
Ashpool has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
waleee-cl has joined #zig
dimenus has joined #zig
<pixelherodev>
Huh
<pixelherodev>
andrewrk: turns out intCast isn't actually supported by codegen.zig yet
<pixelherodev>
(not if the value's actually used, anyways)
<pixelherodev>
Ha!
<pixelherodev>
My solution *is* what codegen.zig uses!
<pixelherodev>
(inst_table)
<pixelherodev>
It maps *Inst to MCValue, I need to map it to []u8
rzezeski has joined #zig
<pixelherodev>
Is there a way to say `this function only returns [infer error type]`?
<pixelherodev>
Currently using `anyerror` as the return type
<pixelherodev>
I have a function that returns !T1 which in some paths returns a function which was returning !void (except that function is *always an error*, so !void is inaccurate)
<cren>
the message seems to get sent but nothing is received
<Nypsie[m]>
It's because you're providing it an empty buffer
<Nypsie[m]>
client.receive() will read until the buffer is full
<cren>
is that the string recv_data ?
<Nypsie[m]>
Yes, sorry
cole-h has joined #zig
<cren>
what should I be doing? a string like " "?
<cren>
oh wait
<cren>
I have to allocate don't I
<Nypsie[m]>
That, or some hard coded length that you re-use
<Nypsie[m]>
W/e fits your use case
<cren>
Do you think you could provide a quick example?
<Nypsie[m]>
For testing purposes you could just do var recv_data: [100]u8 = undefined, and provide that to client.receive()
<cren>
is there no way around using `undefined` here? it feels dangerous
<Nypsie[m]>
You could fill it with zeroes
<Nypsie[m]>
var recv_data = [_]u8{0}*100
<leeward>
undefined isn't dangerous; it's extra safe. If you try to read from something undefined that hasn't been written to, your program will crash (in safe build modes).
<Nypsie[m]>
[_]u8{0}**100 I ment
sawzall has quit [Read error: Connection reset by peer]
<Nypsie[m]>
Agreed with Leeward
sawzall has joined #zig
<Nypsie[m]>
Also, client.receive() returns the length that was read, you could use that to get a slice with the exact length
<cren>
leeward: oh, that's true. I'm just working off a vague fear of `null` that I've picked up from blog posts
<pixelherodev>
NULL isn't scary
<leeward>
Also not an issue in Zig. Optionals have to be unpacked before they can be used, so null has to be handled.
<shakesoda>
the things that make null scary are things zig is designed to avoid anyways
<leeward>
Though I don't think nulls are relevant here.
<pixelherodev>
All the "Blah is bad" posts boil down to "Blah is bad if you don't know how to use it properly so people shouldn't use it because we can't expect them to learn to make these decisions on a case-by-case basis"
<shakesoda>
pixelherodev: and poor enforcement by languages/compilers
<leeward>
To be fair, it's true that we can't expect people to learn to use dangerous features carefully. Decades of vulnerabilities back that up. That's why modern languages don't have those features.
<shakesoda>
although, to be sure, quite a few things actually are bad
<pixelherodev>
leeward: a lot of people will say that about, say, pointers
<pixelherodev>
It's not that we can't expect people to learn them
<pixelherodev>
It's that we actively expect them not to and then tell them to work on codebases using them
<shakesoda>
if you want to be afraid of something, be afraid of needless complexity
<pixelherodev>
I dislike that claim there intensely. The existence of NULL didn't cause those bugs, people not knowing what they were doing did
<leeward>
Things that are easy to misuse will be misused. It's a fact of humanity.
<pixelherodev>
Everything's easy to misuse if you never learn how to use it
<shakesoda>
and in the face of it do not cower, cut it down
<leeward>
People don't know what they're doing.
<leeward>
Programmers are incompetent.
<leeward>
These are fundamental principles of computer science.
<pixelherodev>
The solution to incompetence is education, not dumbing down language
<shakesoda>
preventing footguns isn't inherently dumbing down
<shakesoda>
zig does a lot of footgun prevention
<leeward>
I think you're making an assumption that all those vulnerabilities exist because people didn't know how to use things. That's not true. Very skilled, experienced programmers have written huge numbers of vulnerabilities not out of lack of education but by just making mistakes.
<shakesoda>
and sometimes (fairly often) they aren't even mistakes at the time of writing
<shakesoda>
but, for example, they become mistakes when an assumption is violated from a later change
<leeward>
Zig's philosophy is heavily anti-footgun. If education could fix C, we wouldn't need Zig.
<fengb>
I feel like the null fear is overblown. Auto nulling is bad and null algebra is pretty bad, but having nulls is kind of a given
<leeward>
To be fair, this was really about uninitialized values.
<fengb>
Oh
<leeward>
It just got associated with nulls.
<leeward>
And then the diversion into billion dollar mistakes.
<fengb>
I've seen crazy workarounds in SQL due to "avoiding" nulls, just for them to pop back up because of a left join
<shakesoda>
the fear was that undefined could be null, but it has to be handled in any case that this could be a problem
<Nypsie[m]>
cren: Btw, let me know if you got it working or not. Happy to help further if needed.
<fengb>
Because that's what the data is... missing >_>
<companion_cube>
leeward: also with null being a "valid" value of far too many types
<cren>
Nypsie[m]: thanks
<leeward>
companion_cube: Yeah, I think that's the real issue for nulls.
<leeward>
Conflating "nothing here" with a specific value, and handling them the same.
<fengb>
I think with modern type theory, optional style nulls are great
<cren>
Since we were talking about education: I started trying to learn C and Zig in parallel and gave up with C because I couldn't find resources for C that compared with those available for Zig
<leeward>
Yeah, the Maybe monad pretty much solved the null problem.
<fengb>
Or nothings or whatever you want to rename them :P
<shakesoda>
optionals are nice
<fengb>
You can't find resources for C?
<shakesoda>
cren: you're one of the mythical new programmers that didn't come from many years of C!?
<leeward>
cren: That is very surprising.
<cren>
afraid so
<cren>
I *could* find C resources, but none that I *trusted*
<cren>
C is famous for being hard, so I needed an authoritative source.
<fengb>
The funniest thing is... I always say Zig is hard to learn without a C background because all the resources imply some C understanding
<fengb>
Maybe I'm wrong :P
<shakesoda>
the trick to all programming is to avoid oop designs
<shakesoda>
which are synonymous with needless complexity and shit performance
<Nypsie[m]>
Never did any C either.
<leeward>
I spent a summer working through K&R many years ago. I think it qualifies as authoritative, but 2nd edition only goes through C89.
<fengb>
Disagree with both points. Sometimes OOP is necessary
<danyspin97>
shakesoda: i like oop
<shakesoda>
fengb: it isn't
<cren>
I read K&R, up to a point. But even the new edition is an old book. How can I trust that the K&R examples show best practices for avoiding C's (in)famous plethora of footguns?
<fengb>
Our allocators are OOP, for better or worse
<danyspin97>
you can take a complicate problem and structure it nicely using OOP
<shakesoda>
make sure to color any learning on the subject with the sheer scope of the harm of oop
<shakesoda>
danyspin97: "nicely"
<leeward>
cren: You can't.
<shakesoda>
adding tons of parts is not a nice structure.
<fengb>
That's not OOP though
<Nypsie[m]>
danyspin97: Same can be said about its opposite: It can introduce complexity for a simple problem
<fengb>
OOP is dynamic dispatch polymorphism
<cren>
There were some more modern books but I couldn't find any that seemed to be widely regarded as both "correct" and "modern".
<fengb>
You can add all that other shit if you want
<fengb>
But that's not what makes OOP useful
<cren>
leeward: it was intended as a rhetorical question
<danyspin97>
Nypsie[m]: that's why it's up to the programmer to choose the right tool
<leeward>
cren: I know, but it had an answer :P
<shakesoda>
fengb: i definitely mean the java-branded oop. such designs are really, really prone to excess complexity (especially hierarchical), cache thrashing, just plain being unclear and nasty
<fengb>
Oh yeah, inheritance is a crock
<shakesoda>
these sorts of horrors
<companion_cube>
fengb: why not say "dynamic dispatch" and let "OOP" to the java people?
<companion_cube>
it's less confusing
<fengb>
Because... people reinvent OOP all the time and pretend it isn't?
<fengb>
And it's kinda dumb
<leeward>
Time for everyone to agree on what they mean by OOP: Smalltalk? Java? C++? Anything with encapsulation?
<shakesoda>
i haven't got fundamental problems with dynamic dispatch itself. it's the java kind that leaves me crusading in irc channels against such evils
<companion_cube>
fengb: but then it's not OOP
<fengb>
Erlang/Elixir agrees with message passing OOP
<cren>
In Zig you can attach methods to a struct, right? That's effectively OOP in my book
<companion_cube>
so "OOP" is just a meaningless term.
<leeward>
fengb: I <3 Erlang.
<companion_cube>
cren: they're statically dispatched I believe
<shakesoda>
cren: it's not, that's just a tool you've got for encapsulation
<fengb>
It really isn't. But people who hate OOP will throw away all of it
<cren>
so it's dynamic dispatch that y'all don't like about OOP?
<companion_cube>
no, it's everything except dynamic dispatch :p
<leeward>
I don't like the overloading.
<leeward>
Encapsulation is the best. Dynamic dispatch can be useful.
<fengb>
Alan Kay invented the term object-oriented, and he meant Smalltalk message passing or Erlang actors
<shakesoda>
nah, it's inheritance, overloading, tendency to break problems into meaninglessly small parts that can't be understood as a whole anymore, that kind of stuff.
<shakesoda>
and just plain designing out the very possibility of performance
<shakesoda>
the frequency with which people do this when you let them design their "nice" object models is nearly 100%
<companion_cube>
fengb: so it it's typechecked, it's not OOP? 🙃
<fengb>
I'd consider pattern matching dispatch to not be OOP yeah
<alehander92>
even if dynamic?
<leeward>
Erlang does pattern matching.
<fengb>
I've tried modelling that style of static dispatch in OOP and it's pretty bad
<alehander92>
you can generate dynamic dispatch
<alehander92>
from pattern matching i think
<companion_cube>
it can be dynamic yet typechecked
<companion_cube>
(and yes, pattern matching is just a different thing, totally unrelated)
<fengb>
I mean... if you're talking about defined traits and stuff... that's still OOP
<fengb>
Or Go style interfaces
<shakesoda>
in general code should be as static, direct and simple as it can possibly be. sometimes directness isn't very practical for some reason or other and you end up with a fengb argument
<alehander92>
isn't oop about
<leeward>
I think what most people mean when they say they don't like OOP is inheritance.
<fengb>
But not `interface{}`
<alehander92>
open vs closed
<shakesoda>
no
<alehander92>
because if not, it seems to me one can just generate dynamic dispatch for adt-s
<companion_cube>
fengb: what if I'm talking about dynamic dispatch, statically typed, without a "this" ? :p
<alehander92>
but if it's open: it seems harder, because outside types
<alehander92>
can't be easily accounted for in `case` blocks
<alehander92>
the expr problem etc
<fengb>
I sorta feel like if it's open, it has to be dynamic and OOP in some capacity
<alehander92>
yeah
<alehander92>
but maybe you can just have a table of pointers
<fengb>
Which is why I consider it useful. But I do prefer if it was closed and static
<alehander92>
which .. is it really oop
<fengb>
Manual vtables in C is considered OOP yeah
<shakesoda>
leeward: inheritance is *the* big one, next up would be the tendency to have tons of largely hidden mutable state on these objects (screwing you later) and largely inherent cache waste/thrashing
<fengb>
Inheritance is dumb. No arguments there
<shakesoda>
i have to deal with *so* many cache problems in oop designs to make software run vaguely acceptably
<shakesoda>
you'll note that none of these things correlate with fengb's argument about oop being dynamic dispatch
<shakesoda>
the only issue i take with dynamic dispatch is that it's usually *not* the simplest or most direct approach
<leeward>
shakesoda: Yeah, I figured your problems ran deeper. The performance issue isn't something most people run into, but most people don't actually care how fast their code runs.
<shakesoda>
leeward: people not caring about how fast their code runs happens to be why everything runs so insanely bad
<shakesoda>
leeward: in their defense, it's a complex subject and things like caches are largely hidden and unintuitive
<leeward>
Correct, Performant, Soon. Pick 2. Most businesses don't need performant.
<shakesoda>
leeward: and then i have to come in and save their butts when it's too slow to even ship >:(
<leeward>
In the few places I've worked where performant was a requirement, we sacrificed a lot of soon.
* shakesoda
grumbles loudly!
<shakesoda>
most of the things you can do for performance cost you practically nothing if you don't screw it up when you start
<shakesoda>
it's... really frequent that you can smell-test the worst offenders in any given design from a really early stage
<shakesoda>
the hidden mutable state stuff can be pretty sinister too, to this same effect
<leeward>
It's also really frequent that the worst offenders are complete surprises only revealed by profilers. I do tend to work with above average engineers though.
<fengb>
You have pages, which has routing, rendering, state transitions
<fengb>
But it's stuck in Elm, so you have to do wire all of that in manually without help
<shakesoda>
leeward: yes, that very much happens too
<companion_cube>
fengb: but it's Elm?! it does't have dynamic dispatch? :D
<fengb>
If there was "proper" OO support here, you can create separate Page objects and dynamically dispatch the sub pieces
<fengb>
Yeah it's an OO architecture with terrible boilerplate
<leeward>
My criterion for whether or not someone knows how to make software run fast in an interview is whether or not they mention profilers.
<fengb>
Which is why I like using it as an example :P
<fengb>
Adding a new page involves traversing reams of additional static dispatch through the entire codebase
nvmd has joined #zig
<shakesoda>
leeward: and the weight given is directly proportional to how soon the profiler is mentioned!
<fengb>
It's hard to explain... but in my mind, it's binding of central "methods" into a larger "object"
<fengb>
And that "object" must adhere to these contracts or the other subsystems don't work
<leeward>
shakesoda: Yep. Though the timer gets paused while they talk about algorithmic complexity.
<shakesoda>
how can we make this faster? -> first sentence should be "hit it with the profiler and find out what's going wrong" for "strong hire" :D
<leeward>
shakesoda: Exactly.
<leeward>
The algorithmic complexity thing is just because they misunderstood the question.
<fengb>
Like for example, the file API in Unix is kind of object-oriented. You have a "filepath" and you can talk to it with standard syscalls, but the internals are completely opaque and could go through the network or sshfs or whatever
<companion_cube>
fengb: if it's all static dispatch, it's not OOP :D
<fengb>
Or Zig allocators must adhere to alloc/resize calls
<fengb>
But those aren't static dispatch
<companion_cube>
(in Elm)
<fengb>
Yeah, Elm just makes it really hard
<fengb>
But the architecture is actually OO. It's just poorly done because it doesn't have real OO
<fengb>
You have pages with routes / updates / rendering. But you can't extract those into smaller blobs
<shakesoda>
leeward: yeah. theoretical performance vs real performance. not the same, and often misleading
<pixelherodev>
Anyone who says "toss more hardware at it" gets shot, I assume?
<shakesoda>
yes.
<leeward>
"Toss more hardware at it" has been the best solution for "it kinda runs slow" for several decades.
<companion_cube>
fengb: imho you just describe 99.999% of programs as OOP then
CodeSpelunker has joined #zig
<companion_cube>
as soon as there's a smidge of abstraction or interface, bam! :D
<leeward>
Doesn't help when the EEs say we can't have the budget for more than 512 words of RAM.
<fengb>
Well, OOP is in a lot of places yes. It's also in too many places yes. But it's a useful tool
<fengb>
However... I haven't used OOP in Zig other than allocators
<leeward>
I don't think OOP is the problem. 80% of everything is crap, and some things heavily use OOP principles and aren't crap. It's just a tool that gets misused a lot because it's the first thing people learn.
<fengb>
ECS in gaming is an example of composition-based OO over classical inheritance-based OO
<shakesoda>
ecs is applied data oriented programming
<shakesoda>
this is not an incompatible statement
<fengb>
I was gonna say :P
<fengb>
Anyway, I do agree inheritance is crap
<shakesoda>
inheritance is not just crap, it is *sinister*
<shakesoda>
one of the true evils
<fengb>
So if you're saying OOP = inheritance, I'll disagree with your word choices but agree with your conception :P
<shakesoda>
the model of oop i'm against is the java ideas with all the principles and the inheritance, yes
<companion_cube>
but your definition of OOP is roughly as useful as saying "functional = there are anonymous functions" :)
<fengb>
? Bags of objects with well defined behaviors that are swappable via interfaces is a pretty "classical" view
<companion_cube>
it's just too far reaching, is what I mean
<fengb>
Sure? Other than ignoring inheritance, that's sorta the definition of OO
<shakesoda>
i'm pretty sure the definition i'm using is more in line with what someone would actually interpret oop as
<shakesoda>
not the dynamic dispatch
<companion_cube>
fengb: it means that roughly 100% of languages can do OOP :D
<fengb>
Even in Java circles, it's well known that inheritance is crap now
<fengb>
Yes, most languages can
<companion_cube>
(and 95% can do functional, just exclude C and that's it)
<fengb>
Object-oriented C isn't that uncommon, like GTK or Linux
<companion_cube>
I prefer definition that are a bit stronger…
<shakesoda>
fengb: it's also not uncommon that it is almost completely inappropriate when used :(
rzezeski has quit [Quit: Connection closed for inactivity]
<shakesoda>
where inappropriate means "far from the simplest or most effective, and seemingly done for ideological reasons only"
<fengb>
Languages don't completely determine the architectural styles
<fengb>
OO languages begats a lot of OO and FP languages does FP. But that doesn't mean you can't do FP style in OO languages
<shakesoda>
they don't completely determine the style but they do set the tone for the ecosystem
<fengb>
Yes this I agree
<fengb>
And one of the biggest failures of OO
<leeward>
Standard libraries that provide OO-style things do tend to lead to OO-style code that uses them.
<shakesoda>
most of my complaints stem directly from cases where it's a tool reached for by default
<shakesoda>
instead of by need
<companion_cube>
ok, makes sense I guess
cole-h has quit [Quit: Goodbye]
<companion_cube>
so you can write non OOP c++, and all that
<companion_cube>
(and rust without &dyn is also not OOP ;))
<fengb>
I do wish Zig allowed more FP style stuff :(
<shakesoda>
i mostly want function expressions/1717
<shakesoda>
not much else
<fengb>
I want that too yes. I can live without map/filter/reduce but I still wish I had them
<companion_cube>
maybe it's a point systems
<shakesoda>
i think mentioning 1717 is probably a third of my messages here by volume by now
<fengb>
Zig is unabashedly imperative though
<companion_cube>
FP is when you have a lot of: closures, anonymous functions, immutable data
<pixelherodev>
Hmm, when 1717 gets in it might be worth having `fmt` detect the old style
<pixelherodev>
`struct {fn func()}.func` :P
<shakesoda>
fengb: i really, absolutely hate the approach rust takes with those things
cole-h has joined #zig
<shakesoda>
dunno if that's an average for fp style, but it's cryptic
<shakesoda>
long chains of "wtf does this even..."
<fengb>
I don't like Rust syntax. There's a million symbols and I don't understand any of them
<shakesoda>
yeah, i have that problem too, and also an excess of complexity just kinda everywhere
<shakesoda>
pros: well it's better designed than c++... so that's nice. cons: what does it MEAN
<companion_cube>
fengb: there's & and * :D
<fengb>
shakesoda: C++ is busy making itself better by adding even more features you want!
<companion_cube>
shakesoda: it's the opposite, arguably
<shakesoda>
fengb: every time c++ adds a feature i supposedly want i resolve further to become a goat farmer in the mountains
<companion_cube>
seeing `.map(….).filter(…).collect()` is very clear, at first glance
<companion_cube>
(like, the control flow is clear)
<shakesoda>
companion_cube: it's not even remotely clear in my experience, especially when these things grow as they seemingly always do
<shakesoda>
companion_cube: like, the abstract/simple case is clear, and it quickly gets pretty hairy when i see them in the wild
<pixelherodev>
Yeah, I've been convinced that function chaining is bad
<fengb>
Function chaining works well in a FP language with the pipe operator
<shakesoda>
function chaining is definitely a dangerous path to go down for clarity
<fengb>
Or something that transmutes into an equivalent, like Haskell's do syntax
<shakesoda>
there are sometimes cases where it's a reasonable approach, but in rust i just see function chaining everywhere :(
<pixelherodev>
One of the only ones I've liked was struct initialization in C
<leeward>
companion_cube: I think anonymous functions are a symptom of FP, but not a requirement. FP is when you have immutable data and functions as values.
<shakesoda>
that's just a workaround for the language being deficient
<shakesoda>
really not a fan of builder pattern type nonsense
<fengb>
I wouldn't even consider immutable to be a hard requirement. I'd consider side-effect free as a stronger goal
<shakesoda>
heh, "symptom of FP"
<leeward>
Yeah, side effects are the big thing.
<leeward>
Data mutation just tends to be the most common side effect.
<shakesoda>
i really like a lot of FP-isms, short of actually liking FP
<fengb>
There's a few cases where mutating the end result is easier, but jumping through immutable hoops can be tough
<fengb>
Yeah I'm in the same boat
<pixelherodev>
I think that's the case for most programming philosophies
<pixelherodev>
Some great ideas, some less so
<companion_cube>
builder pattern kind of sucks, yeah
<companion_cube>
leeward: if you have functions as values, it's almost unthinkable to not have closures and anonymous functions, I think
<fengb>
Zig is there! 🙃
<shakesoda>
fp by its very nature of being about the transformation of data has the right idea when you want simple and direct approaches to a solution
<leeward>
companion_cube: True, but only almost. Python didn't have lambdas to start with, and neither did Erlang.
<shakesoda>
and being side effect free to the maximum extent possible is *also* very conductive to this
<shakesoda>
but then most actual fp languages might as well be actually encrypted. argh.
<companion_cube>
yeah I wouldn't call python good for FP
<companion_cube>
it has the features, but in a terribly broken way
<leeward>
It's certainly not designed explicitly for it, but you can do it if you want.
<leeward>
Erlang is less ambiguous though.
<leeward>
Variables are immutable by default.
<companion_cube>
in python you need to guard against all the stupidly broken scoping
<companion_cube>
it annoys me that it's so broken
<fengb>
Erlang didn't have lambdas?
<companion_cube>
it definitely does
<companion_cube>
Erlang is good for FP
<companion_cube>
(a requirement of being good for FP is also to be expression based, and python fails spectacularly at that)
<leeward>
Erlang does have lambdas, but it didn't start that way.
<leeward>
And for a long time funs (what Erlang calls lambdas) were horribly slow so they were mostly not used.
<leeward>
And I'll happily grant that Python is not a great choice for FP. I was just trying to provide an example of a language with functions as values but not anonymous functions, and (very) old versions of Python qualify.
nvmd has quit [Quit: Later nerds.]
<fengb>
Yeah I learned proper FP in Python fwiw
<fengb>
I "learned" FP in Scheme in college, but that wasn't real FP
nvmd has joined #zig
<fengb>
Manually unrolling iteration into recursion! -_-
<companion_cube>
that's proper FP :p
<companion_cube>
(also, recursion is not a subset of iteration)
<fengb>
That's missing forest for the tress
<fengb>
I didn't use map/filter/reduce
<companion_cube>
ah? even though they're much better in scheme?
<fengb>
I didn't learn it
<fengb>
Just because you use an FP language doesn't mean you get FP :P
<companion_cube>
right, if it's only the basics
<leeward>
fengb: Isn't manually turning iteration into tail recursion like chapter 1 of SICP?
<fengb>
Sure? We got into advanced stuff like continuation passing style
<fengb>
But the class missed real FP completely
<fengb>
And I was super annoyed once I learned it in Python
<companion_cube>
well you need to understand recursion
* leeward
skipped the "how to program" bits of college.
<companion_cube>
at some point
<fengb>
Like "what was the point of the class?"
<leeward>
companion_cube: But first you have to understand recursion.
<companion_cube>
exactly
CodeSpelunker has quit [Quit: CodeSpelunker]
CodeSpelunker has joined #zig
cren has quit [Quit: Swirc IRC client]
cole-h_ has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
marnix has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
gazler has quit [Remote host closed the connection]
mgxm has quit [Read error: Connection reset by peer]
mgxm has joined #zig
klltkr has joined #zig
Ashpool has quit [Read error: Connection reset by peer]
Ashpool has joined #zig
cole-h_ has quit [Quit: Goodbye]
wootehfoot has quit [Ping timeout: 256 seconds]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
a_chou has quit [Client Quit]
craigo has quit [Ping timeout: 246 seconds]
CodeSpelunker has quit [Quit: CodeSpelunker]
FireFox317 has quit [Ping timeout: 246 seconds]
<pixelherodev>
Lots of stage2 issues, i see :)
<leeward>
Sounds like a good sign.
<andrewrk>
retired the waterfall project, it's all issues now
<leeward>
So, I'm assuming that pixelherodev has no reason to know what waterfall, kanban, or agile are. Am I wrong?
<pixelherodev>
s/reason/desire
<pixelherodev>
FTFY
<leeward>
Yeah, most people don't have desire; it's not optional in many workplaces.
<andrewrk>
I was only trying to avoid issue spam in the early stages of self-hosted. Now that the project has lift-off and people are starting to contribute it makes more sense to do issues like normal
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
<andrewrk>
oh man this leak tracking allocator is the shit
<andrewrk>
the stage2 development cycle just got a big upgrade
<leeward>
Yeah, no sense writing tickets when the number of contributors and users is less than 3.
<pixelherodev>
andrewrk: I know, I mentioned that this morning
<leeward>
Well, some sense, but only if it stays that way for a long time.
<andrewrk>
pixelherodev, I fixed an issue and bumped the default to 8 for test modes
<andrewrk>
8 stack frames
<pixelherodev>
I'm going to try to finish up that CBE PR tonight
<pixelherodev>
It's basically done now
<andrewrk>
pixelherodev, just wait until you get a double-free :)
<pixelherodev>
andrewrk: Also, I was totally right :D
<pixelherodev>
I looked at codegen.zig, per your suggestion
<pixelherodev>
It does *exactly what I said I should* :)
<pixelherodev>
It's always a great feeling when that happens
<andrewrk>
oh good, glad it can be resolved without a bespoke solution to CBE
<pixelherodev>
Yep :)
<andrewrk>
btw one of the perf issues to investigate (*after* we set up perf testing benchmarks) is to add an untagged union field to ir instructions, so that you can store 1 pointer sized thing per instruction
<pixelherodev>
Might need better naming than `__temp_{}`, but it's fine for now
<andrewrk>
there will be a lot of instances of anonymous named things
<pixelherodev>
Yeps
<andrewrk>
consider: `a + b + c + d` will codegen to .c code with 4 statements each with an anonymous name
<andrewrk>
err, 3 statements. you get the idea
<pixelherodev>
Yep
<andrewrk>
nice work
<pixelherodev>
Thanks! :)
<pixelherodev>
The one thing left to address was the switch you mentioned
<pixelherodev>
That shouldn't be more than a few minutes of work
ur5us has joined #zig
<pixelherodev>
I also want to minorly refactor render{Type,Value,etc} to use the Context
<andrewrk>
yeah, better to start the code skeleton using the intended API usage, I think
<andrewrk>
contributors tend to follow patterns, it's important to set them on the right track in the beginning
<leeward>
decidedly
<pixelherodev>
to be fully honest... I probably wrote that before noticing zigTagType existed, which is why it used the type directly, whereas other switches used zigTagType (because ZLS told me it existed and it was just obviously the right solution there :P)
lunamn has quit [Read error: Connection reset by peer]
linuxgemini4 has joined #zig
linuxgemini has quit [Read error: Connection reset by peer]
linuxgemini4 is now known as linuxgemini
lunamn has joined #zig
stripedpajamas has joined #zig
CommunistWolf has quit [Quit: No Ping reply in 180 seconds.]
CommunistWolf has joined #zig
Ashpool has quit [Remote host closed the connection]
Ashpool has joined #zig
Ashpool has quit [Remote host closed the connection]
Ashpool has joined #zig
stripedpajamas has quit [Quit: sleeping...]
stripedpajamas has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
ur5us_ has joined #zig
stripedpajamas has quit [Quit: stripedpajamas]
ur5us has quit [Ping timeout: 260 seconds]
klltkr has quit [Ping timeout: 265 seconds]
epmills has joined #zig
xackus_ has quit [Ping timeout: 256 seconds]
epmills has quit [Remote host closed the connection]