4 ms·

> 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

> 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.
- jjnoakes 9y ago
  > 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. What I suggested, if you go back and read my initial comment, was that static type systems give you a higher chance of improving performance, efficiency, and quality. I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues. And there's plenty of basis in reality. > It doesn't exist It does exist. > requires significantly less effort and is more naturally suitable to implement in a dynamic language Maybe since dynamic languages are popular. I'm not convinced that dynamic typing made this easier, or if it just so happens that most people know dynamically-typed languages. But that's beside the point completely. The point was pretty simple (I thought...): Quality is visible to the end user, and all other things being equal, a static type system has a higher chance of resulting in quality software. Now in the real world, of course, all other things aren't equal (otherwise everyone would just use statically typed languages). But choosing a dynamically typed language for those other reasons (your developers are more familiar with it, it has more libraries that you need) should be a conscious choice made knowing full well that you are opening your self up to a class of errors that you could have automatically avoided. If that trade-off is worth it to you (it is worth it to many) so be it. But the trade-off is still there, and when it does cause quality issues, users will notice. I'm not saying using a dynamic language is a mistake and I'm not saying using a dynamic language guarantees the quality of the result will be lower (nor am I saying a static language guarantees the quality will be higher, although I believe it helps a lot), so arguing against those points is falling on deaf ears.
  - mythz 9y ago
    > Your opinion... I've provided a number of examples, you've provided exactly none. > I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues. Your comments are full of snide comments against dynamic languages: > That does correlate with being unstable and offline. > plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve > choosing dynamic just leaves more opportunities for inefficiency and runtine errors. > You either have to write more unit tests, or pray, or be infallible. > but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either. > and all other things being equal, a static type system has a higher chance of resulting in quality software. Which is categorically False. Software quality refers to how well it adheres to its fitness of purpose and how it competes with competing alternatives. Users generally prefer to use software which are easier to use and provides them the most value where by being able to iterate quickly holds the most value, which is arguably an inherent benefit in dynamic languages and why they're a popular choice amongst startups. Especially when you're competing in a new market category, velocity is of utmost importance. In fact almost all successful companies that I can think of that were competing in a new software category were developed using dynamic languages including: Facebook, YouTube, Instagram, Spotify, Dropbox, GitHub, Pintrest, Reddit, AirBnB, Uber, Slack, Khan Academy, Coursera, Twitch, Hulu, Kick Starter, Patreon, Trello, etc. Results are overwhelmingly in favor of building new products in a dynamic language. I struggle to think of any recent successful Startups that were able to out compete their competitors and achieved their dominance starting out with a static language. The major ones I can think of predominantly built with typed languages are: LinkedIn (2002), Netflix (1997), Ebay (1995), Amazon (1994). The most recent one I can think of is Stack Exchange (2009) (which I know of because I used to work there :). Of course once they've established market dominance and implemented their core feature-set many go back and focus on optimizing their system of which many identify and rewrite hotspots in more appropriate languages. Which remains a strong case for starting out with a dynamic language first. > But the trade-off is still there, and when it does cause quality issues, users will notice. There's a trade-off on whether adopting a static language is worth it, of which most successful SV Startups don't agree with - and their users are better off for it.

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.

jjnoakes 9y ago
> 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. What I suggested, if you go back and read my initial comment, was that static type systems give you a higher chance of improving performance, efficiency, and quality. I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues. And there's plenty of basis in reality. > It doesn't exist It does exist. > requires significantly less effort and is more naturally suitable to implement in a dynamic language Maybe since dynamic languages are popular. I'm not convinced that dynamic typing made this easier, or if it just so happens that most people know dynamically-typed languages. But that's beside the point completely. The point was pretty simple (I thought...): Quality is visible to the end user, and all other things being equal, a static type system has a higher chance of resulting in quality software. Now in the real world, of course, all other things aren't equal (otherwise everyone would just use statically typed languages). But choosing a dynamically typed language for those other reasons (your developers are more familiar with it, it has more libraries that you need) should be a conscious choice made knowing full well that you are opening your self up to a class of errors that you could have automatically avoided. If that trade-off is worth it to you (it is worth it to many) so be it. But the trade-off is still there, and when it does cause quality issues, users will notice. I'm not saying using a dynamic language is a mistake and I'm not saying using a dynamic language guarantees the quality of the result will be lower (nor am I saying a static language guarantees the quality will be higher, although I believe it helps a lot), so arguing against those points is falling on deaf ears.
- mythz 9y ago
  > Your opinion... I've provided a number of examples, you've provided exactly none. > I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues. Your comments are full of snide comments against dynamic languages: > That does correlate with being unstable and offline. > plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve > choosing dynamic just leaves more opportunities for inefficiency and runtine errors. > You either have to write more unit tests, or pray, or be infallible. > but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either. > and all other things being equal, a static type system has a higher chance of resulting in quality software. Which is categorically False. Software quality refers to how well it adheres to its fitness of purpose and how it competes with competing alternatives. Users generally prefer to use software which are easier to use and provides them the most value where by being able to iterate quickly holds the most value, which is arguably an inherent benefit in dynamic languages and why they're a popular choice amongst startups. Especially when you're competing in a new market category, velocity is of utmost importance. In fact almost all successful companies that I can think of that were competing in a new software category were developed using dynamic languages including: Facebook, YouTube, Instagram, Spotify, Dropbox, GitHub, Pintrest, Reddit, AirBnB, Uber, Slack, Khan Academy, Coursera, Twitch, Hulu, Kick Starter, Patreon, Trello, etc. Results are overwhelmingly in favor of building new products in a dynamic language. I struggle to think of any recent successful Startups that were able to out compete their competitors and achieved their dominance starting out with a static language. The major ones I can think of predominantly built with typed languages are: LinkedIn (2002), Netflix (1997), Ebay (1995), Amazon (1994). The most recent one I can think of is Stack Exchange (2009) (which I know of because I used to work there :). Of course once they've established market dominance and implemented their core feature-set many go back and focus on optimizing their system of which many identify and rewrite hotspots in more appropriate languages. Which remains a strong case for starting out with a dynamic language first. > But the trade-off is still there, and when it does cause quality issues, users will notice. There's a trade-off on whether adopting a static language is worth it, of which most successful SV Startups don't agree with - and their users are better off for it.