7 ms·

Except missing the pesky runtime implementation. We don't need though, right? As long as the types say it's right.

• davidmurdoch 3y ago
  What do you mean? `console.log` supports `%d` and `%f` already.
  • sroussey 3y ago
    console.log("This is a %s and a %d!", "string", 4.3) -> This is a string and a 4!
• smcl 3y ago
  I think the point is safely typing the pattern of having variadic functions with a format string argument. The function implementation itself isn’t that interesting, or “pesky” to be honest
• cobbal 3y ago
  The static types depicted in typescript are entirely fictitious. Any similarity to runtime types is purely coincidental.
  • eyelidlessness 3y ago
    This is such a cynical take. The point is to model what types exist at runtime in the type system, so that you can reason about those same runtime types statically. They’re only “fictitious” if they’re defined incorrectly, or if the type system can’t sufficiently express certain of their nuances. The former is usually only the case when developers intentionally work around the safety provided by the type system; the latter is possible, but at this point it’s usually only ever the case for patterns that are hard to reason about regardless of the type system or even the presence of types at all.
    • zogrodea 3y ago
      I find myself inclined to the opinion you're disagreeing with in all honesty. When defining types in other languages, the task is prescriptive (you specify what fields there are in a type and the runtime accepts this as law), but in Typesxript the task is meant to be descriptive (as you say, one models the types that exist at runtime which is the inverse). I was excited about Typescript when I learned it, but found myself disillusioned by actual experience when using it (of course others love it and have good reason to). Had defined classes in Typescript so I can have some of my types reflected at runtime.
      • quaunaut 3y ago
        Curious what your issue was with duck-typing. Were you effectively looking to create ADTs that are required to go through a specific step-by-step process, not simply 'look like' the thing that was expected? If so, you might be interested in [newtype-ts]. [newtype-ts]: https://github.com/gcanti/newtype-ts https://github.com/gcanti/newtype-ts
        • zogrodea 3y ago
          Thanks for the link. That was exactly my use case and I should remember your helpful suggestion next time I use TS.
  • gibbitz 3y ago
    Yeah. I see a lot of "typescript is more readable" arguments out there, but I find this code dense and verbose. The more words you use to explain something the more likely you are to be misunderstood. What we're looking at here is basically a restricted wrapper for console.log and a regex implementation meant to simulate a logger in another language. Why not just write a cross-compiler for that language? There's no learning curve for the syntax then, only the target platform. <rant>The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages. </rant>
    • quaunaut 3y ago
      This isn't typical application code, but either proof-of-concept or library code. What you'd instead get is the type error, which in turn would explain itself well enough- that it expected a certain type, and got a different type. The reason you wouldn't want a cross-compiler for that other language is that there are true semantic differences between languages, and many languages simply cannot fully support the JS runtime- and if your primary application is still in Typescript, trying to cross-compile for a single feature is downright ridiculous. > The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages. I sincerely don't think statically typed languages are superior, but I'd argue a large part of the increase in quality over the last few years of the ecosystem is due in large part to Typescript. Is it going to fix all, or even a majority of the issues? Probably not. But if it can improve upon the situation I don't see why we'd make perfect the enemy of good.
    • iainmerrick 3y ago
      Hmm, let me try to defend TypeScript, then. I think it’s a terrific language, and more importantly manages to salvage JavaScript into a very decent language. Coming from a mostly C/C++ background, I had been very skeptical of “gradually typed” languages like Dart (and now Python), but I’ve come around to the view that for many purposes it’s better than a completely statically typed compiled language. You don’t need to compile TS at all, just bundle it, which is lightning fast in current tools, so it feels almost as nimble as pure JS. But you have almost-instant type checking in tooltips and code completions, and you can run a full project check whenever you want (that’s slow, but still way faster than compiling Rust). The type system isn’t perfect but it’s incredibly expressive. Almost anything you could imagine doing in straightforward JS can be typed (admittedly sometimes with a lot of effort and head-scratching) and once typed it’s generally easy to use with confidence that most runtime errors will be avoided. The fact that JS and TS are separate languages is a bonus -- it keeps TS honest, and the competition between JS engines means runtime performance is great. If you were designing TS from scratch, I think you’d be tempted to add some kind of runtime type reification, but TS is better off without that. Completely erasing types means compilation will always be fast, and in my experience RTTI causes more architectural problems than it solves.
  • tengbretson 3y ago
    Guardrails won't keep you on the road if you intentionally steer into them at full speed either.
  • quaunaut 3y ago
    I mean, all types are "entirely fictitious" as far as the computer is concerned. Yeah they usually have fewer layers than JS does, but that's a pretty arbitrary line to draw.
  • paulddraper 3y ago
    If they're "coincidental" you missing the point, and not doing them right.