4 ms·

Typescript isn't really a class-based language. It's a language that supports both function and OO paradigms. Also, if macros/DSLs are what you're after, then

Typescript isn't really a class-based language. It's a language that supports both function and OO paradigms. Also, if macros/DSLs are what you're after, then you'd probably be interested in typescript's decorators. (you can use the old experimental decorators based on the old standard from ages past, and the new *standard* decorators introduced in typescript 5 which are based on the current stage-3 ecmascript proposal). The only things typescript as a language is really lacking are: 1. Pattern matching (minor issue) - +90% of pattern matching is really just a more concise switch/case syntax - the remaining -10% can be done by hand with mapping or just basic if statements 2. Immutable data-structures (minor issue) - The `as const` suffix handles most of the use cases. - There is a Records/Tuples proposal which would give some better syntactic sugar and some run-time performance improvements too. 3. Trait system (minor issue) - Typescript compiles down to Javascript which at the lowest level is actually a prototype-based language. Traits can be approximated using run-time mixins which alter the prototypes to essentially perform the same functions as traits. - But, it would be nice to have compile-time rather than run-time support for traits. - I think most languages are still only coming to terms with the fact that traits are often better than "traditional OOP classes". 4. Effects system (investigate) - It's too early to tell, but having an effects system (à la OCAML 5) will probably lead to entirely new programming paradigms. I'm not sure where it will lead, but having native algebraic effects to replace try/catch/throw would be very nice. Edit: Formatting

AlchemistCamp 4y ago
As I said, the primary reason I wanted macros was for the DSLs they make possible, not their use in application code. For example when I’m working on a Phoenix app, I very rarely write a macro, but I get a great deal of benefit from Elixir them since they make Phoenix’s router DSL, Ecto’s database query syntax and the standard testing DSLs possible. I disagree that "pattern matching is "really just a more concise switch/case syntax" and use it regularly in function heads and in parsing nested data structures. More importantly, I reject the premise that the four items you mentioned are the only things really lacking or even that the problem with TS was a lack of features as opposed to its bad features, superfluous features and poor design decisions. For example, I'm not a fan of any of the following: - loose typing - multiple ways to declare variables, with different scoping rules - multiple ways to declare functions, with different treatment of "this" - the ability of code in any module anywhere in the system to affect code in the module you're looking at without leaving any evidence of this in the module you're looking at - the ability of functions to alter parameters they're called with - the sort function in the standard library being destructive by using the above - etc... That said, JS/TS really is missing some important things that didn't make your list: - a good concurrency model - macros - compile time guarantees about references - list comprehensions (actually minor) - a sufficient standard library - etc...
- MrJohz 4y ago
  Fwiw, the function syntax in Typescript/Javascript is generally expressive enough to use as a basis for DSLs, and not needing to use macros for this also has a lot of benefits. I'm a big fan of Rust, but I find often library authors overuse custom syntax in macros when just writing functions would have been easier, just as expressive, and much simpler to integrate with an IDE. Where macros do exist in Javascript-land, they tend to be either to implement upcoming features, or as optimisation tools (e.g. converting CSS-in-JS expressions at build-time rather than run-time). The one exception here is probably JSX, but even there lots of people prefer to use function calls instead. But for things like testing blocks, configuration, HTML/CSS generation, etc, it's generally enough to use the language by itself.
  - AlchemistCamp 4y ago
    If JavaScript is “expressive enough to use as a basis for DSLs”, why do you suppose it is that various explicit attempts to recreate RoR in JS, going way back to SailsJS have failed to recreate its router DSL or even similarly terse models or controllers? Of course not everyone wants a Rails-inspired MVC framework experience, but why do you figure even those who did couldn’t achieve the same level of syntactic sugar? (I know Ruby doesn’t have macros either, but it does have enough expressiveness in a few other ways to do some things Python and even JS can’t)
    - MrJohz 4y ago
      It's interesting that you mention Python, because obviously the RoR equivalent there is Django which leaves something to be desired when it comes to DSLs and expressive APIs. Symphony and Laravel also come to mind here, and I guess Spring in the Java world. I think it's difficult to argue that the creation of a major web framework hinges on being able to express things in a nice DSL. Rather, I think the truth is that server-side Javascript tends to be used in a different way to Ruby - generally Node projects that I've worked on are much smaller (and often coupled with other similarly-sized services), and are often just minimal APIs designed to act as a middleman between a database and a front-end application. It's not an issue with missing expressivity, but rather a tendency not to need (or at least, not to want) the full-featured powerhouse that is RoR.
biorach 4y ago
> typescript's decorators Typescript has decorators?!! Damn, i wish I'd know about this 3 months ago.
- WorldMaker 4y ago
  ~3 months ago the TC-39 (ES/JS language steering committee) hadn't moved their decorators proposal to Stage 3 and Typescript hadn't implemented it yet. Typescript supported a much older (and different) decorators proposal under an experimental compiler flag, but my momma always taught me never to use flags marked "experimental" in Production.
- lioeters 4y ago
  Decorators in TypeScript is still an experimental feature which may change depending on if/how it's implemented in JavaScript. > To enable experimental support for decorators, you must enable the experimentalDecorators compiler option either on the command line or in your tsconfig.json https://www.typescriptlang.org/docs/handbook/decorators.html https://www.typescriptlang.org/docs/handbook/decorators.html > ..the current decorators proposal, which is a work in progress https://github.com/tc39/proposal-decorators https://github.com/tc39/proposal-decorators Oh, but I see that the proposal is now at Stage 3, which means the specs and syntax are stable ("completely described") and ready for browsers to implement. On further digging, it seems decorators will be a standard feature included in TypeScript 5.0 planned for release on March 14th. TypeScript 5.0 Iteration Plan - https://github.com/microsoft/TypeScript/issues/51362 https://github.com/microsoft/TypeScript/issues/51362
cageface 4y ago
Immerjs is close enough to language level immutable data structures that I don't miss them that much. I'm hoping the proposal for match syntax finally lands. Something like Swift's protocols would be nice. TS inherits some unfixable mistakes from JS but overall I find it a pretty comfortable and productive language.
garyclarke27 4y ago
What About Named Parameters? I'm surprised Typescript has not tried to add this major missing feature from Javascript. I know you can hack this using an Object, but for me Named Parameters are so useful for code readability and intent - especially for calling functions to make it obvious what's happening and to so that different order of arguments doesn't cause bugs.

AlchemistCamp 4y ago

As I said, the primary reason I wanted macros was for the DSLs they make possible, not their use in application code. For example when I’m working on a Phoenix app, I very rarely write a macro, but I get a great deal of benefit from Elixir them since they make Phoenix’s router DSL, Ecto’s database query syntax and the standard testing DSLs possible. I disagree that "pattern matching is "really just a more concise switch/case syntax" and use it regularly in function heads and in parsing nested data structures. More importantly, I reject the premise that the four items you mentioned are the only things really lacking or even that the problem with TS was a lack of features as opposed to its bad features, superfluous features and poor design decisions. For example, I'm not a fan of any of the following: - loose typing - multiple ways to declare variables, with different scoping rules - multiple ways to declare functions, with different treatment of "this" - the ability of code in any module anywhere in the system to affect code in the module you're looking at without leaving any evidence of this in the module you're looking at - the ability of functions to alter parameters they're called with - the sort function in the standard library being destructive by using the above - etc... That said, JS/TS really is missing some important things that didn't make your list: - a good concurrency model - macros - compile time guarantees about references - list comprehensions (actually minor) - a sufficient standard library - etc...

MrJohz 4y ago
Fwiw, the function syntax in Typescript/Javascript is generally expressive enough to use as a basis for DSLs, and not needing to use macros for this also has a lot of benefits. I'm a big fan of Rust, but I find often library authors overuse custom syntax in macros when just writing functions would have been easier, just as expressive, and much simpler to integrate with an IDE. Where macros do exist in Javascript-land, they tend to be either to implement upcoming features, or as optimisation tools (e.g. converting CSS-in-JS expressions at build-time rather than run-time). The one exception here is probably JSX, but even there lots of people prefer to use function calls instead. But for things like testing blocks, configuration, HTML/CSS generation, etc, it's generally enough to use the language by itself.
- AlchemistCamp 4y ago
  If JavaScript is “expressive enough to use as a basis for DSLs”, why do you suppose it is that various explicit attempts to recreate RoR in JS, going way back to SailsJS have failed to recreate its router DSL or even similarly terse models or controllers? Of course not everyone wants a Rails-inspired MVC framework experience, but why do you figure even those who did couldn’t achieve the same level of syntactic sugar? (I know Ruby doesn’t have macros either, but it does have enough expressiveness in a few other ways to do some things Python and even JS can’t)
  - MrJohz 4y ago
    It's interesting that you mention Python, because obviously the RoR equivalent there is Django which leaves something to be desired when it comes to DSLs and expressive APIs. Symphony and Laravel also come to mind here, and I guess Spring in the Java world. I think it's difficult to argue that the creation of a major web framework hinges on being able to express things in a nice DSL. Rather, I think the truth is that server-side Javascript tends to be used in a different way to Ruby - generally Node projects that I've worked on are much smaller (and often coupled with other similarly-sized services), and are often just minimal APIs designed to act as a middleman between a database and a front-end application. It's not an issue with missing expressivity, but rather a tendency not to need (or at least, not to want) the full-featured powerhouse that is RoR.

biorach 4y ago

> typescript's decorators Typescript has decorators?!! Damn, i wish I'd know about this 3 months ago.

WorldMaker 4y ago
~3 months ago the TC-39 (ES/JS language steering committee) hadn't moved their decorators proposal to Stage 3 and Typescript hadn't implemented it yet. Typescript supported a much older (and different) decorators proposal under an experimental compiler flag, but my momma always taught me never to use flags marked "experimental" in Production.
lioeters 4y ago
Decorators in TypeScript is still an experimental feature which may change depending on if/how it's implemented in JavaScript. > To enable experimental support for decorators, you must enable the experimentalDecorators compiler option either on the command line or in your tsconfig.json https://www.typescriptlang.org/docs/handbook/decorators.html https://www.typescriptlang.org/docs/handbook/decorators.html > ..the current decorators proposal, which is a work in progress https://github.com/tc39/proposal-decorators https://github.com/tc39/proposal-decorators Oh, but I see that the proposal is now at Stage 3, which means the specs and syntax are stable ("completely described") and ready for browsers to implement. On further digging, it seems decorators will be a standard feature included in TypeScript 5.0 planned for release on March 14th. TypeScript 5.0 Iteration Plan - https://github.com/microsoft/TypeScript/issues/51362 https://github.com/microsoft/TypeScript/issues/51362

cageface 4y ago

Immerjs is close enough to language level immutable data structures that I don't miss them that much. I'm hoping the proposal for match syntax finally lands. Something like Swift's protocols would be nice. TS inherits some unfixable mistakes from JS but overall I find it a pretty comfortable and productive language.

garyclarke27 4y ago

What About Named Parameters? I'm surprised Typescript has not tried to add this major missing feature from Javascript. I know you can hack this using an Object, but for me Named Parameters are so useful for code readability and intent - especially for calling functions to make it obvious what's happening and to so that different order of arguments doesn't cause bugs.