Is dynamic typing on its way out?

[Andre S. Veteran]

I tend to think that dynamically typed languages are on their way out. Here's my reasoning:

 

Dynamic languages were designed to have very expressive, succint syntax, in reaction to the 80-90s tendency towards verbose OOP languages (C++, Objective-C, Java). To this day the main argument people invoke to advocate Python, Ruby, etc., is their high signal-to-noise ratio.

 

Dynamic typing in itself has little or no demonstrable advantages versus static typing. Dynamically typed programs still have a type system, only type errors are caught are run-time rather than compile-time. This makes dynamically typed programs much more brittle, and much harder to provide good tooling for (i.e. static analysis is very limited).

 

However, the main argument in favor of dynamic languages, is itself largely made moot by the emergence of new, statically typed languages that are about as succint and expressive. In the Java and .NET world, Scala and F# are slowly rising, and they're every bit as succint and expressive as Ruby or Python.

 

Here's for example a recursive implementation of QuickSort in Python (from http://en.literateprograms.org/Quicksort_(Python)#Using_list_comprehensions):

def qsort(list):
    if list == []: 
        return []
    else:
        pivot = list[0]
        lesser = qsort([x for x in list[1:] if x < pivot])
        greater = qsort([x for x in list[1:] if x >= pivot])
        return lesser + [pivot] + greater

Here's an equivalent implementation in F# (from http://fsharpforfunandprofit.com/posts/fvsc-quicksort/):

let rec quicksort = function
   | [] -> []                         
   | first::rest -> 
        let smaller,larger = List.partition ((>=) first) rest 
        List.concat [quicksort smaller; [first]; quicksort larger]

Even more concise, yet statically typed.

 

Some might point out the rise of Javascript as a counter-example. Yet TypeScript, a statically-typed superset of Javascript, is seeing rave adoption due to its ability to provide the same power, compatibility and expressiveness as Javascript yet make large-scale application development much more manageable.

 

Another argument for dynamic languages is their natural ability to interact with intrisically untyped APIs, like Web services. And yet, F# proves with Type Providers that a statically typed language can provide an even better experience there with full auto-completion.

 

Static typing has long been associated with high syntactic overhead and old-school OOP, yet this needs not be the case. New statically typed languages like Scala, F# and TypeScript demonstrate that succintness and expressivety need not to come at the expense of static typing, and its many advantages: performance, tooling, large-scale project management and robustness.

 

What do you think?

[Max Norris]

  On 02/10/2013 at 00:06, Asik said:

What do you think?

I'm no expert in Python, been dabbling with it off and on out of curiosity for the past few months and I do rather like it a lot, get a lot done with very little code.. wish I picked up on it sooner. But for me anyway, static typing just overall makes a lot more sense as it sets clear rules as to what something is supposed to be, no guesswork, IDE tools can be a lot more helpful at pointing out dumbassery and no "why the fudge isn't this working" debugging sessions, never mind the end result I'd suspect is a lot more streamlined performance wise. I'm biased though, that's what I'm used to since the late '70s, dynamic typing just doesn't sit right with me. Ok, the Python indent vs blocks thing is just weird too, but that's another thread.

[Son of Hook]

No--although I think the perception differs depending upon if you're a conventional application developer or a Web developer. Conventional applications are the stronghold of statically typed languages; whereas, Web applications are home to (primarily) dynamic languages. But one only needs to look at most web technologies and see that dynamic languages are increasing in popularity.

 

I can't really comment on F# or Scala because my experience is either very limited or non-existent, but I can on TypeScript. It's really only popular with those who:

 

- can't wrap their head around ECMAScript 5-

- don't want to wrap their head around ECMAScript 5-

 

As someone who loves both static and dynamic languages, I get TypeScript's merits but I also see it as unnecessary. I know the primary drive behind TypeScript was to provide better tooling, but that edge dulls as JavaScript tooling gets better.

 

Static languages can play with dynamic typing, but doing so nearly always adds extra complexity.

[Andre S. Veteran]

  On 03/10/2013 at 21:15, jwmcpeak said:

No--although I think the perception differs depending upon if you're a conventional application developer or a Web developer. Conventional applications are the stronghold of statically typed languages; whereas, Web applications are home to (primarily) dynamic languages. But one only needs to look at most web technologies and see that dynamic languages are increasing in popularity.

There's more development getting done in Javascript which happens to be a dynamic language, but if Javascript was statically typed then all web development would be statically typed. There's nothing intrinsically advantageous about using a dynamically typed language for web development; it just so happened, for a variety of historical reasons, that a dynamic language initially intended for lightweight HTML manipulation has become the lingua franca of the Web.

  Quote

I can't really comment on F# or Scala because my experience is either very limited or non-existent, but I can on TypeScript. It's really only popular with those who:

 

- can't wrap their head around ECMAScript 5-

- don't want to wrap their head around ECMAScript 5-

 

As someone who loves both static and dynamic languages, I get TypeScript's merits but I also see it as unnecessary. I know the primary drive behind TypeScript was to provide better tooling, but that edge dulls as JavaScript tooling gets better.

This is like saying that C++ is for programmers who can't wrap their head around C. TypeScript is just EcmaScript with optional type annotations, and type annotations (i.e. optional static typing) proves useful for large-scale application development and static analysis of code. It's not a coincidence that dynamic language tooling is bad: it's a direct consequence of the lack of type information present in the source code. In order to understand what your variables are, tooling for a dynamic language would have to run the program indefinitely which is impossible (i.e. the Halting Problem).

[+Majesticmerc MVC]

I don't think that there's been a major shift away from dynamic typing yet (Ruby is bigger than ever), but I think/hope that a lot of people are realising the error of their ways :p. Static typing provides a lot of advantages to dynamic typing, and when the language is well constructed encompasses most of the advantages of dynamic typing too. Static typing solves a lot of problems even before the code is usable by allowing the compiler to stop you running off a cliff.

Dynamic typing also poses an enormous issue on mission critical software insofar that static analysis is almost impossible, leaving it entirely to runtime tests to find issues with the type system. So much so that, apparently, the US Army doesn't allow the running of dynamically typed programs. Dynamic languages always pose the risk that (for example), you'll end up trying to call a method on the wrong type, but given a sufficiently large system it's not until you run it that you find out such nonsense.

That said, I think that dynamically typed languages often get a lot of bad press because many of the most popular ones are also fairly weakly typed. One only has to look at the JavaScript truth table to see how ###### weak typing can make a language.

I'm a big static typing fanboy (can that be a thing?), but I do love me some Ruby. Great language IMO.

[Son of Hook]

  On 03/10/2013 at 21:43, Asik said:

if Javascript was statically typed then all web development would be statically typed.

You couldn't be more wrong. Well before Eich created LiveScript, dynamic languages, such as PERL and Python, were used to create Web applications. Sure, you could find CGI programs written in C and C++, but PERL-based CGI programs were far more common. PHP, the most popular server-side language/platform today, was introduced in 1995 (development started in 1994--a year before Eich created LiveScript), and it was created because PERL was (is?) too complicated. PHP didn't grow in popularity because of JavaScript; it became popular because it was simple and easy to use. PHP did more to firmly entrench dynamic languages in the web space than JavaScript ever has.

 

  Quote

There's nothing intrinsically advantageous about using a dynamically typed language for web development

And there's nothing intrinsically advantageous about using a statically-typed language for Web development. We can espouse the merits of both types of languages, but at the end of the day, neither of us would have the definitive winner.

 

  On 03/10/2013 at 21:43, Asik said:

This is like saying that C++ is for programmers who can't wrap their head around C. TypeScript is just EcmaScript with optional type annotations, and type annotations (i.e. optional static typing) proves useful for large-scale application development and static analysis of code. It's not a coincidence that dynamic language tooling is bad: it's a direct consequence of the lack of type information present in the source code. In order to understand what your variables are, tooling for a dynamic language would have to run the program indefinitely which is impossible (i.e. the Halting Problem).

A more apt analogy would be C programmers who can't/won't wrap their heads around C++ due to differing programming concepts. JavaScript's prototypal design is foreign to most people who use class-based languages (ie: different programming concepts), which is one of the reasons JavaScript draws ire from "computer sciency" people (there are other reasons, of course).

TypeScript is just a tad more than "JavaScript with type annotations". The annotations are optional, yes, but ironically, JavaScript tooling is better than TypeScript-sans-annotations tooling. But for large-scale applications, it's a toss up. Properly organized and with today's JavaScript tooling (especially in Visual Studio 2013), JavaScript application development is just fine.

It all boils down to this: millions of developers using dynamic languages can't be wrong, and millions of developers using statically typed languages can't be wrong, either. So pick your poison--you can't go wrong.

[Andre S. Veteran]

  On 03/10/2013 at 23:44, jwmcpeak said:

You couldn't be more wrong. Well before Eich created LiveScript, dynamic languages, such as PERL and Python, were used to create Web applications. Sure, you could find CGI programs written in C and C++, but PERL-based CGI programs were far more common. PHP, the most popular server-side language/platform today, was introduced in 1995 (development started in 1994--a year before Eich created LiveScript), and it was created because PERL was (is?) too complicated. PHP didn't grow in popularity because of JavaScript; it became popular because it was simple and easy to use. PHP did more to firmly entrench dynamic languages in the web space than JavaScript ever has.

I was talking about now and making a bit of a hyperbole. Obviously there are other languages used in web development (including statically typed ones), but Javascript can be considered the lingua franca of the web now, even on the server, as far as I know. I hope we can at least agree that PHP is a terrible language (if not I can point you to many informative reads on the topic) that succeeded because it provided a path of least resistance and that there was nothing better at the time.

 

 

  Quote

And there's nothing intrinsically advantageous about using a statically-typed language for Web development. We can espouse the merits of both types of languages, but at the end of the day, neither of us would have the definitive winner.

The same advantages statically typed languages provide elsewhere apply equally to web development; I honestly don't see why web development would be an exception. Advantages of static typing: performance, robustness, maintainability, tooling (auto-completion, static analysis).

 

  Quote

A more apt analogy would be C programmers who can't/won't wrap their heads around C++ due to differing programming concepts. JavaScript's prototypal design is foreign to most people who use class-based languages (ie: different programming concepts), which is one of the reasons JavaScript draws ire from "computer sciency" people (there are other reasons, of course).

 

TypeScript is just a tad more than "JavaScript with type annotations". The annotations are optional, yes, but ironically, JavaScript tooling is better than TypeScript-sans-annotations tooling. But for large-scale applications, it's a toss up. Properly organized and with today's JavaScript tooling (especially in Visual Studio 2013), JavaScript application development is just fine.

 

The main issue with Javascript is the dynamic nature of types and the intrinsically poor performance. Runtime engines have been making progress but they're running into a wall; there's only so much optimization to do on a language with so few compile-time guarantees. The nature of the language makes large-scale development problematic:

 

  Quote

Nicholas Zakas: The ?shared everything? nature of the language is the biggest JavaScript challenge. You can set up a system that is well designed, and an inexperienced engineer might come in and ? accidentally or not ? change some key piece of functionality. ECMAScript 5 helps with some of that by allowing you to lock down modification of objects, but the nature of the language remains largely the same and problematic. http://programming.oreilly.com/2011/06/big-javascript-apps-teams.html

 

 

This is why Google is pushing Dart, Microsoft is pushing TypeScript, and everyone else is creating static language compilers that output Javascript so you don't have to write it yourself ( http://haxe.org/ , http://jsil.org/ , etc.)

 

 

  Quote

It all boils down to this: millions of developers using dynamic languages can't be wrong, and millions of developers using statically typed languages can't be wrong, either. So pick your poison--you can't go wrong.

 

What if they're using it because they don't have or don't know any better? Last time I checked, the only reason console developers used C++ was because that was the only language with good optimizing compilers for all their target platforms. Ecosystems, tools, portability, barrier of entry, all of these are better explanations for the success of certain dynamic languages like Javascript than the intrinsic value of dynamic typing, because it doesn't have any. 

[incendy]

I hope so, was just commenting how typescript has made me finally enjoy js.

[astropheed Veteran]

I would say with significant confidence, 'probably not'.

 

I'm perfectly happy with Python's type system. There are some obvious speed benefits to using a statically typed language that Python isn't benefiting from, but, I'm not using Python for it's speed (although it's plenty fast). Also, I've yet to ever hear a solid argument that can directly attribute to the downfall of a dynamically typed language; it always boils down to a subjective bias with the general conclusion being an overly-glorified pro's and con's list.

 

I have no qualms with either statically or dynamically typed languages. They each have their place in the world. And this is a tired and futile argument akin to whether or not your language of choice is a programming language or a scripting language.

[+Fahim S. MVC]

Sounds like someone who prefers static typing trying to justify their point of view  :yes:  I kid, I appreciate a robust debate.  From a programming perspective I think I have a slight theoretical preference for statically typed languages whilst a practical preference for dynamically typed languages, so I apologise in advance for any biases I may display.

 

I don't think it is any coincidence that the most popular of web development languages to date all have a dynamic type system. The only language with a static type system that has made even the smallest inroads in the web development space is Java, but only really in the enterprise because it runs on enterprise grade platforms (or at least those that purport to be).  If you look at any real web success story, they are pretty much all written in languages with a dynamic type system.

 

If it wasn't JavaScript, it'd be something else like it was PHP before JavaScript and Perl before that.  Even Microsoft only made successful inroads to the web development space when they had a dynamically typed (and admittedly awful) language in ASP (I know ASP wasn't a language, but I don't know of many cases of people using jscript with ASP).

 

So why are these languages so popular?

 

I think it all comes down to productivity, which is not the same as the succinctness of a language.  I also think that the lack of tooling is actually not important to those that actually use this languages to create something 'important' as they don't have the rigour at the time - so that's not really a good reason not to use a statically typed language at the time that they are doing their work.  Frankly all testing is just user acceptance based rather than unit, integration etc.

 

I do also believe that dynamically typed languages have a shallower learning curve to do the basic stuff whilst a much steeper learning curve to do the hard stuff.  Statically typed languages, conversely, have a much steeper learning curve to do the basic stuff that gets flatter when doing the hard stuff.  I think that from a portability perspective, programmers that have a foundation in dynamically typed languages struggle more than those that with a foundation in statically typed languages when moving between different languages.

 

The fact that dynamically typed languages have a shallower learning curve to do the easy stuff, means that those using them are often heavily invested by the time they get round to doing the hard stuff which causes dynamically typed languages stick more that what I believe is logical.

[Andre S. Veteran]

  On 06/10/2013 at 09:39, .fahim said:

I think it all comes down to productivity, which is not the same as the succinctness of a language.

How are dynamic languages more productive then? Especially since, as you admit, they have inferior tooling support. Tooling plays a big part in developer productivity. Auto-completion, compile-time type checking, refactorings, are all big productivity advantages of static typing.

[Andre S. Veteran]

  On 06/10/2013 at 09:39, .fahim said:

If you look at any real web success story, they are pretty much all written in languages with a dynamic type system.

Twitter was recently rewritten in Scala for performance reasons, and also specifically to benefit from static typing.

 

  Quote

Another thing we really like about Scala is static typing that?s not painful. Sometimes it would be really nice in Ruby to say things like, here?s an optional type annotation. This is the type we really expect to see here. And we find that really useful in Scala, to be able to specify the type information.  http://www.artima.com/scalazine/articles/twitter_on_scala.html

 

 

[+Fahim S. MVC]

  On 07/10/2013 at 21:15, Asik said:

Twitter was recently rewritten in Scala for performance reasons, and also specifically to benefit from static typing.

 

 

That is all very well, but Twitter was a success before it re-written in a a statically typed language - it was originally written in a dynamically typed language.  You have to ask why they originally chose a dynamically typed language.  What's your answer to this?

[Andre S. Veteran]

  On 08/10/2013 at 20:04, .fahim said:

That is all very well, but Twitter was a success before it re-written in a a statically typed language - it was originally written in a dynamically typed language.  You have to ask why they originally chose a dynamically typed language.  What's your answer to this?

Probably because Ruby On Rails was a great, mature development framework, and at the time Scala was relatively unknown, so to get static typing they would have had to use the very verbose and inexpressive Java. With Scala around they've realized they can have the flexibility and expressiveness, and the robustness, performance and productivity of the JVM. I think web developers ought to take heed.

 

Another example is Facebook which was written in PHP, but in order to get the performance they needed, they wrote a PHP-to-C++ automatic code translator. So technically, Facebook runs on a C++ backend. Had Facebook been written in a more expressive statically typed language like F# or Scala, I doubt there would have been a need to write a code translator.

[+Fahim S. MVC]

  On 08/10/2013 at 20:22, Asik said:

Probably because Ruby On Rails was a great, mature development framework, and at the time Scala was relatively unknown, so to get static typing they would have had to use the very verbose and inexpressive Java. With Scala around they've realized they can have the flexibility and expressiveness, and the robustness, performance and productivity of the JVM. I think web developers ought to take heed.

 

Another example is Facebook which was written in PHP, but in order to get the performance they needed, they wrote a PHP-to-C++ automatic code translator. So technically, Facebook runs on a C++ backend. Had Facebook been written in a more expressive statically typed language like F# or Scala, I doubt there would have been a need to write a code translator.

 

Are you serious? robustness, performance and productivity of the JVM?

I've introduced Java as a web development platform in several enterprises I have worked in, despite one of my first bosses (in 1998) saying, and I quote 'Java will never fly in the enterprise' - I did win him over eventually.  Today I wouldn't touch it with a very very very long stick.  It is not performant at all and is incredibly wasteful on resources.

 

Lightweight platforms (i.e. not Java) that play nice on PaaS environments are the future.

[Andre S. Veteran]

  On 08/10/2013 at 21:05, .fahim said:

Are you serious? robustness, performance and productivity of the JVM?

Better garbage collection, threading support and long-lived processes support was mentionned by the twitter engineers as advantages of the JVM over Ruby. Both Python and Ruby use a Global Interpreter Lock so multicore concurrency is basically impossible.

 

Not sure how you arrive to the conclusion that Java is "not performant at all": it compiles to optimized code near what good C++ compilers achieve;, it has a highly efficient, state-of-the-art garbage collector, native threads, little object overhead (at least compared to dynamic languages). The Hotspot JVM is a state-of-the-art runtime that makes even .NET look silly in places. Perhaps you were using a slow library; the language itself is certainly among the most performant available.

 

With mobile devices running on limited power, efficiency gets more important today than ever. The runtime overhead of dynamic languages is something that will put software using them at a disadvantage.

[+Fahim S. MVC]

  On 08/10/2013 at 21:30, Asik said:

Better garbage collection, threading support and long-lived processes support was mentionned by the twitter engineers as advantages of the JVM over Ruby. Both Python and Ruby use a Global Interpreter Lock so multicore concurrency is basically impossible.

 

Not sure how you arrive to the conclusion that Java is "not performant at all": it compiles to optimized code near what good C++ compilers achieve;, it has a highly efficient, state-of-the-art garbage collector, native threads, little object overhead (at least compared to dynamic languages). The Hotspot JVM is a state-of-the-art runtime that makes even .NET look silly in places. Perhaps you were using a slow library; the language itself is certainly among the most performant available.

 

With mobile devices running on limited power, efficiency gets more important today than ever. The runtime overhead of dynamic languages is something that will put software using them at a disadvantage.

 

If I wanted to build a highly scalable web application, I would prefer to do this using the reactor pattern rather than trying to build a monolithic, multithreaded application.  You could, of course, do this in Java.

 

You can't have been building commercial/enterprise grade applications for very long - because I don't know a single person who has that would agree that the best platform for building applications is Java, maybe they would have 5 years ago, but it's just not true anymore.

[Andre S. Veteran]

  On 08/10/2013 at 21:44, .fahim said:

If I wanted to build a highly scalable web application, I would prefer to do this using the reactor pattern rather than trying to build a monolithic, multithreaded application.  You could, of course, do this in Java.

And how will you scale without threads? Today's servers are highly multicore.

 

  Quote

You can't have been building commercial/enterprise grade applications for very long - because I don't know a single person who has that would agree that the best platform for building applications is Java, maybe they would have 5 years ago, but it's just not true anymore.

 

I'm not much into Java but where I work we build large-scale enterprise grade software on .NET, which is very similar to Java in all fundamental respects. From first-hand experience I also know that if you want performance and efficiency in mobile applications, Javascript doesn't cut it; it's all C++, C# (Windows Phone), Objective-C (iOS) and Java (Android). Here's a very well researched article on the topic: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

 

Today's basic computing trends - highly parallel CPUs, battery-powered devices - all point towards languages and runtimes with high efficiency and first-class support for concurrency. 

[+Fahim S. MVC]

  On 08/10/2013 at 22:03, Asik said:

And how will you scale without threads? Today's servers are highly multicore.

 

You'd be surprised how much scalability you could achieve with a single thread and a non blocking reactor pattern based engine. See here.

If I wanted to use all of the cores (or threads) that my 'highly concurrent' server has to offer, I would run an application instance per thread.

 

  On 08/10/2013 at 22:03, Asik said:

I'm not much into Java but where I work we build large-scale enterprise grade software on .NET, which is very similar to Java in all fundamental respects. From first-hand experience I also know that if you want performance and efficiency in mobile applications, Javascript doesn't cut it; it's all C++, C# (Windows Phone), Objective-C (iOS) and Java (Android). Here's a very well researched article on the topic: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

 

Today's basic computing trends - highly parallel CPUs, battery-powered devices - all point towards languages and runtimes with high efficiency and first-class support for concurrency.

Just out of interest, how long have you been writing this 'large-scale' enterprise grade software using .NET?

[Andre S. Veteran]

  On 08/10/2013 at 22:23, .fahim said:

 

You'd be surprised how much scalability you could achieve with a single thread and a non blocking reactor pattern based engine. See here.

If I wanted to use all of the cores (or threads) that my 'highly concurrent' server has to offer, I would run an application instance per thread.

Well of course if you're I/O bound it doesn't matter that you're only using one core. Running multiple processes is an alternative but processes are much more heavyweight than threads and inter-process communication is inflexible.

 

  Quote

Just out of interest, how long have you been writing this 'large-scale' enterprise grade software using .NET?

 

For about a year.

 

 

[Brandon Live Veteran]

  On 03/10/2013 at 21:15, jwmcpeak said:

I can't really comment on F# or Scala because my experience is either very limited or non-existent, but I can on TypeScript. It's really only popular with those who:

 

- can't wrap their head around ECMAScript 5-

- don't want to wrap their head around ECMAScript 5-

 

I don't understand this comment. What does one have to do with the other? My JS projects exclusively use ECMA 5 / strict mode. But this gives me nothing of what TypeScript offers.

 

TypeScript includes some very desirable ECMAScript 6 features (classes, arrow functions, etc). I haven't used it myself yet, but it seems like it's popular because it brings ECMA 6 features without waiting for JS engines to support EMCA 6 (which is itself gated on the standard settling down).

[Brandon Live Veteran]

  On 08/10/2013 at 22:23, .fahim said:

 

You'd be surprised how much scalability you could achieve with a single thread and a non blocking reactor pattern based engine. See here.

If I wanted to use all of the cores (or threads) that my 'highly concurrent' server has to offer, I would run an application instance per thread.

 

That is so cute! They think async I/O and event loops are new! They even made up new names! That's almost as adorable as cats stealing dog beds :-)

[+Fahim S. MVC]

  On 17/10/2013 at 20:45, Brandon Live said:

That is so cute! They think async I/O and event loops are new! They even made up new names! That's almost as adorable as cats stealing dog beds :-)

 

Who thinks that?

[Brandon Live Veteran]

  On 18/10/2013 at 09:42, .fahim said:

Who thinks that?

 

I was referring to that link you posted and their presentation. At least the way I read it, it seemed pretty funny.

[+Fahim S. MVC]

  On 18/10/2013 at 18:11, Brandon Live said:

I was referring to that link you posted and their presentation. At least the way I read it, it seemed pretty funny.

Thanks for answering. The pattern has been around for a while but see how it could be interpreted that way. No idea if that's what they meant though