<ljharb>
i think the next one will be xoxo in september, if i get into it
<ljharb>
also roflcopter
<ec>
what's it add?
<ljharb>
LTS support
<ec>
somebody else told me to do xoxo
<ec>
but it looks like ‘festival’
<ec>
which is like. not my thing.
<ljharb>
yeah it's half talks half festival
<ec>
I hate drugs, I hate live music, so like.
<ec>
el oh el nah.
<ljharb>
oh no, not like that
<ljharb>
more like drinking parties and stuff, when not at the talks
<ljharb>
other than xoxo, i'll be in redmond next week for TC39, and that's all i've got planned for the rest of 2016
<ec>
hmmm
<ec>
*also* not hugely my scene, but I'm a lot more compfortable with that than what I'd been assuming :P
<ljharb>
i've done most of my traveling already this year
<ljharb>
lol yeah it's not like it's burning man or woodstock or anything
<purr>
LOL
* ec
shrugs
<purr>
¯\(º_o)/¯
<ljharb>
if you come to any conferences in SF i can hang fa sho
<ec>
lotta things I'm uncompfortable in the tech community. I generally don't associate with nerds offline, for precisely those reasons.
<ec>
Everything from drugs and partying, to social incapacitation, to misogyny, being inherent to the culture,
<ec>
just. I'm huuuuuugely skeeved out on a daily basis by Nerds™, in general. It's a big reason I compress all of my geeky-socialization into conferences: I can sort of delineate “Okay, for <these five days>, I'm gonna Not Worry About all these people being absolute trash ... in exchange for not having to deal with it the rest of the year.”
<ljharb>
any chance you're a bit overdoing the judgement on that?
<ec>
(I'm very aware how judgmental and holier-than-thou that sounds; but it's not intended to imply I'm *better* than anybody else ... just that I'm inherently blind to my own failings, but not to theirs.)
<ljharb>
i mean, misogyny sucks, but that's a problem of "humans" too
<ec>
of course, but here's the thing: I hang out in Heavily Sjwey™ circles, for the most part. The only place where my connections aren't of my own choice/design, is w.r.t. work: does that make sense?
<ljharb>
yes that makes sense
<ljharb>
iow maybe you're just not hanging around the good nerds :-p
<ec>
oh, definitely
<ec>
or rather I *do* hang around the good nerds, most of the time ... but that's *accidental* (i.e. I choose ‘good people’, which here translates to woke people, to hang out with; and a lot of the time, they're nerds)
<ec>
but when it comes to offline-tech, *by definition*, the events are filtered by the *being techie* attribute, not by the *being woke* attribute: make sense?
<ljharb>
totes
<ljharb>
that does seem like a problem that applies to almost all aspects of life tho
<ec>
i.e. a lot of the attendees are just ... going to be people I'm going to be uncompfortable around. It's not entirely Selected By Elliott, like IRC or Twitter or, well, basically anything online, can be.
<ec>
To some extent, perhaps; but I *personally* haven't ended up dealing with it outside of tech culture, basically.
<ljharb>
gotcha
<ec>
I'm seeing a similar version of the same thing returning to school:
<ec>
Luckily I *picked my school* by diversity, so while tech, it's *very* cross-cultural on most axes of oppression ... which gives me a chance to learn a ton, and leaves me a lot less uncompfortable on a given day,
<ec>
with the very shitty and notable exception of women/misogyny. Engineering school, almost no *women*. /=
<ec>
and that's been very noticeable in my everyday life. same sorts of feels as above re: conferences, tech events, soonsoforth
<ec>
but it's just a whoooooolle other order of magnitude: School-life is “Every day, I hear something misogynistic” ... whereas conflife is “Every day, I hear 1. several misogynistic things, 2. several racist things, 3. several things about drugs, 4. several pushy things about drinking, ...”
<ec>
with that list continuing on through, like, a solid ten goddamn listicle items, yano? it's overwhelming. I just *don't have the spoons* to handle it more than a few times a year. /=
<ec>
ON A RELATED BUT LESS DEPRESSING NOTE,
<ec>
the intersection of people who've mentioned @xoxo to me recently has definitely been Awesome, so.
<ec>
it's probably going on my to-attend list, probably for next year, if it's truly not as druggy as I'd been assuming :D
<ljharb>
i went to it in 2014 and only got a festival pass, and altho i certainly did my share of drinking, it mostly was just fun stuff that happened to serve alcohol
<ljharb>
hopefully i get a full conf pass this year
* ec
laughs
<ec>
by the way, I definitely drink. incase that was unclear. it's when it's pushed *by a technical conference*, especially by one that admits underaged people, that it really bothers me.
<ec>
I prefer my getting-drunk-at-conferences to happen amongst a couple friends at dinner, when I'm sure there's nobody underaged there, and there's nobody present (teetotalers, etc) it's going to feel exclusive to :x
<ec>
ahhhhhhhhh I hate how sjw'ey I sound this year
<ljharb>
lol
<purr>
LOL
<ec>
I'm really hoping my set of opinions integrates and crystallizes a lot through the second half of 2016: 2015 and the first part of this year have been new, difficult, strange, for me. /=
<ljharb>
the non-drinkers part is fair
<ljharb>
the drinking age is arbitrary and silly so i don't really care if someone is drinking when under 21
<ljharb>
not that i'd serve them or anything
<ljharb>
but if you just mean that it's not an approps message for an event to push, then yeah i agree
<ec>
If *they choose to*, yeah. I've even *served* my share of kids. But for most geeky, techy kids who go to conferences? Not really the type that have probably started drinking underage, and thus, most likely to be pretty uncompfortable with it.
<ljharb>
ah ok so it's just their comfort with it, ie, same bucket as non-drinkers
<ec>
I have a pretty visceral memory of when I attended a Ruby conference at, uhhhh, 17, I think?, and went on a big ‘startup crawl’ event through San Francisco,
<ec>
and was shocked halfway through to find out that it was a drinking event, and people'd just *assumed* I was of age
<ec>
yah, lol, all this is about inclusivity and safety, nothing else. :P
<ljharb>
gotcha
<ljharb>
k i gt hit the hay
<ec>
like, almost none of it, except the drugs, affects me directly: I just feel like it's my *obligation* as a part of the community to Care, y'know?
<ec>
lmao. sleep tight. <3
<ljharb>
yeah i'm with you there
<ljharb>
night <3
<ec>
just discovered ##workingset
<ec>
how did. i not know about this.
creationix_ has joined #elliottcable
<ec>
creationix_@
<ec>
!*
<ec>
Long time no speak. (=
meowrobot has quit [Quit: let us connect our intestines and mutually digest]
<ec>
3:34:29 AM ⇐ meowrobot quit (~katgirl@ool-18ba0f1f.dyn.optonline.net) Quit: let us connect our intestines and mutually digest
<ec>
omg.
<ec>
clearly I am way too awake and active for the denizens of #ELLIOTTCABLE at this hour.
<purr\ec>
System/Master de3f572 ELLIOTTCABLE: (- vim new) Improving showbreak appearance
thealphanerd has quit [Quit: farewell for now]
thealphanerd has joined #elliottcable
<cloudhead>
ec: I'm like you with regards to tech culture, except for worse
<cloudhead>
ec: I completely stay away from any conference or gathering of tech people
<cloudhead>
ec: I despise the whole thing
<ec>
cloudhead: I do okay with conferences, specifically because I *don't* have a tech job.
<cloudhead>
how does that help?
<ec>
as in, it's the *only time all year* when I'm forced to Be Around Geeks, as I think of it in my head.
<cloudhead>
oh right
<cloudhead>
yeah I get it
<ec>
I spend the vast majority of my time around very non-technical people; and since I don't have to care if they're smart, I *get* to care if they're kind.
<cloudhead>
:)
<ec>
but when I need intelligence (or I suppose I should say knowledge), that really really restricts my ability to *also* care if they're kind. /=
<cloudhead>
haha
<ec>
like sure there's lots of kind geeks out there … but as the technical restrictions grow, that number dwindles and dwindles.
<ec>
You need somebody in the C community? Who uses make? Who's familiar with clang? Who's built large software w/ additional debugging object-data? Specifically for lldb?
<ec>
lik each little ‘and also’ when you have technical needs, exponentially reduces the chances you'll find what you need … and I just can never afford to prefix *all* of those exponential reductions with an *additional* exponential reduction of “oh and must agree with me emotionally/politically.”
<ec>
y'know? it's just unfeasible.
<ec>
I'm sure this is all obvious. I'm just sort of laying it out in words for myself, I suppose.
<cloudhead>
right, but that's a different thing no? "needing somebody" -> they don't have to be your friend
<ec>
ahhhhhhh I'm trying to learn to iron and do fabric-things and it's not going well
<cloudhead>
haha
<ec>
but lol turns out all my electronics tools are surprisingly useful for working w/ fabric
<purr>
lolwut
* cloudhead
hates ironing
<ec>
I've used my: forceps, flush-cutters, soldering iron, soldering surface, Xacto knives, and fume-hood, so far
<cloudhead>
:o
<ec>
so that the only *non*-EE tool I've had to dredge up out of elsewhere in my house is the actual damn iron
<ec>
lolol
<ec>
how's life, cloudhead?
<ec>
whatchoo been up to?
<cloudhead>
it's alright I guess
<cloudhead>
I've been developing the skills I care for this past year: writing, drawing and coding
<cloudhead>
working on an indie game in haskell now
<cloudhead>
everyone in my friend group is going through rough times lately
<cloudhead>
everyone's kind of lost
<cloudhead>
I'm slowly emerging from that dark pit
* ec
smiles
<ec>
I *need* to take some time for skill-development in the future
<ec>
I haven't learned a new programming language in probably a whole fucking year
<ec>
and I used to require of myself that I at least go through a basics-tutorial for a new language every three months
<cloudhead>
yeah I used to do that too ^
<cloudhead>
but you slow down at some point heh
<ec>
I've been really focused on Being Human the last year or two. Ever since Paws got bogged down, and alex/micah/etc disappeared (i.e. my Paws Support System)
<ec>
trying to learn to be a better person. trying to focus on my friends. trying to *make* friends.
<cloudhead>
yes, I've been doing the same essentially
<ec>
trying to get laid, and get better at getting laid, and get better at the laying. :P
<cloudhead>
focusing on life
<cloudhead>
haha
<ec>
but my intellectual life has suffered hardcore.
<ec>
very little work on Paws. learned very few new things. I feel behind, technically.
* cloudhead
nods
<ec>
and to boot I don't see a lot of opportunity to focus on it in the near future, either, with my new math curriculum … /=
<cloudhead>
what happened to micah?
<ec>
envy you the drawing
<cloudhead>
you're going to uni?
<ec>
micah went Music, alex … who knows, devyn's busy with Real Job stuff,
<cloudhead>
hmm
<ec>
eli's still a troll, devin hates this channel,
<ec>
so on and so forth
<ec>
oh, I didn't tell you? i swear we had this conversation earlier this year. yeah, I'm back in school.
<cloudhead>
you didn't :)
<cloudhead>
nice
<ec>
decided to get my undergrad, because my dad's health is scaring me.
<cloudhead>
chicago?
<ec>
and because I hit walls in Paws that I just couldn't surpass without Hard Math, like, graduate-level math, that I *couldn't* pick up on my own
<cloudhead>
in which way is it related?
<cloudhead>
oh
<ec>
just seems like shit that anybody who isn't an absolute savant, needs *instruction* in. it's not like compsci. /=
<cloudhead>
yeah
<cloudhead>
we all know compsci isn't really sci ;)
<ec>
so: goal was to finish undergrad in CS, or something else easy and quick, so they'd let me into the graduate courses I actually *need*
<ec>
but jesus chriiiiiiist cs was boring
<cloudhead>
right I see
<cloudhead>
that's a courageous goal
<cloudhead>
I'd never be able to last more than a year at uni
<cloudhead>
it's like swallowing the blue pill over and over
<ec>
so instead I'm now doing a weird triple-degree thing: CS/applied math undergrad, but co-terminating with a master's-CS? tentatively?
<ec>
yeah yeah yeah ugh
<ec>
in some ways it's great
<ec>
amazingly easy to focus on classes compared to when I was young
<cloudhead>
oh I see, nice
<cloudhead>
yeah, when you actually go by your own volition
<cloudhead>
it's a lot easier
<ec>
it's super-clear to me now that it's Goddamn Criminal that we send *nineteen year olds* to fucking *determine their entire future*, while putting them N-teen thousand dollars in debt to do it … ahhhgehsghr gross
<ec>
yeah. that part is a LOT easier.
<cloudhead>
dude, totally agree
<cloudhead>
uni should be for your mid twenties
<ec>
unfortunately, the downside is that you're *supposed* to waste your 18-22 years in school
<cloudhead>
heh
<ec>
whereas I'm … turning 27 here in a couple days/weeks/months approximately.
<cloudhead>
I sure wasted mine
<cloudhead>
going to three different schools
<ec>
when I finish this program, I'mma be fucking *thirty something*.
<cloudhead>
and dropping out
<ec>
and it's not even a PhD or something important like that.
<cloudhead>
heh
<ec>
so it's really disheartening.
<cloudhead>
yeah
<ec>
entering the workforce at thirty? ugh.
<cloudhead>
yeah, the tech work force which is 100% ageism
<ec>
jesus, in CS, you're old, crotchety, and unwanted at like fucking 37
<cloudhead>
pretty much
<ec>
so that's maybe seven to ten productive career-building years before I've gotta coast on whatever I've achieved
<ec>
sp: scary af.
<ec>
so*
<cloudhead>
the way out is to start your own company
<cloudhead>
gain experience for those 7 years, then start your own thing
<cloudhead>
and bring people with you
<ec>
ew fuck no
<ec>
I have *zero* interest in entrepreneurship, startups, that whoooole culture sickens me
<cloudhead>
yeah, that's not really what I'm saying
<ec>
I'm definitely, and happily, bound for a lifer position at some large technical company
<cloudhead>
haha
<ec>
problem is that while I don't care about power/promotions/leadership, I *do* care about doing difficult and hardcore work.
<ec>
jesus christ I just. want. to. build. programming. fucking. languages.
<cloudhead>
yeah
<ec>
so yeah, if I want to continue to be involved in the meaningful technical work after 40 ... I really, really need to have made a name for myself when younger. /=
<cloudhead>
that's going to be hard to find as a job, the way you want it
<ec>
yep.
<ec>
I don't know what else to do.
<ec>
My interests w.r.t. computers are just, so limited.
<ec>
I deeply hate Rails apps or Node apps or iOS development or,
<cloudhead>
maybe they can be expanded
<cloudhead>
you haven't been directly exposed to much outside of your own interest
<ec>
I give zero shits whatsoever about graphics, search, A.I. / M.L.,
<ec>
I mean, I have? I think?
<ec>
I've done a *lot* of things, but I am really *not* a programmer at heart.
<ec>
I think I'm a budding mathematician who's mostly interested in how discrete-mathematics things get into the hands of Normal Humans.
<ec>
I like programming as UI for math, basically.
<cloudhead>
by exposed I mean have physical people around you doing other things and getting you inspired
<ec>
mmmmmm maybe
<cloudhead>
I think that can make a difference
<ec>
I also enjoy robotics and EE stuff, I vaguely feel like I might accidentally veer off into that as my profession at some point; that lets me focus on PLT as a hobby/passion outside of work.
<cloudhead>
do you enjoy doing mathematics though?
<cloudhead>
I mean *doing* maths
<ec>
discrete stuff, yeah, as far as I've taken it.
<ec>
well ¯\_(ツ)_/¯ it's proofs, which I'm *bad* at; hard to tell if I really like it, until I've done a lot more.
<cloudhead>
hehe
<ec>
continuous maths / calculus / whatever are fun as fuck and easy for me, but aren't what I'm interested in.
<cloudhead>
most of my programmer friends consider that programming is just a stepping stone
<cloudhead>
to something more fulfilling somehow
<ec>
lol “accidentally veer off”, there's also a chance I'll accidentally veer off into academia, and just stick with math. give up on computers entirely, except as tools.
<purr>
lolll
<ec>
but I just doubt I'm *intelligent* enough for that.
<cloudhead>
hmm that can be quite dry though
<ec>
it's pretty clear that the intellect required for the real theoretic mathematics, the derivation of new proofs, basically, is some Hard Shit
<cloudhead>
yeah for sure
<ec>
like quite literally beyond me, in all likelihood
<ec>
/=
<ec>
7:31:29 AM <cloudhead> by exposed I mean have physical people around you doing other things and getting you inspired
<ec>
so whaddya mean by this?
<ec>
because I'm pretty sure I'm exposed to these things constantly
<cloudhead>
I mean working as part of a team
<cloudhead>
or at a company
<ec>
mmm maybe
<cloudhead>
with a variety of things going on
<cloudhead>
you make friends with someone doing X
<ec>
but I have yet to see almost *any* company that is both 1. hiring, and 2. doing interesting work
<cloudhead>
then you get interested in X
<cloudhead>
haha
<ec>
there's like … NPM, and github; and beyond that, it's finding a little bubble of Interesting Work inside one of the larger companies
<cloudhead>
find me a 2., I think the 1. is a non-issue
<ec>
V8 or Go teams at Google, Rust team at Mozilla, Flow team at Facebook, etc.
<cloudhead>
yeah
<ec>
I *think* I could *maybe* get into one of those cool teams; but that's another reason I'm trudging through the degree.
<ec>
“I have a Masters in Applied Math” seems like a great way to *not* get ignored by the Rust team, yano? even if I have no actual compiler chops yet?
<cloudhead>
yeah for sure
<cloudhead>
although the best way would probably be to submit patches
<ec>
also, universities have a lot of connections, opportunities for me to get stupid unpaid internships that might get me into those sorts of tight ingroups
<ec>
well.
<ec>
well, I can definite participate in an external-cloud sort of way.
<ec>
ugh no words. lemme try that again.
<ec>
these sorts of hardcore software I'm interested in, when they're open-source, sort of have the *vast majority* of contributors, that are contributing to the general quality, documentation, interface, feature set, etc … which I could definitely learn enough on my own to do …
<ec>
but with the time I've spent around optimizing-compiler/PLT people, it's become very clear to me that contributing to the *core systems* requires knowledge that I just don't know how to pick up, simply by reading the code and patching easier things.
<ec>
does that make sense?
<ec>
i.e. no amount of fixing Rust bugs will teach me How Rust Works, Theoretically, enough to make meaningful project-level changes and contributions to the *design* of Rust. as a random example.
<ec>
(I barely know Rust, so a bad one. :P)
<ec>
the only way I know to do that, is to 1. embed myself in a team doing it, so I'll have the mentorship and exposure to soak the bleeding-edge theoretics up; or 2. to start from scratch and reverse-engineer it by dealing with all of those same problems from square 1. (what I've basically been doing with Paws for years.)
<ec>
(It's been helping me to read a lot of whitepapers; but that, too, is limited in how much it can give me: there's always a wall of “I'm just missing the basic theory, here.” that I end up hitting, in the interesting papers.)
embri0n has quit [Quit: Leaving...]
<ec>
meh. Realistically, the Paws approach was working quite fine; at least with regards to the things *relevant* to Paws (control-flow, continuations / CPS, some GC), I've learned a ton ... if I had the life-time, I'd just crank through Paws, and then dive into some other arbitrary project for a lower-level / non-GC language, to learn more about typing and
<ec>
compilation, which are things Paws-work has left me woefully inadequate on
<ec>
that just won't get me hired. it'll make me Very Happy and Fulfilled, but, not hired. :P
<ec>
also, it's a lot harder to stay motivate w.r.t. that stuff: whatever whitequark might think, I am still very convinced that Paws is *relevant*. It may not (definitely won't.) take over the world and have 100,000 users and be a household name, but I've got *real, original, interesting* work in the design ...
<ec>
but I'm somehow convinced I can't make any meaningful innovations to optimizing compilation or typing or low-level languages in general
<ec>
so anything I try to build there, unlike Paws, would end up being *exclusively* to learn. which I'm worried I'd lose steam on very quickly.
<ec>
tl;dr easy to keep cranking away for six fucking years when you feel like you're changing the world ... but hard to, when you're just reinventing the wheel to *learn*. /=
<cloudhead>
yeah I agree about Paws
<cloudhead>
wrt Rust, I was thinking more like: you contribute patches, then you get hired and then you learn the core stuff
<cloudhead>
it is indeed difficult to understand the core stuff from the outside
<cloudhead>
although I think it's possible, I've seen some haskell summer of code projects making some important changes to the type system
<cloudhead>
by "new" people
<cloudhead>
because they had mentors
<cloudhead>
that sort of thing is ideal
* ec
nods
<ec>
yeah precisely what I'm talking about.
<ec>
first bit, general patches to present myself in the community, is deffo a given, for whatever project is relevant when this occurs
<cloudhead>
yeah
<ec>
(likelihood of Rust still being the project du jour, where I can make meaningful contributions, in a few years … is pretty low)
<ec>
(like, when I started Paws, I thought I'd eventually be contributing to Ruby / Rubinius. and then, for a while, to V8.)
<cloudhead>
haha
<cloudhead>
yeah that's funny to think about
<cloudhead>
ruby </3
<ec>
oh, I forgot about brixen. Maybe I'll berate him into mentoring me, someday; even though I write *no ruby* anymore, I still think Rubinius is damned cool.
<ec>
so yeah: whatever cool new kid on the block has 1. Real Technical Chops, something new, and 2. is young enough for me to make a significant contribution ... you described exactly what I assume will be involved.
<ec>
poke around in the code. contribute patches to ‘accessory’ code. talk about issues, listen to conversations, learn the community ... then try and *somehow* get myself a mentorship relationship, and be walked-through/taught the things I'm currently struggling to learn on my own, extremely slowly. ¯\_(ツ)_/¯
<ec>
on a different note
<ec>
this effect has been bothering me for a while:
<ec>
every ten years or so, we seem to gain a new level of “stable abstraction” that ... is just, entrenched.
<ec>
and it, depending on *how* entrenched it becomes, either stifles, or straight-up prevents, designs that don't fit on top of it.
<ec>
von-neumann. x86. C/POSIX/whatever. and now, LLVM, kinda.
<cloudhead>
haha
<ec>
lol those are terribly approximated
<purr>
lol
<cloudhead>
100% agree
<cloudhead>
'Unity'
<cloudhead>
in game dev
<ec>
in ten years, will people be *designing* any programming languages that don't translate well to LLVM?
<cloudhead>
is the current one
<ec>
lollllll that, yep
<ec>
ugh so much I need to elarn
<ec>
learn
<ec>
still don't ‘know’ haskell, besides a weirdly specific pile of HKT shit. still don't know Rust, and that may be the closest thing I'll ever get to What I Want in a language, outside of Paws. still haven't actually used LLVM.
<cloudhead>
oh and 'Electron' is a good one also
<cloudhead>
ie: how to make the desktop slow again
<ec>
and I don't have time for *any* of that, because it's all goddamn. banal tooling shit.
<cloudhead>
heh
<ec>
like I want to know the *math*. the *theory*. and time I spend building some huge thing in haskell or rust so that I truly understand them, is time *not* spent learning graph theory or how-to-brain-proofs or w/e.
<ec>
but I feel so worthless and shitty for not knowing Haskell well, or I feel so sad that I have to resort to C when I could use Rust if I'd invested the time to learn it, or ..........aer;lsjrnhogajfwioejksgnhodt
<cloudhead>
wellllllllllll
<cloudhead>
building stuff with haskell for ex, forces you to learn some theory
<cloudhead>
you're not just learning the "Tool"
<cloudhead>
they are tightly coupled
<cloudhead>
tool & theory
<ec>
and all of the above is compressed into the 10% of my life I allow to be dedicated to Intellect, because of aforementioned “being a good human” kick these few years
<ec>
derp.
<ec>
well, Haskell's theory, yes.
<ec>
type theory.
<ec>
I am very, very convinced that that entire fucking stack of concepts is a giant red herring that's ruining programming. -_-
<cloudhead>
yes but haskell's theory is based on universal theories
<ec>
but that's a topic for another time.
<ec>
and annoyingly, one that nobody will respect my views on until I throw away six months of my life to master Haskell. -_-
<ec>
well, yeah, in a way. set theory and shit, yes. but employing those *directly* as a solution for *humans programming computers?* just. just ridiculous.
<cloudhead>
lol
<purr>
lolololol
<ec>
lol I made my best friend in academia thus far with a long-winded rant on this topic: another ex-CS guy who went into math and abandoned the whole field
<ec>
as far as I can tell, all the Actual Mathematicians fucking hate haskell and think it's such an idiotic plan
<ec>
so that makes me feel right at home around all of them.
<cloudhead>
haha
<cloudhead>
that's cause they're mathematicians
<ec>
to be very judgemental and not very accurate, it feels a lot like Haskell is a bunch of programmers wanting to masturbate over how cool Math™ is, without actually doing the math *as math*
<ec>
ahhhh that sentence doesn't even scan
<ec>
I give up
<cloudhead>
but also, I don't think that means they prefer languages that throw maths out the window
<ec>
everybody everywhere has heard me rant about haskell enough :P
<cloudhead>
:D
<cloudhead>
I don't like the mathy stuff in haskell
<ec>
see, opposite
<cloudhead>
I think it's very distracting
<ec>
I like Haskell, if it were ... focused, existed *for* that stuff.
<ec>
if it were kinda on the level of Coq or similar.
<ec>
like, nobody fucking tries to build web-servers in Coq.
<cloudhead>
then it wouldn't be good at general purpose programming though
<ec>
exactly!
<ec>
Haskell is a great not-at-all-general-purpose programming language, and really cool and consistent and remarkably beautiful¹
<cloudhead>
yeah but then you want Agda
<ec>
(1. from what I know, at least)
<cloudhead>
it's very general purpose
<ec>
but then people try to cast it as an alternative to Ruby
<ec>
and I'm like get the fuck out plz
<cloudhead>
lol
<purr>
purrlol
<ec>
Haskell feels like ... the awkwardest fucking flying car *ever*
<ec>
ooo ooo oo
<ec>
Haskell feels like a Segway!
<cloudhead>
yeah when you haven't mastered it
<ec>
high tech, built beautifully, on top of concepts that are *so perfect* for-the-things-they're-perfect-for, ...
<cloudhead>
but once you have, there's no reason to go back to ruby etc
<ec>
... and then hugely mis-used by people who just think it's cool, or get some weird boner for using it?
<ec>
it's like: use a goddamn bike.
<cloudhead>
lol
<ec>
Bikes work great. They don't seem as cool. But frankly, they're *much better designed* for the kinds of things you're trying to do.
<cloudhead>
I think you have no idea what you're talking about right now :D
* ec
shrugs
<purr>
¯\(º_o)/¯
<ec>
8:00:04 AM <+ec> and annoyingly, one that nobody will respect my views on until I throw away six months of my life to master Haskell. -_-
<cloudhead>
yeah because if you did throw away those six months, you'd have a different opinion
<ec>
You think so. I very strongly do not.
Sorella has quit [Quit: Connection closed for inactivity]
<ec>
It's typing *in general* that drives me nuts, and Haskell is that, taken to an extreme.
<cloudhead>
oh well, if you don't like static typing
<cloudhead>
then yeah :)
<cloudhead>
but then you won't like rust
<ec>
or to put it in a different way: non-procedural programming
<ec>
Rust has all of that *for a purpose*.
<cloudhead>
that's strong and static typing too
<ec>
Rust is Haskell's stuff, made waaaaaaay more pragmatic.
<cloudhead>
lol!
<purr>
lollllll
<cloudhead>
you have to actually write some code dude
<ec>
Every new language I learn convinces me, more and more, that we need to *fix* procedural programming, not throw it away and replace it with declarative programming or functional programming or any other paradigm I've seen.
<cloudhead>
both in rust and haskell
<ec>
Humans *think procedurally*.
<ec>
Nothing in the universe is going to make a system, where you need to express your needs non-procedurally, a *better interface* for humans to talk to machines, /=
<cloudhead>
maths?
<ec>
ahghhaghhghhahgh this conversation gets me very upset
<ec>
Maths' interface is fucking terrible!
<ec>
like jesus christ math is very nearly *intentionally* unusable: it's pretty hugely obviously designed to be exclusive.
<cloudhead>
haha
<cloudhead>
no way
<ec>
to be an in-group thing, that makes the users thereof / operators thereof seem more intellectual, more intelligent, ‘better than’ the uninitiates.
<cloudhead>
it's just efficient in its representation of knowledge
<ec>
Wolfram can be kind of annoying, but he's got some great views on this.
<ec>
That the biggest thing Math™ needs, as a whole, is a complete refactor from the ground up with modern notations and naming.
<cloudhead>
well, that would make it more accessible
<ec>
Mathematica is kind a mess in some ways, imnvho, but, if you ignore those ... the attempts to make the notation and encoding *consistent*, is beaitufl
<cloudhead>
but wouldn't help working mathematicians much
<ec>
. beautiful. *
<ec>
well of course not
<ec>
it's the Photoshop problem
<ec>
a terrible interface that is nonetheless entrenched.
<cloudhead>
yes, precisely
<ec>
so all you can really do is try to be as clear, loud, and kind as you can about *how terrible* it is,
<ec>
so that the Next Generation comes up with a healthy disrespect for it,
<ec>
so that *someday* the changes that are so desperately needed, can happen.
<cloudhead>
but that's why I think when you say humans think procedurally, I think that's kind of a red herring
<ec>
because you simply can't effect those changes with a whole inertia-driven industry depending on their productivity. /=
<ec>
oh?
<ec>
I *think* I know where you're coming from, and it's a common viewpoint, but I think it's really, really wrong. /=
<cloudhead>
if Mathematical notation were to adapt to that, it'd be a mess
<ec>
I could be wrong, but I suspect you're gonna make the “people like procedural languages because they learned on them!” argument
<cloudhead>
no
<cloudhead>
what I'm saying is
<ec>
oh, re: math? Mathematica isn't procedural, I don't think *math* should be procedural, eek
<cloudhead>
why did mathematicians not come up with a procedural language
<cloudhead>
if that's better
<ec>
mathematics isn't encoding a *task*, it's encoding a *concept*.
<ec>
*a truth*.
<cloudhead>
yes
<ec>
computers exist to preform tasks, as dictated by their humans (at least, if we ignore ML-powered interfaces, and that's a whoooooole different rant)
<cloudhead>
but programs do the same, if you look at them from farther up
<ec>
if I have a personal assistant, I don't describe to them the state I want the world to be in;
<ec>
nor do I describe phase-transitions and constraints
<ec>
I describe precisely the actions I want taken.
<cloudhead>
:O
<cloudhead>
see that's your problem
<cloudhead>
that's inefficient
<cloudhead>
if I had a personal assistant
<ec>
if I try to tell another human how to get to where I am, I give them *instructions*; again, procedural ones.
<cloudhead>
I would say: make sure the plants are always watered
<ec>
you must be less precise than me :P
<ec>
that comes back to AI/ML, which is something I don't want to go into
<cloudhead>
well not all programs are one-off tasks
<ec>
but assuming a Very Not Gifted personal assistant, if you want something done *right*, it's most intuitive to explain it *procedurally*.
<cloudhead>
the most interesting programs are systems
<cloudhead>
that are always running
<cloudhead>
"a not very gifted" yes, but that's why we have GHC, which is a gifted compiler
<cloudhead>
would rather have gifted assistant
<ec>
see, I disagree: that's Opinionated, low-configuration software, so to speak
<ec>
the same sort of stuff as AI/ML
<ec>
which is an argument I've had waaaaaaaaay too many times in this channel with Micah et al. to want to do it again
<ec>
but personally I have zero, absolutely zero, interest in software that decides things for me.
<ec>
Until we have true artificial sentience, I can *always* make better decisions than software.
<cloudhead>
but do you want to make them?
<ec>
I'm a firm believer (and now we're in philosophical territory, doubly-don't-want) in technology existing to *superpower* humans, not *disnecessitate* them.
<cloudhead>
the whole point of software is to automate decisions
<ec>
the general example being that I heavily prefer a system with very powerful, flexible, and clear/excellent-UI *filters* for spam, to one that machine-learns its way into defeating spam.
<ec>
I want every action and decision surfaced and clear, not buried and murky, to the end-user.
<ec>
I disagree. The point of software is to *abstract* decisions.
<cloudhead>
that always hits a limit
<ec>
There *is* software that automates decisions, but I think that such software is hugely pointless, unintuitive, and harmful to the user.
embri0n has joined #elliottcable
<cloudhead>
you want to decide about your cpus branch prediction?
<ec>
(caveat, until we have true artificial-sentience, etc.)
<cloudhead>
you don't want optimizing compilers?
<cloudhead>
you don't believe in the use of heuristics?
<ec>
that nails it: I despise heuristics.
<ec>
Algorithms over heuristics, every time. ¯\_(ツ)_/¯
<cloudhead>
heh
<ec>
but yeah this is a conversation I'm done with, for now.
<cloudhead>
algorithms use heuristics
<cloudhead>
ok
<ec>
*particularly* the AI/ML thing gets me really, really upset, and I've been awake ... far too long.
<ec>
no, literally, the definitions of them are contrasted, lol
<purr>
lolll
<cloudhead>
I've never brought up AI/ML, it's irrelevant to this
<ec>
talking about the uni defs of them, where they're presented as opposites.
<cloudhead>
heh yeah they're the same in practice
<ec>
not the usual working definition of ‘algorithms’ as a particular plan for a small chunk of software
<ec>
b/cuz of course lots of modern algorithms are heuristic, because we've all gone in this horrible, heuristic direction with software *as an industry*
<cloudhead>
not sure what that changes, many algorithms depend on heuristical decisions
<cloudhead>
like graph navigation
<ec>
I mean, obv
* ec
sighs
<cloudhead>
I think the main problem with this conversation is that you haven't worked seriously with either rust or haskell
<ec>
again: there's ... at *least* six occurrences of this conversation in the logs over the last six years
<cloudhead>
we'll talk again when you have
<ec>
if you're really, really interested in my views and feelings on this, which I doubt, it's pretty easy to grep
<ec>
ugh I need to concatenate and clean all those old logs
<cloudhead>
I am, once you have tried those languages you speak of :)
<ec>
pretty sure that file terminates somewhere when I switched to irccloud ;_;
<ec>
lol.
<purr>
purrlol
<ec>
I *know* that people use Haskell. I *know* that mitigatory processes and approaches exist.
<ec>
Like, it's clear that they're not all masochists.
<ec>
But people also worked productively in C for *decades*. hell, still do. That doesn't mean it's a *good idea*, a *good abstraction*, a *good direction for software to be taking*; much less *the best* direction.
<cloudhead>
it's not an indication either way
<cloudhead>
the indication is elsewhere
<cloudhead>
and it's opinion based, for now
<ec>
Literally, by turing equivalence, we *can* work in *any* abstraction we like.
<cloudhead>
like most things in software
<ec>
rephrase?
<cloudhead>
just because we can be productive in X, doesn't say much about
<cloudhead>
X
<cloudhead>
we agree
* ec
nods
<ec>
Like.
<ec>
My interest isn't whether Haskell should be used.
<ec>
Or even whether it should be suggested to new users.
<ec>
It's whether the *next generation* of languages should imitate it.
<cloudhead>
I absolutely wouldn't suggest it to new users
<ec>
It's whether Functional Programming is The Answer™.
<cloudhead>
they are already imitating it
<ec>
A lot, a *lot* of people, nowadays, think it is.
<ec>
and I disagree violently strongly.
<cloudhead>
Idris, Elm...
<ec>
yes. I know.
<ec>
That is why I am so upset about all this.
<ec>
The time remaining to make an impact here (read: stop something horrible, that is happening, from my perspective), is dwindling.
<cloudhead>
but how can you be upset if you haven't given it a chance
<cloudhead>
it makes no sense
<cloudhead>
it's irrational
<ec>
I swear, I swear you're not listening
<ec>
It's *not about whether using haskell works out*. It's about the *general shape*, i.e. the thing we all foolishly refer to as the ‘paradigm’, of it.
<ec>
And I know more than enough about it to know *that*?
<cloudhead>
no that's exactly what I'm saying
<ec>
Just because I can't write, say, a 10,000-line optimizing compiler for Paws in it, doesn't mean I don't know how it works, or what it is?
<cloudhead>
what pure functional language have you worked with?
<ec>
None. Intentionally.
<ec>
“Worked with” ≠ “know.”
<cloudhead>
that's what I'm saying!
<cloudhead>
it absolutely == know!
<cloudhead>
you can't know something just by reading about it
<cloudhead>
that's madness!
* ec
searches for words, again
<cloudhead>
here's a more specific way to put it:
<cloudhead>
you can't have strong opinions about something without having experience with it
<ec>
All I can think of to convey my disagreement with what you're saying, is to return to an earlier statement:
<cloudhead>
you believe you can accurately judge something you don't have experience with
<cloudhead>
but that doesn't work!
<ec>
You can take any paradigm, however terrible, and make it arbitrarily better for Actual Tasks. (Tooling. Support. Community. Quality of the compiler, expanse of the standard library.) *How pleasant a language is to work in*, frankly, how *good* it is, only *distantly* relates to how good the *paradigm* is.
<ec>
i.e., the paradigm is only the first of *many* things that affect the final product.
<cloudhead>
yes, I agree
<ec>
You're saying to me, “You can't have an opinion on the value of sulfur as an element, until you've tried <famous food with sulfur in it>!”
<ec>
“That food is delicious! Stop bad-mouting sulfur!”
<ec>
I'm talking about *the paradigm*, and I don't remotely need to *taste a final product involving it*, to speak on it.
<ec>
Does that make any sense?
<ec>
I *get* why you're saying what you're saying.
<cloudhead>
it does, but it's wrong
<ec>
And I've generally resigned myself to avoid having these discussions until such a time as I can no longer say “I don't know Haskell well.”
<cloudhead>
because you absolutely do need *experience* with the paradigm
<cloudhead>
to judge it accurately
<ec>
But the point is, you thinking it will *change my opinion*, is illogical as hell.
<cloudhead>
you think so, because there are unknown unknowns involved
<cloudhead>
whereas they are known unknowns to me
<cloudhead>
and that's my whole point
<cloudhead>
you don't know what you don't know
<cloudhead>
because you haven't experienced it
<cloudhead>
the paradigm is very different when looked at from the outside
<cloudhead>
compared to actually working with it day to day
<ec>
ahhghghh no
<ec>
that's precisely what I'm saying
<cloudhead>
let me rephrase: "the paradigm" is completely unimportant here
<ec>
another way to put it, although in a loaded way that bothers me, because I can't think of other words:
<ec>
As someone who's acquired a taste for sulfur, you are *biased*.
<cloudhead>
because you don't program with a paradigm, but with a language and toolset
<ec>
Yes!
<ec>
Agreed!
<ec>
YES
<ec>
aofubEIUAGUAEG THAT'S MY ENTIRE POINT
<cloudhead>
yes, so that's why IT DOESNT MATTER
<ec>
IT ABSOLUTELY MATTERS
<cloudhead>
knowing the paradigm doesn't change a thing!
<cloudhead>
because the language is what matters
<ec>
with N quality toolset, plus M quality paradigm, you have an N+M quality experience building and maintaining software.
<cloudhead>
you can forget there even *is* a paradigm
<ec>
“It's so good to work in!” doesn't negate the fact that it'd be *better* if any one of those components was chosen or designed better in the first place.
<cloudhead>
that's besides the point though
<cloudhead>
also I don't think quality is a function of paradigm
<ec>
so, for *future work*, it's important to understand which of <given component's options> is superior for given needs
<cloudhead>
paradigm is completely orthogonal
<ec>
in this case, the component I am most interested in, is the fundamental control-flow and expression paradigm
<ec>
and I think *purely functional* is a red herring, for that component; and that future languages will be better served by, and can better serve their users in, other shapes.
<cloudhead>
but you're still talking theoretically
<ec>
yes, you have to. any particular implementation is going to be, *has* to be, contaminated / shaped by *the rest of the toolkit*
<cloudhead>
the paradigm has little effect whether a language can be successful or not
<ec>
these things *have* to be discussed philosophically, and then implemented en masse over decades, to get real meaningful results.
<ec>
aggggh
<ec>
I have to be done, I *have* to be.
<cloudhead>
you can talk about the paradigm all you want, but in the end, programmers use tools
<cloudhead>
that's all I'm saying
<ec>
cloudhead, I 1. have a point, 2. know what I'm saying, and 3. if necessary, will have this discussion with you again in five years, when you're willing to believe me because I have some additional barriers-to-entry you wish for me to have, to have this discussion
<cloudhead>
and you can't talk about those tools
<ec>
but for right now, I'm just, done.
<cloudhead>
without having used them
<ec>
8:38:32 AM <cloudhead> you can talk about the paradigm all you want, but in the end, programmers use tools
<ec>
that's fine *when you're talking to a programmer about programming*
<ec>
but you and I, at least right now, are *tool-developers talking about tools*
<ec>
it's like …
<cloudhead>
I don't see the difference
<ec>
it's like you saying ‘But Gmail is great for the end user, and in the end, users use products, so whatever-gmail-is-written-in is great!’
<cloudhead>
maybe we're not talking about the same thing
<ec>
hold on
<cloudhead>
yes
<cloudhead>
that's what I'm saying
<ec>
I think this might make a lot of sense. Hold on a sec.
<cloudhead>
lol
<purr>
purrlol
<ec>
the user:product::developer:tool analogy is really useful for conveying this
<cloudhead>
we agree that developers are users of developer tools though right?
<cloudhead>
in the same sense as I'm a user of gmail
<ec>
Gmail (level-1-product) being great for the user (level-1-user), does not have any bearing whatsoever on a discussion amongst programmers (level-2-users) about tools (level-2-products)
<cloudhead>
there is a symmetry though
<ec>
*because* there are so so many other things that go into that final product.
<cloudhead>
wait what?
<cloudhead>
it's absolutely the same thing
<ec>
*Java* or *GWT* can't be called great, or justified at all, simply because it worked *for Gmail*. There's also Google's weight to consider, so on, so forth.
<cloudhead>
a user uses Office for work, I use an editor
<cloudhead>
oh, yeah we agree on that
<cloudhead>
they have no bearing on each other
<cloudhead>
that's obvious
<ec>
and *in the same way*, Haskell (level-2-product) being great for a programmer (level-2-user) does not have any bearing whatsoever on a discussion between tooling-developers (level-3-users) about paradigms (level-3-product)
<ec>
because there's ten thousand other things that go into Haskell, other than it being pure-functional.
<cloudhead>
except tooling developers use level 2 products
<ec>
“does not have any bearing whatsoever” very wrong. I spoke too fast.
<ec>
but “cannot be used to justify”, again, is the phrasing I want; same as above.
<cloudhead>
we understand each other
<cloudhead>
it's not the essence of it
<cloudhead>
the thing is, I don't see a difference between level 2 and 3
<cloudhead>
ie: tooling programmers are just programmers
<cloudhead>
who write programs they use
<cloudhead>
and other programmers use
<cloudhead>
or rather, I thought we were talking about level 2
<cloudhead>
not 3
<ec>
so, tl;dr: Gmail doesn't justify GWT; Haskell doesn't justify pure-functional. You *have* to evaluate programming languages/tools, level-2, either *exclusively* in the context of a particular situation (“GWT is great for Gmail”), or *exclusively* theoretically, in the large (“GWT is terrible in general”)
<ec>
you can't mix up the two
<ec>
and the same applies here:
<cloudhead>
because 3, to me, is the implementation of haskell, for ex ghc, and however that is implemented (llvm etc)
<ec>
You *have* to evaluate paradigms either specifically in the context of a partcular tool (“pure-functional works well for Haskell”), or specifically theoretically, in the absence of any particular implementation (“pure-functional is unintuitive”)
<cloudhead>
umm
<cloudhead>
yes
<cloudhead>
and I'm arguing for the former
<cloudhead>
because I think the later has no baring on anything whatsoever
<ec>
so, in that context: I wouldn't expect you, as a professional programmer with 1. lots of experience in general w.r.t. tools that you could use for tasks, and their general shapes, and 2. a reasonable level of outsider knowledge about GWT,
<cloudhead>
ie: it's just an idea
<ec>
to go *use GWT for a year* before making meaningful, useful decisions/comments about its' utility and quality
<ec>
and the same can be said here: Yes, it's totally reasonable to tell me that I can't speak about Haskell's quality *for a purpose*, that is, as a tool, until I've used it extensively.
<cloudhead>
yes, I can make a decision based on what I know of it (a few facts channeled through my experience of similar things), but I can still be wrong about that decision
<ec>
but it's *not* reasonable to expect me to learn it in detail before drawing conclusions, information, about *the shape of it*, when I have the same 1 & 2 from above
<embri0n>
anyone want to hear something im working on?
<ec>
yeah. reasonable. ugh. I badly botched that.
<ec>
embri0n: hm. how do I know you? the nick isn't familiar
<embri0n>
isnt or IS?
<ec>
isn't; did we meet recently somewhere and I told you to join up in here? :P
<cloudhead>
ec: yes, you can draw conclusions, I'm saying it's likely they will be wrong given limited experience around similar tools
<embri0n>
i dunno, maybe from #edmproduction
<ec>
I agree, *for level-2-to-level-2 discussions*
<cloudhead>
ec: if you had experience with Idris for ex, then I'd consider that enough to make a solid judgement call on haskell
<ec>
I didn't explicate that, maybe I should have: I'm arbitrarily defining something, we'll call it a “level of abstraction.”
<ec>
I may not be able to speak of Dropbox, until I've used Dropbox. That's totally reasonable. But *without being a Dropbox power-user*, I can use *things I have reliably heard about Dropbox* and/or *things I have experienced when using Dropbox at a superficial level*, to speak authoritatively about ... let's call it Dropbox-Prime.
<ec>
The abstraction-level above Dropbox.
<cloudhead>
the problem is you can say very few pertinent things about a paradigm without having experience with an implementation of said paradigm
<cloudhead>
because paradigms on their own aren't very useful
<ec>
I can *use* Dropbox, without extensive experience with it, to talk about something that *isn't* Dropbox, that I *do* have experience with.
<ec>
Are you with me so far? Don't make leaps.
<ec>
8:50:51 AM <cloudhead> because paradigms on their own aren't very useful
<cloudhead>
of course, I agree with the dropbox thing
<ec>
I disagree strongly, but I know you feel that way already, lol. you've said that in a few different ways, above.
<purr>
lolololol
<cloudhead>
you can infer based on incomplete knowledge
<ec>
no, not the same thing
<ec>
that's where I fucked up on the GWT example
<cloudhead>
well then you're saying I can talk about programming languages without ever having programmed, and have correct opinions on them
<ec>
I'm not talking about ... “evaluating a specific possibility based on incomplete knowledge.” (GWT example. fucked up.) I'm talking, instead, about “extracting inferences about higher-levels-of-abstraction, from a set of multiple pieces of incomplete-knowledge.”
<cloudhead>
dropbox prime is not a higher level of abstraction from dropbox though
<cloudhead>
it's an add-on
<ec>
so, in this Dropbox example ... again, let me run with this for a second, I think it really might help
<cloudhead>
I don't like analogies that stray too far but o
<cloudhead>
k
<ec>
ugh
<ec>
okay.
<cloudhead>
(I think it's easy to end up arguing about the analogy and not the thing itself)
<cloudhead>
but if you think it'll help..
<cloudhead>
do you think though, that you can have a valid opinion on programming languages without having programmed?
<ec>
The point is: I know functional programming, well. I know *some* pure-functional programming. I can use Haskell, as an instantiation of that knowledge, to make a point ... without knowing Haskell, that specific instantiation, thoroughly. *Because* I'm using it as an example, a *generic*, for an argument about the higher-kinded thing.
<ec>
Or to put it yet another way; Haskell is a placeholder, and the specifics of how it *fails* to live-up-to the statements about the category (in this case, fails to be as difficult-to-use as predicted), do not inherently refute those statements.
<ec>
i.e. “Haskell is easy to use for me” does not act as a refutation to “Pure-functional languages, like haskell, are terribly unintuitive to use.”
<cloudhead>
they do refute them I think..
<ec>
precisely *because* Haskell is a particular *thing*, an instance, consisting of much more than ‘pure functionality’
<cloudhead>
because the specific is always stronger than the vague
<ec>
No! Oh my god, are you even a programmer? :P
<ec>
sorry, that was a joke
<ec>
as in:
<cloudhead>
this is my whole point
<ec>
Foo = new Bar
<ec>
Foo.hasProperty = true
<cloudhead>
there's no such thing as 'pure functionality', disembodied of anything
<ec>
I can still say “Bar has no hasProperty”
<ec>
without it being false because Foo *does* haveProperty
<ec>
there's also no such thing as Bar!
<cloudhead>
we can't talk of functional programming as being good/bad without talking about languages
<ec>
do you not understand abstraction? o_O
<ec>
aaaahghg
<cloudhead>
lol
<purr>
lollll
<cloudhead>
dude
<cloudhead>
experience > knowledge
<ec>
Just because I cannot produce an Absolutely Pure (oh no, overloaded word) instantiation of ‘pure functionalness’, does not mean I can't make meaningful expression about that.
<cloudhead>
correct
<cloudhead>
but it doesn't go very far
<cloudhead>
because soon enough, you have to talk about the RealWorld™
<cloudhead>
and in that world, there are *specific instances*
<ec>
well, that brings us back to our split where you feel that paradigm doesn't matter, and I feel that it does
<cloudhead>
of said abstractions
<cloudhead>
that trump them
<ec>
but that's just a whole different conversation
<ec>
can you please put that aside for a sec? let's *finish* one debate before diving into another?
<cloudhead>
it does, insofar as we're pitting them against each other
<ec>
moving goalposts etc.
<cloudhead>
are we on more than one debate?
<cloudhead>
:d
<ec>
Can we at least, *finally*, agree that Haskell being good, does not mean pure-functional is necessary good for future, new langauge work?
<ec>
(And your response *need not imply* that you think Haskell is bad, or that choice-of-paradigm has any implication on future-language-work. Those are separate conversations!)
<cloudhead>
here: I can agree with you at first that, _as a paradigm_ procedural is better than functional, but who cares? because in practice, the functional language I'm using refutes that.
<cloudhead>
yes, I agree with that
<ec>
Your last statement just seems extremely, extremely illogical to me!
<cloudhead>
haskell being good does not infer *directly* anything about its paradigm's goodness
<ec>
Again, instantiation and abstraction:
<cloudhead>
but in this case, I do think there is a connection
<ec>
As you put it, w.r.t. the specific versus the general, *in your specific situations*, the specific solution that works better, *does indeed work better*. But that's a tautological result.
<cloudhead>
I think haskell being good is 30% that it is pure functional
<ec>
The thing we're interested in here, is *new* results: conclusions that can be drawn, that can inform the direction of future efforts and research.
<ec>
And while we *can* draw information and experience from Haskell, to inform those things, *the final user experience as a wholesale product* is *not* something useful to draw from
<cloudhead>
yes, but empirically, we can say that: haskell, idris and elm, three modern functional languages are all "good"
<cloudhead>
therefore this paradigm can produce good languages
<cloudhead>
that's all
<ec>
I definitely don't disagree.
<cloudhead>
:D
<ec>
I don't think functional is the *worst*, to be clear. I definitely don't think it's incapable of producing good languages.
<ec>
Here, here, here
<ec>
Here's a different way to state my original position that might clear a lot of disagreement up:
<cloudhead>
but do you not think that the strength of your position is weakened by the fact that you don't have a whole lot of *direct* experience with the paradigm, that is to say: experience with implementations of it
<ec>
I posit, most clearly put, that a large sector of the community we participate in ... toolers (people building software for career programmers, that is) ... has decided that *the aspect* of <a set of currently successful, useful tools) that is the cause for their utility and success, is this thing we'll call their ‘paradigm.’
<ec>
I believe that this will inform and direct future work in this space,
<ec>
and I think that is a Bad Thing, because I think the members of <that set> are *flukes*: that is, their quality does not follow from the thing that they happen to share.
<cloudhead>
I see I see
<cloudhead>
I almost agree with that
<cloudhead>
almost
<cloudhead>
I Agree with the first two statements
<ec>
I think, in fact, that that particular quality is *minorly harmful.*
<ec>
Not extremely. Just minorly.
<cloudhead>
right
<cloudhead>
but the problem here is that the quality is an essential part
<cloudhead>
of those tools
<cloudhead>
so if the tools are good, then that quality must be good
<cloudhead>
because the tools can't exist without that quality
<ec>
If goto-based programming is a -100 to productivity, and Ruby-style, dynamic-procedural programming is at 0, our baseline, I think purely-functional is *slightly* unintuitive, and has *middling* drawbacks to systemic design and maintenance in the large for the average human-wishing-to-leverage-computers: let's call it a -10.
<cloudhead>
not in the way they do
<cloudhead>
ex: purity is what allows laziness (not judging, just a fact)
<ec>
and thus my point, from all of the above statements, is that *as far as programming paradigm matters* (I know we differ on this),
<ec>
I wish to find *better* programming paradigms, that give the products based on them +10, or +50, or even the perfect +100.
<ec>
does that … horrible analogy using video-game stats help?
<cloudhead>
yeah, we agree on this actually
<cloudhead>
I can concede that -on it's own-, fp is a -10
<ec>
pure*
<cloudhead>
but the reality of it is that that -10, allows for a +100
<ec>
functional is great
<cloudhead>
yes
<ec>
I fucking love functional JavaScript
<ec>
... for small, self-contained libraries/modules/sections of code, that can then be integrated into non-functional wholes.
<ec>
but that's just opinion.
<cloudhead>
:)
<cloudhead>
so: pfp is -10, but enables other +100s
<ec>
there's also shadows falling here of larger opinions of mine, that I should have disclosed at the start:
<cloudhead>
or +10s
<ec>
I dislike purity *period*. Not objectively, not as “here's my logically-drawn conclusions for the field as developed thus far through my life as a person contributing to this field”, just, *I* don't want to use them or build them.
<cloudhead>
so this is the same as saying: static typing sucks, but it enables compile time checking. If I could get compile time checking without static types, then throw them away! But I can't. so I like static typing.
<ec>
(purely *anything* bores me, because I find it inherently unpragmatic.)
<ec>
mmmm!
<ec>
we're reaching agreement
<cloudhead>
yeah
<ec>
I agree with that statement, but only because of the *if*.
<cloudhead>
I think I just see things more from the practical side
<ec>
You mis-speak by saying “But I can't.”
<cloudhead>
ie: what pfp enables, rather than pfp itself
<ec>
and people with that precise viewpoint held back our field for *a decade*.
<cloudhead>
well, I can't *right now*, not theoretically
<ec>
it wasn't until recent advancements in static analysis / flow analysis trickled out of academia that people realized *that that's not true*
<ec>
and the same thing applies here:
<cloudhead>
it's still 95% true
<ec>
if we all jump on the pure-fp boat as the only way to get laziness, or safety, or what-have-you-result-that-you-enjoy, *then that will stifle development of alternatives*
<ec>
lol not at all
<purr>
lollllll
<cloudhead>
you can't catch nearly as many errors at compile time in javascript, as in haskell
<ec>
depends of course on other aspects of the langauge, but there's *tons* of research on static analysis of apparently very dynamic languages.
<cloudhead>
there's research sure
<cloudhead>
but show me a tool that can do it
<ec>
yes, but that doesn't imply that you need to be Haskell to catch those errors are compile-time! you see?
<ec>
what's the logical term for that, I forgot
<ec>
false derivation or w/e?
<cloudhead>
currently it does
<ec>
drawing the conclusion from the result?
<cloudhead>
well, I'm not doing that
<cloudhead>
since there's causality
<ec>
yessss but again you're equivocating, dropping down to a different level, a different discussion.
<cloudhead>
the type system is what allows it to catch errors
<ec>
Right now? You need safety? Go use Rust! Go use Haskell! Just don't tell me “you need to be like Haskell, to have what Haskell has.” that's not true.
<ec>
not at all. it's *one way* to catch errors.
<cloudhead>
it IS to a great extent
<cloudhead>
show me another way!
<cloudhead>
show me the same error catching functionality without static types
<cloudhead>
and I'll accept it
<ec>
again with the example of flow-analysis: there's other ways to design the language (again, there *have* to be constraints, to make it guaranteed-to-terminate, but they *don't have to be* any one of those specific things. i.e. type annotations) to lend some, most, or even all, of those same benefits
<ec>
flow analysis!?
<ec>
am I using the term wrong?
<cloudhead>
yes, I know about it
<ec>
type inference plus flow analysis yo
<cloudhead>
I Don't think it's nearly as capable
<ec>
never type a type.
<cloudhead>
you can't have type inference with dynamic types
<ec>
The foundation is there; it hasn't been extended to the level of intensity that fully-statically-declared languages are, but you can't seriously tell me that you don't see how it *could* be?
<cloudhead>
I am saying that
<cloudhead>
it's fundamentally limited
<ec>
well, okay, we're getting specific enough that we need to define terms.
<cloudhead>
*this current approach*
<ec>
what do you mean by ‘dynamic types,’ w.r.t. this precise topic
<cloudhead>
maybe someone will invent something better in the future
<ec>
because I disagree, but I would use the term ‘dynamic language.’
<cloudhead>
but currently we're not there
<cloudhead>
nothing comes close
<cloudhead>
dynamic types => a variable can old different types during its runtime
<ec>
uh, I'm very convinced that things that currently exist, in terms of esolangs/theory, come Very Close;
<cloudhead>
hold*
<ec>
and that their distance/differences are due to it being a new field (five, ten years old) compared to static typing, an approach with thirty years of expansion under its belt?
<cloudhead>
you don't see the fundamental difference?
<ec>
again, instantiation: I wouldn't suggest this *for a project*
<cloudhead>
static typing is not just a way to check types, it's a way to write programs that says types are *decided* at compile time
<ec>
but if you're designing a new language, I'd be horrified if someone locked themselves into a pure-functional / statically-typed “shape” from day one of the design work, because they think there are no alternatives out there that can reach that level of <desired quality>
<ec>
(whether safety or whatever.)
<cloudhead>
yeah I would also be horrified
<cloudhead>
but that doesn't mean these approaches are wrong
<cloudhead>
in fact they could be the best ones we have today
<cloudhead>
so going a completely different route needs a compelling reason
<cloudhead>
ie: great claims need great explanation
<cloudhead>
dynamic languages will never have the error checking static languages have
<cloudhead>
fundamentally that's impossible without running the program
<cloudhead>
because running the program can change the types
<cloudhead>
so you're talking about predicting the future
<ec>
okay, back up off of types for a moment
<ec>
again I'm always more interested in discussing the more-abstracted topic
<cloudhead>
sure
<ec>
so, we've kinda accidentally moved on from pure-functional, or even just *functional*, to typing
<cloudhead>
but it's hard when there's not one example
<cloudhead>
that checks out
<ec>
and if we're gonna talk typing, I'd much rather talk *annotation in general*.
<ec>
that is:
<ec>
the fundamental and philosophical difference (“paradigm-level” aspect of programming-langauge design, I suppose ... except this is a bit orthogonal to paradigm),
<ec>
of “design our language in a way that requires as much information from the user as possible, up front, and then over time improve the language by doing more and more with that information”,
<ec>
versus “require as little information from the user as possible, and improve our language over time to *infer* as much as we can from that information”
<ec>
unfortunately the terms dynamic language and static language are very overloaded, rn
<cloudhead>
the reason this was brought up is because I believe paradigm is the reason why certain language can do certain "Good" things. So paradigm on its own is not very interesting to discuss, since it's all about what it allows to do.
<ec>
but specifically *not* referring to variable declaration, usage, and extent (the language work I'm interested in doesn't even *have* variables, much less care/talk about whether those variables have a limited extent w.r.t. type)
<ec>
let's call the former static (“statically entered annotation”) and dynamic (“dynamically inferred annotation”)
<cloudhead>
hmm, it's not *just* information though, it's also "truths"
<ec>
yeah, and I disagreed
<ec>
I think this discussion will go a long way towards clearing that up, though
<ec>
yes, yes, I definitely know what you're saying there
<cloudhead>
annotations are a dynamic concept
<ec>
hold up w.r.t. *constraints*
<cloudhead>
kk
<ec>
what you're calling truths, I call constraints: absolute constraints on the user are *enabling*, annotations by the user are *aiding*.
<ec>
does that make sense?
<ec>
saying “Variables have a type” is aiding, but saying “Variables cannot change type” is constraining.
<cloudhead>
yes
<ec>
so, let's table constraints for a moment.
<cloudhead>
and the later is an annotation + a constraint
<ec>
well it requires the former, so yes, lol
<purr>
lolololol
<cloudhead>
ok
<ec>
shit
<ec>
frankly a cute girl is talking to me and that's going to immediately monopolize my attention :P
<cloudhead>
lol
<cloudhead>
that's ok, I need to shower
<cloudhead>
I've been sitting here for 2h in pjs
<ec>
-queue 9:24:27 AM <cloudhead> the reason this was brought up is because I believe paradigm is the reason why certain language can do certain "Good" things. So paradigm on its own is not very interesting to discuss, since it's all about what it allows to do.
embri0n has quit [Quit: Leaving...]
<ec>
-queue annotations vs. constraints
<cloudhead>
perfect
<cloudhead>
that's a good springboard
* ec
nods
<ec>
cloudhead: I love you. Okay?
<cloudhead>
ec: of course
<ec>
I respect you and all of the work I've seen out of you fucking immensely.
<cloudhead>
<3
<cloudhead>
I don't typically discuss things in depth with people I don't care about
<ec>
sorry, just felt necessary to annotate (
<cloudhead>
kek
amatecha has quit [Max SendQ exceeded]
amatecha has joined #elliottcable
embri0n has joined #elliottcable
embri0n has quit [Quit: Leaving...]
<incomprehensibly>
ec: idk if you've ever worked on like several hundred-thousand line code bases but saying "variables cannot change type" is absolutely aiding
<ec>
incomprehensibly: re-read, was contrasting "just aid" with "constraining aid"
<ec>
not "constrain" in a bad way.
<ec>
lol loaded terms in cs.
<purr>
lollll
wraithgar has joined #elliottcable
<cloudhead>
'constraining aid' sounds like something for the retired
embri0n has joined #elliottcable
embri0n has quit [Ping timeout: 272 seconds]
embri0n has joined #elliottcable
embri0n has quit [Ping timeout: 264 seconds]
eligrey has joined #elliottcable
eligrey has quit [Read error: Connection reset by peer]
eligrey has joined #elliottcable
eligrey has quit [Read error: Connection reset by peer]