8 ms·

>> Extreme late-binding is important because Kay argues that it permits you to not commit too early to the "one true way" of solving an issue (and thus makes it

>> Extreme late-binding is important because Kay argues that it permits you to not commit too early to the "one true way" of solving an issue (and thus makes it easier to change those decisions), but can also allow you to build systems that you can change while they are still running! >> Binding can also refer to binding a variable type to data. As someone who has over 15 years of experience going back and forth between statically typed and dynamically typed programming languages (but who has settled on dynamically typed languages in the last 4 years), this statement resonates very strongly with me. Also, it ties in perfectly with my philosophy of focusing on integration tests instead of unit tests; the idea that you should lock down the features of your system but keep the flexibility to move around the all the internal implementation is critical. It's a shame to see the new generation of developers moving back to statically typed languages (e.g. TypeScript) instead of actually trying to understand how to use dynamically typed languages properly. The obsession around achieving 100% unit tests coverage is equally shameful. Many of the people who came up with or promoted the idea of dynamically typed languages had decades of experience working with punchcards, assembly code and statically typed languages; they were onto something. Why does the new generation so easily discard this vast amount of wisdom?

Pop2019 7y ago
Everyone gets this one wrong. It's static typing within objects and dynamic typing outside of objects. Sadly we don't have languages with good micro/macro split. Maybe Axum only.
rndmio 7y ago
Because having some guarantees about the correctness of my code before it goes into production is valuable. Because the system I develop on is not the system that will run the code. Wisdom is not being discarded, the importance of different factors is simply not universal.
jompe 7y ago
I'm a fresh graduate from uni so I'd say that I don't have that much experience. My last years working on the side of studies using Python really made me prefer strongly typed languages like Haskell, Rust, Elm etc. My experience is that the compiler almost always finds my small errors and would-be-bugs which Python exposes at runtime (crashes with e.g. None-type errors). What would you say the benefits are with dynamic typing?
- armitron 7y ago
  The article explains (very well) what the benefits of dynamic typing are, it's just that Python is a terrible language that spits in the face of Alan Kay's ideas. It's like someone went out of their way to create a language that would not be too paradigm shifting by discarding the crucial elements that Alan Kay keeps raving about and only choosing the most superficial with the only consideration being ease of use and popular appeal. Try programming in Erlang, Common Lisp or Smalltalk. All dynamically typed languages. All meshing perfectly with Alan Kay's vision. All very different to Python. It's too bad that people's idea of "dynamic typing" has been - mostly - reduced down to Python and Javascript.
  - 0x445442 7y ago
    I wouldn't say current Smalltalk implementations mesh perfectly with Kay's vision. It's focus on class hierarchies and inheritance breaks with what Kay's initial vision was. That said, it's possible to write Smalltalk code favoring composition over inheritance or in a much more functional way that focuses on messages.
- dec0dedab0de 7y ago
  Python IS strongly typed. ie: 1 == '1' is FALSE, and 2 + '2' raises an exception.
  - AnimalMuppet 7y ago
    So forgive jompe for using the wrong term. The point, however, was clear. It wasn't "strong vs weak"; the point clearly was "compile time vs run time". And, well, Python is, from jompe's perspective, on the wrong side of the line, no matter how "strong" Python's type system is.
    - PunchTornado 7y ago
      since python 3.6 you can use static types in python if you want.
    - 7y ago
pleasecalllater 7y ago
Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code. I like to have both.
- jondubois 7y ago
  Why next week? Why not use the integration tests as part of your debug cycle now? The kinds of integration tests that I write only take a few milliseconds to run so if they fail I can just make a code change (or add a new breakpoint or log), then run again, then repeat. The flow should not be any different from doing TDD with unit tests. Note that integration tests don't necessarily have to be end-to-end; the point is more that each test case should cover a specific behavior.
  - adwn 7y ago
    > Why next week? I think pleasecalllater's point is that without unit tests, you'll spend a lot of time just pinpointing the bug, since it could be anywhere in your module (which unit tests would cover), not just at the interface to other modules (which integration tests cover).
    - jondubois 7y ago
      That's not my experience. Usually it only takes me a few minutes to fix a bug once it has been caught by an integration test.
      - pleasecalllater 7y ago
        Depends on your system. Mine usually are huge. The integration test showing "this json reply is wrong" doesn't tell me anything else than I have to dig through all the layers.
        jondubois 7y ago
deleted 7y ago
[deleted]
cbdumas 7y ago
> Many of the people who came up with or promoted the idea of dynamically typed languages had decades of experience working with punchcards, assembly code and statically typed languages The problem IMO is that the languages used at that time mostly had ad hoc, poorly specified, unsound type systems. I find that more "modern" type systems are helpful rather than burdensome, but the theoretical foundation for them didn't really exist until the 70s.
armitron 7y ago
We need to acknowledge that this particular field of, let's be generous and call it engineering, we are talking about is, for the most part, slow-moving and rather backwards to begin with. It's also shaped by forces and concerns that are suboptimal. As I wrote in the past: "Software Engineering must be the only engineering discipline where mastery of tools and barrier to entry in terms of skills are in many ways inversely correlated with market demands. Every clown can write software these days and in fact a lot of clowns get paid six figure salaries to do so. When the domain is largely composed of clowns, standards become extinct and one finds oneself calibrating for a circus." This is very important when we think about certain ideas expressed by geniuses that are so far ahead of their time that even smart people don't understand them. Unfortunately this seems to have happened to Alan Kay and his ideas. Maybe in 50 or 100 years, the modern software engineering race-to-the-bottom culture will have evolved enough (or more realistically, either exhausted dead-end paradigms or slammed into one unfathomable disaster or another) to appreciate them.
- potta_coffee 7y ago
  You sound like a really fun guy to hang out with. Also, a lot of those "clowns" are building things that make a lot of money and serve a lot of customers.
ladyattis 7y ago
I've always been on the fence with respect to dynamic versus static typing. In some cases, static typing is nice but the majority of my issues don't rise from such cases where data passed in don't match the type of a function or class. I've noticed this quite a bit in my toy projects with Racket and Common Lisp. I think static typing might have its uses in places where you want to ensure the numeric values are within a range but one can argue that the compiler or runtime system should be competent enough to make arbitrarily large numbers acceptable even if they're rare in execution. But for all others, I think one can ignore types unless the former situation affects your work.
balfirevic 7y ago
> Why does the new generation so easily discard this vast amount of wisdom? If you are actually looking to have some input from people who prefer statically typed languages about their reasons, you might want to write your comment in a way that does not presuppose that these people are obviously wrong (and, apparently, unwise).
- pjc50 7y ago
  Indeed. Berating people is the worst form of advocacy. Advocates of LISP and Smalltalk need to come up with reasons why their languages have not won the adoption wars that aren't "everyone else is an idiot" or "if only we told them the gospel they would convert". (In fact, in some ways they've almost overwhelmingly won, it's just that those two particular languages didn't. The bulk of code today is written in the late-binding language Javascript, with its novel prototypical inheritance that enables run time patching. Lots of data is stored in JSON, which is a marginal improvement over S-expressions. Apple have people undramatically writing Objective-C, the Smalltalk inheritor. Perhaps the problem is not that they didn't win but that they aren't being hailed as heroes?)
bsaul 7y ago
I really don't agree with your point. The analogy Kay uses with biology is very telling : Cells (co-)evolved for billions of years, they were not "designed" to accomplish certain tasks. Just survival and reproduction. And still, even with those billion of years, we still have cancer (as in bug in the reproduction process). We design software. We evolve software. Software doesn't build itself, or decide for itself what's the best way to accomplish some task. We maintain software, we need guarantees, as much as we can get. Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time. It just doesn't work. It's an ideal vision that explodes as soon as your software gets any kind of commercial success and longevity, and you need to maintain it, and evolve it.
- dnautics 7y ago
  > Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time. I don't think most people who program in dynamically typed languages believe that. However there are people in the extreme that believe that static typing will save you from errors. Sometimes I worry that the cognitive overhead of and code legibility, conciseness, and lax documentation that become habits in static typed languages add complexity to the program which is antithetical to maintainability. In practice, static typechecking of a dynamic language is probably enough. Especially erlang family languages do a great job of keeping type annotations looking "more like documentation" which is how it ought to be.
  - sgt101 7y ago
    Static typing doesn't eliminate any errors, it just exposes them earlier when you run the compiler rather than when a unit test finds them. Of course, that's if the unit test has been written.
  - jondubois 7y ago
    I've had several experiences where static typing forced my hand into making a software design decision which I later regretted. Many real-world entities don't have a fixed set of characteristics/properties; instead, they have fluid characteristics that can change over time. Trying to model those entities using static types which have a fixed/static set of properties is a bad idea. For example, in nature, a tadpole might grow arms and legs and become a frog. Trying to represent a single entity using two different classes 'Tadpole' and 'Frog' doesn't always work... What type is the creature if it's exactly halfway between being a Tadpole and a Frog? Do you keep inventing new discrete types to keep re-categorizing the creature as it grows or do you acknowledge that the exact type of this creature cannot be expressed discretely but that it lies on a continuum?
ivanhoe 7y ago
How exactly types and unit tests stop you from moving around the internal implementation? My impression was always that they help you in exactly that, allowing one to refactor any piece of code without worrying about unexpected side-effects.
Zelphyr 7y ago
I think our industry has become rife with people who don't know its history. So we get people "discovering" new ways of doing things that were known decades ago. Take for example "JAM stack", also known as basically the way web development was done 20 years ago. It is touted it as something new and exciting when it's only so if you don't understand the history of web development. Sure, JavaScript is used more now than it was back then but that doesn't make Jam Stack altogether new, does it? Likewise, statically typed languages aren't new and refreshing. They're just another way of solving a problem. Note I said they're "another way", not a "better way". They have their place (right tool for the job, etc...) but I think OP's point is that too many people think statically typed languages are better for everything and that's simply not the case. But one needs to understand the history of languages and programming in order to better appreciate the distinction and, more importantly, know which tool is the right one for the job.
- Fice 7y ago
  Pop culture, that's it. A rather known and obvious approach at web development needed a catchy name and dedicated promotional website so that webdevs know that's cool and trendy. Alan Kay said in 2004: «You could think of it as putting a low-pass filter on some of the good ideas from the ’60s and ’70s, as computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.» https://queue.acm.org/detail.cfm?id=1039523 https://queue.acm.org/detail.cfm?id=1039523
munificent 7y ago
> As someone who has over 15 years of experience going back and forth between statically typed and dynamically typed programming languages I have >20, in a mix of dynamic and statically typed languages. I've even designed a few of both including some that straddle the line. > It's a shame to see the new generation of developers moving back to statically typed languages It's only a shame if you presume to know better than all of those developers. If dynamic typing was what they wanted, they wouldn't have added TypeScript to their existing JavaScript code. Personally, I trust that in the aggregate, developers aren't dumb and do understand their own pain points and solutions even when the pain and solutions aren't obvious to me. > Many of the people who came up with or promoted the idea of dynamically typed languages had decades of experience working with punchcards, assembly code and statically typed languages; they were onto something. Most of the designers of the initial statically typed languages came from that same era and technology background, so I don't think this argument carries much weight. Neither dynamic nor static typing supplanted the other. They are parallel tracks and have been for virtually all of computing history (see BASIC and FORTRAN). Both branches are still going strong, so anyone on one branch isn't discarding the wisdom of the other, they're simply choosing their preferred path. If I use a hammer and you use a screwdriver, I'm not "discarding the vast amount of screwdriver wisdom", I simply know that I have a nail and not a screw to deal with. One of the real problems I see with advocates of dynamic typing is that we for the most part, we have lost a dynamic code editing experience. Without something like Smalltalk's "open a code editor when an error occurs" live debugging/editing experience, you'll never get the real benefits of dynamic typing. Editing dynamically typed code in a textual static user experience seems like the worst of both worlds to me.
- Supermancho 7y ago
  > https://vimeo.com/9270320 https://vimeo.com/9270320 There's very little you can prove, other than "less code gives you fewer errors/bugs". Arguably, this is primarily due to specification gaps being opaque and less logic to hold state. You can't file a bug or raise an issue about a choice that was already made by a dynamic language. > It's only a shame if you presume to know better than all of those developers. Statistically, someone is going to be right. The "right tool for the job" trope does not extend to every facet of every choice. The totality of developers are not experts in every set of practices (while it still may apply to some cases). Less code is better and until there's a study to say something more, I'm not interested in the hand waving. > > Many of the people who came up with or promoted the idea of dynamically typed languages > Most of the designers of the initial statically typed languages came from that same era This isn't an argument about better, but precisely the point you turn around and make. It's not worse. Less code is better, for sure. > Without something like Smalltalk's "open a code editor when an error occurs" live debugging/editing experience, you'll never get the real benefits of dynamic typing. Debuggers allow this. You generally don't want the user to have this power. There is a shocking lack of science in the industry. Re: The Quorum Programming Language made some attempts at advancement. It's been decades and I still see the same squabbles and continue doing 10x more with dynamic languages than when I am forced back to something like Java. At some point, I have to assume that I'm special or one of those language choices are crippling.
paulddraper 7y ago
> It's a shame to see the new generation of developers moving back to statically typed languages (e.g. TypeScript) Equating TypeScript to Pascal, C++, and Java, or even newer languages like Scala, Kotlin, and Rust is a poor comparison. TypeScript's type system is extremely flexible and even optional. It lets you choose your own point on the spectrum of dynamic and static types, and move that fluidly over time if that changes.

Pop2019 7y ago

Everyone gets this one wrong. It's static typing within objects and dynamic typing outside of objects. Sadly we don't have languages with good micro/macro split. Maybe Axum only.

rndmio 7y ago

Because having some guarantees about the correctness of my code before it goes into production is valuable. Because the system I develop on is not the system that will run the code. Wisdom is not being discarded, the importance of different factors is simply not universal.

jompe 7y ago

I'm a fresh graduate from uni so I'd say that I don't have that much experience. My last years working on the side of studies using Python really made me prefer strongly typed languages like Haskell, Rust, Elm etc. My experience is that the compiler almost always finds my small errors and would-be-bugs which Python exposes at runtime (crashes with e.g. None-type errors). What would you say the benefits are with dynamic typing?

armitron 7y ago
The article explains (very well) what the benefits of dynamic typing are, it's just that Python is a terrible language that spits in the face of Alan Kay's ideas. It's like someone went out of their way to create a language that would not be too paradigm shifting by discarding the crucial elements that Alan Kay keeps raving about and only choosing the most superficial with the only consideration being ease of use and popular appeal. Try programming in Erlang, Common Lisp or Smalltalk. All dynamically typed languages. All meshing perfectly with Alan Kay's vision. All very different to Python. It's too bad that people's idea of "dynamic typing" has been - mostly - reduced down to Python and Javascript.
- 0x445442 7y ago
  I wouldn't say current Smalltalk implementations mesh perfectly with Kay's vision. It's focus on class hierarchies and inheritance breaks with what Kay's initial vision was. That said, it's possible to write Smalltalk code favoring composition over inheritance or in a much more functional way that focuses on messages.
dec0dedab0de 7y ago
Python IS strongly typed. ie: 1 == '1' is FALSE, and 2 + '2' raises an exception.
- AnimalMuppet 7y ago
  So forgive jompe for using the wrong term. The point, however, was clear. It wasn't "strong vs weak"; the point clearly was "compile time vs run time". And, well, Python is, from jompe's perspective, on the wrong side of the line, no matter how "strong" Python's type system is.
  - PunchTornado 7y ago
    since python 3.6 you can use static types in python if you want.
  - 7y ago

pleasecalllater 7y ago

Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code. I like to have both.

jondubois 7y ago
Why next week? Why not use the integration tests as part of your debug cycle now? The kinds of integration tests that I write only take a few milliseconds to run so if they fail I can just make a code change (or add a new breakpoint or log), then run again, then repeat. The flow should not be any different from doing TDD with unit tests. Note that integration tests don't necessarily have to be end-to-end; the point is more that each test case should cover a specific behavior.
- adwn 7y ago
  > Why next week? I think pleasecalllater's point is that without unit tests, you'll spend a lot of time just pinpointing the bug, since it could be anywhere in your module (which unit tests would cover), not just at the interface to other modules (which integration tests cover).
  - jondubois 7y ago
    That's not my experience. Usually it only takes me a few minutes to fix a bug once it has been caught by an integration test.
    - pleasecalllater 7y ago
      Depends on your system. Mine usually are huge. The integration test showing "this json reply is wrong" doesn't tell me anything else than I have to dig through all the layers.
      - jondubois 7y ago

deleted 7y ago

[deleted]

cbdumas 7y ago

> Many of the people who came up with or promoted the idea of dynamically typed languages had decades of experience working with punchcards, assembly code and statically typed languages The problem IMO is that the languages used at that time mostly had ad hoc, poorly specified, unsound type systems. I find that more "modern" type systems are helpful rather than burdensome, but the theoretical foundation for them didn't really exist until the 70s.

armitron 7y ago

We need to acknowledge that this particular field of, let's be generous and call it engineering, we are talking about is, for the most part, slow-moving and rather backwards to begin with. It's also shaped by forces and concerns that are suboptimal. As I wrote in the past: "Software Engineering must be the only engineering discipline where mastery of tools and barrier to entry in terms of skills are in many ways inversely correlated with market demands. Every clown can write software these days and in fact a lot of clowns get paid six figure salaries to do so. When the domain is largely composed of clowns, standards become extinct and one finds oneself calibrating for a circus." This is very important when we think about certain ideas expressed by geniuses that are so far ahead of their time that even smart people don't understand them. Unfortunately this seems to have happened to Alan Kay and his ideas. Maybe in 50 or 100 years, the modern software engineering race-to-the-bottom culture will have evolved enough (or more realistically, either exhausted dead-end paradigms or slammed into one unfathomable disaster or another) to appreciate them.

potta_coffee 7y ago
You sound like a really fun guy to hang out with. Also, a lot of those "clowns" are building things that make a lot of money and serve a lot of customers.

ladyattis 7y ago

I've always been on the fence with respect to dynamic versus static typing. In some cases, static typing is nice but the majority of my issues don't rise from such cases where data passed in don't match the type of a function or class. I've noticed this quite a bit in my toy projects with Racket and Common Lisp. I think static typing might have its uses in places where you want to ensure the numeric values are within a range but one can argue that the compiler or runtime system should be competent enough to make arbitrarily large numbers acceptable even if they're rare in execution. But for all others, I think one can ignore types unless the former situation affects your work.

balfirevic 7y ago

> Why does the new generation so easily discard this vast amount of wisdom? If you are actually looking to have some input from people who prefer statically typed languages about their reasons, you might want to write your comment in a way that does not presuppose that these people are obviously wrong (and, apparently, unwise).

pjc50 7y ago
Indeed. Berating people is the worst form of advocacy. Advocates of LISP and Smalltalk need to come up with reasons why their languages have not won the adoption wars that aren't "everyone else is an idiot" or "if only we told them the gospel they would convert". (In fact, in some ways they've almost overwhelmingly won, it's just that those two particular languages didn't. The bulk of code today is written in the late-binding language Javascript, with its novel prototypical inheritance that enables run time patching. Lots of data is stored in JSON, which is a marginal improvement over S-expressions. Apple have people undramatically writing Objective-C, the Smalltalk inheritor. Perhaps the problem is not that they didn't win but that they aren't being hailed as heroes?)

bsaul 7y ago

I really don't agree with your point. The analogy Kay uses with biology is very telling : Cells (co-)evolved for billions of years, they were not "designed" to accomplish certain tasks. Just survival and reproduction. And still, even with those billion of years, we still have cancer (as in bug in the reproduction process). We design software. We evolve software. Software doesn't build itself, or decide for itself what's the best way to accomplish some task. We maintain software, we need guarantees, as much as we can get. Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time. It just doesn't work. It's an ideal vision that explodes as soon as your software gets any kind of commercial success and longevity, and you need to maintain it, and evolve it.

dnautics 7y ago
> Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time. I don't think most people who program in dynamically typed languages believe that. However there are people in the extreme that believe that static typing will save you from errors. Sometimes I worry that the cognitive overhead of and code legibility, conciseness, and lax documentation that become habits in static typed languages add complexity to the program which is antithetical to maintainability. In practice, static typechecking of a dynamic language is probably enough. Especially erlang family languages do a great job of keeping type annotations looking "more like documentation" which is how it ought to be.
- sgt101 7y ago
  Static typing doesn't eliminate any errors, it just exposes them earlier when you run the compiler rather than when a unit test finds them. Of course, that's if the unit test has been written.
- jondubois 7y ago
  I've had several experiences where static typing forced my hand into making a software design decision which I later regretted. Many real-world entities don't have a fixed set of characteristics/properties; instead, they have fluid characteristics that can change over time. Trying to model those entities using static types which have a fixed/static set of properties is a bad idea. For example, in nature, a tadpole might grow arms and legs and become a frog. Trying to represent a single entity using two different classes 'Tadpole' and 'Frog' doesn't always work... What type is the creature if it's exactly halfway between being a Tadpole and a Frog? Do you keep inventing new discrete types to keep re-categorizing the creature as it grows or do you acknowledge that the exact type of this creature cannot be expressed discretely but that it lies on a continuum?

ivanhoe 7y ago

How exactly types and unit tests stop you from moving around the internal implementation? My impression was always that they help you in exactly that, allowing one to refactor any piece of code without worrying about unexpected side-effects.

Zelphyr 7y ago

I think our industry has become rife with people who don't know its history. So we get people "discovering" new ways of doing things that were known decades ago. Take for example "JAM stack", also known as basically the way web development was done 20 years ago. It is touted it as something new and exciting when it's only so if you don't understand the history of web development. Sure, JavaScript is used more now than it was back then but that doesn't make Jam Stack altogether new, does it? Likewise, statically typed languages aren't new and refreshing. They're just another way of solving a problem. Note I said they're "another way", not a "better way". They have their place (right tool for the job, etc...) but I think OP's point is that too many people think statically typed languages are better for everything and that's simply not the case. But one needs to understand the history of languages and programming in order to better appreciate the distinction and, more importantly, know which tool is the right one for the job.

Fice 7y ago
Pop culture, that's it. A rather known and obvious approach at web development needed a catchy name and dedicated promotional website so that webdevs know that's cool and trendy. Alan Kay said in 2004: «You could think of it as putting a low-pass filter on some of the good ideas from the ’60s and ’70s, as computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.» https://queue.acm.org/detail.cfm?id=1039523 https://queue.acm.org/detail.cfm?id=1039523

munificent 7y ago

> As someone who has over 15 years of experience going back and forth between statically typed and dynamically typed programming languages I have >20, in a mix of dynamic and statically typed languages. I've even designed a few of both including some that straddle the line. > It's a shame to see the new generation of developers moving back to statically typed languages It's only a shame if you presume to know better than all of those developers. If dynamic typing was what they wanted, they wouldn't have added TypeScript to their existing JavaScript code. Personally, I trust that in the aggregate, developers aren't dumb and do understand their own pain points and solutions even when the pain and solutions aren't obvious to me. > Many of the people who came up with or promoted the idea of dynamically typed languages had decades of experience working with punchcards, assembly code and statically typed languages; they were onto something. Most of the designers of the initial statically typed languages came from that same era and technology background, so I don't think this argument carries much weight. Neither dynamic nor static typing supplanted the other. They are parallel tracks and have been for virtually all of computing history (see BASIC and FORTRAN). Both branches are still going strong, so anyone on one branch isn't discarding the wisdom of the other, they're simply choosing their preferred path. If I use a hammer and you use a screwdriver, I'm not "discarding the vast amount of screwdriver wisdom", I simply know that I have a nail and not a screw to deal with. One of the real problems I see with advocates of dynamic typing is that we for the most part, we have lost a dynamic code editing experience. Without something like Smalltalk's "open a code editor when an error occurs" live debugging/editing experience, you'll never get the real benefits of dynamic typing. Editing dynamically typed code in a textual static user experience seems like the worst of both worlds to me.

Supermancho 7y ago
> https://vimeo.com/9270320 https://vimeo.com/9270320 There's very little you can prove, other than "less code gives you fewer errors/bugs". Arguably, this is primarily due to specification gaps being opaque and less logic to hold state. You can't file a bug or raise an issue about a choice that was already made by a dynamic language. > It's only a shame if you presume to know better than all of those developers. Statistically, someone is going to be right. The "right tool for the job" trope does not extend to every facet of every choice. The totality of developers are not experts in every set of practices (while it still may apply to some cases). Less code is better and until there's a study to say something more, I'm not interested in the hand waving. > > Many of the people who came up with or promoted the idea of dynamically typed languages > Most of the designers of the initial statically typed languages came from that same era This isn't an argument about better, but precisely the point you turn around and make. It's not worse. Less code is better, for sure. > Without something like Smalltalk's "open a code editor when an error occurs" live debugging/editing experience, you'll never get the real benefits of dynamic typing. Debuggers allow this. You generally don't want the user to have this power. There is a shocking lack of science in the industry. Re: The Quorum Programming Language made some attempts at advancement. It's been decades and I still see the same squabbles and continue doing 10x more with dynamic languages than when I am forced back to something like Java. At some point, I have to assume that I'm special or one of those language choices are crippling.

paulddraper 7y ago

> It's a shame to see the new generation of developers moving back to statically typed languages (e.g. TypeScript) Equating TypeScript to Pascal, C++, and Java, or even newer languages like Scala, Kotlin, and Rust is a poor comparison. TypeScript's type system is extremely flexible and even optional. It lets you choose your own point on the spectrum of dynamic and static types, and move that fluidly over time if that changes.