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.

Area there any major architectural differences when designing applications that will be built on static languages (such as C# or Java) and dynamic languages (such as Ruby or Python)? Wich are the design possibilities that might be a good choice for one type that's a bad one for the other? Are there any useful features achievable with one type that's not with the other (in design and architecture, of course)?

Finally, are there any good resources on the subject of the differences, or to specific design/architecture for dynamic languages?

EDIT: It just came to my mind now: are there any dynamic-specific design patterns?

share|improve this question
1  
Whatever those architectural differences are, the dynamic languages - IronRuby and IronPython - easily compliment .Net's static languages. –  IAbstract Sep 1 '11 at 21:38
2  
I'm not certain, but if metaprogramming is easier in the dynamic languages (it sure seemed easier in Ruby than Java, the last time I looked), that might have an influence on architecural decisions. I'm not sure what kind of influence because I've never really worked on anything that big in these dynamic languages. –  FrustratedWithFormsDesigner Sep 1 '11 at 21:56
add comment

4 Answers

up vote 10 down vote accepted

Let's get a few things straight:

  1. Interactive scripting and static languages aren't mutually exclusive. F# and Haskell both have REPL interfaces.
  2. Dynamic languages and high performance aren't mutually exclusive, though some optimizations are. JavaScript runs pretty damn fast on most browsers nowadays.
  3. Even in dynamic languages, you still need to document, remember and think about types.
  4. Due to the increasing popularity of type inference, a lot of static languages don't have to notate types very often anymore. In static languages with strong type inference, the compiler figures out what the types are from your code so that most of the time, and tells you if you ever do something that violates the type definitions. As far as syntax is concerned, this provides the best of both worlds.
  5. OOP and dynamic languages aren't mutually exclusive. PHP now supports classes and even inheritance.

All those surprising similarities aside, there are some practical differences that do influence the development process:

  1. Dynamic languages allow for interesting ways of passing data around in the small.
  2. Static languages allow you to reduce the amount of testing you have to do by making many kinds of bugs impossible.
  3. In that same vein, static languages allow interesting validation and automatic conversion features, like units of measure in F#.
  4. Taken to the extreme, static languages allow for code contracts and formal verification, which can document and flat out prevent things like potential divide-by-zeros, infinite loops, null references, invalid list sizes or indices, range errors and other logically invalid state that you might define.
  5. Taking that extreme even further, CPU optimizations can be made based on these static constraints, which yields even better performance.

There is also one type of program that could never have been made without static typing: Singularity, an OS without hardware process boundaries. It's written in a small amount of C, some C#, and a dialect of C# called Spec#, which supports code contracts.

Despite being written in a garbage-collected language, multitasking and interprocess communication performance on this OS is in fact better than anything else out there, due to the fact that all the processes run in one memory space, and due to the formal verification optimizations I mentioned above. You couldn't do this without static typing, because in order for programs not to be able to compromise the rest of the system, the communication objects need to be statically verifiable.

Most of the time, though, architectures should look very much the same. Static languages may make programs easier to reason about in many cases because the types are well-defined, but a well-written dynamic language program would also have types that are, at the very least, well-defined in the developers' minds.

share|improve this answer
add comment

Are there any major architectural differences when designing applications that will be built on static languages (such as C# or Java) and dynamic languages (such as Ruby or Python)?

No.

It's slightly easier to write fancy frameworks for dynamic languages. But that's not an application thing.

Which are the design possibilities that might be a good choice for one type that's a bad one for the other?

None, really.

You can write good things in either kind language.

Are there any useful features achievable with one type that's not with the other (in design and architecture, of course)?

No.

The difference is that dynamic languages are "write, run, fix". You can experiment and fix quickly.

Static languages are "write, compile, build, run, fix". You can't experiment as easily.

Other than that, they're nearly identical in their capabilities.

Are there any dynamic-specific design patterns?

Maybe. The Python eval() and execfile() functions -- in a way -- point up a dynamic language feature that's difficult (but far from impossible) to handle in a static language. It would be a lot more lines of code to compile and execute code in the same process space.

It's not dynamic-language specific. It's just easier.

share|improve this answer
    
"You can't experiment as easily."-- True, the tradeoff being that the compiler helps you find errors whereas with interpreted languages you may not find an error until a user executes that line of code. –  Doug T. Sep 2 '11 at 2:19
3  
@Doug T.: "compiler helps you find errors". Sometimes. Not often enough. The interesting errors can't be found by a compiler at all. That's what unit testing is for. –  S.Lott Sep 2 '11 at 2:21
    
@S.Lott I find that APIs written in dynamic languages require a bit more documentation. In a static language, the method signature tells you what types of arguments are required. In a dynamic language, you can't tell as easily - the API documentation has to tell you what objects are expected. –  quanticle Sep 2 '11 at 2:52
1  
@quanticle: That's not really architectural, is it? –  S.Lott Sep 2 '11 at 2:54
    
"You can't experiment as easily." -- F# and Haskell are both static languages, and they have full-fledged REPLs, and seldom ask you of an identifier or expression's type. –  Rei Miyasaka Sep 2 '11 at 4:16
add comment

I have never thought along these lines. So when did a Google, Peter Norvig's blog was one of the top hits. It says some design patterns are easier to implement in dynamic languages than traditional object oriented languages such as C++. I think there should be differences at design/architecture as well since he notes that implementation is easier in dynamic languages. I will try to add more to the answer as I study further.

share|improve this answer
add comment

There is a significant architectural difference. Performance.

Depending on your hardware budget, expected workload and service level agreements it might not be possible to meet the requirements with a dynamic language.

Most often the speed of development and flexibility provided by dynamic languages offset the slower response times higher cpu and memory consumption. But for larger systems with budget or performance constraints the overheads of a dynamic language can be high.

share|improve this answer
add comment

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.