5 ms·
Ask HN: JS++ ? Why not make a new, strongly typed JavaScript ?
Javascript has a nice syntax but needs to be faster and more reliable.
With strong typing JS++ would eliminate many runtime bugs. Without all the crazy implicit conversions, boxing, 'eval', etc... fantastic speeds could be achieved.
Lots of electricity and developper hair could be saved.
JS++ would break backward compatibility but this could be softened by retaining the old syntax as largely as possible. With implicit and explicit typing.
It should be easy/automated to convert js to js++.
Inb4 ActionScript 3 : yes, something like that.
- dusted 6y agoIt's probably a terribly unpopular opinion, but I think the weak typing is the main attraction of JS. When I want stronger typing, I have C or (god forbid) C++. If you've ever written typescript, you can see how a strongly typed JS gives you the worst of both worlds.
- fingerlocks 6y agoI think you’re confusing strong/weak with static/dynamic. The former happens at runtime, the latter at compile time. Typescript adds static typing to JS, but it’s still weakly typed. This post is about strong typing in JS, which I’m still scratching my head about.
- alcover 6y ago> which I’m still scratching my head about. I'm no type theorist and - per wikipedia - 'strong' is not precisely defined. 'Static' may be closer to my idea : a JS where `typeof` and Number.isInteger are of no use.
- dusted 6y agoMaybe, whatever the case, what I think immensely practical in JS is being able to do things like const o = {}; o.prop = "something"; // oh, actually, o.prop = 5; and being able to do if( typeof o.prop === 'number' ) ...
- stephenr 6y agoI bet you really like spaghetti.
- dusted 6y agoI like clean, elegant, expressive code, just like everyone else. I don't particularly care for the attitude that because something can be used to write horribly unmaintainable messes, it must necessarily be bad and have few practical applications. No, if you get horrid unmaintainable messes it's because you're either inexperienced or a bad programmer, you may be able to hide that in layers and layers of corporate Java that adheres to every guideline, but the second anyone tries to touch it, you'll be found out anyway. I'm going to take a wild guess that you're also imbued with a similarly low opinion of PHP based on that (insightful if somewhat one-sided and flawed) article that guy wrote. In my opinion, the flexibility and elegance you can get out of exploiting, not abusing or misusing, the dynamic nature of JS, is the main appeal of the language, it's really damn fast to get stuff done, and even done in a nice and safe way, provided you have some idea what you're doing. There are terrible things that you can do in JS, and those are terrible even in the context of JS, but, what is a terrible thing to do in one language may be just fine(tm) in another, so trying to force some Java or C++ ideas onto any other language is just not a good way of going about things. Every language must be considered on its own. What is reasonable to do when writing machine code may not be reasonable in assembler, and what is reasonable in assembler may not be reasonable in C and up you go.
- yarinr 6y ago> const o = {}; o.prop = "something"; // oh, actually, o.prop = 5; Care to share some examples / use cases where using these language characteristics can result in better, more expressive, more readable code? (Not saying there aren't. I've been wondering about it myself and am genuinely curious) Thanks!
- stephenr 6y agoI mean... let’s keep in mind we’re talking about a language and community that uses the keyword “const” to define mutable objects. Logic went out the window a long fucking time ago.
- dragonwriter 6y ago> I think you’re confusing strong/weak with static/dynamic. The former happens at runtime, the latter at compile time. Strong typing usually describes the combination of compile and runtime typing; Haskell code doesn't have types after compilation, so there is no runtime enforcement of typing, but no one calls it weakly-typed, because the static typing prevents any of the conditions which would display weak typing behavior fromm happening.
- alcover 6y ago> When I want stronger typing, I have C Not in the browser.. Nor in the app/server.
- stephenr 6y agoIn what world does C code not run in “app/server”?
- alcover 6y agoI meant server web application. The one in Node/Go/Python where you will write your business logic then `http.listen()`. See what I mean ? JS matters most client-side anyway.
- vorticalbox 6y agoActually a lot of high performance modules are wrote in c for python and you can do the same for node.
- dusted 6y agoNode is absolutely excellent server side, and if you have something where you want it to be much faster, and slower to develop, go with C or C++, there are libraries out there for writing webservices, or go another route and write your critical parts as native node modules, against V8.
- alcover 6y agoWeb service in C ? dealing with http queries, strings, regexp, json... is a lot of (unsafe) work..
- stephenr 6y agoSo literally somewhere c code can and does run all the time.
- dragonwriter 6y ago> I meant server web application. You can absolutely write server web apps in C (there are even web app frameworks in C), though I wouldn't want to, or... > The one in Node/Go/Python where you will write your business logic then `http.listen()`. You definitely can link and call C code from Node, Go, and Python; they'd be much less useful otherwise; it's not at all hard in Python, and I assume the same is true of Node and Go.
- thiht 6y ago> If you've ever written typescript, you can see how a strongly typed JS gives you the worst of both worlds. Actually, no. I genuinely think Typescript is amazing and I would love if there was native support one day.
- fjfaase 6y agoI have understood that current JIT compilers for JavaScript are smart enough to recognize when a function is called with the same type of arguments and compile the function into an optimized form making use of this typing knowledge. So, adding types to JavaScript might no result in a great performance boost. If will definitely make JavaScript more verbose which might have a negative effect on performance.
- alcover 6y ago> making use of this typing knowledge That makes JIT a complicated business, for you still have to accept any value. So two versions of the func would have to coexist ? One strong and one weak ? I'm no JS/JIT expert..
- fjfaase 6y agoHave a look at https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/ https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-...
- alcover 6y agoThanks, I read it. It is like I thought : holding different optimisation versions of the same code... that is overly complicated in my (naive) view.
- silicaroach 6y agoHonestly, ask yourself _why_ you think you need strongly typed JS. Are type errors the most common source of errors in JS? Not even close. So why add another level of complexity for negligible gain.
- alcover 6y ago> ask yourself _why_ you think you need strongly typed JS Because I -and everyone- need a faster, less energy-wasting JS. > Are type errors the most common source of errors in JS? They happen. And could be caught at compile-time under a stronger type system. JS is used client-side in many banking/crypto webapps. I know everything is validated on the server but still presentation is done by JS with its nutty casts/coercions...
- muzani 6y agoParent comment has a point - the appeal of JS is that it's a weakly typed, hacky language. I love duck typing. I don't use Typescript, nor would I use a JS++. There are a good number of programming languages. Why not something like Go? I heard Go compiles to JS, but never tried it. Why is JS even used for banking, and why would converting to a JS++ be easier than adopting something else?
- alcover 6y ago> duck typing hacky language It may be possible to keep duck typing for objects while introducing fast unambiguous primitives like int64_t ? > Why not something like Go? Because JS syntax is very nice - that's my premise. Moreover, client side has to be JS, no other choice yet.
- stephenr 6y agoI’m still surprised that for all the “enhancements” it’s had in the last decade or so JavaScript still doesn’t allow basic things like optional type declarations (ie type hints in php). Want to accept muck? Leave it as is. Want to accept something specific? Specify the class to accept, or even specify the shape if you want to go the duck typing route.
- dragonwriter 6y agoThere are plenty of strongly typed (and often both strong and static typed) languages that compile to JS or WebAssembly for web use (or portability anywhere JS/WASM run). If you are going to break from JS semantics by using strong typing rather than JS’s mostly-very-weak typing, I don't see what the point is of making code deceptively look like JS.
- techsin101 6y agolast time i had a bug due to type error was probably years ago. all bugs i get are due to logical errors or misunderstanding stuff.
- wdiamond 6y agoyou can typify untyped code, but you can't untypify typed code. because typify is to make constraints and untypify is real life, I mean, a window is a house device and a computer device, the meaning window relies on other information of context besides type. that other information is unkown so if you close de door to unkown you will never know if that exception could be handled by machine at first runtime. it's more related to the tradeoff between scale and flexibility. i'm not concerned with scale, it's tedious and prone to automation. the question is do you believe in money or in future code? I mean a code that is so untyped that behaves like human.
- probinso 6y agoIt exists and it's called Elm. it's not work backwards compatible, but it's a really solid language