ec changed the topic of #elliottcable to: a 𝕯𝖊𝖓 𝖔𝖋 𝕯𝖊𝖙𝖊𝖗𝖒𝖎𝖓𝖊𝖉 𝕯𝖆𝖒𝖘𝖊𝖑𝖘 slash s͔̞u͕͙p͙͓e̜̺r̼̦i̼̜o̖̬r̙̙ c̝͉ụ̧͘ḷ̡͙ţ͓̀ || #ELLIOTTCABLE is not about ELLIOTTCABLE
<jfhbrook>
ljharb: I hear you and it's true that more people are going to already be familiar with javascript, but there's also the counterargument that all the people that *do* want to work w/ reason would be kicking down our door
<jfhbrook>
ljharb: but all of the disadvantages together do mean that typescript might strike the better balance
<ec>
I'd strongly advise against typescript
Rurik has quit [Quit: Rurik]
<ec>
it has all the downsides of *both* an untyped language *and* a typed language
<ec>
and its one, single (admittedly huge! it's still a good tool!) upside is completely unrelated to your situation
<ec>
drives me 7% batty tbh that TypeScript has such huge uptake
<ec>
it's a _gradual typing system_, fam. it's hugely useful for one situation, and that's _never_ the situation I see it being used in: adopting types in a large, successful codebase which can't be rewritten from scratch, and which the authors never expected to last so long
<ec>
great for that! absolutely terrible for anything else.
<jfhbrook>
I dunnooooo
<jfhbrook>
I think you have the advantage that it adds typing to javascript rather than being a fundamentally new language
<jfhbrook>
and I think adding typing features to an existing language means you have to make compromises
<jfhbrook>
so like we'd lose *sound* typing, but we'd still gain type safety overall while still basically writing javascript, and if nothing else having straightforward interop with the libraries on npm
<jfhbrook>
less bindings and more writing types in post
<jfhbrook>
like the ability to type gradually within an existing codebase? great! but making everything typed from the get-go on a greenfield project is also a viable path I think
<ec>
but the input-effort you have to expend for the partial type-safety is _absurd_
<jfhbrook>
I used type annotations in python and didn't find it took /that/ much extra effort
<ec>
like, you need to put in Haskell levels of "assuaging the type-system", in exchange for sub-OCaml-levels of type safety
<jfhbrook>
but python is also class-oriented, meaning typeclasses are straightforward
<ec>
it lies right *below* that inflection point where types make you do less work, overall
<jfhbrook>
with something like typescript you need to lean really heavily on structural typing I figure
<ec>
so instead, you're literally doing more work, it's such a poor position to be in
<jfhbrook>
in a world where the code doesn't account for types to begin with
<ec>
god, my macOS builds, this is torture
<jfhbrook>
I think you'd be doing more work if you had code that was "idiomatic javascript"
<ec>
yes, that's exactly what gradual typing is good for
<jfhbrook>
so like if you had that existing codebase and were trying to add typing in post, that would be a lot of work; but if you minimize the surface area of javascript and instead write your code "in typescript" - so "still javascript" but not written like regular javascript because you're writing code that makes typing it easy
<ec>
i'm not saying gradual typing is bad! again, I'm a huge toolbox-er. I think TypeScript has a place in the JS ecosystem, I just don't think that place is the one it's _currently occupying_.
<jfhbrook>
then the benefits are more clear
<ec>
people start a ton of greenfield libraries in TypeScript, which is ... really sad.
<jfhbrook>
so you commit to complete typing from the get-go
<ec>
signing themselves up for a ton of extra work for very little benefit.
<jfhbrook>
gradual typing is a technique not destiny
<jfhbrook>
you don't *have* to start w/ an untyped codebase
<ec>
not sure what you're saying
<jfhbrook>
I'm saying that gradual typing is a *use case*
<ec>
yes, and TypeScript is a tool well-suited to that
<jfhbrook>
if I write all my code to be fully typed from the get-go then it's not gradually typing, it's me using types from the beginning
<ec>
and poorly suited to anything else, because of the compramises it chose to support that use-case
<jfhbrook>
but that's not the /why/ of the compromises
<jfhbrook>
it's a capability that's easy to add simply by allowing type inference
<ec>
6'1 not parsing your argument, lol
<jfhbrook>
the *reason* typescript works for gradual typing is because it's *semantically* javascript, plus the types
<ec>
er, no, not at all. typescript has _extremely poor_ inference. because it supports gradual typing.
<jfhbrook>
it *happens* that this means that you can gradually add typing to javascript
<jfhbrook>
"type inference" -> assuming things that don't have typing are of type Any
<ec>
that's exactly my point: if you don't need to add types, gradually, to an existing codebase, you're buying into some really poor tooling for your task, that's going to support you very little as you work
<jfhbrook>
but you're saying that the justification for typescript is gradual typing
<jfhbrook>
it's not
<jfhbrook>
the justification for typescript is that it's "just javascript"
<jfhbrook>
so it's not a new language, it's a superset of an existing language
<jfhbrook>
that /enables/ gradual typing but that's not the raison d'etre
<ec>
having a top type does not mean type inference, what???
<jfhbrook>
I chose the wrong words
<jfhbrook>
that doesn't detract from my point about gradual typing
<ec>
I think you have something very mixed up, here; but I'm trying to get something done, I shouldn't dive into a bunch of "WRONG ON THE INTERNET GRRRRRRR"'ing, lol
<jfhbrook>
ok
<ljharb>
typescript is broken tho, it’s not a superset of js and it can generate invalid js
<ljharb>
I’m keeping a list of all the ways it’s not a superset
<ec>
it's also a terrible type-system, for everything except gradual typing -_-
<ec>
lol we have a similar opinion for opposite reasons, that's slightly adorable
<ec>
FAM MY GODDAMN BUILD FINISHED
<ec>
well the three builds that have to happen sequentially, and take 25-45 minutes each
<jfhbrook>
my argument is about semantics
<jfhbrook>
the end result is the same
<jfhbrook>
that's fair ljharb but you'd at least admit that the impedance mismatch is lower than something like bucklescript
<jfhbrook>
or even something like clojurescript, which is still fundamentally going to have different semantics from javascript
<ljharb>
sure, the issue with typescript is the marketing lie that it’s a superset
<ljharb>
those others don’t make that claim
<jfhbrook>
a vague superset :)
<jfhbrook>
I have a friend that will say "vaguely" instead of "somewhat"
<jfhbrook>
we give her shit about it
<ec>
BuckleScript does something similarly annoying
<ec>
the marketing claims it produces extremely readable output
<ec>
like, yeah! it totally does! … by compiler-developer standards, like mine.
<ec>
if you’re looking at OCaml-compiles-output and comparing it to that coming out of, say, ClojureScript or the Google compiler or Fable, oh wow holy shit is it more simple and JavaScript-y
<ec>
but A. it’s definitely not “woah! nobody’ll know you didn’t write this by hand!!!”, which is what non-compiler-developers expect when they hear ‘readable output’,
<ec>
and B. it really only is good, at all, because OCaml’s already so similar, semantically, to JS. for a lot of basic common stuff, compilation amounts to removing the type-annotations and translating the syntax. :P
<ec>
that’s not to say Hongbo et. al haven’t put a ton of work into making the less-semantically-similar parts compile beautifully, but it’s still very obviously compiled output. so, idk, yuck took-marketing all around, I guess? >,>
<jfhbrook>
🤔 either way I think it's time for me to give typescript a shot - I think I have a project that it will be a good fit for in terms of learnings
<jfhbrook>
and if it sucks it's a small project
<jfhbrook>
I *was* gonna do the elixir project but in order to do the elixir project I need the postgres manager project which for Reasons needs to target node.js/electron as a runtime 🙃
<jfhbrook>
funny enough, elixir doesn't have type annotations at all - instead you're forced to do runtime pattern matching, which to be fair is pretty good - but you aren't allowed language-enforced type safety :)
Rurik has joined #elliottcable
vilhalmer has quit [Remote host closed the connection]