201–207 of 207 posts
As a C++/C#/Java developer I just couldn't deal with Javascript. Since discovering TS its fast becoming my favorite language. I think I might even use in the back end going forward.
How do you feel about the performance tradeoffs of doing so?
Earlier quoted context omitted.
If that's what you meant ("c# is unpopular among the best paying tech companies") I can accept that. But what you originally wrote that I disagree with is: That unfortunately hasn’t helped C# become more popular outside of Microsoft legacy shops even when it did go cross platform and open source. Where I work is very much not a microsoft legacy shop (a game dev startup) & we use c#. This is hardly unusual.
And where you work is probably on the “enterprise” side of the bimodal enterprise dev/tech company compensation bimodal distribution. https://news.ycombinator.com/item?id=33140210 When talking about compensation, it might as well be an “enterprise shop” Just in case you don’t read the link above, that’s not meant to be derisive. It’s just a pure statement of fact. There are plenty of “startups” that locate in major c…
I think you would get a lot less pushback by simply using more precise terminology- even though for you it may all be the same, for people working outside of FAANG-esque companies it isn't.
Earlier quoted context omitted.
>you can’t have explicit type defs without explicit defining them somewhere Sure, as long as I have to define them once and exactly once . Not always possible, as in the case of simple, garden-variety keyword arguments. // foo is required, bar has default, baz is optional type POJO = { foo: number, bar: number, baz?: number } function myFn ({ foo, bar = 3, baz }: POJO = {}) { // oh wait... function myFn ({ foo, bar,…
> Not always possible, as in the case of simple, garden-variety keyword arguments. // foo is required, bar has default, baz is optional All of your examples are correctly identified by TS as type errors, because they all have a default argument which will never bind `foo`. True in JS as well as TS. Consider the untyped code, with some access to a required `foo`: function myFn ({ foo, bar = 3, baz } = {}) { return bar…
Where? The response I saw on GitHub issues (to the few people who considered it worthwhile to be vocal about the issue) was literally (well, paraphrased): "yeah we did this wrong but we're sticking to it anyway" (because of MS-internal org inertia I assume, something that the TS devs surely have to account for but it's hidden from us as an "open source" downstream)
Earlier quoted context omitted.
The strong evidence in support of static typing for productivity and security is well known and a trivial Google search away.
Which you conveniently not linking because you know it's going to be controversial at best. Get off the high horse, static vs dynamic has been a never ending debate since the dawn of time. Just because you side with one religion doesn't automatically make it "well known". Learn to recognize your own biases.
Here, enjoy the trivial search and read through links and their references:
https://www.google.com/search?q=Evidence+for+productivity+an...
TLDR: for productivity, there's basically no measurable impact detected in studies, positive or negative. For security and bugs, the impact is as expected: dynamic languages are as safe as strictly typed languages if they are paired with exhaustive test suites which enforce type safety. You can either write the type information alongside the application code, or write the test suite to enforce it.
Folks who think Dynamic Typing frees them of having to consider types are just fooling themselves; in this thread, even, the argument is that because they know what the types are then stating them is just unnecessary "noise". Which is all well and good, in the here and now, but provides no value when the code is foreign or forgotten; and with just a little additional syntax both the information is available to the programmer and the compiler can perform performance and security analysis with greater ease.
Earlier quoted context omitted.
> Not always possible, as in the case of simple, garden-variety keyword arguments. // foo is required, bar has default, baz is optional All of your examples are correctly identified by TS as type errors, because they all have a default argument which will never bind `foo`. True in JS as well as TS. Consider the untyped code, with some access to a required `foo`: function myFn ({ foo, bar = 3, baz } = {}) { return bar…
>Thankfully they’re actively working to address that now. Where? The response I saw on GitHub issues (to the few people who considered it worthwhile to be vocal about the issue) was literally (well, paraphrased): "yeah we did this wrong but we're sticking to it anyway" (because of MS-internal org inertia I assume, something that the TS devs surely have to account for but it's hidden from us as an "open source" downst…
Earlier quoted context omitted.
One of the first things that made a bad impression on me was back in the day when classes were still used in the js world. I was not pleased when it told me I have have to do this.blahBlah = value in the constructor because it didn't quite catch, and maybe still doesn't, that Object.defineProperties(this, { bla: { value: ... } blah: {get, set} }) is completely legit That said, I do prefer ts to vanilla. It's less wor…
But who want to use Object.defineProperties when there is a clearer and shorter way? Or am I misunderstanding something?
Earlier quoted context omitted.
Which you conveniently not linking because you know it's going to be controversial at best. Get off the high horse, static vs dynamic has been a never ending debate since the dawn of time. Just because you side with one religion doesn't automatically make it "well known". Learn to recognize your own biases.
Nah, I was on mobile and linking was cumbersome. Here, enjoy the trivial search and read through links and their references: https://www.google.com/search?q=Evidence+for+productivity+an... TLDR: for productivity, there's basically no measurable impact detected in studies, positive or negative. For security and bugs, the impact is as expected: dynamic languages are as safe as strictly typed languages if they are paire…
> for productivity, there's basically no measurable impact detected in studies, positive or negative
As I said, controversial at best.
But you're not being completely honest here. Most research is either inconclusive, or says dynamic is more productive. It is nearly impossible to find research that says static typing is more productive.
Which is quite obvious today, Uncle Bob and Steve Yegge were talking about this since 2000s.
https://sites.google.com/site/steveyegge2/is-weak-typing-str...
https://www.artima.com/weblogs/viewpost.jsp?thread=4639
> with just a little additional syntax
Unfortunately a little additional syntax easily turns into this:
f(): Array> | undefined> {...}
And gradual typing is the worst. It is either a terrible idea, or at least a terrible implementation (looking TS/mypy). It combines the worst of two worlds.
The only viable benefit of gradual typing is making dependency hierarchy explicit.