241–250 of 359 posts
I wish Dart was more popular as a JS alternative. I've been using it recently it's really surprisingly productive and fun.
Does Dart still allow you to compile to JS or was that feature dropped?
Earlier quoted context omitted.
JS has zero unique set of feature. There is not a single feature in JS you can't find elsewhere, often better implemented. If anything, the vast majority of scripting languages (Python, Ruby, PHP...) have more features than JS. JS is so lacking in features that half of its ecosystem is dedicated to compensate for that (typescript, babel, webpack, undersacore...).
JS has a great future: first class ubiquitous promise + async-everything. Can't find that in Ruby/Python/PHP, you have to use something like Twisted/asyncio which limits you to a bolted on subset of the ecosystem, unlike in JS. Very dishonest take btw. Here's a forum of people who could tell you why they use JS instead of your $favelang, yet instead of trying to figure it out, you just assume everyone is lazy or a ju…
So for the rare cases where async does matter (and they are a niche, given even big names like facebook code behind async proxy and do long polling), there are still little reason to choose JS.
I can't think of a single mission where, if I were not being forced to use it, I would chose it over something else. And I say that while coding a LOT of JS all year long. Even training people regularly in the language.
I double down on my initial statement, if tomorrow JS is removed from the browser, it would die in a few years.
It's a badly designed language that has been accumulated fixes over the years to make it acceptable while never removing what's bad. It was so initially bad that half the ecosystem of JS exists to not code in JS (typescript, coffeescript, babel, jsx, webpack...).
And it has received that much of attention because we had no choice. Google spent millions to make a technical marvel of a JIT to run it at decent speed.
Any tech that would have had half the resources poured into it would today be the incarnation of skynet.
It's a language surviving on artificial life support than can do so because it has the best blackmail game of all time.
Earlier quoted context omitted.
You don't have to write as many tests when you use static typing, because your method contracts are solid. You can refactor your entire codebase with a few operations and don't have to worry about anything breaking. Is your timestamp in seconds? Millis? Is it a duration? Does it have a time zone? Have you ever written a method that returns more than one type of thing? Or had polymorphic inputs? Where are your dynamic…
Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have th…
Meanwhile: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
'Percentage of memory safety issues has been hovering at 70 percent for the past 12 years.'
And this is not just Microsoft–it's a pretty consistent finding across industry, that when programming in C/C++, memory safety issues make up around 65% to 70% of all issues.
What this tells us is that people in general can't guarantee the safety of their code, but an automated checker can.
This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It…
Accidentally mixing incompatible types is mostly a problem for junior developers. I'm much more likely to accidentally put on my pants, socks and shoes in the reverse order in my daily life than mix up incompatible types in my code.
The solution is not to add stickers all over your clothes to remind you which way is the front or what order you need to put them on; you don't need more tools, you just need more focus.
Earlier quoted context omitted.
I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.
I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head). I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (a…
Using JS instead of TypeScript is very short-sighted and they will regret it, eventually. Sounds like they got frustrated and gave up. Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc. All you're doing by switching from TS to JS, is trading one set of minor problems (which…
Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.
https://github.com/Clay-Ferguson/quantizr
I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.
Earlier quoted context omitted.
Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.
That is one key thing I see a disconnect with. I definitely can see the value in having static types in a long-lived/large js project, but at the same time 1) how long does the average js project really stay relevant, 2) people have got by just fine w/o it so far. I’m kind of mixed on it, but for my new web app I’m working on I decided to use vanilla js because it feels much more efficient.
Earlier quoted context omitted.
Yeah, I tend to agree. After 18 months with TypeScript, I can't really imagine going away from it. After every single refactoring I do, I'm extremely grateful for proper typing. Not to mention sugar like null coalescing, etc.
null coalescing is good, but I personally found that Typescript doesn't offer many advantages on a large team. I know it's not cool these days! But it just slows me down and if you're reasoning about functions I never run into that many production level issues with types, but maybe that's just my brain I dunno!
Things like when this system was built all the code assumed social security could not be null. We now need to make the system able to handle a null social security system. What code do I change?
Do I need to null check the results of this value?
What does this function return and how can I be sure I'm handling all use cases?
I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn't work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type dec…
typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-j... I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works! Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.
This is not a language flaw. It is a tooling problem.