Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are using PHP (a dynamically-typed language) in our project. However, I have found my colleagues asking questions such as

I’m feeling like we have a paranoia that we are going to get unexpected errors (E.G. if you look at that example question, you will see that the poster is asking how to ensure that a like does not get initialized for a Person), and we are using static-typing (something that doesn't exist in PHP) along with unit tests to help ourselves rest easy at night. :-)

Now, the thing that tells me our approach is wrong is the number of big websites written using dynamically-typed languages: Google uses Python extensively, Facebook is written using PHP, Twitter and GoodReads are written using Ruby. So what I feel is that web applications—at the very least—are moving toward dynamically-typed languages.

However, no matter how I try to comprehend this, i can’t. Don’t these guys have trouble comprehending the domain? Don’t they have problems that arise when using dynamically-typed languages (E.G. “Property whatever is not defined on this object.”)? If they do, how do they deal with those while keeping the agility that comes with using dynamically-typed languages?

share|improve this question
In addition, I see a lot of science-related projects using Python, what I feel unsafe for runtime, undetectable errors. How is this managed? – aldo.roman.nurena Dec 7 '13 at 7:30
Those websites don't necessarily use dynamic languages exclusively; I have a friend at Facebook who is working on a team that develops in Haskell (a very statically typed language). – KChaloux Dec 9 '13 at 20:18
up vote 2 down vote accepted

how do they deal with those while keeping the agility that comes with using dynamically-typed languages?

Many people would argue if you really want to be agile (i.e. comfortably change your code often), you need unit testing.

Relying on the compiler to make sure: 2+2=Number is really just a false sense of security. So if you're going to take the trouble to write a unit test, why not be a little more accurate and test: 2+2=4?

With Domain Driven Design, you're dealing with much more complicated problems and objects (That's typically why it is used.) that will barely be managed by type checking alone. Consider writing some tests.

share|improve this answer
I'm not sure if I'm disagreeing or what but a good type system can capture lots of domain logic if developers wield it right. E.g. Scala can capture in its type system lots of what you should imperfectly implement in Unit Tests in PHP. I believe OP is asking since PHP lacks such a type system, how the domain constraints (and domain logic in general) are captured in an assuring way? As I understand it you say "Unit Test is enough". Right? – ashy_32bit Dec 8 '13 at 11:48

You're over-thinking the differences between interpreted and compiled languages, and not really realizing the benefit of dynamic object creation and object oriented design.

Assuming that you had a situation similar to the question linked, where a user could like a Business but not a Person, you would be better off not allowing a direct instantiation of a distinct Like object, but instead making the execution point a method on the Business object.

That is, instead of:

//Like a business
$thisBiz = ...;
$myLike = new Like[$thisBiz];

You could have:

//Like a business
$thisBiz = ...;
$myLike = $thisBiz.Like();

If a latter programmer tries calling a method of an object that doesn't possess it, they'll get a runtime error, and a good IDE will catch it at design-time as well. Which is exactly what happens in a compiled language with static types.

The real power of dynamic typing is when you want to make a change to how things work. If Like is an object that takes a business as a parameter, and you want to allow people to be liked as well, you may wind up having to make a second Like constructor, or even a separate class, or even redefine it to accept a Thing parent that both Businesss and Person can be CAST to. Or you could just add the method to the Person class and be done with it.

share|improve this answer
The thing is, I can’t understand the difference of adding a second constructor versus adding a method to the Person class. The methods would likely be just as long, but in different classes. Plus, this method will render the Like class very thin, and every class that can be liked will have to have a like() method which does the same thing — right? – Parham Doustdar Dec 7 '13 at 8:39
notice: I am not a PHP expert. This sounds more like a domain modelling problem than dynamic vs. static typing. Go over your SOLID principles and see how the domain verb "Like" could be best modelled. If you decide Like will be a method on Likeable types, then you might want to define an ILikeable interface that these types implement. – MetaFight Dec 7 '13 at 10:55

Your Answer


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.