ec changed the topic of #elliottcable to: a 𝕯𝖊𝖓 𝖔𝖋 𝕯𝖊𝖙𝖊𝖗𝖒𝖎𝖓𝖊𝖉 𝕯𝖆𝖒𝖘𝖊𝖑𝖘 slash s͔̞u͕͙p͙͓e̜̺r̼̦i̼̜o̖̬r̙̙ c̝͉ụ̧͘ḷ̡͙ţ͓̀ || #ELLIOTTCABLE is not about ELLIOTTCABLE
_whitelogger has joined #elliottcable
_whitelogger has joined #elliottcable
Sgeo_ has quit [Read error: Connection reset by peer]
Sgeo_ has joined #elliottcable
<ec>
happy new year, all y'all! 🤗
<ec>
man, I'm in this excellent-but-frustrating position at work
<ec>
I have no boss rn, long story; just an absentee CEO directly above me and my team,
<ec>
and the situations surrounding that suck a lot, but it *also* removed the biggest thing holding us back.
<ec>
in particular, our CEO is quite technical, and my team and I sat down and had a long and really in-depth discussion about tools and techniques and changes that need to be made, and he definitely listened.
<ec>
tl;dr maybe we're switching from Ember to React, at least for some stuff; and from untyped, extremely-boilerplate-unit-test-y JavaScript (*not* a great choice for a programming language … jesus. I should know.) to OCaml or Elm or something, or at the very least a breath of TypeScript.
<ec>
thing is, i can't get us *business* breathing room to do that. we're busy startupey startupping a startup, and if someone sits down and bangs out some better replacements, it's gonna be one of us, and it's gonna probably involve a *lot* of unpaid overtime.
<ec>
s/one of us/all of us/
<ec>
which like. goes really fucking hard against a "don't burn yourself out for the sake of some startup" and "work 40 hours and no more for your own well-being" mindset that's been burned into me by my community over years …
<ec>
tl;dr I can either 1. work healthy hours over the next six months, but spend those healthy hours (and many more to follow — I don't particularly want to quit this place) working in old tools, and struggling with ancient, deprecated tools and techniques that are really inappropriate for the workpiece;
<ec>
or 2. I can work *unhealthy* hours, to no direct personal benefit financially, over the next six-ish months, and during/thereafter get to work in Fucking Cool and Much-Less Frustrating Tools.
<ec>
</vent>
<jfhbrook>
typescript sounds cool
<jfhbrook>
we use flow at work, the typechecks are handy
<ec>
I luff Flow
<jfhbrook>
I still like javascript though I was reading some of my old shit the other day and it aged well
<ec>
hahah same feels!
<ec>
strong agree
<jfhbrook>
also: happy new year, I'm super hung over
<ec>
was *just* having this conversation in the car lmao
<jfhbrook>
I think you should do something in the middle - don't work 80 hr weeks to put this startup on a FP platform
<jfhbrook>
but adding support for something like flow won't take as long and will pay immediate dividends
<ec>
yeah, that's definitely the minimum
<ec>
one thing I'm *desperate* for is type-extraction in Reason et al
Sgeo__ has joined #elliottcable
<ec>
thing is, I want sound type systems in an end product, someday; but literally by definition, sound systems are difficult to install partially or without strong opinions
<ec>
I'd love to start using sound systems in some leafy places (think implementing dependency-less UI components in ML, which React was literally built for, and is therefore noncontroversial);
<ec>
while simultaneously starting to type nastier — but way more important — code with an unsound gradual-typing system like Flow
<jfhbrook>
don't remember what sound means
<ec>
problem right now is, while it's on various roadmaps for products that I've seen, there's really no *extant* story for extracting the latter from the former … so I would just have to trust/assume that such a system will exist by the time those two systems meet in the middle
<jfhbrook>
assume it's some guarantee that you can't get the wrong types past the compiler but dunno
<jfhbrook>
but also I love surround sound!
<ec>
so, flow and typescript are ‘unsound’. in this context, it basically means they have an `any` type.
<jfhbrook>
I got mad tweeters b!
<jfhbrook>
oh, yeah
<ec>
which is very definitely a *feature* in those systems lol
<jfhbrook>
yeah def
<jfhbrook>
hard to put the genie back in there
<ec>
but also a huge problem in interop'ing with something like ML …
<ec>
(also they're like. not-done unsound, too. both have very young ‘strict’ features you can opt-in to; but they're unfortunately still unsound even when in strict mode … but that's beside the point.)
Sgeo_ has quit [Ping timeout: 268 seconds]
<ec>
(more specifically yah, sound means proven, in the mathematical sense. without soundness, you need runtime typechecks, which defeats a huge portion of the purpose of these things … someday, though!)
<ec>
anyway yeah my vague plan would be better in an ideal, or future, world, wherein I can automatedly extract Flow, or TypeScript definitions from BuckleScript/Reason/OCaml, or Elm.
<ec>
then, at a middle boundary where the gradually-typed-but-critical system starts to meet the soundly-typed-but-vapid frontend, the whole system merges into one effectively-gradually-typed machine
Sgeo has joined #elliottcable
<jfhbrook>
vapid?
<jfhbrook>
oh
<ec>
but without that component, those interfaces are going to have to be entirely *untyped*, which means that neither the sound system nor the unsound system can ever call into the other … which means two or three orders of magnitude more unit tests than would otherwise be necessary
<jfhbrook>
I mean frontend can be important
<jfhbrook>
anyway, yeah
<ec>
I don't mean that judgementally lmao
<ec>
more in a math-adjacent sense, I guess? like ‘trivially true’
<jfhbrook>
oh, sure
<ec>
hahah thx 4 chattin it thru
<ec>
w/ me
<ec>
time to read more React docs!
<ec>
so far, super impressed. this stuff is surprisingly well designed.
<jfhbrook>
oh, yeah
<jfhbrook>
I did a react tutorial once seemed decent
<ec>
well, I guess not *surprisingly,* because it's taken over the entire universe … had to have *some* merits … lmao
<jfhbrook>
but the tutorial didn't say enough about structure
<jfhbrook>
I think it's really funny how much react code has .bind in it
<jfhbrook>
it was generally a thing I avoided because it breaks call/apply no?
<jfhbrook>
dang I'd danged near forgotten about that
<ec>
well now we almost have the new syntax for that
<ec>
which is waaaaaaaaay more intuitive for stuff like this, once you grok it
<jfhbrook>
new syntax?
<ec>
`::this.func` is way more reasonable than `this.func.bind(this)`
<jfhbrook>
oh yeah
<jfhbrook>
but they're doing that for real?
<jfhbrook>
man new age javascript is weird
<ec>
afaik ¯\_(ツ)_/¯
<ec>
right!?
<ec>
I can never quiiiiite wrap my head around new stuff
<jfhbrook>
well it /looks/ weird
<ec>
about the only feature I regularly use in my head w/o actively thinking about it slash realising why I need it, is `const`/`let`
<jfhbrook>
it's like if someone made an addition to an old house but did something ultra sleek and modern
<jfhbrook>
and the styles don't match at all
<ec>
everything else, fatarrows, classes, import, I have to actively pause and *choose* over the 2009 alternative :x
<jfhbrook>
yeah const/let is straightforward
<jfhbrook>
I'm ok w/ fat arrow and classes
<ec>
class statement I kinda hate tbh
<jfhbrook>
import hasn't proven itself to be reliable yet in my mind but I can do it
<ec>
I was watching Kachel struggle with this literally last week
<jfhbrook>
I'd def still pick require from nodejs
<ec>
and it's just. such a fucking unnecessary lie.
<ec>
it's not 1998, we don't need to ‘sell’ JavaScript as if it were Java or w/e …
<ec>
just jesus what an unnecessary stumbling-block for newcomers /=
<ec>
CoffeeScript's shorthand for `x.prototype.y` was far superior. strong belief.
<ec>
import well
<ec>
I strongly appreciate? or appreciate the need for? but it kinda sucks that we're still only ‘allllllllmost there’, half a decade later … (ish? how long *has* it been? I don't remember.)
<jfhbrook>
and yeah agree, I think there was def room to improve the syntax around prototypes without, y'know, lying/bending the truth
<jfhbrook>
well like if you're using webpack you're golden, except then you're dealing with bundling
<ec>
statically-analysable dependencies? all fucking for it! yeah! but let's just like, get there already, jesus Node.
<ec>
only-kinda-golden*. esnext, module, whatever field is *still* not fucking settled on.
<jfhbrook>
yeah I mean those guys have been talking in the same circle for that entire time
<jfhbrook>
it's just every time they commit to something someone gets pissed off
<jfhbrook>
or almost commit to something
<jfhbrook>
webpack and friends do it ok though they transpile to one of the things that the node people have to work around now
<jfhbrook>
our frontend uses imports
<jfhbrook>
at work I mean
<ec>
ljharb has some Stuff™ about this, maybe he can elaborate; but apparently one of the parties involved did exactly that? and now it's stomped on and can't be reused by a standardised process?
<jfhbrook>
well yeah
<ec>
idr the details but yeah I understood why that's basically bad and kinda sucks for the future, even as badly as I want all this to fucking be over already.
<ec>
future is a pretty cool place tho.
<ec>
React is really impressive so far.
<jfhbrook>
babel, it was babel
<ec>
I learned waaaaaaay more about Webpack than I ever wanted to at work this fall, but now I'm kinda happy to have — it's actually so very cool
<jfhbrook>
babel introduced a way of transpiling module syntax that means that node has to make sure to read the transpiled version for those libraries
<ec>
I'm still pissed about Yarn, can that fucking please die already, but otherwise, JS in 2018 has been pretty hella positive.
<jfhbrook>
yeah I have not messed w/ webpack
<jfhbrook>
yeah yarn sucks we use that too
<ec>
I transitioned my entire company's architecture away from it without asking anybody lmao. was just kinda “run this command to uninstall the old thing, add this alias if you have muscle memory, this is done, deal with it.”
<jfhbrook>
nice
<jfhbrook>
my coworker did that with dbt
<jfhbrook>
he went to the looker conference (looker is our BI tool) and saw a talk about using dbt to replace our looker PDTs (a feature of our BI tool that lets us construct materialized views)
<ec>
what do any of those acronyms mean
<ec>
i am a dumb and bad at business startup stuff
<ec>
hahah all my coworkers kinda handle me with kid gloves, it's really cute
<jfhbrook>
business intelligence - dashboards and data explorers for the business built on top of your data warehouse (the data that you collect so that the business can flip through it in the dashboards)
<ec>
ahhhh we use uhhh
<ec>
Periscope? is that that?
<jfhbrook>
I think that's a streaming app
<ec>
and dbt? wassat
<ec>
hahaha shaddup
<jfhbrook>
so dbt is this thing where you write a massive sql expression (w/ a down and dirty macro system built on top of jinja templates) and it will make a new table out of the output of that sql expression
<jfhbrook>
and you can make tables reference each other and it'll manage/update full pipelines
<ec>
reminder that I still, somehow, do not know SQL
<ec>
need to learn SQL
<jfhbrook>
meanwhile the looker ones don't have that concept, no macros
<jfhbrook>
oh sql is fucking dope
<ec>
maybe need to do a Dan-Abramov-y post about the things I still don't fucking know lmao
<jfhbrook>
like it's gnar but it's a real language
<jfhbrook>
and we use it to do real data transformations
<ec>
oh wait
<ec>
yah got it
<ec>
so its a more direct layer on top of the underlaying technology
<ec>
so that anything supporting SQL can now reference an efficient, standardised view kinda
<ec>
cool
<jfhbrook>
oh, well so the syntax looks like CREATE TABLE new_table AS ( query that returns a million rows here );
<jfhbrook>
so you can use that to do batch jobs, data cleanup and such, if you have a database tuned for that use (or more likely Big Data sql tools like hive)
<jfhbrook>
anyway, when mike got back from the looker conference he was like, "oh I heard about this thing called dbt it looked really cool" a few days later 'oh here look I'm rewriting all of this shit to use dbt' *not even mad*
<jfhbrook>
he did that with type checking in the data warehouse too
<jfhbrook>
I've been meaning to add type checking to my work
Sgeo_ has joined #elliottcable
Sgeo has quit [Ping timeout: 250 seconds]
<ec>
is dbt a product, or a feature of modern databases that goes underused
Sgeo__ has joined #elliottcable
<ec>
ah I see it
<ec>
fucking cool!
<jfhbrook>
oh yeah it's a piece of software, open source afaik
Sgeo_ has quit [Ping timeout: 250 seconds]
<jfhbrook>
materialized views as a more general concept are fairly popular if you're working with a data lake, like you'll hear people talk about hive or presto, those are sql engines on top of a bunch of, say, files in s3
<jfhbrook>
redshift, the database we buy from aws, also supports that mode now, though we haven't set it up
<jfhbrook>
I think it could be a really cool way to query old data
scrptktty has joined #elliottcable
<ec>
data lake 🤣
<pikajude>
that's my favorite lake
<ec>
man I can't say I understand or remotely buy into "composition over inheritance"
<ec>
like I've read thru some of React's "we ran into these problems" w/ mixins and inheritance and such
<ec>
and *functional* composition, sureyesyayyummmmy
<ec>
but when there's state? and it's already shared? composition seems the *opposite* of the way to go …
Sgeo_ has joined #elliottcable
Sgeo__ has quit [Ping timeout: 250 seconds]
<jfhbrook>
ec I like to joke that our data infrastructure is less a data lake or data pond and more a data wetlands
<jfhbrook>
data marsh, data swamp
<jfhbrook>
you can stretch this metaphor pretty hard
<ljharb>
ec: just got the ping, looks like you answered it :-p but if you want to rant about more js stuff in 2018 lmk
<ec>
O hey saw a comment from you on conditional access wtfevrr,
<rrrik>
hey ec
<ec>
Do you think fuckin safe navigation is gonna be stage 2/3 in 2019? Or should I give the fuck up on this? ಠ_ಠ
<ec>
Grrrr
<ec>
rrrik: hi love <3
<ljharb>
ec: i mean, it's stage 1 right now, and i think there's the *possibility* of it advancing in march
<jfhbrook>
safe navigation?
<ljharb>
the main conflicts were that `?[` and `?(` were impossible, `??.`/`??[`/`??(` worked but killed `??` for nullish coalescing; and `?.`/`?.[`/`?.(` isn't a consistent "prefix + operator"
<ljharb>
(optional chaining)
<jfhbrook>
oh neat
<jfhbrook>
freaking javascript lol
<ljharb>
i'm one of the few people who have been fighting very hard for consistency around `<token>.`/`<token>[`/`<token>(`, but i suspect i'll end up caving so that it can advance
<rrrik>
ec, sup with you these days
<rrrik>
I moved to Germany
<ec>
Get into PLT? 🤣
<ec>
ljharb: personally, I’d rather see bleh[ and bleh( compromised, or even dropped, to get ?. Into the language faster /=
<rrrik>
ec, soon
<rrrik>
I'm gonna be doing Computational Linguistics from next year
<ec>
I don’t think I’ve wanted/needed those two *once*, but I hurt for ?. several times a week
<ec>
God I’m so tired
<ljharb>
ec: a) dropping them now prevents them from ever being added ever, so that's not a good idea
<ec>
Oh my ideas are terrible. Speaking as a user, not a language designer. 🤣
<ljharb>
ec: and b) dropping `[ ]` is not an option because symbols are a first-class language feature, and you need bracket to use symbols
<ljharb>
lol
<ec>
Ahhhh fair point
<ec>
Sigh
<ljharb>
you'd be pretty sad if you got optional dot, but couldn't use optional protocol access once first-class protocols ships :-p
<ec>
But. Still. Compromising.
<ljharb>
"status quo" is the easiest compromise
<ec>
Nnnnnnno
Sgeo_ has joined #elliottcable
<ec>
Foo?.bar, Foofuckthisisannoyingbutheywealldealtwithprototypefordecades[bar], and Foofuckthisisannoyingbutheywealldealtwithprototypefordecades(bar)