<samueldr>
(and I checked if there was a relevant patent)
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 272 seconds]
lassulus_ is now known as lassulus
pie__ has joined #nixos-chat
pie_ has quit [Read error: Connection reset by peer]
sir_guy_carleton has joined #nixos-chat
Drakonis has quit [Remote host closed the connection]
Drakonis has joined #nixos-chat
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-chat
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-chat
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-chat
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-chat
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
tertle||eltret has joined #nixos-chat
Drakonis has joined #nixos-chat
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-chat
Drakonis has quit [Remote host closed the connection]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
jD91mZM2 has joined #nixos-chat
<jD91mZM2>
samueldr: One problem with comments: How should they be represented in the middle of an AST?
<joepie91>
oh man, this serialization stuff turned out to be a real rabbit hole
<joepie91>
I'm now left figuring out how to produce a deterministic hash of a cyclical type specification...
<jD91mZM2>
joepie91: What are you doing?
<joepie91>
jD91mZM2: well... I'm writing a sort of typing/constraint/validation/relation thingem for JS... and I have type specifications... and a traits implementation.... and I need a way to serialize data such that it can be deserialized back into its original typed structure in a different environment with the same type definitions
<joepie91>
this is easy enough when you know exactly what type to expect where... but that is no longer true once you bring trait constraints into the mix
<joepie91>
so I need to encode the type in the serialized data in such a way that it can be related back to a type definition on the other end
<joepie91>
obvious solution: produce a hash of the type definition and use that to find the relevant type
<jD91mZM2>
Ah
<joepie91>
but... types and traits can have cyclical references to each other, with any number of intermediary types
<joepie91>
so how the hell do you hash that :P
<joepie91>
current working theory, and I really dislike this approach but I can't see that I have any other options, is to only use the actual type definition the first time it is encountered somewhere, and from that point on use 'location references' for every subsequent encounter, ie. a description of where the type can be found first relative to the current encounter
* jD91mZM2
doesn't know JS types well enough
<joepie91>
jD91mZM2: this isn't 'JS types' :P
<jD91mZM2>
Oh?
<joepie91>
this is an entirely runtime typing implementation
<joepie91>
no language-specified typing involved really
<joepie91>
or well, this is not just a typing implementation, but that's the part I'm working on now
<joepie91>
essentially I'm bolting a constraint/validation/typing system onto JS
<joepie91>
specifically for use with long-lived semi-persistent data
<jD91mZM2>
Not sure what problem traits introduce. Excuse me if I'm stupid, but can't the name of the trait be used as type?
<joepie91>
ivan: that doesn't seem like it can accommodate my typing requirements though
<ivan>
what are you typing requirements?
<jD91mZM2>
Like, Java style. Interface value = 5;
<joepie91>
jD91mZM2: the problem is that a trait is a constraint, not a type; it specifies that whatever type is specified must *implement* that trait, ie. specify that it wishes to implement the trait and satisfy all the interface requirements introduced by the trait
<joepie91>
jD91mZM2: so if you want to deserialize it into a concrete type, you can't know just from that "must have trait X" specification which type it should be
<joepie91>
it can be anything implementing X
<jD91mZM2>
What if every value gets a type tag?
<joepie91>
the problem is the 'type tag' part
<joepie91>
I need a deterministic way to produce a type tag that doesn't come down to "globally reserved name"
<joepie91>
(as that would break modularity)
<joepie91>
ivan: ^
<joepie91>
hence why I am looking into hashing the type definitions themselves
<jD91mZM2>
Can you do some name mangling like C++?
<joepie91>
nop :P
<joepie91>
name mangling requires explicit namespacing
<ivan>
take a look at how clojurescript implements protocols in javascript
<ivan>
not sure if directly applicable to your problem
<ivan>
I need a better problem description but I also need to sleep
<joepie91>
ivan: from a quick glance that seems to be a name mangling approach based on explicit namespacing :/
<joepie91>
and go get some sleep :P
<joepie91>
I think I'm just going to stick with location references for now, until a better solution comes along
<joepie91>
(the reason I don't like them is because they're finicky to get right consistently)
<joepie91>
(though I guess it helps that type definitions are immutable...)
Drakonis has joined #nixos-chat
Drakonis has quit [Quit: Leaving]
<jD91mZM2>
How bad would it be to keep comments in the AST like this: Add(3, Comment("comment inbetween + and 4", 4))?
<jD91mZM2>
So the comment is basically Comment(String, <rest of the AST>)
<joepie91>
jD91mZM2: afaik comments in ASTs is still basically an unsolved problem :P
<joepie91>
at least in the sense that there is no elegant solution
<joepie91>
would recommend looking at how it's done in ESTree / Esprima / Acorn
<joepie91>
there's a significant pile of tooling built on them so evidently whatever they're doing can't be *that* bad :P
<jD91mZM2>
joepie91: Seems like Esprima has one trailingComments vector at the end of each AST
<jD91mZM2>
That's something I considered doing as well, problem is that my ASTs are rust enums, which can't hold fields that apply to all variants
<joepie91>
jD91mZM2: you could specify a trailingComments field on every variant though? or alternatively write a macro to do that (or even just have a type specifically for holding that information and referencing it everywhere)
<jD91mZM2>
ew
<jD91mZM2>
I have kinda solved this with spans, keeping a wrapper tuple struct, like AST(Span, ASTType)
<jD91mZM2>
This caused enough issues with unit tests breaking because I don't supply span information in the tests. That I solved by making an extra ASTNoSpan type that discarded all the span data
<jD91mZM2>
For comments it seems better to just have a specific AST type that can hold a comment and the trailing/leading AST
<joepie91>
lo and behold
<joepie91>
my cyclical type hashing appears to work
<jD91mZM2>
Impressive! How'd you find out the types?
<joepie91>
jD91mZM2: in what sense>?
<jD91mZM2>
Maybe I'm wrong, but it looks like you somehow detect that User is a string?
<jD91mZM2>
Wait, never mind
<jD91mZM2>
I thought you somehow parsed that JS into that output
<jD91mZM2>
I can be slow at times :P
<joepie91>
jD91mZM2: oh, nah :P
<joepie91>
jD91mZM2: the JS is type definitioins that use my library to define those types, and the second gist contains the internal representation pre-hashing of all the type definitions and their references
<joepie91>
definitions*
<joepie91>
so it's mostly just a matter of producing simpler representations of every type, and tracking cyclically dependent types and replacing them with relative-location references (ie. the levels thing)
<joepie91>
but it took quite a few failed designs to get there :P
<jD91mZM2>
Ooo, now I see
<jD91mZM2>
Cool!
<joepie91>
for example, every type hash requires a full evaluation of every dependent type, even those for which a hash has been previously calculated
<joepie91>
because to get deterministic output, despite the relative-location references, every type hash must be calculated from the perspective of the initial type you tried to generate a hash for
<joepie91>
so my first attempt of 'generate a hash for a type and then store that and use it everywhere else' turned out impossible to implement
* jD91mZM2
pretends to understand all of that
<jD91mZM2>
I see
<joepie91>
lol
<joepie91>
jD91mZM2: this is my kind of mad science
<joepie91>
but once it's done, I'll have strongly-typed/validated/etc. serialization/deserialization with support for cyclical type references, all at runtime, with zero language cooperation!
<jD91mZM2>
\o/
<joepie91>
and then I'll finally have shaved sufficient yaks to start working on my... messaging client
<jD91mZM2>
joepie91: Ooo, what's it gonna be? Messaging clients have me a little interested because even though there are infinite of them, the amount of good messaging clients is limited
<joepie91>
[10:09] <joepie91> 6) unified messaging implementation that isn't a trainwreck like libpurple
<joepie91>
something like that :P
<joepie91>
I want a single messaging client that actually works well (also for intensive and professional use) for all protocols I use
<joepie91>
with first-class support for all of them
<jD91mZM2>
Oh, so it'll support IRC and other things?
<joepie91>
this is apparently an impossible ask for existing clients
<joepie91>
yeah
<jD91mZM2>
Nice!
<gchristensen>
well they all use libpurple
<joepie91>
IRC, XMPP, probably Matrix are the things I'll be implementing myself
<joepie91>
probably others will eventually pitch in with their own plugins
<joepie91>
gchristensen: right, and libpurple is a trainwreck :P
<jD91mZM2>
Is it bad that `man configuration.nix` is no longer in my shell history? Haven't edited my setup for too long
<joepie91>
like, you know the joke about how Wordpress is a remote shell with blogging as a handy side-feature?
<joepie91>
same for libpurple, except messaging
<joepie91>
it's absolutely fucking terrifying how bad libpurple is from a security perspective
<joepie91>
especially considering how widely it is used and how little review it has had, and how it's littered with unmaintained implementations for obsolete protocols
__monty__ has joined #nixos-chat
<joepie91>
so yeah, I'm taking a scorched-earth approach in dealing with messaging protocols :P
<gchristensen>
sounds great
<jD91mZM2>
Should my nix parser provide any convenience stuff on the AST, like simplifying mathematical expressions, inlining variables, or whatever?
<jD91mZM2>
(and especially inlining imports, which seems like the most useful usecase)
<joepie91>
jD91mZM2: I would expect the parser itself to provide an AST that exactly provides a representation of the original code
<joepie91>
leaving any more complex logic (including handling imports, inlining, etc.) to higher-level tooling
<joepie91>
mostly to avoid the scenario of "blah I need the original AST for this $weirdUsecase but the parser won't let me do that"
<joepie91>
(and for the general advantages of single-responsibility implementations :P)
<joepie91>
jD91mZM2: real-world example: all the ISO9660 implementations I was able to find a while ago were either insufficiently complete or had a hard dependency on the filesystem
<joepie91>
I ended up writing my own because I needed to extract data from an ISO over HTTP using range requests, without downloading the whole thing
<joepie91>
and that wasn't possible with the existing implementations because they all assumed "oh they must be reading it from a filesystem, let's just put the I/O calls directly in the parser"
tertle||eltret has quit [Quit: Connection closed for inactivity]
<__monty__>
Dates back to Knuth I think.
<__monty__>
Oops, wrong channel. But whatever was said, it probably still applies : )
<elvishjerricco>
Oh cool. You can set different properties for different datasets with ZFS. Anything useful to set on /nix/store?
<infinisil>
elvishjerricco: I usually set atime=off and xattr=off
<infinisil>
And compression on everything of course
<elvishjerricco>
infinisil: Are there significant drawbacks to compression?
<infinisil>
Nope
<infinisil>
I guess if your CPU is ancient and can't do it efficiently then yes, but that's unlikely
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-chat
<elvishjerricco>
infinisil: Sweet. Guess I'll turn that on.
<infinisil>
elvishjerricco: It makes my /nix 2.14 times smaller, from 108GB to 54GB :)
<infinisil>
Oh wait, wrong numbers, those GB's
<jD91mZM2>
joepie91: Sorry for the late reply, dad said we were going to a family friend quickly, but it took 2 hours because usually dad is horrible at estimating.
<jD91mZM2>
The parser will of course not do any inlining by default, but I thought it could be nice to have extra optional functions for common usecases
<joepie91>
jD91mZM2: I'd still keep those in a separate library/implementation
<joepie91>
(designed against the format produced by the AST parser)
<jD91mZM2>
Got it!
<jD91mZM2>
Btw introducing span information to the AST got me in lots of trouble with the unit tests lol
<jD91mZM2>
Since I then would either have to test all the span information which is waaay too messy, or discard it. But I can't easily just "discard" it and compare to one without
<jD91mZM2>
Ended up creating a while separate ASTNoSpan type that can be converted to from a normal AST
<samueldr>
jD91mZM2: (haven't caught up) I have no idea
<samueldr>
though, from a quick overview, another answer: probably not, simplifying should be a transformation step that's opt-in; for tranformation uses (format, linting, etc) keeping the pristine AST is necessary I think
<samueldr>
though I have no *actual* experience yet
<joepie91>
jD91mZM2: honestly for most of the design considerations you can probably just literally copy whatever the javascript tooling is doing, lol
<joepie91>
there's years of bikeshedding behind those
<joepie91>
sorry, did I say bikeshedding? I meant well-informed rational discourse
<joepie91>
jD91mZM2: I have now progressed to a point where I seem to be breaking the stacktraces produced by V8
<joepie91>
some excerpts:
<joepie91>
at Object.assign.constraints.rule._constraints.map (src/type-hash.js:130:12)
<joepie91>
at Array.map (<anonymous>)
<joepie91>
also two line numbers appear to be getting swapped around somehow?
<jD91mZM2>
joepie91: I have no experience with the JS tooling
<joepie91>
jD91mZM2: it's generally pretty well-documented though
<joepie91>
including a specified AST format, standardized tooling around it, that sort of stuff
<joepie91>
(ESTree and ESTools respectively)
<jD91mZM2>
joepie91: Cool!
<jD91mZM2>
I implemented interpolation into rust-nix today btw, so I think I'm just missing: lists, everything functions, if..then..else, and inherit
<joepie91>
jD91mZM2: have you gone into edge cases yet? :P
<joepie91>
there are some fun ones, like space sensitivity...
<jD91mZM2>
joepie91: Not too much. I imagine trying to parse nixpkgs will reveal a lot
<jD91mZM2>
I've noticed some really quirky path handling
<joepie91>
having started writing a Nix parser in JS: oh yes
<jD91mZM2>
a/b is a path
<jD91mZM2>
a / b is a value
<joepie91>
yep
<jD91mZM2>
a/ b is a path
<joepie91>
and foo-bar is an attrpath
<jD91mZM2>
In fact, EVEN a+b/c IS A PATH
<joepie91>
but foo - bar is an expression
<joepie91>
dunno about foo- bar and foo -bar
<jD91mZM2>
Worst part, a+b is not an ident
<jD91mZM2>
Had to rewrite the parser to be able to do lookaheads
<joepie91>
I suspect `foo -bar` would be parsed as negative bar being passed as an argument to foo
<jD91mZM2>
Which is sad, I liked having it being able to take an iterator as input
<joepie91>
hehe
<joepie91>
yeah, Nix is not exactly a language with particularly clean syntax, parser-wise
<joepie91>
jD91mZM2: iirc hnix has a crapton of cornercase tests btw
<joepie91>
I have a few stored locally as well, somewhere
<joepie91>
I can dig them up for you at some later time
<samueldr>
hard for a parser, but a lot of things imho make it good for its domain :/
<samueldr>
(for those that didn't follow yesterday, I, too, tried to write a parser)
<joepie91>
samueldr: mmm. there's a lot of cornercases that could... not be cornercases, without affecting domain suitability
<joepie91>
:P
<MichaelRaskin>
Well, the parts hardest for parsers are actually the parts we avoid using too much
<joepie91>
but you still have to support them :D!
<joepie91>
doesn't help that there's no up-to-date language spec
<joepie91>
language spec is basically 'whatever the reference implementation does'
<joepie91>
jD91mZM2: btw, I can probably roll JS bindings once you have the parser working :P
<samueldr>
yes, not *everything* is to help the domain-specifics, but I'm thinking about those examples (without the counter-examples)
<samueldr>
maths should probably always have been separated by someting, spaces, parens, so a+b probably should have never wored, since a-b is a valid identifier
<samueldr>
sams for a*b a/b
<samueldr>
same*
<samueldr>
but I guess we're stuck with the language until maybe nix 3 :o
<joepie91>
samueldr: tbh, I am not convinced that the function call and list syntax were a good choice
<joepie91>
the resulting space sensitivity is causing lots of problems
<joepie91>
including the infamous function-call-within-a-list problem
<joepie91>
and readability-wise I find the function call syntax etremely lacking, to the point where I end up using parens and lots of intermediate assignments anyway
<joepie91>
extremely*
<jD91mZM2>
I dislike the idea of a-b being a valid identifier
<joepie91>
that one is kind of understandable given the domain
<joepie91>
package names and all that
<samueldr>
yeah, the function call is one I don't like
<jD91mZM2>
Oh, true with the package names
<samueldr>
yeah, identifiers-with-dashes is foreign when coming from some (most) backgrounds, but I wouldn't exchange it
<jD91mZM2>
I mostly just dislike everything paths
<samueldr>
a linter could (when no `with` is used) figure out whether a-b is a valid identifier or a possible mistake
<jD91mZM2>
Welp, I just found another thing to hate about them
<jD91mZM2>
Apparently even 3-2/1 is a path and not math
<joepie91>
that makes sense
<samueldr>
:)
<joepie91>
paths can have dashes
<samueldr>
I think the mistake is allowing maths with identifiers in nix
<jD91mZM2>
My parser currently only allows stuff to start with [a-zA-Z]
<jD91mZM2>
identifiers and paths I mean
<jD91mZM2>
Eh, it should be ./3-2/1
<samueldr>
it should have been (builtins.add a b) only :)
<joepie91>
jD91mZM2: there's a regex in the reference implementation that specifies what a path can be
<joepie91>
iirc
<joepie91>
samueldr: meh
<samueldr>
yeah, three regexes
<joepie91>
also, you meant operators I think
<jD91mZM2>
I know, I've seen that. Didn't read it closely enough
<samueldr>
yeah joepie91
<samueldr>
or maybe a "maths" thing
<samueldr>
because let's be honest: what percentage of nix is maths compared to other programming languages?
<joepie91>
math(4 + 3 - 1)
<joepie91>
done
<simpson>
samueldr: 100%, because computer science is a subfield of maths.
<samueldr>
simpson: splitting hairs :D
<samueldr>
I think you know what I meant :)
<joepie91>
lol
<jD91mZM2>
joepie91: Nonono please, now the tokenizer needs to know if it's a function
<samueldr>
s/math/arithmetic/ probably
<joepie91>
pft, tokenizers
<simpson>
samueldr: Hey, you asked me to be honest.
<samueldr>
you got me there :/
<jD91mZM2>
joepie91: ??
<joepie91>
hah
<joepie91>
jD91mZM2: I'm not a fan of the tokenizer/parser distinction
<joepie91>
it's a leaky abstraction
<jD91mZM2>
It is kinda weird, but it serves a purpose
<joepie91>
for... well, precisely the reason you just mentioned
<joepie91>
jD91mZM2: the only vaguely compelling argument I've ever seen for it is "so that you can tokenize and parse in two separate threads"
<joepie91>
which is an edge case if I've ever seen one
<jD91mZM2>
To me it just seems a crap ton easier
<joepie91>
it's not though :P
<simpson>
joepie91: The biggest boon is that composition of relatively weak tokenizer and parser can yield a relatively complex grammar, e.g. in languages like Python and Haskell with offside rules.
<joepie91>
because halfway through the process you realize that a particular thing needs to be parsed contextually
<joepie91>
and the split between the two is no longer clean
<jD91mZM2>
In the parser to say "I expect the next token to be a semicolon", rather than ""oH lETS ReAD All WhIETePSaCe FiRSt Ok IS ThIS A SemiCoLOn?"
<jD91mZM2>
also for strings
<joepie91>
I honestly can't say that I've ever seen a case where a tokenizer/parser split made things easier than eg. a single-pass PEG grammar
<joepie91>
what I *do* regularly see is tokenizer hacks to deal with contextually parsed things...
<joepie91>
also, one of these days I should make some PRs to PEG.js
<joepie91>
there's a few common cases that it requires too much decorum for...
<joepie91>
like eg. things with separators
<jD91mZM2>
Ah, PEG.js is a parser... parser?
<jD91mZM2>
parser interpreter?
<joepie91>
jD91mZM2: parser generator
<joepie91>
uses PEG grammars
<joepie91>
the three main approaches for parsing right now are, more or less, 1) hand-rolled parser, 2) parser generator, 3) parser combinator library
<joepie91>
(PEG.js and lex/yacc are the second kind, nom is the third kind)
<samueldr>
I'm beginning to wonder if in the end my PEG-based parser could have worked... I know that I didn't understand everything fully
<joepie91>
samueldr: I've run into a few tricky cases but I've not yet found anything _impossible)
<joepie91>
_*
<joepie91>
at least with PEG.js
<joepie91>
it's mostly ergonomics issues
<samueldr>
past-me should have left better notes about what I was doing :/
<joepie91>
part of the problem is that PEG-based generators are not especially standardized and so there's not a lot of documentation on how to approach common cases
<samueldr>
yes!
<joepie91>
but with enough persistence it can be done
<joepie91>
I've been using that parser that I gisted on all-packages.nix and I believe I'm thousands of lines in, although I have not exhaustively checked correctness yet
<joepie91>
and I'm definitely not yet handling all corner cases correctly
<jD91mZM2>
joepie91: Fun fact: I always underestimate what an idiot with too much time (myself) can do. This is why I normally make hand-written everything, to prove to myself that "that's not too bad, see?"
<samueldr>
joepie91: does your parser keep all the information around? comments, whitespace
<joepie91>
samueldr: no, those are discarded
<samueldr>
:(
<joepie91>
some PEG parsers do allow keeping this around in a standardized way I believe
<samueldr>
can't piggy back on your hard work
<joepie91>
all PEG.js does is keep around location information
<joepie91>
and you *could* make comments part of the AST
<joepie91>
but I have not had a reason to try that :P
<joepie91>
samueldr: the comment/whitespace rules are near the top btw
<samueldr>
joepie91: nixfmt
<samueldr>
you need the comments to re-output them :)
<samueldr>
(I think)
<joepie91>
yeah, I don't do auto-formatting tools :)
<joepie91>
I find auto-formatters to be solving problems at the wrong level
<samueldr>
you can't fix humans :(
<joepie91>
lol
<joepie91>
not what I meant
<joepie91>
the problem with auto-formatters is that they are used to mutate the actual code in files
<samueldr>
though, not strictly "format it", but also allow giving the hints about the formatting
<jD91mZM2>
I feel like I could start writing an example (far from optimal, but example ) formatter soon with rust-nix
<joepie91>
which means you lose a lot of author hints where formatting inconsistency is used to convey a particular meaning
<samueldr>
so an integration with an IDE could be made to show: yeah, this should probably be on a newline
<joepie91>
which worsens readability
<samueldr>
yes
<samueldr>
"nixfmt" was a way to shorten this
<joepie91>
and if you want everything to be formatted consistently, sure, but that's a display concern and should not mutate the underlying code
<joepie91>
afaik nixfmt is meant for mutating code files?
<samueldr>
I don't know if there's a nixfmt tool yet
<joepie91>
there isx
<joepie91>
is*
<samueldr>
ah
<joepie91>
experimental though I believe
<samueldr>
if I were to implement one, it *could* but would also work like linters do by showing where to fixup things
<joepie91>
anyway, implementing this as an editor display feature, sure, no problem with that
<joepie91>
samueldr: I also have issues with linters that try to enforce style :)
<samueldr>
and I'd make sure to make the distinction between indentation and alignment
<joepie91>
for exactly the same reason
<joepie91>
consistency is not actually a desirable property of code
<joepie91>
and I am aware that this is an unpopular opinion
<joepie91>
but I'm not too concerned about that given that nobody who disagrees with this has ever been able to present objective readability metrics to me...
<samueldr>
joepie91: I'm with you here that you can't have *one* representation fit all
<samueldr>
but there are easy fixes that could at least be warned about
<joepie91>
easy fixes for what? inconsistency? :)
<samueldr>
yes
<joepie91>
that presumes that consistency is a desirable end goal again
<samueldr>
let's assume it is for this case
<joepie91>
it isn't
<samueldr>
when the tool *understands indentation vs. alignment* it can tell you where you mixed and matched wrongly
<joepie91>
and honestly, I don't really have the time for this discussion right now, because it inevitably results in an hour of trying to argue that "well consistency is fine if you limit it to..."
<MichaelRaskin>
Well, if you extrapolate from grammar studies…
<joepie91>
and I need to sleep
<samueldr>
sleepie91
<joepie91>
samueldr: also, indentation is an easy one, tabs are correct, the end
<joepie91>
:P
<samueldr>
joepie91++
<{^_^}>
joepie91's karma got increased to 2
<MichaelRaskin>
But frankly, Nix code is edited almost as much as it is read
<jD91mZM2>
tabs?
<jD91mZM2>
What are those?
<jD91mZM2>
You mean 4 spaces?
<samueldr>
tabs for indentation, spaces for alignment
<samueldr>
it's as simple as that
<joepie91>
(and when I say 'correct' I mean that literally, I don't mean "it is my preference")
<MichaelRaskin>
_Two_ lightnings to the heretic, please
<joepie91>
(I mean _semantically correct_)
<jD91mZM2>
Ah yes, two for nix, four for everything else
<joepie91>
samueldr: alignment is also a display concern
<samueldr>
well, in my humble real opinion, neither are right, programming languages should evolve beyond plain-text
<MichaelRaskin>
Elastic tabs for alignment would be a nice dream
<joepie91>
as is line wrapping
<joepie91>
none of these things have any place in code
<joepie91>
samueldr: oh, that I agree with
<samueldr>
every time I say something like that I'm looked at like a trollish creature :)
<joepie91>
samueldr: what, that it needs to evolve beyond plaintext?
<joepie91>
:p
<samueldr>
yes
<joepie91>
also an unpopular opinion, I am aware
<joepie91>
nevertheless valid
<joepie91>
humans are not that good at parsing text :P
<MichaelRaskin>
Going beyond plaintext means fragmenting editing different languages
<samueldr>
tabs and spaces are a temporary measure for readability that should have been replaced with something else entirely, but the parties are still arguing instead of evolving ;)
<MichaelRaskin>
It will take a few eterneties to reconverge
<joepie91>
samueldr: I'm not sure if you're trying to say something provocative but you are not going to find disagreement from me on this line of discussion
<joepie91>
lol
<samueldr>
I think we're kinda agreeing
<MichaelRaskin>
Basically, information processing on computers is still going downhill, so I do not trust move from plain text will not lead to more absurdity
<samueldr>
one is assuming there is a hill to control the fall
<joepie91>
MichaelRaskin: the point of moving away from plaintext is to remove a layer of mental translation
<joepie91>
and represent logic as something that is more intuitively interpretable to humans, and less error-prone
<joepie91>
therefore reducing mistakes
<samueldr>
joepie91: pretty sure we're agreeing because of how you phrased that
<andi->
lets go back to punch cards?
<joepie91>
andi-: that's just *more* mental translation :P
<MichaelRaskin>
joepie91: text with minimal decorations is a representation of information that we have already learned both to comprehend from senses and to edit
<joepie91>
MichaelRaskin: and that right there is precisely the problem
<joepie91>
"learned to"
<andi->
joepie91: no no you got it all wrong! It is an abstraction of text. It is just a bit more verbose :-)
<joepie91>
there is no intuition to it
<MichaelRaskin>
Oh right, these myths
<MichaelRaskin>
There is no common intuition to anything
<andi->
intuition that tells you that jumping from a bridge might be a bad thing is common?
<MichaelRaskin>
andi-: first, I think experience shows it is not completely universal
* joepie91
doesn't feel that this discussion has a chance of getting anywhere fast
<joepie91>
yeah, maybe I'll engage on this later, but I'm going to sleep now
<MichaelRaskin>
Any reasonable intuitions are grounded in biology. No undo, and you need to make less errors than the other hunter.
<MichaelRaskin>
Good night
<{^_^}>
MichaelRaskin: Night!
<MichaelRaskin>
Hm
<MichaelRaskin>
joepie91: Good night
<joepie91>
MichaelRaskin: Bret Victor has done some interesting (albeit non-generalizable) work in this area, btw
<MichaelRaskin>
I know
<MichaelRaskin>
Some of that is interesting, but I have no idea how to scale this
<joepie91>
I don't think that his work - as he presented it, anyway - is exactly scalable
<joepie91>
nevertheless it gives a good idea of what properties make for more intuitive development
<joepie91>
anyway, time to sleep :P
<joepie91>
night
<joepie91>
bot does not like me :(
<samueldr>
infinisil implemented to be on a timer so it wouldn't spam the channels
<samueldr>
(the good night thing)
<infinisil>
:P
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-chat
<gchristensen>
cute :)
<gchristensen>
infinisil: maybe drop the user highlight so it doesn't wish the wrong person a good night
jD91mZM2 has quit [Quit: WeeChat 2.0]
Drakonis has joined #nixos-chat
<infinisil>
gchristensen: Hmm maybe
<MichaelRaskin>
Yes, I was wishing goodnight, not leaving
<infinisil>
Ah right, yeah I'll do that
<infinisil>
I should slap some language processing on it :P
<gchristensen>
just hook it up to ELIZA
<MichaelRaskin>
No chance: from single-message point of view there was not enough context
<infinisil>
"I'm going to sleep now" should be enough
<MichaelRaskin>
It reacts to simple «Good night», though
<infinisil>
Yeah currently
<MichaelRaskin>
That can be directed or not, and the distinction is close to NLP-complete
<gchristensen>
I should properly deploy my "wish me luck" bot
<MichaelRaskin>
Will it also react to «hold my beer»?
<infinisil>
gchristensen: *cough* I stole that feature heh
<infinisil>
But I'll turn it off for you ;)
<gchristensen>
oh good! would you like my list of responses?
<gchristensen>
it picks three and always finishes with an English good luck
<infinisil>
Hehe
<MichaelRaskin>
It has Cyrillic but not Russian? Really?
<gchristensen>
I just picked a big list off the internet and deleted ones I didn't feel confident were a complete phrase based on how the list was formatted
<MichaelRaskin>
Right, in Russian it can be said as a single word
<infinisil>
MichaelRaskin: You speak russian?
<MichaelRaskin>
It is my native language
<gchristensen>
:)
<infinisil>
:O
<MichaelRaskin>
Why is it _that_ surprising?
<infinisil>
Haha, I just have no idea where all of you are from in general
<infinisil>
I know gchristensen is from usa though
<MichaelRaskin>
I am from Moscow, but a postdoc somewhere in Europe recently, but in Moscow right now to apply for a visa which would create annoying risks if I would apply from France
<gchristensen>
are you a Dr. Michael Raskin?
<MichaelRaskin>
Which styling I never use, as I am either in a situation where this is irrelevant, or where it is more or less obvious.
<MichaelRaskin>
Also, Russian-language leaks: in Russian, just doctor is next stage after PhD-equivalent
<MichaelRaskin>
(And I only hold PhD-equivalent)
<gchristensen>
yeah, I'm just not sure how I, who barely graduated high school, came to be part of such a huge community of brilliant people.
<MichaelRaskin>
Answer: by not trying to argue finer points of parsing ambiguities in the syntax?
<MichaelRaskin>
I mean, degrees are never relevant to doing the programming.
<gchristensen>
my mom says I should go for a phd
<MichaelRaskin>
Dunno if the negotiation benefits are worth the effort of getting it (if you want to work with universities, though…)
<MichaelRaskin>
No doubt you are good enough in designing and implementing things to write something that can be presented as an applied-CS PhD work, and your articles have a good chance to be much nicer than median
<gchristensen>
that might be the nicest complement I've ever received
<MichaelRaskin>
Every compliment is well complemented by a jaded comment on status quo?
gchristensen has quit [Ping timeout: 268 seconds]
gchristensen has joined #nixos-chat
__monty__ has quit [Quit: leaving]
Lisanna has quit [Remote host closed the connection]