<alexgordon>
pretty sure whitequark wouldn't have that reaction to transformers porn
<alexgordon>
or maybe he would
<cuttle>
so it's basically an frp language
<alexgordon>
I dunno, whitequark sent us ACTUAL porn before
<cuttle>
like, hooking up functions to each other
<alexgordon>
so I'm assuming he's not that squeamish
<ELLIOTTCABLE>
squeamishquark?
<alexgordon>
cuttle: function sex?
<whitequark>
alexgordon: it was surprisingly strange
<cuttle>
so i kind of want to have less internal state in the functions themselves than i do right now, maybe move it out into some big ol databse thing
<cuttle>
but like
<ELLIOTTCABLE>
function speed-dating?
<cuttle>
for now thats how it is
<cuttle>
so
<whitequark>
cuttle: hmm interesting
<cuttle>
the inspiration:
<whitequark>
you know that lisps and co represent oo by saying that object is a function, and you send it messages by invoking it?
<ELLIOTTCABLE>
confused. inevitably.
<whitequark>
and it encapsulates all the state
<cuttle>
"you can represent data as functions, but it's more interesting to represent functions as data. you can pass data over a network. how do you pass functions over a network?"
<alexgordon>
cuttle is the straight man, right?
<cuttle>
whitequark: right, sicp style
<joelteon>
okay, so what I have to do
<whitequark>
cuttle: I think you can make it cleaner by combinators
<joelteon>
what I have to do is store event state myself
<joelteon>
and then in the game tick, modify acceleration based on that
<chellio>
Happy now?
<whitequark>
so you would have clean pure stuff to represent computation
<joelteon>
then speed based on acceleration
<ELLIOTTCABLE>
lol it's chelsea
<purr>
lol
<joelteon>
that's stupid as fuq
<ELLIOTTCABLE>
NO I AM NOT HAPPY I AM SAD
<whitequark>
cuttle: and dirty stuff around to support it
<joelteon>
ugh
<joelteon>
what's the point of this game
<alexgordon>
jesus christ what is that thing
* alexgordon
just clicked the link
<joelteon>
i should probably design a game first
<joelteon>
before i try to write it
<whitequark>
alexgordon: yes exactly
<alexgordon>
why so much HAIR
<alexgordon>
and METAL
<alexgordon>
fuck
<ELLIOTTCABLE>
chelsea and I are snorting with laughter.
<ELLIOTTCABLE>
aaaaand then she put rice on her face.
<ELLIOTTCABLE>
bbl.
<ELLIOTTCABLE>
wait, no.
<ELLIOTTCABLE>
listening to cuttle.
<ELLIOTTCABLE>
so.
<cuttle>
so
<cuttle>
there is one data structure
<ELLIOTTCABLE>
what's your approach to inverting data-as-functions?
<cuttle>
it's not stupid shit like urbit's pairs and atoms
<cuttle>
it's literally
<cuttle>
a bunch of fucking bits
<ELLIOTTCABLE>
binary sexps?
<whitequark>
so no memory safety?
<cuttle>
but the type system is like a haskell that doesn't abstract
<cuttle>
no, very much memory safety
<ELLIOTTCABLE>
I mean, not directly, but conceptually
<whitequark>
well
<cuttle>
so functions are basically from a region of bits to a region of bits
chellio has joined #elliottcable
<ELLIOTTCABLE>
wert
<whitequark>
I guess you could just say that you have a big bunch of bits representing entire RAM
<cuttle>
so they're very restricted on what memory they can touch
<whitequark>
I mean really
<cuttle>
and the type system will guarantee you can't fuck up integrity of a structure and then pas sit to a function that needs that structure
<whitequark>
did you just invent hardware virtualiztaion?
<ELLIOTTCABLE>
LOL
<ELLIOTTCABLE>
whitequark: wat.
<purr>
beep.
<cuttle>
whitequark: well this is not a von neumann thing
<whitequark>
ELLIOTTCABLE: what's about?
<cuttle>
whitequark: it would be implemented, for now, obviously, on top of that
<whitequark>
cuttle: I don't think hw virt is required to be von neumann
<ELLIOTTCABLE>
you understand the what feature, right?
<cuttle>
but eventually i want it on some fpga shit
<ELLIOTTCABLE>
it's for messages that would make great non-sequitur.
<whitequark>
ELLIOTTCABLE: yes
<whitequark>
ELLIOTTCABLE: I don't get what surprised you
<whitequark>
cuttle: um
<whitequark>
cuttle: wait.
<whitequark>
first
<ELLIOTTCABLE>
it's not necessarily surprising, in-context.
<alexgordon>
I'm fairly sure cuttle explained nothing at all and you guys are just making shit up now to confuse me
<ELLIOTTCABLE>
it's just excellent *out* of context.
<cuttle>
alexgordon: why do you have to be so negative
<whitequark>
cuttle: "you can't fuck up integrity of a structure"
<joelteon>
i feel like the poorest son of a bitch
<ELLIOTTCABLE>
alexgordon: you haven't realized by now that #ELLIOTTCABLE is a conspiracy for your benefit?
<whitequark>
cuttle: I guess I should ignore alexgordon now
<joelteon>
my common projects haven't shipped so i wore lim x target sneakers today
<cuttle>
whitequark: i haven't gotten to what "structure" means yet
<whitequark>
despite ec's predictions this worked with otters
<joelteon>
how embarrassing
<whitequark>
:p
<alexgordon>
oh man I'm on the list
<joelteon>
oh you're ignoring ME for saying irrelevant things
<whitequark>
cuttle: ok go on
<cuttle>
ok so
<joelteon>
does he have me ignored?
<whitequark>
I have also a filter in my head
<joelteon>
whitequark do you have me ignored now
<alexgordon>
joelteon: not sure, do you know any russian insults?
<cuttle>
if you define your data structures as like
<joelteon>
dunno
<joelteon>
"russian"
<joelteon>
that's an insult
<cuttle>
a bundle of pointers to other data structures
<ELLIOTTCABLE>
can't decide if I should ignore somebody in my own channel.
<ELLIOTTCABLE>
does that make them not exist?
<joelteon>
no
<whitequark>
ELLIOTTCABLE: yep
<joelteon>
who are you ignoring
<ELLIOTTCABLE>
since you're all figments of my imagination?
<joelteon>
is it me
<cuttle>
then making cyclic stuff is hard in an immutable language
<cuttle>
and
<joelteon>
just like everybody else is ignoring me
<cuttle>
garbage collection and shit
<ELLIOTTCABLE>
cuttle: well, duh …
<cuttle>
isn't fun
<joelteon>
cyclical things in immutable languages is ridiculously easy
<whitequark>
cuttle: it still doesn't click for me
<joelteon>
let m = 1:m in m
<cuttle>
but so that's not what this is
<alexgordon>
joelteon: try пенис вашей матери вял
<cuttle>
whitequark: haven't finished :p
<cuttle>
so what this is, is a way of formatting a region of bits
<joelteon>
that's [1,1,1,1,1,1,1,...]
<cuttle>
so a type is a lens through which to view the bits
<whitequark>
joelteon: that breaks the language rules
<cuttle>
and it would have way nice primitives
<whitequark>
as in, it's internally implemented with mutability
<joelteon>
oh
<whitequark>
which you can't access
<whitequark>
Obj.magic
<cuttle>
for making like graphs and directed graphs and cycle graphs
<cuttle>
cyclic*
<ELLIOTTCABLE>
SLOW DOWN
<ELLIOTTCABLE>
DICKS
<whitequark>
ELLIOTTCABLE: no u
<joelteon>
uhh, i guess
<whitequark>
ooooh
* whitequark
is all anticipation
<joelteon>
oh what
<joelteon>
i forgot i had voice
<cuttle>
oh hey i have voice
* cuttle
waves
<ELLIOTTCABLE>
okay, cuttle, go
<purr>
lol
<ELLIOTTCABLE>
I'll unmoderate in five minutes. 'cause I'll be leaving. but I want to listen, this interests me.
<cuttle>
so it would all be kinda like C++ templates, in that you define it once and it has many low-level realizations
<cuttle>
ok
<cuttle>
and it's like, you're compiling down to something *kinda* like an fpga
<cuttle>
so every place you use the function it's copied
<cuttle>
and could have differently sized elements in an array etc.
<ELLIOTTCABLE>
so, typed binary language?
<cuttle>
yeah
<cuttle>
you can drop down to bits
<ELLIOTTCABLE>
“<whitequark> cuttle: do you understand how fpgas work?”
<cuttle>
but then if you fuck up the type representation, use operations not guaranteed to preserve it
<cuttle>
whitequark: not all the way, but am somewhat familiar
<ELLIOTTCABLE>
how ‘guaranteed?’
<cuttle>
like
<cuttle>
you define functions like append and remove and stuff for a list of ints
<cuttle>
and so those are type-guaranteed to *keep it an array*
<cuttle>
but
<cuttle>
binary xor
<cuttle>
does not guarantee that
<ELLIOTTCABLE>
type-guaranteed
<ELLIOTTCABLE>
i.e. the “compiler” checks that, then
<cuttle>
yeah
<ELLIOTTCABLE>
checking the logic, like a typed higher-level language,
<cuttle>
and it would be embedded in the os
<ELLIOTTCABLE>
that the logic somehow is guaranteeable to result in a “still sane” data-structure …
<ELLIOTTCABLE>
how is this different from C?
<ELLIOTTCABLE>
stupid-ass question.
<cuttle>
like, the whole functions-are-data thing, all the os does is
<ELLIOTTCABLE>
but, structs of bits.
<cuttle>
take some data that represents a function
<cuttle>
and plug it in
<cuttle>
that's the function of the os
<cuttle>
and so that representation itself would be typesafe in that nature
<cuttle>
anyway it would probably end up being much more von-neumann than fpgas are
<ELLIOTTCABLE>
hmmmmmmmm
<cuttle>
but it would still be more distributed and tiny-cores and frp-network-flowing than any like x86 or arm or whatever
<ELLIOTTCABLE>
you're saying, since “function” code is a type, that the execution-safety of the function type would be preserved by any higher-level function, yes?
<cuttle>
yeah
<ELLIOTTCABLE>
as they can't modify the function's body in such a way that it's no longer validly a function
<cuttle>
well yeah there is a set of operations that will leave you with a valid function
<cuttle>
i don't even know how theoretically possible this all is
<cuttle>
it's a top-down idea for me
<ELLIOTTCABLE>
meh brainstorming don't get bogged down in possible
<cuttle>
but yeah
<ELLIOTTCABLE>
so, again:
<cuttle>
it would favor by-value everywhere
<ELLIOTTCABLE>
how, differentiable from C? given that C structs *are* (or can be) “just hunks of bits”
<ELLIOTTCABLE>
and expound on your “functions are from <block of bits> to <block of bits>”
<cuttle>
well in C you can cast a void* to a goomba_struct
<cuttle>
and c functions optionally take arguments, and modify the whole goddamn ram
<cuttle>
whereas in this language functions take some small region of ram
<cuttle>
and can only touch that
<cuttle>
and like, idk if there would be a central ram. depends on low-level realization of the code
whitequark has left #elliottcable [#elliottcable]
<ELLIOTTCABLE>
LOL
<purr>
LOL
<ELLIOTTCABLE>
turns out whitequark doesn't like +m very much
<ELLIOTTCABLE>
so, it's like a RAM-region-protected, slightly-lower-level C
<ELLIOTTCABLE>
without the assumptions of OS presence / UNIX / whatever that much C programming involves, and without the assumptions of compilation down to a byte code that *all* C programming involves?
<ELLIOTTCABLE>
instead, with some sort of environment / design catering to FPGA'ing the environments into some sort of representation of the actions you encode into those functions …
<ELLIOTTCABLE>
sentence is backwards but it meant what I meant >,<
<cuttle>
right yeah
<cuttle>
and i mean, ram-region-protected, slightly-lower-level c, that is purely functional in that functions can only see their arguments
<cuttle>
and it does have a much higher glass ceiling in terms of abstractions
<chellio>
ellllliooooottttt
<jesusabdullah>
wat
<jesusabdullah>
what is this ELLIOTTCABLE ?
prophile has quit [Ping timeout: 245 seconds]
prophile has joined #elliottcable
<ELLIOTTCABLE>
jesusabdullah: what?
<jesusabdullah>
ram region prowhaaa
<joelteon>
well
<joelteon>
getting into this project was a TERRIBLE idea
<joelteon>
does every game designer figure this out on their own
<cuttle>
joelteon: figure out what?
<joelteon>
using polar coordinates for physics
<cuttle>
the best vector libraries let you use both kinds
<cuttle>
interchangeably
<joelteon>
well i have plebeian vector libraries
<cuttle>
haha
<cuttle>
what are you using?
<joelteon>
i'm not using one
<joelteon>
but i'm sure there is one
eligrey has quit [Quit: Leaving]
<cuttle>
joelteon: no i mean in general
<joelteon>
uhh
<joelteon>
fr what
<joelteon>
graphics?
<cuttle>
yeah
<cuttle>
well like for everything
<joelteon>
gloss
<cuttle>
what language
<joelteon>
and everything else is manual
<joelteon>
haskell
<cuttle>
ahh
<cuttle>
cool
<joelteon>
yeah i'm going all natural
<cuttle>
what approach are you talking?
<cuttle>
taking*
<joelteon>
in the "extremely high language" way
<cuttle>
frp type stuff?
<joelteon>
gloss has a "play" function that automates ticking and event handling
<joelteon>
yeah
<cuttle>
neat!
<joelteon>
well, no
<joelteon>
helm and fungen both are
<cuttle>
:p
<joelteon>
fungen is old
<joelteon>
helm uses SDL
<joelteon>
which doesn't work on OSX
<joelteon>
without the proper sacrifices
<cuttle>
wait I thought it did
<cuttle>
oh yeah
<cuttle>
yeah
<joelteon>
gloss is openGL which generally works
<joelteon>
but doesn't do antialiasing on its own
<joelteon>
this entire thing is an exercise in misery
<cuttle>
yeah
<cuttle>
haskell does not have established ways to make games nicely
<joelteon>
i dooooon't think gloss can do audio
<joelteon>
on its own
<joelteon>
and the game loop must be pure
<joelteon>
god DAMN IT
<joelteon>
oh wait, no
<joelteon>
there's playIO
<joelteon>
and then I can manually play audio
<cuttle>
oh nice
<purr>
<alexgordon> micahjohnston: lol don't be a whitequark
<cuttle>
haha
whitequark has joined #elliottcable
<whitequark>
cuttle: what
fwg has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
fwg has quit [Ping timeout: 260 seconds]
fwg has joined #elliottcable
<purr>
* devyn haggasadandalcold
PragCypher has joined #elliottcable
Sgeo has quit [Read error: Connection reset by peer]
Sorella has joined #elliottcable
fwg has quit [Quit: gone]
brr has quit [Ping timeout: 260 seconds]
brr has joined #elliottcable
yorick has joined #elliottcable
<purr>
<vil> i'm drawing a bunch of songs
niggler has joined #elliottcable
PragCypher has quit [Remote host closed the connection]
PragCypher has joined #elliottcable
<joelteon>
okay, so
<joelteon>
when you're doing acceleration and friction in a game
<joelteon>
do you implement friction as part of acceleration, or as part of speed?
<niggler>
what is friction?
<niggler>
better phrased, is friction a force?
<joelteon>
i dunno
<niggler>
it is :)
<joelteon>
yes
<joelteon>
it is
<joelteon>
duh
<niggler>
there's a coefficient of kinetic/static friction
<niggler>
its not obvious joelteon
<joelteon>
i know
<niggler>
in classical physics the higher order effects are disregarded
<joelteon>
ok so does friction increase as speed increases
<niggler>
the normal way to calculate the magnitude of the force is coefficient * normal force
<niggler>
no
<joelteon>
okay
<joelteon>
so if I subtract a fixed value from the speed each tick, will that be realistic friction effects?
<niggler>
yeah, its an acceleration effect
<joelteon>
okay
<joelteon>
ok brb
<joelteon>
back
<joelteon>
yeah, so what i was thinking was take the x/y input from the keyboard, convert it to polar coordinates, add it to the current speed
<joelteon>
and then to apply friction, i can reduce the y-value of the polar
<joelteon>
which will then auto-magically be converted into x,y again
<joelteon>
but
<joelteon>
adding polar vectors
<joelteon>
is the question
<joelteon>
how do you do that
<joelteon>
oh, that's easy
<joelteon>
it's just sqrt(r^2 + r'^2)
<joelteon>
and the angle is arctan(y'/x')
<joelteon>
awesome, okay
alexgordon has joined #elliottcable
joelteon has quit [Ping timeout: 256 seconds]
joelteon has joined #elliottcable
<purr>
<Nuck> I love the feeling of blood on my dick
<cuttle>
joelteon: and make sure that this doesn't happen:
<joelteon>
okay i can't find anything that does what i want to do
<cuttle>
there are a couple vector libraries on there :P
<joelteon>
yeah, but they both handle vectors of arbitrary dimensions
<joelteon>
and they're excessively complex
* cuttle
shrugs
<purr>
¯\(º_o)/¯
<joelteon>
complex enough that i couldn't figure out how to get a basic magnitude calculation
<joelteon>
so no thanks
purr has quit [Remote host closed the connection]
purr has joined #elliottcable
<ELLIOTTCABLE>
hi
<purr>
ELLIOTTCABLE: hi!
<ELLIOTTCABLE>
chjj: you around?
<ELLIOTTCABLE>
chjj: sorry that my presence is so spotty, I'm in and out as well this week.
<chjj>
ELLIOTTCABLE: what's up?
<ELLIOTTCABLE>
so, I wanted to chat terminals briefly. :D
<chjj>
roger
<ELLIOTTCABLE>
I love your project. I was involved for a while in porting the ncurses API to Ruby, a very long time … and I, rightly, came to hate ncurses with the fury of a thousand suns.
<ELLIOTTCABLE>
It's one of those “honestly … you know what, I'd prefer to just be dipped in bees.” kinda things.
<ELLIOTTCABLE>
so, to see competition of *any* sort, much less a bit lighter/agile/friendlier, much less *implemented in my current language-of-choice*, is just happy-making.
<chjj>
yeah, i really wanted to make it bearable
<ELLIOTTCABLE>
anyway. Unicode support's a big deal to me (I'm the kinda guy who likes lots of colorful text, Unicode art, and pretty indentation in my terminal output.) … but, somehow, widget-drawing is completely outside my area of interest. /=
<ELLIOTTCABLE>
as in, it's boring and difficult enough that it'd turn me off to contributing at all.
<chjj>
we have unicode support, just not wide character support
<chjj>
the double width characters from asian character sets break things, all the rest of unicode is fine.
<ELLIOTTCABLE>
sorry, Unicode-except-for-any-of-the-characters-that-are-wider-than-X-columns support isn't Unicode support in my book /=
<ELLIOTTCABLE>
not to be, er, offensive or anything. Just seems incomplete.
<ELLIOTTCABLE>
so. being a maintainer of a lot of open-source myself, I *know* how much of a pain it is to get contributions that require more effort of yourself. I know that it's often better to not receive such contributions at all, unfortunately.
<ELLIOTTCABLE>
do you *want* me to dive in and start trying to provide upstream widech support in the plumbing API? as that leaves *you* extra work, in further supporting that in all of your widgets code.
<ELLIOTTCABLE>
i.e. I'm sure there's quite a bit of refactoring in width-calculations for widgets' borders and layout and wrapping, etcetcetc.
<chjj>
you can do whatever you want, but i can't guarantee i'll merge your code in if i'm not happy with it. that's another thing too. so much of the code relies on the assumption that 1char=1cell, it would be really easy to screw something up
<chjj>
i want to add wide char support, it's just a big task. i do want to get around to it eventually.
Sorella has quit [Quit: Ex-Chat]
<chjj>
another thing is speed
<chjj>
.length is optimized. writing a function to calculate the cell width of a string is not.
<whitequark>
you have to take combining characters in account anyway, don't you?
<chjj>
hm?
<whitequark>
well, I imagine that in order to determine how much cells a string will occupy, you need to:
<whitequark>
1) split it into graphemes; 2) calculate cell width for each grapheme (which is, AIUI, hardcoded to 1 now); 3) sum it
<ELLIOTTCABLE>
whitequark: *technically*, for perfect support, yes.
<ELLIOTTCABLE>
whitequark: but *realistically*, no.
<ELLIOTTCABLE>
the accepted approach to this is:
<chjj>
this looks like a port of the implementation ncurses uses.
<ELLIOTTCABLE>
or rather, there's two, a fast-but-innacurate, and a slow-but-fairly-accurate, in addition to the extremely-slow-but-perfectly-accurate approach you're assuming
<ELLIOTTCABLE>
chjj: (it's a direct port of the widely-accepted C function, which is used outside ncurses)
<chjj>
i see
<whitequark>
ELLIOTTCABLE: lolwhat? wcwidth implements exactly what I said
<purr>
lolwhat
<ELLIOTTCABLE>
whitequark: the fastest way is simply: A) drop all known-invisible characters, B) double all known-wide characters (see that linked file).
<whitequark>
it accounts for both graphemes and variable-width cells
<ELLIOTTCABLE>
whitequark: then the second fastest is to follow Unicode's specified normalization procedures, then double, then count
<whitequark>
I'm fairly, though not completely, sure that "drop all combining characters" is OK for width calculation
<whitequark>
how is normalization related at all?
<ELLIOTTCABLE>
(hold on girlfriend capturing my attention)
<ELLIOTTCABLE>
normalization is basically the recommended way.
<ELLIOTTCABLE>
*not* just removing combining characters
<ELLIOTTCABLE>
you normalize, which *results* in the removal of combining characters, and *then* it's “more okay” to take approaches like removing *remaining* combining characters
<whitequark>
recommended by whom?
<ELLIOTTCABLE>
sorry, I've been buried in Unicode research for the last week (at least when I've been near computers), so forgive me if I sound obtuse :x
<ELLIOTTCABLE>
… fuck if I know. People who deal with complex Unicode data-sets a lot? It's the same thing I've seen everywhere. ‘norm to NFC, then strip.’
* whitequark
shrugs
<purr>
¯\(º_o)/¯
<whitequark>
it's likely snake oil
<ELLIOTTCABLE>
why? Unicode is huge, complex, and full of things that neither you nor I understand.
<whitequark>
I'm not fond of cargo culting an approach because something is complex. this always leads to *more* broken software, not less.
<ELLIOTTCABLE>
There's almost *certainly* examples in some kanji-set or some supported obscure historical character-set where *combining* the characters, changes the resultant width or the result of the length-calculating algorithm we're discussing.
<whitequark>
I suggest you to actually read the description of the normalization in the standard
<chjj>
wow
<chjj>
how quickly something can turn into an argument over standards
<whitequark>
Unicode rendering is indeed complex, but it's not as loosely specified as you try to describe it.
<joelteon>
really fast!
<whitequark>
chjj: it's not even an argument about standard. it's an argument of "let's read the standard" vs "let's just cargo cult stuff around and hope it works correctly".
<whitequark>
the latter must not be tolerated. ;)
<ELLIOTTCABLE>
whitequark: I've read the description of normalization. I know how it works, unless I'm forgetting something major.
<whitequark>
ELLIOTTCABLE: excellent.
<ELLIOTTCABLE>
whitequark: How about, instead of “sagely” suggesting that I read something simply so you can feel, and act, superior to someone, you *actually say* what it is you think they don't know?
<ELLIOTTCABLE>
whitequark: or, to re-phrase: which part of the normalization standard contradicts what I'm saying?
<ELLIOTTCABLE>
dskuza: sooooo, I might not be there for part of SecondConf.
<ELLIOTTCABLE>
dskuza: specifically, I might be gone for part of Friday. But, hopefully, I'd be back for the GitHub after-party, at least.
<whitequark>
ELLIOTTCABLE: you're saying that normalization *may* change something obscure
<whitequark>
I'm saying it cannot.
<chjj>
ELLIOTTCABLE: you can go at it. let me know what you come up with. i'll let you know if you're missing anything crucial. the main methods you're going to have to deal with are parseContent, _wrapContent, _align, draw, etc. there's probably a few more that check string width and assume cell width.
<ELLIOTTCABLE>
chjj: <3
<dskuza>
yous a ho
<chjj>
ELLIOTTCABLE: if you do use that wcwidth function, please refactor it to not use underscore.
<ELLIOTTCABLE>
chjj: fly safe, you beautiful bastard; and keep making command-line support in JavaScript more delicious.
<ELLIOTTCABLE>
chjj: (already got a non-Underscore version.)
<chjj>
ELLIOTTCABLE: lol
<purr>
lol
<chjj>
ELLIOTTCABLE: good. underscore just seems kind of worthless there.
<purr\GH>
System/Master d7f8bf3 elliottcable: (- vim fix) Using vim-gitgutter's *own* always-sign-column feature
<ELLIOTTCABLE>
jdhartley / dskuza: sooooo, when're we re-scheduling for ch1.1? >:
<whitequark>
ELLIOTTCABLE: in other words, the only valid response to "*prove* normalization never changes behavior X" is "read the standard".
<whitequark>
which is why it exists in the first place.
<ELLIOTTCABLE>
whitequark: so, you're telling me you have time to *fully read* and *fully implement* every standard that specifies a technology a given project of yours depends upon?
<ELLIOTTCABLE>
*not* reading standards, and depending upon somebody else's work based on *their* understanding of a given standard, is *what we do* as software developers.
<ELLIOTTCABLE>
It's called modularization. It's what you do every time you `npm install`, or refer to a standard-library HTTP API in your favourite language.
<whitequark>
ELLIOTTCABLE: I'm either implementing a standard or not. If not, I use someone else's work and hope they did it well. If I do, yes, that is exactly what I'm doing.
<ELLIOTTCABLE>
In this case, there's no JavaScript library for Unicode support, so I'm doing the next best thing: reading others' code, in other languages, of those who understand the Unicode standard better than I do; and reading other's advice along those lines.
<ELLIOTTCABLE>
see, that's the failure in your logic.
<ELLIOTTCABLE>
There's no difference, whatsoever, between trusting somebody's implementation in code, and their advice in written text.
<ELLIOTTCABLE>
anyway. done with this conversation, back to real-life concerns. )=
<whitequark>
ELLIOTTCABLE: there is. code can be interpreted unambiguously, written text cannot.
<whitequark>
(unless it's a standard!)
<whitequark>
and this is exactly what I'm talking about.
<ELLIOTTCABLE>
yes, I know it is, and I know you disagree with me.
<whitequark>
you have no idea if the guy used NFC because his downstream library wanted it, or it was convenient, or his UCD database was broken.
<ELLIOTTCABLE>
I'm simply stating, since it wasn't previously clear, that *I* disagree with *you*, now that you've laid out your position.
<whitequark>
with *his* code, it works, because see above.
<ELLIOTTCABLE>
Now that that's done, and we understand each other, I'm moving on to the (many.) better things I have to do, than argue this point.