6 ms·

> other developers have their own language and tooling preferences Of course if you prefer a language, use it, but don't argue that your preference has any bea

> other developers have their own language and tooling preferences Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible. > there is no shortage of talented developers preferring dynamic languages There is also no shortage of talented developers preferring static languages. And given the two, I know which developer I prefer. Especially since I've never worked with an infallible developer, even in the upper echelons. > Developer iteration times are much faster in dynamic languages I disagree, I find I'm about as productive in either, but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either. > tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity Those features are orthogonal to the type system.

mythz 9y ago
> Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible. I've not once mentioned my preference. My preference and where I spend the majority of my time developing server libraries and Services C# which I consider the most well-balanced modern statically-typed language available. But I'm not naive enough to think everyone would be better off developing in C#, most startups prefer dynamic languages with good reasons stemming from being quicker to market, faster iteration times, more malleable in implementing customer requirements and having a rich pool of talented resources available. There are a lot of smart people sharing the same opinion, like Alan Kay: > If you’re using early-binding languages as most people do, rather than late-binding languages, then you really start getting locked in to stuff that you’ve already done. You can’t reformulate things that easily. - http://mythz.servicestack.net http://mythz.servicestack.net Smalltalk was first released 45 years ago and it still has live programming features like being able to re-program its IDE while it's running that I've never seen any static language been able to do. There's a whole class of software I can't imagine being built in a static language, like Wordpress rich extensibility and plugin ecosystem, I've implemented a few Wordpress sites and custom plugins which would've taken an inordinate amount of time in a statically typed language. I've spent a few years developing PHP and I very much dislike PHP based on its language merits, but I have an appreciation of what it's been able to be built with it. There are other classes of software that are extremely hard to implement in a statically typed language like React which IMO is revolutionary in developing complex UIs. I also think it's infeasible for tools like Webpack to have been written in a typed language, where its able to import any kind of asset in the source files that use them, being able to easily chain loaders together, running incremental watched builds that transpile source code, generate source maps, inline images, cache-breakers, etc. Webpack's Hot reloading feature would also take significantly more effort to develop in a statically-typed language. Tools like this are born from dynamic languages because it's simply much easier to do which would've taken significantly more effort in a statically-typed language. I also develop and maintain http://techstacks.io http://techstacks.io (Server in C#, not that it matters) and see the amazing number of successful products being built with dynamic languages, not in-spite of them. From what I've seen a large majority of successful SV startups use dynamic languages. Languages and technology should be a tool to achieve your objectives, many technology choices involves trade-offs, dismissing and throwing shade on successful companies usage of dynamic languages prevents you from seeing the benefits they have in using them, what advantages they have and which scenarios where they'd offer the most compelling value. The reason why many amazing software and talented engineers use dynamic languages isn't because they don't know statically-typed languages exist - it's a mistake to write-off other people's choices because they don't share your same views.
- jjnoakes 9y ago
  > I've not once mentioned my preference. That's fine, no one was talking about you specifically. > I'm not naive enough to think everyone would be better off developing in C# That's good. Neither am I, so I'm not sure why it is being mentioned. > There are a lot of smart people sharing the same opinion, like Alan Kay Smart people also have the opposite opinion. It doesn't mean anything; that part is all subjective. > There's a whole class of software I can't imagine being built in a static language A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed. > There are other classes of software that are extremely hard to implement in a statically typed language like React Define "extremely hard". Would you consider Elm "extremely hard", for example? And why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally. > throwing shade on successful companies usage of dynamic languages All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea. I have no qualms about which companies use which programming languages, as long as the result is a quality product from my (the user's) point of view. If they get that quality through dynamic languages, good for them. I think they worked harder than they should have, and I think they are spending more money on server infrastructure than necessary, but that's their choice. But I don't believe for a second that the quality, performance, or the end user experience was improved because a dynamic language was chosen. And this discussion (at least, where I chimed in) was precisely the point where the end user experience was called into question.
  - mythz 9y ago
    > A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed. In almost all cases runtime "holes" in static type languages provides a sub par development experience that's worse than both dynamic and static typing, it's definitely not a strategy for developing the same class of software on and it's not comparable to using a first class dynamically typed language. The places where it works is in static type systems are used to annotate a dynamic runtime like TypeScript, Hack and (less so) Dart. > All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea. Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality. > why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally. It doesn't exist because it's simpler, requires significantly less effort and is more naturally suitable to implement in a dynamic language. In these classes of software choosing a static language is the wrong choice that will always yield inferior results due to their lack of dynamic capabilities and interested resources who naturally gravitate around dynamic language ecosystem. No doubt many devs will still try using their preferred static language but they will all fail to achieve anywhere near the level of success, featureset and penetration of equivalent dynamic language implementations. Of course as it's software, given enough resources anything is possible, like Apple is able to do with Swift Playgrounds but they're in the unique position of being able to change Swift's language and runtime to introduce the capabilities needed to make Swift Playgrounds feasible - which is major strategic project for Apple which I still hold would require significantly less effort using a dynamic language. Google has the same benefits with what they're able to do with Dart where their flutter project offers a compelling live programming experience for developing native mobile Apps. Both would be considerably harder if they weren't able to change the language and runtime to make it easier for them, e.g. snapshots would be nigh impossible without language/runtime support. Likewise their exists classes of performance and mission critical software that's not suitable for dynamic languages, but it's not always a mistake to start with a dynamic language first to prototype quickly then rewrite once the system requirements have been identified and solidified.

mythz 9y ago

> Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible. I've not once mentioned my preference. My preference and where I spend the majority of my time developing server libraries and Services C# which I consider the most well-balanced modern statically-typed language available. But I'm not naive enough to think everyone would be better off developing in C#, most startups prefer dynamic languages with good reasons stemming from being quicker to market, faster iteration times, more malleable in implementing customer requirements and having a rich pool of talented resources available. There are a lot of smart people sharing the same opinion, like Alan Kay: > If you’re using early-binding languages as most people do, rather than late-binding languages, then you really start getting locked in to stuff that you’ve already done. You can’t reformulate things that easily. - http://mythz.servicestack.net http://mythz.servicestack.net Smalltalk was first released 45 years ago and it still has live programming features like being able to re-program its IDE while it's running that I've never seen any static language been able to do. There's a whole class of software I can't imagine being built in a static language, like Wordpress rich extensibility and plugin ecosystem, I've implemented a few Wordpress sites and custom plugins which would've taken an inordinate amount of time in a statically typed language. I've spent a few years developing PHP and I very much dislike PHP based on its language merits, but I have an appreciation of what it's been able to be built with it. There are other classes of software that are extremely hard to implement in a statically typed language like React which IMO is revolutionary in developing complex UIs. I also think it's infeasible for tools like Webpack to have been written in a typed language, where its able to import any kind of asset in the source files that use them, being able to easily chain loaders together, running incremental watched builds that transpile source code, generate source maps, inline images, cache-breakers, etc. Webpack's Hot reloading feature would also take significantly more effort to develop in a statically-typed language. Tools like this are born from dynamic languages because it's simply much easier to do which would've taken significantly more effort in a statically-typed language. I also develop and maintain http://techstacks.io http://techstacks.io (Server in C#, not that it matters) and see the amazing number of successful products being built with dynamic languages, not in-spite of them. From what I've seen a large majority of successful SV startups use dynamic languages. Languages and technology should be a tool to achieve your objectives, many technology choices involves trade-offs, dismissing and throwing shade on successful companies usage of dynamic languages prevents you from seeing the benefits they have in using them, what advantages they have and which scenarios where they'd offer the most compelling value. The reason why many amazing software and talented engineers use dynamic languages isn't because they don't know statically-typed languages exist - it's a mistake to write-off other people's choices because they don't share your same views.

jjnoakes 9y ago
> I've not once mentioned my preference. That's fine, no one was talking about you specifically. > I'm not naive enough to think everyone would be better off developing in C# That's good. Neither am I, so I'm not sure why it is being mentioned. > There are a lot of smart people sharing the same opinion, like Alan Kay Smart people also have the opposite opinion. It doesn't mean anything; that part is all subjective. > There's a whole class of software I can't imagine being built in a static language A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed. > There are other classes of software that are extremely hard to implement in a statically typed language like React Define "extremely hard". Would you consider Elm "extremely hard", for example? And why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally. > throwing shade on successful companies usage of dynamic languages All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea. I have no qualms about which companies use which programming languages, as long as the result is a quality product from my (the user's) point of view. If they get that quality through dynamic languages, good for them. I think they worked harder than they should have, and I think they are spending more money on server infrastructure than necessary, but that's their choice. But I don't believe for a second that the quality, performance, or the end user experience was improved because a dynamic language was chosen. And this discussion (at least, where I chimed in) was precisely the point where the end user experience was called into question.
- mythz 9y ago
  > A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed. In almost all cases runtime "holes" in static type languages provides a sub par development experience that's worse than both dynamic and static typing, it's definitely not a strategy for developing the same class of software on and it's not comparable to using a first class dynamically typed language. The places where it works is in static type systems are used to annotate a dynamic runtime like TypeScript, Hack and (less so) Dart. > All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea. Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality. > why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally. It doesn't exist because it's simpler, requires significantly less effort and is more naturally suitable to implement in a dynamic language. In these classes of software choosing a static language is the wrong choice that will always yield inferior results due to their lack of dynamic capabilities and interested resources who naturally gravitate around dynamic language ecosystem. No doubt many devs will still try using their preferred static language but they will all fail to achieve anywhere near the level of success, featureset and penetration of equivalent dynamic language implementations. Of course as it's software, given enough resources anything is possible, like Apple is able to do with Swift Playgrounds but they're in the unique position of being able to change Swift's language and runtime to introduce the capabilities needed to make Swift Playgrounds feasible - which is major strategic project for Apple which I still hold would require significantly less effort using a dynamic language. Google has the same benefits with what they're able to do with Dart where their flutter project offers a compelling live programming experience for developing native mobile Apps. Both would be considerably harder if they weren't able to change the language and runtime to make it easier for them, e.g. snapshots would be nigh impossible without language/runtime support. Likewise their exists classes of performance and mission critical software that's not suitable for dynamic languages, but it's not always a mistake to start with a dynamic language first to prototype quickly then rewrite once the system requirements have been identified and solidified.