The return of statically typed languages! Why? | Coursera Community
Coursera Header

The return of statically typed languages! Why?

  • 15 November 2018
  • 4 replies

Userlevel 3
Badge +1
Golang is a rising star in the large family of programming and it is strongly and statically typed.

Twenty years ago there was the sunrise of dynamically typed languages, like Perl, PHP, Ruby. Today my impression is, that the pendulum swings back. Is my impression right?

And if! What may be the reason? My perspective is limited. I have the theory, that the major reason is in modern IDE. Having type informations at hand they can quickly deliver a large amount of information and give a rich assistance in typing code. I think this outweighs the amount of typing spared by using dynamic typing.

What do you think? Are dynamic languages like Perl or Ruby declining? How do you explain the development?

I am curious to read your views upon this matters.

4 replies


To me the most important part are not the optimizations that can be made to statically-typed code (these are a big selling point, but most compilers of statically-typed languages ​​do not reach that level of intelligence) but the better type-systems. The origin of type-systems was to give (mathematical) meaning to programs, guarantee that what you wrote will execute exactly as you think. Of course, you still do not have this perfect type-system (Haskell comes pretty close) but newer languages ​​are getting closer.

Personally, I think that the return of statically-typed languages ​​is related to the recent interest in functional languages: most type-system papers can only be used on pure functional languages ​​(in other words, only Haskell and a few others benefit). The more functional a language is, the more they can use these powerful type-systems.

Functional or not, type-systems are a powerful tool, and in my opinion, the only reason that we didn't started to use them earlier was the bad fame of type-systems like the ones of C, C ++, Java and others on being rigid and having to write things like "SomeType variable = new SomeType ()" instead of just "variable = new SomeType ()" (C ++ also helped to spread the myth that statically-typed languages ​​have bad error messages), modern type-systems also comes with type-inference algorithms, some better than others (OCaml does not need any type-declarations, it can infer everything, while Haskell can infer most, but in a few places you will still need them, and on the other side of the spectrum Java and C++ didn't have any type-inference until recently).

On the other hand, dynamically-typed languages ​​are not going anywhere. For most applications the speed difference between a JIT and the GHC complex type-system optimizations are unimportant. The biggest fault of current type-systems are error messages, this can be fixed of course, but it's not trivial. Also we have the problem that (if I remember correctly) not everything can be typed, so it does not matter how advanced the type-system is, there will always be a valid program that can not be compiled (thankfully most type-systems are so powerful that all you need is to rewrite a few parts to different, equivalent forms).
Userlevel 3
Badge +1
There are unfortunate. almost religious, strongly stated opinions about strong typed versus dynamic languages. I see both as thriving. Some of the strongly types languages seem (to my eyes) to enjoy an extreme complexity (look at discussions about covariant and contravariant generics for some examples).

I'll agree that Haskell is the best example we have of doing strong typing well. It's one of my "languages that everyone should learn" (others include C, Lisp, Python, and assembly code for at least two different instruction sets).

Sometimes the features that make a language superb in some spaces just don't map to other language styles. As an example the flexibility of function definition and call in Python, with its effective support for keyword and positional parameters, helps it to be the super "script and glue and domain-specific base" that it is. But those features do not map at all well onto the "strongly typed" language philosophy (particularly when you try to have such a function as a parameter or return value.

A language is a tool. As we use it in more spaces we hope to get from an apprentice skill to journeyman to master craftsman. That takes time, and getting to master craftsman can only be done by studying the works of other master craftsmen. At some point we get to the point of being master craftsmen with several different languages, so that we can choose which of them is the appropriate choice for areas of a large project.

What we don't want to do is to become the language lawyer so obsessed by the arcane details of a single language that they don't see the value in others.
Userlevel 6
Badge +4
I'm a software dev using C# and Python professionally.

Although I really like Python for simple "throw-away" projects and prototypes I tend to find C# easier to use when it comes to big code bases.

The reason is simple: it comes down to the editor. In Visual Studio C# is very well supported (hardly surprising), the "intellisense" and compiler will flag up a lot of errors (e.g typo's) and so you correct most of the stupid mistakes before Jenkins runs the pipeline.

For Python however, I've looked and looked but I cannot find an editor that works as well as Visual Studio works for C#. -- Eclipse is the best I've found, but even that misses a lot of stuff.

The End result is that I'll end up running a Jenkins Pipeline only for it to crash an hour into testing because there was some silly mistake in the Python script.

So, in answer to your question, I find python a powerful and flexible language, but the power and flexibility frequently end up slowing down development because few code editors can actually pick up on the mistakes.

So why does intellisense work better for C# than Python? Well, I suspect it has something to do with dynamic/static languages; it is probably easier to write intellisense for more "rigid" languages than the dynamic ones.
Userlevel 3
Badge +1
An issue with Python is that it has grown, originally being largely the "quick script" language (that displaced Perl) but now being used for many large applications. There is a lot of Python used in the machine learning, neural network world. Not "scripts", but major libraries and frameworks.

I'd suggest as an editor that you try Visual Studio Code, it provides useful amounts of assistance. Certainly statically typed languages are a big help for IDEs to do intellisense well. Microsoft have stated that as a justification for TypeScript in the JavaScript world.

I have some different prejudices. I'm a (retired) old-timer, from when we submitted jobs on punched cards, and got them back the next day. I learned then the value of examining code on paper, using pencil (and office-mate eyes), and I've always kept using those methods. When I see people working with IDEs I feel that they are never actually "looking at and reading" a piece of code. As I said, my prejudices.