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

The return of statically typed languages! Why?


Userlevel 2
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.

2 replies

Badge
Hello!

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 1
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.

Reply

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept or continue browsing you agree to our cookie policy. Learn more about our cookies.

    Accept cookies Cookie settings