How do you program differently in dynamic languages?

Question

How would someone who really knows how to take advantage of dynamic programming languages approach programming differently than someone working in a static language?

I'm familiar with the whole debate over static versus dynamic typing, but that's not what I'm getting at. I'd like to discuss problem solving techniques that are practical in dynamic languages but not in static languages.

Most of the code I've seen written in dynamic programming languages isn't very different than code written in static programming languages. As the saying goes, you can write FORTRAN in any language, and many people do. But some people use dynamic programming languages to solve problems in a way that wouldn't easily translate into, for example, C++. What are some of their techniques?

What are some good resources that discuss how to use dynamic programming languages? Not books on language syntax or API reference, but resources on problem solving approaches that take advantage of dynamic language capabilities.

EDIT (1/5/2009): I appreciate the answers below, but they don't seem to account for the huge increases in productivity that dynamic language advocates say they experience.

Shipman

For what its worth, I wrote a post on the subject of dynamic vs static typing idioms: #407260 – Soukup

Great question +1! too bad it resulted in lackluster and uninteresting answers. – Viki

Answer 1

I like slim's answer. I do spend a crazy amount of time in Java and C++ crafting custom data structures that are just free in Python/Ruby. And crafting specialized functions to process these custom data structures. Yes, in C++, STL is really nice. Yes, Generics in Java are nice. They help create custom data structures much faster, however they still require a lot of thought and consideration.

However, there is a more fundamental reason why dynamic languages are easier to work with. It is a deep idea which is called duck typing. Some comments above refer to duck typing, but please take time to reflect on what duck typing is. It is a fundamentally different way to view the world. A view that is incompatible with languages like Java and C++.

Duck typing means that you waste not time in defining what a duck is. By not having to formally define your objects you save a lot of time and energy. Getting definitions right is hard. Have a look at this blog post of mine where I give examples: Formal definitions are less useful than you think

Duck typing has proven extremely useful. The "Must Ignore" principle in XML is what has made XML so significant and useful on the web. But that's just an instance of duck typing.

Another way to express duck typing is by the Web mantra "Be strict in what you send, generous in what you accept". That is also a very fundamental idea.

Finally, you may want to back to a long blog post of mine where I explain duck typing and how it relates to things like AI and modelling: Duck Typing, Artificial Intelligence and Philosophy

Hogen

Duck typing != dynamic typing. OCaml's structural typing is one of the underappreciated gems of the language, its more or less "duck typing for a statically typed language". You have to keep reimplementing data structures in Java and C++ because those languages have a really lousy type system (seriously, generics in Java is so as-if). See en.wikipedia.org/wiki/Structural_type_system – Soukup

Answer 2

One way I typically find myself taking advantage of dynamic programming languages is in simplifying and clarifying syntax. If I'm representing a database, for example, the syntax I use for interacting with it can be much cleaner if I can dynamically load properties and methods on the database object for its tables, the tables and rows for their columns, and so on. The difference might be between:

$row = $db->getTable('user')->getRow(27);
$row->setValue('name', 'Bob');

and

$row = $db->user->getRow(27);
$row->name = 'Bob';

The 'visual noise savings' of the second form really starts to add up when you're doing complex things.

Sandman

Answer 3

Dynamic Languages can change the object at run time, you can add methods, properties...

One good example of Dynamic Languages magic is this Groovy code snippet which call a method on a webservice in just two lines of code:

def proxy = new SoapClient("http://localhost:6980/MathServiceInterface?wsdl");
def result = proxy.add(1.0, 2.0);

This is another Groovy snippet that extract data from XML:

def contacts = new XmlParser().parseText("<contacts><name>Bahaa Zaid</name></contacts>");
def myName = contacts.name[0].text();

You cannot do this in Static Languages. Dynamic Language can change the objects to reflect the actual runtime condition.

Furrier

Answer 4

I think the most dramatic difference in choice of data structures.

In Java or C I define structs or classes very strictly. If I need to add a property, I go back and change the definition.

In Perl I'll just use a hash, and 'invent' keys as I code.

Refuge

Were it not for the strict typing in C++, it'd be trivial to do that with an STL map. – Ariel

Likewise, in Java you could use a HashMap - but it wouldn't be a good idea. Type checking is a friend. You sacrifice it in Perl in exchange for rapid prototyping and syntactic sugar. – Refuge

@slim: Having worked extensively in both C++ and Perl, I dispute that type checking is a friend. At least as it exists in C++. – Ariel

Answer 5

In dynamic languages, I'm more experimental. It's easier to change things on the fly, so I can explore solutions faster.

If I know what I want to do, and generally how to do it, I like C++. If I don't know how to do what I want to do, and likely am not entirely sure about what I want to do, I much prefer Lisp.

Fibril

Answer 6

Fast iterations make happier programmers, and they don't come any faster than an interactive interpreter. Good interpreter exploitation gives you sandbox, testing, and prototyping at the same time.

Beware programming by permutation, however. My personal rule of thumb is that it's just because it works doesn't mean it's ready, when you can explain why it works it's ready.

Abdominous

Note that Scala which is statically typed indeed has a REPL! – Dement

Answer 7

My biggest gains are in mapping between databases and objects (ORM).

If there is no concept of a type, it becomes very easy to say assign every column in a row to a value in an object. Of course the trade off is that there can be a mismatch between the type of value you think is there and what type the computer does.

Boult

Answer 8

It comes down to one of my favorite ratios: How much time I spend thinking about solving a problem, vs. how much time I spend thinking about the tool I'm using to solve the problem. Think of it as equivalent to S/N ratios.

With duck-typing languages (which I consider to be the factor that helps me the most with productivity), I simply am able to spend more time thinking about my problem and its solution (and write code that addresses those specifically), and I spend less time keeping the language artifacts straight.

Then there's a lot of code I just don't write, involving declarations and especially type-casts.

But it's mainly keeping my focus in the sweet spot.

Drummond

Answer 9

I can't cite this right now (my memory is failing me), but I've heard something along the lines of:

The closest the programming industry has come to a silver bullet is managed languages – freeing the programmer from having to worry about the details of memory management and letting them focus more energy on solving the problem at hand.

So, I might venture a guess and say it's not so much that you program differently, it's that you can devote more of your brain to "solving the problem" rather than the solution's implementation details.

Zomba

Answer 10

More libraries and more important more useable libraries.

My guess is that the "Duck Typing" usually associated with dynamic languages helps simplify the code significantly and makes writing generic code much easier. You are not constrained by a strict class hierarchy and thus are able to more easily compose components from different libraries together.

Semanteme

Answer 11

John, just based on your update edit of 1/5/09, you might find AMOP an interesting read, and more on the line you're thinking of. It's pretty lisp-centric, but after all many of the good dynamic ideas started there. So if you can enjoy (or get past) that aspect, the authors do discuss the dynamic aspects needed and used to do something like this. It's pretty powerful stuff.

Dodecahedron

Answer 12

I do not have a specific answer, just a suggestion: have a look at the book "Design patterns in Ruby" : it goes over most of the classic design patterns (à la Gamma et al., and more) and express them, quite succinctly, in Ruby :)

Countess

Answer 13

Read "Higher Order Perl" by Mark Jason Dominus. It only discusses Perl but it does give techniques that are natural to Perl that would be less natural in most static languages.

All languages obviously have their strengths and weaknesses and dymanic vs static 

is only one of many ways to classify a language. I would not make the argument that dynamic languages as a whole are better or worse then static languages. But I do think this book is very good at showing different ways of approaching problems using Perl that would be more difficult or impossible in most Static languages.

Muezzin

Answer 14

Dynamic languages are capable of executing code which was created at run-time. This is very dangerous if malicious code is injected. But very powerful if you can sanitize the environment.

I think Javascript people do this by executing JSON files.

Murther

Programming languages aren't that black-and-white. I can easily execute code that is created at runtime with C#... However that is neither good practice nor is C# normally considered an especially dynamic language. Python code rarely does this, even though it easily allows this, yet even Haskell provides a dynamic interpreter prompt, and haskell is a far more static language than most. – Repeal

Answer 15

For me it's turnaround speed. The dynamic languages I use (Python and a bit of JavaScript at the moment) are interpreted. This means I can try things out on the fly. If I want to see how a certain bit of the API behaves I can just hack away at the interpreter for a couple of minutes.

If I wanted to do the same in a language like C# I'd have to fire up VS, make a project, then compile it. If I want to test a part of a bigger piece of software I'm working on I probably have to compile that, which can take ages. Fortunately in .Net I can load up assemblies from the big project in IronPython and get some of the same benefits (i.e. quickly testing out different parts of the API) of interpreted languages.

Cleodell

REPL != dynamic typing. Case in point: I prototype all of my F# code in the F# top-level, and I like to use the Haskell Prelude to test my Haskell code. – Soukup

I did give the caveat that it's the dynamic languages I use. I could be wrong, but dynamic often seems to go with interpreted. – Cleodell