11 ms·

> Two decades ago, it was widely argued that dynamic programming languages were more productive because you didn't have to spend time dealing with type signatur

> Two decades ago, it was widely argued that dynamic programming languages were more productive because you didn't have to spend time dealing with type signatures. The only reason, then, to use a statically typed language, was for better performance. This boggles the mind. I am using typed languages since I can think. I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". Like seriously, I don't even know what articles like this are talking about. Types are not your enemy, they surface issues early. Yeah you can whip something up in Python and JS, but ultimately you DO have to deal with types, except now you don't have a compiler doing this job anymore, you have to do it yourself... Somehow. The only thing typed languages need is something like `dynamic` from C#, which automatically boilerplates untyped access with reflection, without cluttering your code. I.e. duck typing is one of the things some languages like Java need to get better at. But the situations in which I yearn for this are far and few between. You don't think about types, unless you are new to typed languages... It's really that simple. I never have to think about types. Perhaps its subconcious, but its definitely not slowing me down, its making things faster through robust refactoring, auto-complete and welll doh: TYPE SAFETY!

mbesto 6y ago
> The only reason, then, to use a statically typed language, was for better performance. Uhh, someone please correct me if I'm wrong, but aren't statically typed languages about reliability (e.g. testing, mutability)? EDIT: in addition to performance, not solely.
- zdragnar 6y ago
  Two decades ago, dynamic languages were more typically scripted / interpreted, and statically typed languages were more typically compiled. Scripting does allow for quicker iteration (especially if compared to a language with a slow compiler) and compilation usually does produce faster code (at least pre-dating sophisticated JIT compilers).
- marta_morena_28 6y ago
  Statically typed languages only eliminate SOME things you'd otherwise have to test. In the end, you can eliminate almost anything besides logical errors, however, those are unfortunately a pretty big portion of bugs :D. So while I would always use statically typed languages for anything that needs to be reliable, I do not see how this is in any way a necessity. You CAN write reliable programs without type safety, you just have to test things you normally wouldn't have to test (i.e. the lack of type safety introduces a whole bunch of null-pointer style scenarios where you get something your code totally didn't expect but has to deal with). As for performance. Statically typed languages are usually faster, mostly because we do not have the technology yet to make dynamically typed ones as fast (in the general case). Not because there is something inherently different about them. However, I imagine the technology to make them on par with statically typed languages will take another few decades. Mainly because untyped languages need sophisticated transformations to be fast. That is the job the human normally does for the compiler in typed languages. Things just fit together and play nicely. With dynamic languages, your get one big spaghetti soup with no structure and now the compiler has to figure out the "intended" types and compile for different estimated function signatures, etc. all while honoring the JIT-style performance considerations (fast startup, low overhead during runtime). This is a gargantuan task that probably will require advanced machine learning before it really takes off.
  - mbesto 6y ago
    > I do not see how this is in any way a necessity. Right, but that's not my point. My point is that using a static type language isn't JUST about performance. If I define foo as a string and call it as an integer in my program, my compiler is going to catch it, whereas in a dynamically type language I may not discover the bug until it hits production.
- hedora 6y ago
  Statically typed languages typically have better performance. In C, i++ is one or two machine instuctions. In javascript, we don’t know if i is an int, or something that overrode ++ to download wikipedia. So, it ends up being a function call in naive JavaScript. Fast forward a decade, and dozens of PhD theses mean that ++ is usually a machine instruction in JavaScript, but it is not guaranteed.
  - deleted 6y ago
    [deleted]
coldtea 6y ago
>This boggles the mind. I am using typed languages since I can think. I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". You might not, but this was a common sentiment (not saying it is necessarily a valid one, mind you, but it was common). Were you programming 2 decades ago and/or paying attention to the average sentimeντ expressed in blogs/etc re types and dynamic languages (and the general tone up to around 2012 or so even in HN)? Another common sentiment was that "who needs types when you have TDD".
- mjcohen 6y ago
  Without types, TDD can become TTD.
- taneq 6y ago
  The people who have problems with types and think removing them makes programming easier are the same people who have problems with syntax and think that replacing text with some kind of graphical representation makes programming "easy for non-programmers".
mdoms 6y ago
> This boggles the mind. I am using typed languages since I can think. I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". Like seriously, I don't even know what articles like this are talking about. This was OVERWHELMINGLY the sentiment on hacker news a decade ago. Strongly statically typed languages were NOT WELCOME on this website.
- danenania 6y ago
  A lot of that can probably be attributed to major advances in type system ergonomics. A verbose, clunky type system with poor inference can easily be worse than none at all. Ten years ago, there just weren't that many popular, practical languages with really good type systems. Now there are quite a few.
nicoburns 6y ago
Statically typed languages without Sum Types (aka tagged unions aka enums) which includes Java, C# and C++ amongst others drive me crazy: they have no ergonomic way to express "or" types. This is a massive expressive hole which (along with lacking type inference) I believe is responsible for a lot of the hate towards statically typed languages.
- lolinder 6y ago
  Sealed classes in Kotlin largely solve that problem for me, and Java is getting those. It's not quite the same, but most of the time I find that if I'm trying to do Int|String, it's primitive obsession and there is actually a better sealed type hierarchy I'm missing.
- valenterry 6y ago
  Yes, totally agree. It's the lack of statical type systems like this one that makes people hate them - for good reasons.
  - NOGDP 6y ago
    These languages have far better type systems than languages like python or javascript, that's not a reason to hate them.
    - valenterry 6y ago
      We are talking about user experience here. In that regard, comparing python/javascript with Java/C++ is comparing apples with oranges.
      - NOGDP 6y ago
        We are talking about Python and JavaScript from the top of this comment chain, and the 'user experience' of writing Java/C# is closer to Python and JavaScript than to, say, Haskell.
        6y ago
randomdata 6y ago
> I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". Is that sentiment based on modern languages, though? While modern in its place in history, but adhering to older principles, I frequently hear exactly that from people evaluating Go. Languages with more complex type systems bring tools to help alleviate those concerns. Not all of those concepts were widely available looking back two decades ago. Java, for example, which was probably the most popular typed language of that time did not provide even generics until 2004. Being able to write a function once and use it for many (dynamic) types was no doubt seen as a big improvement for many use cases. Type systems are back in fashion now largely because they are much more usable now, especially outside of the academic languages.
visarga 6y ago
> I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy" For example, this is ugly in Python: def handler(on_error: Callable[[int, Exception], None]):
- emptysea 6y ago
  Alternatively a Protocol can be used instead of Callable from typing import Protocol class ErrorHandler(Protocol): def __call__(self, p0: int, p1: Exception) -> None: ... def handler(on_error: ErrorHandler): ...
- valenterry 6y ago
  It doesn't matter if you have the types ascribed explicitly or not. In the end, the developer needs to know the types in both cases anyways. Otherwise, if they don't know the types, they will pass in a callable that expects the wrong types (for example they mix up [int, Exception] to [Exception, int]) and now you just have a runtime error. If anything, having type signatures like that are a good thing! If you think they are too complicated/ugly or driving you crazy, then you have an incentive to improve them. In many languages, callbacks are now considered bad style and that's good! Hiding the type signature does not make the problem go away, you just move it into the future where it will bite you even more.
- Too 6y ago
  What's the alternative? No type signature? Or documentation in another file somewhere else guaranteed to be out of sync, difficult to find and not enforced by the compiler? No thanks to either of them.
dpc_pw 6y ago
Languages like Java (which was THE statically typed language around that time) were extremely verbose and inexpressive. It's hard to write anything in Java without metric tons of boilerplate and repeating the type of every value over and over and over again. On top of it, with OOP languages it's very easy to box the code in deep layers of ridiculous inheritance taxonomies, making it pretty much impossible to refactor anything after business requirements changed. Barely any escape hatches and absolutely no flexibility. And type-safety is kind of pointless when everything is of a given type "OR NULL". I was always proponent of typing but after working with Java, I can totally see why so many people back in the day considered static typing as not worth it.
pjmlp 6y ago
I share the same sentiment, the only dynamic language I put up with is JavaScript, and PHP when dealing with my own site. Tcl, Smalltalk, Lisp, Prolog, while great to program in the small, have taught me that I really want types when working in a team. Python, Ruby and Perl, I really don't see the use beyond learning to program or grown up shell scripts, given their lack of attention to performance.
- Daishiman 6y ago
  The vast majority of code ever written is not performance-sensitive, but is very sensitive to getting produced rapidly. If you need to quickly perform some statistical analysis, you'd be hard pressed to be more productive in anything else over Python+NumPy or R.
  - pjmlp 6y ago
    Statistical analysis is a domain I am more than happy not to care about, it was already enough what I had to bare with during my engineering degree. Still, given that Python and R are just glue languages for C, C++ and Fortran libraries, I rather use the source directly, or bindings to typed languages. Modern C++, .NET, Java or ML based languages are just as effective,. And here is a fun fact, I have spent 4 years working for life sciences companies, where several researchers I got to know, would do statistical analysis in Excel + VBA, eventually using VB.NET as well for more complicated stuff.
d0mine 6y ago
A dynamic language is not just a statically-typed language where all type labels are removed -- it is the wrong mindset -- don't try to write Java programs using Python syntax. On type safety: Python is a strongly typed language unlike e.g. C: >>> "%d+%d=%d" % (2, '2', 4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %d format: a number is required, not str vs: #include <stdio.h> int main(void) { return printf("%d+%d=%d\n", 2, "2", 4) < 0; }
- tomc1985 6y ago
  Funny, that's one of the things that drives me nuts about Python. It knows each types, it knows function to convert to each type, but... it doesn't do the conversions! So frustrating! Why do I have to care about types in these dynamically typed languages?? Also, is sprintf-style string formatting the best example here? I think that feature is type strict in a lot of languages, after all you are declaring the types you want in the formatting string. I imagine most implementations of % in dynamic languages pass to sprintf internally?
  - marmaduke 6y ago
    Some of those things in Python reflect its history as a better language between Bash and C, and the gotchas of those languages became verboten in Python. Elsewhere in eg NumPy conversions between number types are automatic as long as they don’t lose information.
  - imtringued 6y ago
    >It knows each types, it knows function to convert to each type, but... it doesn't do the conversions! So frustrating! It surprises me that you are incapable of thinking one step ahead. Implicit type conversions undermine the type system and make your language completely unpredictable. Pretty much everyone regrets this feature in C++ and it is still a huge source of bugs because you have to opt out of it. You want things to fail with a loud bang instead of continuing and destroying things along the way.
    - 6y ago
deleted 6y ago
[deleted]
kumarvvr 6y ago
Where dynamic typing helps a lot is for creating frameworks, like Django, RoR, etc. Because the framework is working on a level above the application, it can easily deal with objects without worrying about what is inside them. However, people got caught up in this no-type nonsense and took it to all corners of every app development. When you are creating, say web apps, you may not create types in dynamic languages like python, but you sure as hell will use known variables in those types. There are a few edge cases, where dynamic types allow you to build logic on user-defined sets of data, but those cases are few and far between. Even those can be solved using generic data containers or custom data protocols such as XML.
- valenterry 6y ago
  > Because the framework is working on a level above the application, it can easily deal with objects without worrying about what is inside them. Even for that there is no need for dynamic typing anymore. This problem has been solves with type parameters (aka generics) and type-classes.
  - Daishiman 6y ago
    Not true. In Python and Ruby it's an extremely common pattern to return a dictionary with a half-dozen entries at most that will be consumed at a single location. Defining an entire class for this sort of extremely common use case is for the most part a waste of time. These languages allow for the formalization of those types by creating classes out of them, but looking at what 50% of my functions do in web dev code, they're returning tuples, small dictionaries, or standard library objects.
    - valenterry 6y ago
      What makes you think that statically typed languages don't have (type-safe) tuples or dictionaries? Maybe you can give a minimal code example of what you mean and I'll show you how I would solve that in a statically typed way. :)
      - 6y ago
magicalhippo 6y ago
> Types are not your enemy, they surface issues early. Not only that, but they document the code. When working with a new framework or library in Python or JavaScript I never know what I can do, I have to look at the documentation constantly. Not seldom I'm still left scratching my head or doing stuff like "print(dir(result))" to figure out what I can do with whatever that function returned. With a static typed language I can see what type the function expects and what it returns. If I don't know a type I can discover what it can do in a few clicks in my IDE.
mixmastamyk 6y ago
> This boggles the mind. I am using typed languages since I can think. And therein lies the problem. It's a tradeoff: prototyping speed/readability vs longterm reliability. Modern languages have greatly improved the tradeoff, but it still exists, whether purists believe it or not. I personally find the highest productivity in adding the majority of tests and typing later, after a design solidifies, not before.

mbesto 6y ago

> The only reason, then, to use a statically typed language, was for better performance. Uhh, someone please correct me if I'm wrong, but aren't statically typed languages about reliability (e.g. testing, mutability)? EDIT: in addition to performance, not solely.

zdragnar 6y ago
Two decades ago, dynamic languages were more typically scripted / interpreted, and statically typed languages were more typically compiled. Scripting does allow for quicker iteration (especially if compared to a language with a slow compiler) and compilation usually does produce faster code (at least pre-dating sophisticated JIT compilers).
marta_morena_28 6y ago
Statically typed languages only eliminate SOME things you'd otherwise have to test. In the end, you can eliminate almost anything besides logical errors, however, those are unfortunately a pretty big portion of bugs :D. So while I would always use statically typed languages for anything that needs to be reliable, I do not see how this is in any way a necessity. You CAN write reliable programs without type safety, you just have to test things you normally wouldn't have to test (i.e. the lack of type safety introduces a whole bunch of null-pointer style scenarios where you get something your code totally didn't expect but has to deal with). As for performance. Statically typed languages are usually faster, mostly because we do not have the technology yet to make dynamically typed ones as fast (in the general case). Not because there is something inherently different about them. However, I imagine the technology to make them on par with statically typed languages will take another few decades. Mainly because untyped languages need sophisticated transformations to be fast. That is the job the human normally does for the compiler in typed languages. Things just fit together and play nicely. With dynamic languages, your get one big spaghetti soup with no structure and now the compiler has to figure out the "intended" types and compile for different estimated function signatures, etc. all while honoring the JIT-style performance considerations (fast startup, low overhead during runtime). This is a gargantuan task that probably will require advanced machine learning before it really takes off.
- mbesto 6y ago
  > I do not see how this is in any way a necessity. Right, but that's not my point. My point is that using a static type language isn't JUST about performance. If I define foo as a string and call it as an integer in my program, my compiler is going to catch it, whereas in a dynamically type language I may not discover the bug until it hits production.
hedora 6y ago
Statically typed languages typically have better performance. In C, i++ is one or two machine instuctions. In javascript, we don’t know if i is an int, or something that overrode ++ to download wikipedia. So, it ends up being a function call in naive JavaScript. Fast forward a decade, and dozens of PhD theses mean that ++ is usually a machine instruction in JavaScript, but it is not guaranteed.
- deleted 6y ago
  [deleted]

coldtea 6y ago

>This boggles the mind. I am using typed languages since I can think. I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". You might not, but this was a common sentiment (not saying it is necessarily a valid one, mind you, but it was common). Were you programming 2 decades ago and/or paying attention to the average sentimeντ expressed in blogs/etc re types and dynamic languages (and the general tone up to around 2012 or so even in HN)? Another common sentiment was that "who needs types when you have TDD".

mjcohen 6y ago
Without types, TDD can become TTD.
taneq 6y ago
The people who have problems with types and think removing them makes programming easier are the same people who have problems with syntax and think that replacing text with some kind of graphical representation makes programming "easy for non-programmers".

mdoms 6y ago

> This boggles the mind. I am using typed languages since I can think. I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". Like seriously, I don't even know what articles like this are talking about. This was OVERWHELMINGLY the sentiment on hacker news a decade ago. Strongly statically typed languages were NOT WELCOME on this website.

danenania 6y ago
A lot of that can probably be attributed to major advances in type system ergonomics. A verbose, clunky type system with poor inference can easily be worse than none at all. Ten years ago, there just weren't that many popular, practical languages with really good type systems. Now there are quite a few.

nicoburns 6y ago

Statically typed languages without Sum Types (aka tagged unions aka enums) which includes Java, C# and C++ amongst others drive me crazy: they have no ergonomic way to express "or" types. This is a massive expressive hole which (along with lacking type inference) I believe is responsible for a lot of the hate towards statically typed languages.

lolinder 6y ago
Sealed classes in Kotlin largely solve that problem for me, and Java is getting those. It's not quite the same, but most of the time I find that if I'm trying to do Int|String, it's primitive obsession and there is actually a better sealed type hierarchy I'm missing.
valenterry 6y ago
Yes, totally agree. It's the lack of statical type systems like this one that makes people hate them - for good reasons.
- NOGDP 6y ago
  These languages have far better type systems than languages like python or javascript, that's not a reason to hate them.
  - valenterry 6y ago
    We are talking about user experience here. In that regard, comparing python/javascript with Java/C++ is comparing apples with oranges.
    - NOGDP 6y ago
      We are talking about Python and JavaScript from the top of this comment chain, and the 'user experience' of writing Java/C# is closer to Python and JavaScript than to, say, Haskell.
      - 6y ago

randomdata 6y ago

> I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy". Is that sentiment based on modern languages, though? While modern in its place in history, but adhering to older principles, I frequently hear exactly that from people evaluating Go. Languages with more complex type systems bring tools to help alleviate those concerns. Not all of those concepts were widely available looking back two decades ago. Java, for example, which was probably the most popular typed language of that time did not provide even generics until 2004. Being able to write a function once and use it for many (dynamic) types was no doubt seen as a big improvement for many use cases. Type systems are back in fashion now largely because they are much more usable now, especially outside of the academic languages.

visarga 6y ago

> I never once recall an instant where I was saying "Uh uh, this type signature is driving me craaazy" For example, this is ugly in Python: def handler(on_error: Callable[[int, Exception], None]):

emptysea 6y ago
Alternatively a Protocol can be used instead of Callable from typing import Protocol class ErrorHandler(Protocol): def __call__(self, p0: int, p1: Exception) -> None: ... def handler(on_error: ErrorHandler): ...
valenterry 6y ago
It doesn't matter if you have the types ascribed explicitly or not. In the end, the developer needs to know the types in both cases anyways. Otherwise, if they don't know the types, they will pass in a callable that expects the wrong types (for example they mix up [int, Exception] to [Exception, int]) and now you just have a runtime error. If anything, having type signatures like that are a good thing! If you think they are too complicated/ugly or driving you crazy, then you have an incentive to improve them. In many languages, callbacks are now considered bad style and that's good! Hiding the type signature does not make the problem go away, you just move it into the future where it will bite you even more.
Too 6y ago
What's the alternative? No type signature? Or documentation in another file somewhere else guaranteed to be out of sync, difficult to find and not enforced by the compiler? No thanks to either of them.

dpc_pw 6y ago

Languages like Java (which was THE statically typed language around that time) were extremely verbose and inexpressive. It's hard to write anything in Java without metric tons of boilerplate and repeating the type of every value over and over and over again. On top of it, with OOP languages it's very easy to box the code in deep layers of ridiculous inheritance taxonomies, making it pretty much impossible to refactor anything after business requirements changed. Barely any escape hatches and absolutely no flexibility. And type-safety is kind of pointless when everything is of a given type "OR NULL". I was always proponent of typing but after working with Java, I can totally see why so many people back in the day considered static typing as not worth it.

pjmlp 6y ago

I share the same sentiment, the only dynamic language I put up with is JavaScript, and PHP when dealing with my own site. Tcl, Smalltalk, Lisp, Prolog, while great to program in the small, have taught me that I really want types when working in a team. Python, Ruby and Perl, I really don't see the use beyond learning to program or grown up shell scripts, given their lack of attention to performance.

Daishiman 6y ago
The vast majority of code ever written is not performance-sensitive, but is very sensitive to getting produced rapidly. If you need to quickly perform some statistical analysis, you'd be hard pressed to be more productive in anything else over Python+NumPy or R.
- pjmlp 6y ago
  Statistical analysis is a domain I am more than happy not to care about, it was already enough what I had to bare with during my engineering degree. Still, given that Python and R are just glue languages for C, C++ and Fortran libraries, I rather use the source directly, or bindings to typed languages. Modern C++, .NET, Java or ML based languages are just as effective,. And here is a fun fact, I have spent 4 years working for life sciences companies, where several researchers I got to know, would do statistical analysis in Excel + VBA, eventually using VB.NET as well for more complicated stuff.

d0mine 6y ago

A dynamic language is not just a statically-typed language where all type labels are removed -- it is the wrong mindset -- don't try to write Java programs using Python syntax. On type safety: Python is a strongly typed language unlike e.g. C: >>> "%d+%d=%d" % (2, '2', 4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %d format: a number is required, not str vs: #include <stdio.h> int main(void) { return printf("%d+%d=%d\n", 2, "2", 4) < 0; }

tomc1985 6y ago
Funny, that's one of the things that drives me nuts about Python. It knows each types, it knows function to convert to each type, but... it doesn't do the conversions! So frustrating! Why do I have to care about types in these dynamically typed languages?? Also, is sprintf-style string formatting the best example here? I think that feature is type strict in a lot of languages, after all you are declaring the types you want in the formatting string. I imagine most implementations of % in dynamic languages pass to sprintf internally?
- marmaduke 6y ago
  Some of those things in Python reflect its history as a better language between Bash and C, and the gotchas of those languages became verboten in Python. Elsewhere in eg NumPy conversions between number types are automatic as long as they don’t lose information.
- imtringued 6y ago
  >It knows each types, it knows function to convert to each type, but... it doesn't do the conversions! So frustrating! It surprises me that you are incapable of thinking one step ahead. Implicit type conversions undermine the type system and make your language completely unpredictable. Pretty much everyone regrets this feature in C++ and it is still a huge source of bugs because you have to opt out of it. You want things to fail with a loud bang instead of continuing and destroying things along the way.
  - 6y ago

deleted 6y ago

[deleted]

kumarvvr 6y ago

Where dynamic typing helps a lot is for creating frameworks, like Django, RoR, etc. Because the framework is working on a level above the application, it can easily deal with objects without worrying about what is inside them. However, people got caught up in this no-type nonsense and took it to all corners of every app development. When you are creating, say web apps, you may not create types in dynamic languages like python, but you sure as hell will use known variables in those types. There are a few edge cases, where dynamic types allow you to build logic on user-defined sets of data, but those cases are few and far between. Even those can be solved using generic data containers or custom data protocols such as XML.

valenterry 6y ago
> Because the framework is working on a level above the application, it can easily deal with objects without worrying about what is inside them. Even for that there is no need for dynamic typing anymore. This problem has been solves with type parameters (aka generics) and type-classes.
- Daishiman 6y ago
  Not true. In Python and Ruby it's an extremely common pattern to return a dictionary with a half-dozen entries at most that will be consumed at a single location. Defining an entire class for this sort of extremely common use case is for the most part a waste of time. These languages allow for the formalization of those types by creating classes out of them, but looking at what 50% of my functions do in web dev code, they're returning tuples, small dictionaries, or standard library objects.
  - valenterry 6y ago
    What makes you think that statically typed languages don't have (type-safe) tuples or dictionaries? Maybe you can give a minimal code example of what you mean and I'll show you how I would solve that in a statically typed way. :)
    - 6y ago

magicalhippo 6y ago

> Types are not your enemy, they surface issues early. Not only that, but they document the code. When working with a new framework or library in Python or JavaScript I never know what I can do, I have to look at the documentation constantly. Not seldom I'm still left scratching my head or doing stuff like "print(dir(result))" to figure out what I can do with whatever that function returned. With a static typed language I can see what type the function expects and what it returns. If I don't know a type I can discover what it can do in a few clicks in my IDE.

mixmastamyk 6y ago

> This boggles the mind. I am using typed languages since I can think. And therein lies the problem. It's a tradeoff: prototyping speed/readability vs longterm reliability. Modern languages have greatly improved the tradeoff, but it still exists, whether purists believe it or not. I personally find the highest productivity in adding the majority of tests and typing later, after a design solidifies, not before.