Pour One Out For The Pre-TypeScript Mindset (or Perl)

When I first started learning code, in 1989, it was QBASIC.

When I first started programming semi-professionally in 2000, it was Visual Basic and very quickly after that, early iterations of ASP.NET.

When I first started programming fully professionally, in 2006, it was in Perl, and it was in Perl that I remained through 2013, the years that I rose from junior to mid to senior to full stack (and then would go on to a CTO position at my next job).

These were the years that I had most of my full-fledged "real world programming team learning experiences". All the little formative bits of real business dynamics, both interpersonal and technical, that they don't teach you in college or boot camp but you understand once you really live it.

• The way that 99% of your tickets are about adding more business logic to a form field and 1% are about reversing a linked list.
• The way your one coworker went all-in, hard, on an exciting new framework only to be humbled when it doesn't take. (Yahoo's YUI, anybody?) Then the way you feel when it happens to you later and your big framework lands with a thud or gets beaten at its own game six months later. (This was me when I went in hard on prototype only to see jQuery eat its lunch.)
• The tireless march from other managers to find a way to ascribe a number to what devs do so that number can later be made to go up ??... the neverending quest that has taken a dozen different forms since I entered the workforce.

It was during these formative years where most of my learning how to problem-solve idioms were formed, and they were formed in a Perl context. This shaped the way I would fundamentally think about solving problems in the future: it gave me a new toolset of idioms that would form my "reach for these tools first" toolkit.

• I got used to reaching for console.logs and debug statements more than interactive IDE debuggers.
• I got used to in-code commenting rather than explicit documentation docs.
• I got used to adding ad-hoc properties to objects (oh listen youngster back in my day we called them hashrefs) as just a kind of grab bag catch-all. You getting an array of objects that all have key and id properties? You want them to have a objDingus property now? Go ahead and toss it in there. You want it to be a number or a string? Go nuts.
• I got used to simple diligence on most things that were ambiguously typed as best practice so that I could be explicit about how user input was being treated anyway.
• I got used to going right into lib files and hacking them to be to my liking.
• I got used to hand-waving away everything I didn't care about. For instance, a common idiom in perl was to trap for errors (if you can even call it that) by appending "or die" to the end of an imperative statement. What's it mean? It's just a general "okay uh if that didn't work, idk man, just kill the process". It's inelegant but also extremely useful for moving on with your life.
• I got used to the official mantra of TMTOWDI (There's More Than One Way To Do It") that defined the perl ethos and got used to accepting any Good answer rather than debating and questing with the implied belief that there would be a Best answer.

None of these is "better" than the alternative; in fact, I've got to say they're almost all worse, honestly. Of course you ought to truly investigate the different properties of an error rather than throwing your hands up in the air and saying "honestly i don't care". Of course you should actually fork repos you need to customize and manage your own packages instead of just applying diff patch files to your /lib directory. Of course it is useful for everybody to favor Best answers over Good ones. Of course it is great to have referenceable docs rather than ad hoc comments.

All these admittedly bad styles of working lived on after Perl well and truly died. They lived on in Javascript.

(Aside: I am aware Perl is dead and am not contesting that it is dead, and I don't secretly want to still use it or something.) (Double Aside: if you point out that Perl 6 is still forging ahead, I just know you're in on the joke).

Javascript had similar-enough syntax to Perl that it was an easy move and most importantly, the TMTOWDI ethos lived on. Sure, arrayrefs and hashrefs simply became arrays and objects, and you couldn't word boolean operators using english words any more (rip "or carp and croak"), but it was still basically a get-on-with-the-show mentality.

Got an error? Meh, catch(e), console.log(e), finally resume.

Need to augment the interface of a third party library with extra functionality? Load up extra properties in the objects you pass in and reap the rewards on the objects you get out.

Know something has properties called "dingus1" and "dingus2"? Cool, you know what your code does, as it should be, on with the show.

Want some classes? Go as shallow or as deep as you want, there are multiple functional models of inheritance to choose from. Mix & match!

All right, here we go:

To me, Typescript is not an improvement on Javascript: rather, it takes away everything I liked about Javascript. I am exhausted of hearing all the ways that Typescript is superior to Javascript when they're all "technically correct" but to me just worse in practice, and I wish to be left to write my regular Javascript in peace.

I'm not advising you to not use Typescript, but I do wonder if something of value is being lost in educating new arrivals to the workforce in the wonders of type safety. This was how I was taught Java in college from 2002-2006, after which I promptly spent the rest of my life deliberately never using Java again.

I have to ask the fundamental question here: "But how will you know if something is the wrong type?!?!" Get ready: my answer is "so what".

Things have been the wrong type my entire career; it's usually not my fault or something I can control.

Things are the wrong type when a third party updates its API and doesn't update its libraries. If a new property shows up in an object that you aren't counting on in vanilla Javascript, it barely matters. In Typescript it's a disaster.

Things are the wrong type when a plugin is made for one version of React or Next and not the upcoming version, which is a problem I have actually gotten past by hacking Javascript but never successfully hacked Typescript to accomplish... too many Types all up and down the tree.

Things are the wrong type when somebody else tinkers with a database table schema without informing the people who consume that table. You've got a problem here organizationally that is not something a language should fix.

Who is in charge here? Me or the type system?

Every time I have worked in a Typescript repo (and there have been many) I have inevitably run into satisfying the compiler rather than satisfying my business directives. In an effort to protect me from myself, it slows me down on every front.

I have a third party library that's not behaving and I can't force it to act the way I want via injecting new properties because it makes dozens or even hundreds of type checks fail.

I have to stop and think about whether every user input is a number or a string, even though it doesn't truly help me on that front, since numbers can still act stringy and vice versa, and I still have to account for that.

Eventually I lose my patience and wind up having to YOLO something with a type: any and that's just game over because it's all downhill from there. I remember when I used to meddle in a lot more css, we had a saying- once you solve a problem with a !important, it's a death loop because you're gonna have to solve a different problem with a !important to override THAT. type: any has the same impact.

More than anything else, though, I could overcome all these small technical annoyances either by more correctly reforming my habits around them, learning new hacks, getting used to it, or whatever. What really bums me out is how I see juniors getting impaled on these Typescript showstoppers like my peers used to on Java over twenty years ago.

My heart breaks when I am trying to mentor some junior out of bootcamp trying to make a create-next-app with the typescript flag on who can't yarn start because some tutorial they were reading didn't get updated since the newest version of a key library with new types got released, and due to enforcing type safety, it simply doesn't run at all rather than runs in good-enough mode.

Is this what we want them to learn about the art of programming? The need to appease the Technically Correct God? The need to spend your time detailing definitions of things instead of just getting to Act II so your code can make some money?

Y'all already had this language. It was called Java and/or .NET. That's already the C-style syntaxed properly typed language with a rich class ecosystem that rigidly enforces typing and refuses to compile if everything doesn't align.

Let me have my sloppy, dirty, javascript. Let me have some loose objects that I'm just gonna assume have a property called "val" and if they do or don't I'll adjust accordingly. If that property goes away I'll have to cope somehow for reals regardless... I don't really care if it's "Type Safety" that calls me out or if it's "cannot read property val of undefined". They're both errors I gotta deal with, but one spared me hundreds of type files.

Let me have my MVP's for my clients that are done in four weeks while the other teams that do it with Type Safety take twelve, and mine can be tinkered with and changed almost instantly by anybody of any skill level where theirs can't be tinkered with without changing dozens of types.

Let me have my assumption that if let myVariableNames = prettyDescriptive() then people who are intelligent will probably figure out what's what, rather than acting like they are going to be some crazy adversaries who would just love to load a giant array of Booleans into my field called "address2" if I don't explicitly stop them.

So, I'm not trying to take y'alls Typescript away. I'm just pouring one out for the old way of thinking. The way that got it done. The way that honestly couldn't give a shit if a type check failed if the script just kept on truckin'. The way that can usually deploy a hot fix at 2am if necessary even if a third party library changes without digging through hundreds of types and eventually just resorting to type: any.

I like my Javascript right where it is. Improvised, interpreted, and just-in-time. Y'all can keep your C#.NET-except-you're-pretending-it's-in-my-ecosystem.

??