Architectural differences between dynamic and static languages

Question

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)?

Which 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)?

Also, are there any dynamic-specific design patterns?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.