10 ms·

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful bene

by mdoms 6y ago

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.

fallingknife 6y ago
I worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."
- bqmjjx0kac 6y ago
  Yikes. The only way I could imagine this being okay is if N is bounded and small, or if the DB is SQLite.
- mdoms 6y ago
  The term "premature optimization" has been weaponized in the industry at large. Especially in front end development. And it really, really shows.
  - hajile 6y ago
    I'd say that's only partly true. Even at large companies, there's often pressure to deliver quickly and often. Throwing out large parts of the UI and starting over to please the marketing department is SOP at a lot of places too. If it were a normal desktop application, they would throw a 30-man team at the problem, but because "it's just a web page/site", it'll be a team of 3-5 people and the time tables will be pushed up. When you combine these problems, it's no wonder that a lot of JS devs view almost anything that isn't a new deliverable as overly-optimized.
  - akiselev 6y ago
    It's especially ironic considering the source of the phrase: > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -Knuth It's like that cliche "it's only a few bad apples" from the proverb "a few bad apples spoils the bunch."
jpgvm 6y ago
JS the language isn't great but it's JS the culture that is the real problem. There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore. If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's become so pervasive that isn't really a tenable position anymore.
- rovek 6y ago
  > JS the language isn't great but it's JS the culture that is the real problem. This is the money quote of the thread for me. From the perspective of someone whose main language has been JS or TS for about 8 years, it's getting worse since some of the biggest names in the discipline just seem to be people with large social followings giving terrible advice. This advice is then eaten up by hoardes of bootcamp alumni who have been given a loose understanding of React and unleashed on the world as "junior developers". But maybe I'm just cynical.
  - akiselev 6y ago
    The fact that it's getting worse says to me that we're just returning to the human mean. For decades programming was seen as the purview of nerds and geeks so the only people who turned to it tended to genuinely like it and master their craft as much as exploit it. Now everyone and their grandma use software so programming has become one of those semi-prestigious professional career paths but without the crazy expensive barrier to entry or restrictions in supply that doctors, lawyers, etc have. Even though programming is largely problem solving and "intellectual" rather than menial physical labor, the field has become so accessible with the internet that the distribution of engineering ability is starting to look a lot more like the usual bell curve centered on "just average". It was great while it lasted.
  - imbnwa 6y ago
    Its not just bootcamp alumni, frontend is filled with people with 15 years of experience who were sitting in some shop before the frontend boom basically being a jQuery engineer and never actually learning about software design, never mind basic computer science concepts. Then the boom came and now these types are managers and senior engineers who only know how to talk about "which framework?" as far as design goes and who are eager to call any other discussion as over-engineering.
axguscbklp 6y ago
Much of web development doesn't need extreme levels of attention to safety. A good fraction of web development is such that errors are quickly caught in manual testing and at worst just make some button look weird for the short span of time before the problem is noticed and fixed. Also, time spent using generic safety tools is time that could instead be spent reworking and better understanding the specific code to make it safer. There is a lot of cultism in the industry about testing and type safety. I have seen people demand almost 100% test coverage for code that displayed some extremely simple UX which, if it broke, would be completely obviously broken the first time you tried actually interacting with it. I have seen TypeScript used for short code that basically just displays simple UX and is made up largely of calls to third party libraries anyway. I think there is no generic appropriate level of attention to safety. It depends on the context. If you're working on code that controls a spacecraft or a medical device, it makes sense to spend an enormous amount of thought and work on safety. For much of web development, that just doesn't make sense, but organizations seem to often fall into a trap of mandating bondage-and-discipline features for stuff that doesn't need it - why, I don't know. Maybe because there's an impression that "everyone else is doing it". I guess also, some people just enjoy it. But I don't enjoy it. I like writing JavaScript. I think I can often do it elegantly and that the perceived elegance at least somewhat corresponds to objective quality. TypeScript makes my code uglier, to my taste at least, and makes development less fun for me. This impacts not just my feelings, but also my productivity. TypeScript had better provide me with something great to make up for this. I rarely make the kind of errors that TypeScript is capable of catching or feel like I need the help with readability and code discovery that it provides. But other people, I recognize, do benefit from it sometimes and in any case, other people pay me to use TypeScript.
spideymans 6y ago
I did one of my internships at a financial services company. Their web applications were responsible for performing transformations on massive JSON datasets, with a huge variety of financial data. This is precisely the kind of project that would benefit most from typing. I was relieved to find out that they were smart enough to use TS, yet horrified when I looked at the code base and found that the entire codebase was littered with the "any" keyword, making typing damn near useless. We had so many bugs reports that essentially boiled down to "this data is being transformed in a way it shouldn't be". Almost invariably these bugs were due to the developer thinking that some variable represented one thing, when it really represented something else, and they thus performed an incorrect transformation on it. Typing would've eliminated this entire class of bugs. Figuring out what any variable represented often involved traversing the huge codebase to find out where the variable originated. On some occasions, I even had to talk to the back-end developers to figure out what the heck was going on. Typing is self-documenting, and would've completely eliminated the need to go on a scavenger hunt to figure out what a variable meant. Anyways I got sick of this rather quickly, and made sure to add types to any new code that I wrote. I was the only developer on the 20 person team that bothered to do so. As an intern, I didn't understand why these developers refused to use types. I just assumed that with their years of experience, they must've had a good reason. Now looking back at it, it's clear that they didn't understand types, didn't want to learn how to use types, and thus just chose to completely ignore typing. As you said, this is utterly horrifying (especially for a financial services company dealing with real money).
- lfxyz 6y ago
  I've had a similar experience. My team is using Vue 2 and, while the VueX store is almost entirely correctly typed, inside the Vue components everything was typed as 'any'. There was no value being added in the slightest, but attempting to upgrade packages resulted in many new TypeScript and ESLint errors. I ended up opening a PR to strip out TypeScript from all the Vue components so I could get things up to date (and ease a possible transition to Vue 3, which behaves much better with TypeScript). I'm starting a new job soon and really hope I can work with React and TypeScript again.
- polishdude20 6y ago
munificent 6y ago
This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared me ..." The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. > specifying your types is about as low-hanging, basic a step as you can take. No, absolutely not. Learning an entirely new syntax, static semantics, and entire way of reasoning about code is about as high-hanging as you can get. Sure, once you know how to use static types, applying that knowledge is fairly easy. But it's a big mountain to climb before you get to do that. This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work. Now, personally, I think it is worth learning that. And, certainly, once you learn it, you get to amortize that benefit through the rest of your career. But there's a lot of people standing at the base of the mountain, realizing only how far they have to climb with no idea of the view they'll have once they're up there. Those people deserve sympathy, understanding, and encouragement to climb. Not criticism and mockery like I see all over this thread.
- mdoms 6y ago
  > They're saying that they found learning about types to be difficult and stressful No, they're saying that types (which they don't understand) are "over-engineering". This is, frankly, not acceptable to me.
  - jolux 6y ago
    They're describing how they felt before learning about types.
    - mdoms 6y ago
      Yes. Like I said. > I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.
svachalek 6y ago
That's true to a point but it depends on perspective. On a big team with a mix of experience levels, you are going to want to put up as many barriers to mistakes as possible and it doesn't matter how much it slows anyone down because it can't be more than dealing with the problems will be. But less people, smaller projects, higher experience levels, and better testing are all factors that shift the balance between effort and expected return. Before TypeScript came around I wrote multiple 5-10k loc apps alone in JS and the number of bugs that TypeScript would have caught in those was pretty minimal. Working on a team of 5 on apps twice that big, I see errors that TS could catch in almost every single file.
aeturnum 6y ago
I think one of the sources of this kind of attitude is experience with type systems that are clumsy or slow to use. This goes equally for languages without type declarations and those with. Personally, the two things I informally look for are: * Does the language allow instant-to-a-human static analysis so I can see warnings when I'm passing the wrong type to a call? * Will this language allow me to leave sections (almost always something I get off the wire) with minimal / no type information in order to come back to it later? Typing is hugely powerful for avoiding problems. I've done a lot of work in Python, which I think has missed huge opportunities to introduce a more robust type-checking system. My current favorite is Elixir / Erlang, which I think uses pattern matching and static analysis to balance strong typing v.s. weak typing wins. It's interesting to compare Elixir to Elm. Elm has a much stronger type system, which means I almost never pass the wrong thing, but it also makes dealing with unstructured data much more frustrating.
mekoka 6y ago
> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? > If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases. "Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.
- luuio 6y ago
  > there have been many languages whose success was specifically tied to the fact that they were dynamically typed Language success does not mean product success. A language is just one of the many things in your toolbox. There's a reason why when many products grew larger, they all are migrating to statically/strictly typed languages.
- lmm 6y ago
  > How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? The pain point was always tedium, not difficulty. At least that's how it was sold. We haven't seen a new major dynamic language since type inference went mainstream (and existing dynamic languages are putting a lot of effort into enabling static typing), and I don't think that's coincidence.
- eyelidlessness 6y ago
  > How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? How do you come to the pain point conclusion about static types, rather than prior art static type systems, when the vast majority of tooling around the most popular dynamically typed language explicitly dedicates resources and visibility to its most popular static type system?
throwaway894345 6y ago
I've worked with a lot of people in the Python world who just wanted to move tickets across the kanban board as fast as possible, and they'd do a quick check of the happy path and call it a ticket. They'd be praised for their output and we (rightly, I think) didn't try to trace bugs back to a developer. They would do all sorts of dynamic-typing hacks to get the immediate task at hand done with little regard for the mess that was made, and they strongly disliked static types because they made those error prone, unmaintainable hacks really difficult to express. Let me pull that out into a block quote: > [types] made those error prone, unmaintainable hacks really difficult to express This is, in my mind, the most valuable feature of static types, and one that at least some dynamic typing enthusiasts can't easily get their heads around. Types are like rails that guide you to code which is maintainable. Another very valuable feature is that they serve as documentation that would otherwise never be written or quickly fall out of date in a dynamically typed language. Lastly in importance is that the compiler/type-checker precludes certain errors.
ChrisRR 6y ago
As a c developer, I've always found the lack of typing to be one of the things I dislike about python. If you're calling a function in C, a lot of the time just knowing the type and argument name is enough to call functions without resorting to documentation In python, you have the argument name and then... what do you want? A number? Are floats or integers alright? Is it a string? And object? An enum? Are there any bounds on the input data that a data type would've instantly told me? Fine, I'll go read the documentation Adding types gives you so much more information in so few characters
- lmm 6y ago
  What C has barely counts as typing, frankly. No generics, no polymorphism at all, no sum types, even basic wrapper types are painful...
pbreit 6y ago
Types make little sense to me. I guess I'm not welcome in your world.
- eyelidlessness 6y ago
  Types do make sense to me, but they didn't always. You're certainly welcome in my world. You're also welcome to reach out if you want to gab and learn a little about how learning static types has improved my engineering life and skills. Easy to find contact from my profile.
- nicbou 6y ago
  Types loudly state what you accept, and what you return, and possibly enforces it. The real world equivalent is giving plugs specific shapes, so that you don't plug your headphones into a 240V wall socket. In a large enough team, this is essential to prevent incorrect data from being passed around, and breaking further down the line after causing a lot of damage.
andrew_ 6y ago
"horrifying" is horribly melodramatic. perhaps sigh-worthy, but let's stop short of sensationalism.
eyelidlessness 6y ago
Oh come on, this is a discussion probably older than both of us put together. And we probably both know that the discussion devolves into where/what kind of tests are written. I'm on your side in the static type system debate, but you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing.
- eropple 6y ago
  > you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing. I certainly realize it, and I've seen it once in ten years and it'd have been dealt with automatically by a compiler because they were writing tests for autogenerated code. (Why not test the generator, you may ask - and that's a story for another day.)
nromiun 6y ago
If a majority of software developers had your attitude towards static types all dynamic typed languages (maybe except for JS) would have died out by now. > If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases. Does that mean no thought and design went into all the huge protects like Instagram, Netflix and Whatsapp (that use dynamically typed languages)? Design and engineering is much more then just adding types. Clean design patterns, good code, tests and docs are pretty important too. In fact they are much more important then just static types.
jimmont 6y ago
Interesting characterizing engineering as honestly, horrifying, low-hanging and regarding one approach to typing as translatable to all practices and the underlying assumption it conveys a guarantee of reliability. I don't find any of those things to be true (in isolation or together). Of course I only know so much so there's that.
nicbou 6y ago
Typing offers guarantees. You can guarantee that your function will receive the right inputs, and produce the right outputs. Even soft typing enforced by an IDE is beneficial in that sense. I have refactored a large, central chunk of JavaScript code back at HERE. I found and fixed several bugs related to typing as I went along. A lot of code passed server responses or a subset of them as-is, so I had to read API documentation to understand the inputs of some deep parts of the frontend code. This is why I favour explicitly encapsulating server responses in a data class. In addition to typing, I favour microtypes and enums. Those go further to prevent unexpected application states. Assert statements are a last barrier against unmet expectations that could break things. If you want to build reliable software, you must be strict about the inputs you accept. Don't let sloppy inputs propagate.
coldtea 6y ago
There's nothing especially "horrifying" about this. In fact, several geniuses in Computer Science have historically been of the same opinion (pro dynamic typing).

by mdoms 6y ago

fallingknife 6y ago

I worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."

bqmjjx0kac 6y ago
Yikes. The only way I could imagine this being okay is if N is bounded and small, or if the DB is SQLite.
mdoms 6y ago
The term "premature optimization" has been weaponized in the industry at large. Especially in front end development. And it really, really shows.
- hajile 6y ago
  I'd say that's only partly true. Even at large companies, there's often pressure to deliver quickly and often. Throwing out large parts of the UI and starting over to please the marketing department is SOP at a lot of places too. If it were a normal desktop application, they would throw a 30-man team at the problem, but because "it's just a web page/site", it'll be a team of 3-5 people and the time tables will be pushed up. When you combine these problems, it's no wonder that a lot of JS devs view almost anything that isn't a new deliverable as overly-optimized.
- akiselev 6y ago
  It's especially ironic considering the source of the phrase: > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -Knuth It's like that cliche "it's only a few bad apples" from the proverb "a few bad apples spoils the bunch."

jpgvm 6y ago

JS the language isn't great but it's JS the culture that is the real problem. There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore. If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's become so pervasive that isn't really a tenable position anymore.

rovek 6y ago
> JS the language isn't great but it's JS the culture that is the real problem. This is the money quote of the thread for me. From the perspective of someone whose main language has been JS or TS for about 8 years, it's getting worse since some of the biggest names in the discipline just seem to be people with large social followings giving terrible advice. This advice is then eaten up by hoardes of bootcamp alumni who have been given a loose understanding of React and unleashed on the world as "junior developers". But maybe I'm just cynical.
- akiselev 6y ago
  The fact that it's getting worse says to me that we're just returning to the human mean. For decades programming was seen as the purview of nerds and geeks so the only people who turned to it tended to genuinely like it and master their craft as much as exploit it. Now everyone and their grandma use software so programming has become one of those semi-prestigious professional career paths but without the crazy expensive barrier to entry or restrictions in supply that doctors, lawyers, etc have. Even though programming is largely problem solving and "intellectual" rather than menial physical labor, the field has become so accessible with the internet that the distribution of engineering ability is starting to look a lot more like the usual bell curve centered on "just average". It was great while it lasted.
- imbnwa 6y ago
  Its not just bootcamp alumni, frontend is filled with people with 15 years of experience who were sitting in some shop before the frontend boom basically being a jQuery engineer and never actually learning about software design, never mind basic computer science concepts. Then the boom came and now these types are managers and senior engineers who only know how to talk about "which framework?" as far as design goes and who are eager to call any other discussion as over-engineering.

axguscbklp 6y ago

Much of web development doesn't need extreme levels of attention to safety. A good fraction of web development is such that errors are quickly caught in manual testing and at worst just make some button look weird for the short span of time before the problem is noticed and fixed. Also, time spent using generic safety tools is time that could instead be spent reworking and better understanding the specific code to make it safer. There is a lot of cultism in the industry about testing and type safety. I have seen people demand almost 100% test coverage for code that displayed some extremely simple UX which, if it broke, would be completely obviously broken the first time you tried actually interacting with it. I have seen TypeScript used for short code that basically just displays simple UX and is made up largely of calls to third party libraries anyway. I think there is no generic appropriate level of attention to safety. It depends on the context. If you're working on code that controls a spacecraft or a medical device, it makes sense to spend an enormous amount of thought and work on safety. For much of web development, that just doesn't make sense, but organizations seem to often fall into a trap of mandating bondage-and-discipline features for stuff that doesn't need it - why, I don't know. Maybe because there's an impression that "everyone else is doing it". I guess also, some people just enjoy it. But I don't enjoy it. I like writing JavaScript. I think I can often do it elegantly and that the perceived elegance at least somewhat corresponds to objective quality. TypeScript makes my code uglier, to my taste at least, and makes development less fun for me. This impacts not just my feelings, but also my productivity. TypeScript had better provide me with something great to make up for this. I rarely make the kind of errors that TypeScript is capable of catching or feel like I need the help with readability and code discovery that it provides. But other people, I recognize, do benefit from it sometimes and in any case, other people pay me to use TypeScript.

spideymans 6y ago

I did one of my internships at a financial services company. Their web applications were responsible for performing transformations on massive JSON datasets, with a huge variety of financial data. This is precisely the kind of project that would benefit most from typing. I was relieved to find out that they were smart enough to use TS, yet horrified when I looked at the code base and found that the entire codebase was littered with the "any" keyword, making typing damn near useless. We had so many bugs reports that essentially boiled down to "this data is being transformed in a way it shouldn't be". Almost invariably these bugs were due to the developer thinking that some variable represented one thing, when it really represented something else, and they thus performed an incorrect transformation on it. Typing would've eliminated this entire class of bugs. Figuring out what any variable represented often involved traversing the huge codebase to find out where the variable originated. On some occasions, I even had to talk to the back-end developers to figure out what the heck was going on. Typing is self-documenting, and would've completely eliminated the need to go on a scavenger hunt to figure out what a variable meant. Anyways I got sick of this rather quickly, and made sure to add types to any new code that I wrote. I was the only developer on the 20 person team that bothered to do so. As an intern, I didn't understand why these developers refused to use types. I just assumed that with their years of experience, they must've had a good reason. Now looking back at it, it's clear that they didn't understand types, didn't want to learn how to use types, and thus just chose to completely ignore typing. As you said, this is utterly horrifying (especially for a financial services company dealing with real money).

lfxyz 6y ago
I've had a similar experience. My team is using Vue 2 and, while the VueX store is almost entirely correctly typed, inside the Vue components everything was typed as 'any'. There was no value being added in the slightest, but attempting to upgrade packages resulted in many new TypeScript and ESLint errors. I ended up opening a PR to strip out TypeScript from all the Vue components so I could get things up to date (and ease a possible transition to Vue 3, which behaves much better with TypeScript). I'm starting a new job soon and really hope I can work with React and TypeScript again.
polishdude20 6y ago

munificent 6y ago

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared me ..." The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. > specifying your types is about as low-hanging, basic a step as you can take. No, absolutely not. Learning an entirely new syntax, static semantics, and entire way of reasoning about code is about as high-hanging as you can get. Sure, once you know how to use static types, applying that knowledge is fairly easy. But it's a big mountain to climb before you get to do that. This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work. Now, personally, I think it is worth learning that. And, certainly, once you learn it, you get to amortize that benefit through the rest of your career. But there's a lot of people standing at the base of the mountain, realizing only how far they have to climb with no idea of the view they'll have once they're up there. Those people deserve sympathy, understanding, and encouragement to climb. Not criticism and mockery like I see all over this thread.

mdoms 6y ago
> They're saying that they found learning about types to be difficult and stressful No, they're saying that types (which they don't understand) are "over-engineering". This is, frankly, not acceptable to me.
- jolux 6y ago
  They're describing how they felt before learning about types.
  - mdoms 6y ago
    Yes. Like I said. > I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.

svachalek 6y ago

That's true to a point but it depends on perspective. On a big team with a mix of experience levels, you are going to want to put up as many barriers to mistakes as possible and it doesn't matter how much it slows anyone down because it can't be more than dealing with the problems will be. But less people, smaller projects, higher experience levels, and better testing are all factors that shift the balance between effort and expected return. Before TypeScript came around I wrote multiple 5-10k loc apps alone in JS and the number of bugs that TypeScript would have caught in those was pretty minimal. Working on a team of 5 on apps twice that big, I see errors that TS could catch in almost every single file.

aeturnum 6y ago

I think one of the sources of this kind of attitude is experience with type systems that are clumsy or slow to use. This goes equally for languages without type declarations and those with. Personally, the two things I informally look for are: * Does the language allow instant-to-a-human static analysis so I can see warnings when I'm passing the wrong type to a call? * Will this language allow me to leave sections (almost always something I get off the wire) with minimal / no type information in order to come back to it later? Typing is hugely powerful for avoiding problems. I've done a lot of work in Python, which I think has missed huge opportunities to introduce a more robust type-checking system. My current favorite is Elixir / Erlang, which I think uses pattern matching and static analysis to balance strong typing v.s. weak typing wins. It's interesting to compare Elixir to Elm. Elm has a much stronger type system, which means I almost never pass the wrong thing, but it also makes dealing with unstructured data much more frustrating.

mekoka 6y ago

> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? > If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases. "Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.

luuio 6y ago
> there have been many languages whose success was specifically tied to the fact that they were dynamically typed Language success does not mean product success. A language is just one of the many things in your toolbox. There's a reason why when many products grew larger, they all are migrating to statically/strictly typed languages.
lmm 6y ago
> How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? The pain point was always tedium, not difficulty. At least that's how it was sold. We haven't seen a new major dynamic language since type inference went mainstream (and existing dynamic languages are putting a lot of effort into enabling static typing), and I don't think that's coincidence.
eyelidlessness 6y ago
> How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? How do you come to the pain point conclusion about static types, rather than prior art static type systems, when the vast majority of tooling around the most popular dynamically typed language explicitly dedicates resources and visibility to its most popular static type system?

throwaway894345 6y ago

I've worked with a lot of people in the Python world who just wanted to move tickets across the kanban board as fast as possible, and they'd do a quick check of the happy path and call it a ticket. They'd be praised for their output and we (rightly, I think) didn't try to trace bugs back to a developer. They would do all sorts of dynamic-typing hacks to get the immediate task at hand done with little regard for the mess that was made, and they strongly disliked static types because they made those error prone, unmaintainable hacks really difficult to express. Let me pull that out into a block quote: > [types] made those error prone, unmaintainable hacks really difficult to express This is, in my mind, the most valuable feature of static types, and one that at least some dynamic typing enthusiasts can't easily get their heads around. Types are like rails that guide you to code which is maintainable. Another very valuable feature is that they serve as documentation that would otherwise never be written or quickly fall out of date in a dynamically typed language. Lastly in importance is that the compiler/type-checker precludes certain errors.

ChrisRR 6y ago

As a c developer, I've always found the lack of typing to be one of the things I dislike about python. If you're calling a function in C, a lot of the time just knowing the type and argument name is enough to call functions without resorting to documentation In python, you have the argument name and then... what do you want? A number? Are floats or integers alright? Is it a string? And object? An enum? Are there any bounds on the input data that a data type would've instantly told me? Fine, I'll go read the documentation Adding types gives you so much more information in so few characters

lmm 6y ago
What C has barely counts as typing, frankly. No generics, no polymorphism at all, no sum types, even basic wrapper types are painful...

pbreit 6y ago

Types make little sense to me. I guess I'm not welcome in your world.

eyelidlessness 6y ago
Types do make sense to me, but they didn't always. You're certainly welcome in my world. You're also welcome to reach out if you want to gab and learn a little about how learning static types has improved my engineering life and skills. Easy to find contact from my profile.
nicbou 6y ago
Types loudly state what you accept, and what you return, and possibly enforces it. The real world equivalent is giving plugs specific shapes, so that you don't plug your headphones into a 240V wall socket. In a large enough team, this is essential to prevent incorrect data from being passed around, and breaking further down the line after causing a lot of damage.

andrew_ 6y ago

"horrifying" is horribly melodramatic. perhaps sigh-worthy, but let's stop short of sensationalism.

eyelidlessness 6y ago

Oh come on, this is a discussion probably older than both of us put together. And we probably both know that the discussion devolves into where/what kind of tests are written. I'm on your side in the static type system debate, but you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing.

eropple 6y ago
> you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing. I certainly realize it, and I've seen it once in ten years and it'd have been dealt with automatically by a compiler because they were writing tests for autogenerated code. (Why not test the generator, you may ask - and that's a story for another day.)

nromiun 6y ago

If a majority of software developers had your attitude towards static types all dynamic typed languages (maybe except for JS) would have died out by now. > If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases. Does that mean no thought and design went into all the huge protects like Instagram, Netflix and Whatsapp (that use dynamically typed languages)? Design and engineering is much more then just adding types. Clean design patterns, good code, tests and docs are pretty important too. In fact they are much more important then just static types.

jimmont 6y ago

Interesting characterizing engineering as honestly, horrifying, low-hanging and regarding one approach to typing as translatable to all practices and the underlying assumption it conveys a guarantee of reliability. I don't find any of those things to be true (in isolation or together). Of course I only know so much so there's that.

nicbou 6y ago

Typing offers guarantees. You can guarantee that your function will receive the right inputs, and produce the right outputs. Even soft typing enforced by an IDE is beneficial in that sense. I have refactored a large, central chunk of JavaScript code back at HERE. I found and fixed several bugs related to typing as I went along. A lot of code passed server responses or a subset of them as-is, so I had to read API documentation to understand the inputs of some deep parts of the frontend code. This is why I favour explicitly encapsulating server responses in a data class. In addition to typing, I favour microtypes and enums. Those go further to prevent unexpected application states. Assert statements are a last barrier against unmet expectations that could break things. If you want to build reliable software, you must be strict about the inputs you accept. Don't let sloppy inputs propagate.

coldtea 6y ago

There's nothing especially "horrifying" about this. In fact, several geniuses in Computer Science have historically been of the same opinion (pro dynamic typing).