Take the 2-minute tour ×

This statement suggests that statically typed languages are not ideal for web sites:

I’ll contrast that with building a website. When rendering web pages, often you have very many components interacting on a web page. You have buttons over here and little widgets over there and there are dozens of them on a webpage, as well as possibly dozens or hundreds of web pages on your website that are all dynamic. With a system with a really large surface area like that, using a statically typed language is actually quite inflexible. I would find it painful probably to program in Scala and render a web page with it, when I want to interactively push around buttons and what-not. If the whole system has to be coherent, like the whole system has to type check just to be able to move a button around, I think that can be really inflexible.

Source: http://www.infoq.com/interviews/kallen-scala-twitter

Is this correct? Why or why not?

share|improve this question

closed as primarily opinion-based by gnat, m3th0dman, Bart van Ingen Schenau, GlenH7, Dan Pichelman Sep 30 '14 at 16:50


Sounds to me like they didn't consider a language/package with a proper object hierarchy. No need to check if the control you're moving is a Button when WebControl contains all the info you need and all controls are derived from it. –  Matthew Read Mar 2 '11 at 14:47
Yup @Matthew - sounds like someone who doesn't really know polymorphism –  NickC Mar 2 '11 at 16:47
Also - Twitter may be popular, but it's not because their site is an engineering masterpiece. –  NickC Mar 2 '11 at 16:48

9 Answers 9

up vote 35 down vote accepted

I totally disagree. As systems grow bigger, statically typed languages ensure robustness at component level and thus flexibility at system level.

Also, the example given by the author doesn't really make any sense. It rather seems as if this guy doesn't know that polymorphism can be achieved by other means than duck typing.

There's a number of people who claim dynamic languages to be superior, but that's usually based on their lack of experience with expressive type systems that for example support structural subtyping, algebraic datatypes and first order functions.

share|improve this answer
How does first order functions fall in the same category as structural subtyping and algebraic data types? You make it sound like dynamic languages don't have first order functions, which is clearly not true (Scheme, Common Lisp, Erlang, Smalltalk, ...). –  Frank Shearar Mar 2 '11 at 16:23
+1 for "It rather seems as if this guy doesn't know that polymorphism can be achieved by other means than duck typing." –  NickC Mar 2 '11 at 16:49
@Frank Shearer: What I mean is, that they are supported with the same type safety as any other value. There's a number of strictly typed languages that support function values, but do not distinguish between signatures. –  back2dos Mar 2 '11 at 19:00
I disagree too, which is why I'm selecting this as the answer. –  Bradford Mar 3 '11 at 14:46

First of all, take in mind that the author of the above statement is talking about website development. So he is worried about presentation development, and that's where he thinks Scala would not be a good choice...

Having said that, I do have a good experience with web development. I've worked for at least 8 years exclusively with it, 5 of that in digital agencies.

And, yes, in my experience a statically typed, compiled language at the presentation layer can be a big hindrance. Content needs to be changed constantly, much more often than business requirements. And usually this needs to be done by a distinct team (the "front-end" developers). They normally know a lot about HTML, JavaScript, web standards, CSS, but not much about server-side languages like Java and C#. They also assume that any kind of change in a template is immediately available; they are not used to compilation and type errors. And they are right: statically typed languages are very good for hard, complex requirements, like data access and business rules, but not as good for interface development.

That's, in fact, one of the main benefits of using a specialized and interpreted template language like Velocity. Its easy of use, power and flexibility are adequate to presentation-layer developers. And then server-side guys are free to use a serious, statically typed language everywhere else...

However, I also agree that Scala is somewhat different. Being at the same time much less verbose and much more expressive than Java, I believe it could be used for presentation development - so maybe it could be successfully used as a template language. And if it also could be combined to a framework like Play (which compiles the web site automagically after every change), it could be a winner IMHO. Still, even Play has opted for a Groovy-like (dynamic) template language, which is not a good sign.

To sum up: the problem with Scala is much more related to the fact that it is compiled. In fact its type inference mechanism makes you almost forget it is also statically typed.

(And sorry about my English. Let me know if something is not clear, I'll try to fix it up.)

share|improve this answer
I would second this -- just look at the JSP/STRUTS mess when they tried to make Java a web language! –  James Anderson Sep 30 '14 at 8:39

I think the text (and most answers) are mixing Statically typed languages and excessively verbose languages. Of course, the intersection is very big (specially when considering only the most mainstream languages); but there are some interesting examples of non-verbose, statically-typed languages: Go, Haskell, Scala, Rust…

share|improve this answer
Define "excessively". As programs become more and more complex, and their lifespan and maintenance cycles increase, the likelihood that someone other than the original author will need to debug or modify any given piece of code continues to grow. When you're in that situation, you're usually under the gun, and the more information there is immediately available to you about exactly what data you're dealing with and what it can do the better. I've debugged other people's Delphi and other people's JavaScript, and the Delphi is orders of magnitude easier, because of the verbosity and type info. –  Mason Wheeler Feb 28 '12 at 3:51
Just a side note: Something like TypeScript (JavaScript, with static type information) might be a straightforward way of testing the OP's theory. My short exposure to it has been pretty nice - one time when converting some JavaScript to TypeScript, it actually helped me find that there was no possible way for a certain method to be called, and not produce an error. –  Katana314 Sep 30 '14 at 13:44

I encourage you to read Bruce Eckel's Strong Typing vs. Strong Testing. It's main argument is that software quality all boils down to testing. You can test in a lot of different ways. Compilers test some things at compile time: try to store a string in an int variable and it will likely bark at you. In dynamic languages, a lot of the testing occurs at runtime. Ultimately, it doesn't matter when the testing occurs. It just has to happen. What time you gain not compiling in dynamic languages is lost testing at runtime. You robustly test everything, right?

Given that, a preference for compiled languages with rigid type systems versus dynamic languages is just that - a preference. Kind of like boxers versus briefs or thongs versus french knickers. There's no right or wrong answer. Wear them with the right attitude and there's only awesome.

share|improve this answer
"Compilers test some things at compile time: try to store a string in an int variable and it will likely bark at you. In dynamic languages, a lot of the testing occurs at runtime.": True, when using a dynamic language I happen to write lots of tests that replace type checking. Using a static language I can have my tests focus more on the business logic. –  Giorgio Sep 30 '14 at 14:09
@Giorgio Interesting, I rarely have any type checking logic in my tests. –  pllee Sep 30 '14 at 16:13
@pllee: Sometimes it is not directly type-checking logic, but the tests check some behaviour that a static type system would have enforced anyway. –  Giorgio Sep 30 '14 at 18:54

I agree with that in most of if, because lets face it, when you deal with clients on a web-plataform, flexibility is a must.

Statically typed languages are more robust and secure that a dinamically typed one, but when you start adapting code to act in a way it was not meant to be and you need it fast, solutions look kind of complex and rigid.

So if you have the change to merge technologies i would recommend to create a core in a statically typed language (core dont change much) and use dinamically for user interaction.

share|improve this answer
Loose coupling is good. But dynamic languages are not required to achieve it. See, the Web is all about loose coupling done via HTTP, and most web servers and browsers are written in static languages. Dynamic languages shine in scripting applications when you need a piece of code easily modifiable at runtime, without invoking a large toolchain. –  9000 Mar 3 '11 at 10:28

I think the author of this post has not looked into Scala himself. While I agree that Java and C# have limitations and are a bit inflexible for web development, Scala is a statically typed language that is quite different to what you normally think of when you hear that. Scala allows for duck typing aswell as a type safe version of monkey patching (Through implicit conversions). That makes programming libraries a bit more complex because you will have to think about types, but if you just use a library like Lift it feels very much like a dynamic language except that the compiler will inform you about obvious bugs where you just dont use it right. I personally think the lift web framework doesnt have to hide from ruby on rails or similar. Have a look at the code examples here or here and decide for yourself. I develop in lift for quite a while now and never had a situation where I had a type error and though "Ah man, if this was dynamic it would work" ... because if it was dynamic it would have just not told me that there was a bug until it crashed during runtime.

share|improve this answer

Personally I think what they say is true for any system, not just Websites. You will need static typing when you talk to hardware, for everything else dynamic typing has the same drawbacks and benefits no matter what you do, really, and what is best depends on taste and the specific issues for each project.

share|improve this answer
I think its worth noting that Scala is a bit special because it use type inference and thus doesn't belong the same static typing category as say Java. –  Winston Ewert Mar 2 '11 at 18:18

Practical Quick answer: It depends in the size and complexity of the web size. Small website, dynamic progr. lang., Complex Large website, static progr. lang.

Extended boring answer: Many developers insist that a website should be done with a dynamic progr. langr. but the truth is that, eventually, web development tools tend to use or emulate static typed languages.

I had work with PHP several times, and sooner or later, we had to add a lot of code that verifies the types of the given data, that is implicit in a static typed progr. lang.

Typed Lagn. also helps the usage of I.D.E. (s), that requires a lot of type verification.

( brought by your neighbour progr. & compiler designer ;-) )

share|improve this answer

I kind of agree. When I look at most web front-end C# code, there is a lot of casting from strings and serializing data to strings. Basically, HTTP as a protocol is a good fit for dynamic languages.

share|improve this answer
