5 ms·
The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that th
by mubou 1y ago
The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types.
On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely using types.
- 18nleung 1y agoI would have written a shorter source, but I did not have the time.
- sgrove 1y agoOr even run doom in TypeScript's type system!
- throwanem 1y agoPeople have fussed the same of the C preprocessor, around the same time I and maybe you were born. (There's a pretty good chance I'm your parents' age, and nearly no chance you're the age of mine.)
- NoTeslaThrow 1y agoThe criticisms were valid then, too. C (including the preprocessor of course) is still not fully parseable if you include things like token concatenation.
- throwanem 1y agoI make no representation as to soundness, then or now. Not till I figure out where my copy of the UNIX-HATERS Handbook has got to, at any rate. I've had cause reasonably recently to reread the X and sendmail chapters, not so much this one.
- antonvs 1y agoX and sendmail are not really very relevant today.
- deleted 1y ago[deleted]
- throwanem 1y agoThe mistakes embodied in both thus far look not just still relevant but positively timeless. Certainly, to judge by how often young people with no sense of their field's history recapitulate those mistakes.
- antonvs 1y agoWithout specifics it's difficult to evaluate what you're saying. What are some examples of the timeless mistakes in those programs? I think X was a pretty good effort, it's just that it essentially ossified and has been left behind compared to some more modern systems (although I'm using it right now.) Sendmail approach to dynamic configuration was sub-optimal. But these aren't examples of mistakes that I see recapitulated often.
- throwanem 1y agoI referred to the relevant chapters of a book which I named. This is the book: https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf Not every configuration system is as bad as the m4 nightmare that sendmail used, and I understand nothing really better was feasible in the prelapsarian or Stone Age days of its implementation. But I worked - fought - with sendmail for years and, as in the book, I also remain mildly surprised that Allman continues to perambulate. Most such things in my later professional experience differ by degree, not kind. YAML is not as bad as what was typically perpetrated in Perl days, but it does too much and too little and all its fiddly rules give me headaches. JSON is awful and what we're basically stuck with, because even though it's so simple it's almost useless, at least it's simple. XML is much better than it gets credit for, but nobody likes it because most programmers seem to regard the need to use a keyboard as an imposition, and I assume also have frequent nightmares featuring lots of pointy angle brackets. (I use Emacs because I don't hate myself, and I wish more people had the sense to keep things as simple as Emacs Lisp typically is.) I don't want to talk about X. Wayland has been about 60% mistakes by volume, and I like too many of the people who made it too well to be anything other than sad about that.
- plopz 1y agoI wish javascript had gone in the same direction as php with types.
- rad_gruchalski 1y agoWhich is?
- 1oooqooq 1y ago[flagged]
- rad_gruchalski 1y agoI was hoping to hear how are php types better than TS instead of another rant about how Rust is the greatest. Anyone? By the way, having lived in Scala 2 for a few years, Rust is half-assed. Type system leaks through the fingers when working with async collections. Future.sequence from Scala makes great cli apps. Scala collections are a work horse. The only thing from Rust I like is the shorthand question mark return (compiler magic for Result type).
- 1oooqooq 1y agolol. i mentioned rust as being the worst typed solution, to highlight ts is even beneath that.
- rad_gruchalski 1y agoYou haven’t mentioned anything. It’s not clear what you mean. All you said “coming from rust”. That could mean a ton of things.
- spankalee 1y agoTypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS programs - it's not fluff! And luckily, the most complex of types are usually limited to and contained within library type definitions. They add a lot of value for the library users, who usually don't have to deal that that level of complexity.
- mubou 1y agoI don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly. Imagine if WASM were supported natively instead, with browsers exposing the same DOM interfaces that they do to JS. You could link a wasm binary in a <script> and do everything you can with JS/TS, but with any language of your choosing. No doubt a compiled form of TS would appear immediately. We'd no longer need separate runtime type checking. Just feels like priorities are in the wrong place.
- merb 1y agoWasm gc was needed for that. Wasm evolves slowly so that it can be done right. Even if the dom api comes, not a lot of it will change since only c-like languages will be as small as possible to fit into the space of JavaScript.
- spankalee 1y agoI think you're conflating cause and effect in several cases. TypeScript can't be thought of, and would never exist, independently from JavaScript like you're trying to do. TypeScript wasn't created separate from JavaScript and then chose JavaScript as a backend. TypeScript only exists to perform build-time type checking of JavaScript. There wouldn't be a TypeScript that compiled to something else, because other languages already have their own type systems. Runtime type-checking isn't part of TypeScript because 1) It isn't part of JavaScript, and TypeScript doesn't add runtime features anymore. 2) It'd be very expensive for simple types, 3) Complex types would be prohibitively expense as you have to both reify the types and perform deep structural checking. WASM also is natively supported, and with newer extensions like reference types and GC, we're getting closer to the point where a DOM API could be defined. It'll still be a long while, but that's the long-term direction it's heading in. But even then, you would only see a TypeScript-to-WASM compiler[1] because there's already so much TypeScript out there, not because TypeScript is a particularly good language for that environment. A more static language would be a lot better for a WASM target. [1]: Porfor is already such a compiler for JS and TS, but it does not do runtime type-checking: https://porffor.dev/ https://porffor.dev/
- sandreas 1y agoHere is Doom in TypeScript types: https://www.tomshardware.com/video-games/porting-doom-to-typescript-types-took-3-5-trillion-lines-90gb-of-ram-and-a-full-year-of-work https://www.tomshardware.com/video-games/porting-doom-to-typ... A fun read / Video...