> (btw the SIMD proposal has been dropped to stage 1, and implementations are > not pursuing implementing it in JS for now > tc39/proposals/blob/master/inactive-proposals.md)
Yeah, that seemed predictable. I wanted the SIMD operations to use operators intuitively. That and all the SIMD core types lacked ECMAScript equivalents. Like one expected to be able to write SIMD code and not lose all the speed-up dealing with Number or casts. Was never really sold on the idea of having a float32x4 when the language can't even represent float32 without a TypedArray. Putting the cart before the horse. > where is this demand coming from? Wherever TypeScript and Flow are used; so companies like Microsoft and Facebook. I know friends that use TypeScript exclusively for application development with teams of over three people. Personally I've worked on projects over 25K lines of Javascript usually by myself, and while it would have been nice to have types it's not necessary for what I did. I didn't use classes either and relied more on a mix between agile and cowboy programming. Things have changed over the years though. One of the reasons I started wanting types and created this specification years ago was because I was working on more complex applications. Essentially taking programs that would be written (or were written in my case) in C++ and C#/WPF and writing them for the web for Android, Mac, Linux, and Windows. Part of this involved architecting and designing out ORM systems with database types and schemas. I was also doing a lot of binary WebSocket stuff at the time, some of which was somewhat performance critical with node.js on the backend. So to answer your question the demand would be developers that have transitioned to using HTML5 and Javascript for application development in teams. (In my case programs for all OSes along with web applications and interfaces). There's other reasons. My work projects have spawned off personal projects for myself in networking in databases. I'd like to use Javascript more, but I tend to fallback to C++ or C# simply because of the lack of types. I find it strange to pretend like the demand isn't there. TypeScript, and Flow have existed for a while now and I hear about them all the time in my circles. OST as described in my mind brings in the core features that people are seeking such that they can use Javascript again by itself in the future. Some people might not use them, but a lot of people would in certain places. It also might open up new features and spin-off languages since types would have already been handled without reinventing the wheel like AS3, TypeScript, and Flow did. Also realize I never intended this proposal to be implemented right away. It could take years still. Part of my slight worry as things draw on is that with all these proposals floating around that one of them will change the grammar slightly add new tokens, ASI, or other slight changes and make types infeasible or very inconsistent across the language. > Choosing type system descending from Java type system is message "creators of > language endorse OOP as main JavaScript paradigm". It's fine for TypeScript > to take opinionated approach, but it's unlikely with TC39. More like descending from Actionscript 3. I wouldn't relate a type system to OOP though. People still write non-OOP TypeScript. If you want to blame the rise of classes in Javascript you'd be looking at the introduction of classes themselves. You give programmers what they want and they'll use them for frameworks and programming. (The old way was just ugly or cumbersome so people avoided it was my experience). In any case classes are already in the spec. Types aren't going to change that. > Runtime type checking would incur significant cost on browsers (and > JavaScript parse time is already an issue for smartphone CPUs). It's > especially important to remember about dynamic nature of JavaScript. > TypeScript can rely on assumption that no one creates accessors on > Object.prototype or Array prototype, but it's unacceptable for language > feature. I'm glad you brought that up. I've been thinking about this problem of types changing for a while. Can you write down a bunch of examples and scenarios? It would help to analyze them. (Creating an issue with all of them would be ideal). Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable. That is referencing a class in say a variable declaration or function signature would freeze the class. Seems a bit extreme of an option though that would cause problems for certain designs or ideas later where people want to add, remove, or update properties. Is it that important? When would a freeze even happen? I think having a lot of examples would make this easier to analyze. > People hates writing types > That's why C++ have auto, Kotlin have val, and it's significant reason why > dynamically typed languages became popular. Type inference is awesome, but > integrating it with existing JavaScript code in backwards compatible way > seems to be hard. Part of this is to find out how hard a lot of this stuff is. Speaking of type inference someone opened a ticket that started a small discussion: https://github.com/sirisian/ecmascript-types/issues/27 Basically trying to figure out if larger non-Number literals could even be placed into the language without unforeseen issues. > It might be easier to submit your ideas to these communities than to push a > third proposal. At least, a gap analysis would help people who already know > these systems. I've talked to people in the communities in the past. They seem beyond caring about Javascript. I've been told to "just use TypeScript" on a few occasions with little input. I'd probably have to find someone very specific on their team willing to help. That's more or less why I made a comment about looking for a champion or a few to take over. If someone wants to pass this along or link my github I'd appreciate it. Isiah, I was looking through my original old post. I must have missed the emails a year ago: > First, no type checker (TypeScript, Flow, or any other) can fully check the > core language (most notably bind, apply, call, and Object.assign). > Second, they both still are missing some pretty significant features required > for typing common JavaScript idioms (higher kinded types for Fantasy Land and > Ramda users, variadic generics for bind, call, and apply, n-ary unions for > Object.assign and similar, etc.). I've had a section in my spec for typed rest parameters which I think covers a few cases. https://github.com/sirisian/ecmascript-types#rest-parameters Has anything changed with your view on these topics? Or examples and scenarios I should handle in the initial spec? _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
