3 ms·
I feel exactly the opposite. I'm continually amazed that Java devs have still not acclimated themselves to Javascript after all this time. If you notice that th
by Dr_tldr 10y ago
I feel exactly the opposite. I'm continually amazed that Java devs have still not acclimated themselves to Javascript after all this time. If you notice that the style you're used to coding in is causing a lot of problems and that people coding in other styles have few-to-none of these problems, maybe it's worth questioning your approach.
I maintain a medium-sized (50k lines) codebase with frequent requirement changes that uses a functional style, and the closest we've come to ever needing a type-check is null checks. Type errors are maybe 2% of total errors when developing, and because our code doesn't have too many layers of indirection, they've all been trivial to fix way before production. I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours writing type files and code in a dialect of Javascript that doesn't provide 100% coverage.
If you embrace functional programming with mostly immutable data structures and avoid mutation, side-effects, and gross mixins/polymorphism, you reduce the size of your codebase significantly, which makes it much easier to keep documentation terse and up-to-date.
On the other hand, if your team is so undisciplined and untrustworthy that you need to throw errors on compilation because you don't trust them to update comments and docs or name variables descriptively and your entire team knows Java but not Javascript, I could see the huge amount of boilerplate involved in Typescript being well worth it.
As someone who's primarily a Javascript developer who does Clojure on the side, I feel that the Java approach is fundamentally impoverished. I've never met anyone who chose to develop in Typescript whose background wasn't enterprise Java, just like I've never met anyone using Ramda (before lodash replicated it) whose background wasn't in FP.
- adamnemecek 10y ago> I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours... I'll take "unrealistic estimates" for $500, Alex.
- Dr_tldr 10y agohttp://games.greggman.com/game/dynamic-typing-static-typing/ http://games.greggman.com/game/dynamic-typing-static-typing/ So we've got data plus my experience plus my team's experience in a large, very successful enterprise on one side, and we've got snark and defense of existing habits on the other? I'll take the risk, I think.
- adamnemecek 10y agoYou've got "data" and "experience". I also like the part of your post where you are implying that using dynamically typed languages is some sort of act of defiance. What typed languages have you used? Btw do you care about John Carmack's opinion on the subject?
- Dr_tldr 10y agoYou didn't present an argument, you just put my words in quotes and then made an appeal to an irrelevant authority. John Carmack doesn't do web apps, he does high-end 3D engines You couldn't pick a more different field and still be in the business of writing code for computers.
- adamnemecek 10y ago> You didn't present an argument, Neither did you. That link you posted is laughable. Like there isn't a single agreeable thing about the research it presents and the methodology by which they arrive at the conclusions it makes. > to an irrelevant authority Is that kind of like appealing to "experience" and "team experience"? > John Carmack doesn't do web apps, he does high-end 3D engines Is this an admission of the possibility that types work in one subfield of programming? If so, how is that subfield different from another subfield.
- Dr_tldr 10y agoHave you noticed that you never speak in concrete terms, only pejorative adjectives? Saying you find something "laughable" and not "agreeable" is a feeling, not a refutation.
- adamnemecek 10y ago> Have you noticed that you never speak in concrete terms, only pejorative adjectives? Saying you find something "laughable" and not "agreeable" is a feeling, not a refutation. Well, neither do you. I mean, if I have to spell it out for you (but the summary is that they take languages that aren't good examples of typed languages and make conclusions based on those). But more detailed breakdown: First slide. They make their own languages (first issue) snd have people solve small problems (second issue). Advantages of static typing really kick in for larger projects. Also, different type systems have different advantages so this comparison holds little informational value Second point, they are talking about code that has already been written, it doesn't say how much time was spent making the code correct. I really don't know what to conclude from their data though. > His point there is that all that static boilerplate you write to make a statically typed language happy, He's ignoring statically typed languages with type inference. They have been around since the 70's. > Some other study compared reliability across languages and found no significant differences. In other words neither static nor dynamic languages did better at reliability. How do you measure readability (notice that good research would indicate this). > Part of that was reflected in size of code. Dynamic languages need less code. They are comparing python vs C/C++/Java. Code terseness is orthogonal to type systems. Why do they not include say, Haskell? > Another point he made is that writing static types is often gross and unmaintainable whereas writing unit tests not. Hahahaha, what? Unit tests are more maintainable than types? And he gives a C++ example?