Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Yes, similar questions have been asked but always with the aim of finding out 'which one is better.'

I'm asking because I came up as a dev primarily in JavaScript and don't really have any extensive experience writing in statically typed languages.

In spite of this I definitely see value in learning C for handling demanding operations at lower levels of code (which I assume has a lot to do with static vs dynamic at the compiler level), but what I'm trying to wrap my head around is whether there are specific project contexts (maybe certain types of dynamic data-intensive operations?) involving things other than performance where it makes a lot more sense to go with Java or C# vs. something like Python.

share|improve this question

migrated from stackoverflow.com Aug 11 '11 at 20:10

This question came from our site for professional and enthusiast programmers.

5  
The answer is "Yes". Each type of language - indeed each language - has its strengths and weaknesses and so is better suited to some tasks than others. –  ChrisF Aug 11 '11 at 20:18

4 Answers 4

up vote 8 down vote accepted

Yes, definitely. Dynamic programming has definite advantages in cases where you want to be able to treat everything as one single type. Serialization/deserialization is one of the classic examples. This is why so much Web programming is done in dynamically-typed scripting languages: they're well-suited to a task which involves a whole lot of converting all sorts of data to and from strings.

For application programming, on the other hand, static languages work much better because trying to treat everything as one single type is not frequently a requirement. You often want to have efficient data structures with data represented as itself and not getting converted to other types very frequently. This makes the features of dynamic typing a drawback instead of a benefit, which is why applications are almost exclusively written in statically typed languages.

share|improve this answer
    
So it sounds like it is basically about the tradeoff of raw number-crunching low-level performance vs. convenience/speed of development via high-level abstraction. I do wonder sometimes, however if the abstraction can't lead to perf wins in its own right simply by making certain approaches more accessible/easier to maintain, like node.js's heavily event-driven paradigm. I think I can definitely see the appeal of glue languages in conjunction with lower level languages handling memory intensive operations. –  Erik Reppen Aug 12 '11 at 5:37
2  
@Erik: I'm not sure I'd even say that. Things change during development. Requirements can change, or you find that you're not implementing a requirement correctly, and the code needs to be updated. Being able to change one thing and use the resulting compiler errors to show you where to find everything else that needs to be changed provides a huge boost to convenience and speed of development that you lose in languages where that technique is not available. That's one of the reasons why you just don't see complicated apps developed in dynamic languages. –  Mason Wheeler Aug 12 '11 at 5:53
    
@mason-wheeler Well you do see complicated apps developed in SmallTalk, Python, Ruby, Clojure and Groovy. Admitted less these days in SmallTalk but it's not because it's dynamic. This feeling probably comes from the fact that there are a lot of other light weight scripting languages out there that are also dynamic (javascript, lua, vb). –  jbtule Aug 12 '11 at 12:35
6  
@Mason Wheeler: Very good answer.+1 I would add that static type checking also helps to find bugs earlier by having the compiler check type correctness. E.g. I debugged a 200-line Ruby program yesterday and there were two bugs related to type that I could only detect by running the program. I do not want to think what happens in a 100000-line project. So dynamic typing gives you more flexibility, which is good in the contexts you have described, at the price that you cannot find certain bugs at compile time. So statically typed is not only related to efficiency, but also to correctness. –  Giorgio Apr 21 '12 at 11:11
1  
@MasonWheeler Two years and a lot more C# and Java than I bargained for later I would now disagree with a couple things. Complex web apps are done entirely with dynamic languages. Compile vs. run time is meaningless when you can make changes that are visible immediately. And I've developed the opinion that all the fussing over types makes a lot more sense in a procedural language than it does in a language that's supposed to be driven by OOP where data shouldn't be changing hands constantly in the first place. –  Erik Reppen Jul 5 '13 at 21:13

They're different tools, but it's not by performance. It's all about complexity.

Dynamic languages usually aim maximum flexibility, and it brings lack of validation and a sort of guarantee. Then, it's very powerful in small scale programs, but it becomes almost impossible to maintain large scale programs (complexity).

Static languages usually aim maximum validation. Their first goal is usually catching errors (or bugs) as early as possible. Many guarantees are made for the validation. Then it's harder to learn and start, but as programs goes larger, it provides better program validation with far less cost (coding efforts).

As a result, dynamic languages usually fit for small (I mean very small) programs such as dynamic web pages, web browser DSL (not for browser applications!) or shell scripting. Static languages suit better for system programmings or any other stuffs.

Above descriptions are something about very purely dynamic or static languages. Most real-life languages are in between them, and shows various characteristics.

See here for more details: http://programmers.stackexchange.com/a/105417/17428

share|improve this answer
1  
"dynamic languages usually fits for small (I mean very small) programs": In my experience you can use dynamic languages also for middle-sized applications (and, of course, there are people using them successfully for large applications). I agree that the larger the code base becomes, the more you can profit from static checks provided by static languages. –  Giorgio May 4 at 10:00
2  
@Giorgio Well, that's maybe because I'm addicted on the static validation stuffs. It's so sweet to me, and I literally can't live without them even on small scale :p –  Eonil May 4 at 11:13
    
I see the advantages of static languages (and I have upvoted your answer). Recently I have been using Python and Common Lisp and I admit that in practice you get good results if you use a clean design and, especially in Python, if you write enough tests. These languages can be very effective to build a prototype that can then easily turned into your production code. But, yes, for the more complex projects I would like to have as much help as I can get, so I prefer a static language. –  Giorgio May 4 at 12:11

I currently program in static type languages (C# and F#), but I enjoy programming in dynamic languages (Smalltalk, Ruby). There are a lot of pros and cons that people associate with one type vs another that are more about the language than when you enforce types. For example, dynamic languages usually have a cleaner, more concise syntax, however F# and OCaml with their type inference system have as clean a syntax as any dynamic language. And with static typing, you have real automatic refactorings and autocomplete, but Smalltalk, with it's entire source code in a database and each method compiled separately, was the first language to really have serious automated refactorings, and it worked great. Ultimately, modern dynamic and static languages today are type safe, which is the most important aspect of your type system, and automatically testing for correctness is done by unit testing, which you'll be doing in both types of languages.

share|improve this answer
    
I have at times suspected that static typing is only a small part of the equation of what makes a language more or less flexible. I think what I'm also starting to realize is that a lot of devs prefer a comfy set of rails to guide them rather than having free reign to do absurdly dangerous things like overloading operators. VS makes me want to kick puppies sometimes but I've definitely been curious about F# and what you said about it has me even more curious. I assume this is something more than just the C# thing where you can cast to a more inclusive type implicitly. –  Erik Reppen Aug 12 '11 at 5:21
    
@erik, Oh yes more than implict typing and var: F# Type inference –  jbtule Aug 12 '11 at 12:40

The way I look at it is, if you can work naturally within a statically typed language, then static typing is the way to go. In general, the purpose of a type system is to prevent you from performing operations with undefined semantics - like (string) "hello" + (bool) true. Having the extra level of safety preventing you from performing these operations can be a good way to prevent bugs in your code, even without extensive unit tests. That is, type-safety provides another level of confidence in the semantic correctness of your code.

But type systems are very hard to get right. I don't believe there is a perfect type system in nature at the time of this writing. (By "perfect type system", I mean a strict type system, that doesn't require verbose code annotations, that generates no false-positive type errors, and whose type errors are easy for the programmer to understand.) Further, it can be difficult to understand the really good type systems that do exist. When I was learning Haskell, I can't tell you the number of obscure type errors that I got while attempting to write what looked (to me) like correct code. Usually the code wasn't actually correct (which is a point in favor of the type system), but it took a lot of work to understand the error messages from the compiler, so that I could correct the underlying problems. In OO languages, you may eventually find yourself thinking "this argument should be contravariant with the input type, not covariant!", or (more likely) reverting to typecasts to escape from the bounds of the type system. Type systems can get much trickier than you'd think.

For what it's worth, it's my understanding that the difficulty in coming up with good type systems is part of what motivated Gilad Bracha to include pluggable type-system support in Newspeak.

share|improve this answer
    
WRT unit tests, I completely agree. You always see people saying "if you have good unit tests, they can verify type correctness for you." That's always reminded me of how Paul Graham (who strongly believes that dynamic typing is always a good thing) says that a language making you manually do the compiler's work for it is a flawed language. Sorta makes you stop and think... –  Mason Wheeler Aug 11 '11 at 21:47
    
I think many of the concerns about the 'dangers' of dynamically typed languages fail to take in account how we write this stuff. Much of Python and JS can be written console-style. Screw compile vs. run-time, I can try it out right now and see what happens. I think you are on to one very good point, however. Nothing makes me crazier in client-side web development than when all the supposedly good browser vendors give a confusing pass on horrible code while IE6 or 7 does the unexpected, which is to crap out when it's supposed to rather than just, well... sucking in a more typical fashion. –  Erik Reppen Aug 12 '11 at 6:21
    
@mason-wheeler mismatch types are trival errors, and it's not that dynamic languages don't check the types, it's just at runtime. I'm my experience most static language's have the same level of coverage of unit tests, they aren't losing any tests from having the compiler check there types ahead of time, and dynamic languages aren't having to add specific tests to check types, the runtime system checks your types, if your unit test cover your method it would catch them. –  jbtule Aug 12 '11 at 12:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.