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.

I have read some articles about Dynamic typed languages and Static typed languages. They said dynamic typed languages are more expressive than statically typed. But they didn't show that using a code example.

Is there any clear code example to show that this code is implemented in a dynamic typed languages and it can not be implemented using any statically typed languages.

Can anyone give a code example to show that...

share|improve this question
    
The code I can think of that's not expressable (without Boost::Variant-esque trickery taken up to eleven) in statically typed languages isn't very good code in dynamic languages either. However, much perfectly fine code I write in dynamic languages requires additional boilerplate (varying amounts, depending on the task in question) to be typed statically. –  delnan Apr 14 '11 at 16:54
    
There are plenty of terrible dynamic languages (e.g. Basic variants), and excellent statically-typed languages (C++, SML and friends, Haskell). –  Marcin Apr 14 '11 at 21:28
1  
I think the first prerequisite for real answers to this would be a definition of "expressive". Without that, almost any answer is likely to really boil down to, "I like this better than that." Unfortunately, with a definition, it's likely to boil down to "I [dis]agree with your definition of expressive." To a large extent, it's likely to come down to a question of "What do you want to express?" –  Jerry Coffin Apr 15 '11 at 5:06
    
@Jerry And we have such a definition of "expressive" - see Felleisen's On the Expressive Power of Programming Languages. –  Frank Shearar Apr 15 '11 at 13:46
    
@Frank Shearar: I've seen it -- while it is a definition (sort of, anyway), it doesn't seem to be particularly widely known or accepted. If the OP wants to use it, he probably needs to link to it explicitly. –  Jerry Coffin Apr 15 '11 at 14:11
show 1 more comment

migrated from stackoverflow.com Apr 15 '11 at 5:01

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

8 Answers

[Moving my answer from the other question]

Is there any clear code example to show that this code is implemented in a dynamic typed languages and it can not be implemented using any statically typed languages.

I highly doubt it. Technically speaking anything one Turing complete language can implement can be done by any other Turing complete language. That's also a misrepresentation of the argument. The argument is that dynamically typed languages can be more expressive, to which I can only suggest that you look at code with similar functionality in various languages and make up your own mind. Rosetta Code is a good resource for this.

That said, I suspect that this question is far too subjective and contentious to admit of many good answers.

share|improve this answer
add comment

It isn't a fun example but dynamic coding makes it much easier to do stuff like COM interop because of the insane typing otherwise used

A more interesting example is simulating things like multiple dispatch in languages that not support them per se: http://blog.martindoms.com/2011/01/04/collision-detection-the-oo-way-with-c-multiple-dispatch/

share|improve this answer
    
I gather this is one of the major drivers behind adding the dynamic feature to C#. –  Steve Haigh Apr 28 '11 at 10:16
add comment
giraffe = new Giraffe()
giraffe.quack = function()
    { echo "Quack! I am a duck!" }
...
if (object.quack)
    object.quack()

This is why dynamically-typed languages are also called duck-typed ("When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.") although strictly speaking dynamic and duck typing are not the same thing, but are present in many languages simultaneously.

Not that duck typing is impossible to imitate in static languages, but such imitation wouldn't be as elegant and expressive.

The downside of duck/dynamic typing is that in most cases you'd expect quack() to be defined within a given object, but dynamic languages generally can not guarantee you that. Making checks (if (object.quack) ...) is costly, and calling quack() without checks is, strictly speaking, unsafe. In big projects, a change made elsewhere in a project can unintentionally result in a crash in some other part of a program at run time.

Edit: besides the Turing-completeness argument, there is another, simpler one: any dynamically typed run-time system in the end is implemented using a statically typed language, typically C. So there is nothing that's impossible in static languages, the only question is the price you pay and elegance of the code.

Edit: (since I am not allowed to comment): The above is not true, since machine code is mostly untyped. The gist of it is correct, though, as you can implement an interpreter for any Turing-complete language in any other TC-language.

share|improve this answer
1  
Thanks for pointing out the need for if(object.quack). It's one example, but by no means the only one a person could come up with. I find that that small amount of keystrokes saved by not annotating type is more than consumed by all the runtime sanity checking required to make sure the program runs correctly. –  scriptocalypse Apr 15 '11 at 13:56
    
This is not exactly what I'd call a "concrete example". –  Robin Green Apr 15 '11 at 18:13
    
Its probably worth noting that the above could be done with a statically typed language using inferred structural typing. The type system could see that the object is having it's quack method called and make sure that any objects passed in have such a method defined. Haskell's type classes come close to this, but it's entirely possible to move one step further to full structural typing removing the need to define even type classes. –  RHSeeger Apr 23 '11 at 5:23
    
Scala (which is statically typed) has the ability to express, for example "any type which has a 'close()' method," which is essentially duck typing done safely. A Scala type may also be marked Dynamic, meaning that what appear to be method invocations to nonexistent methods are allowed (i.e. are translated to calls to special handler methods). These are direct analogues of features generally associated with dynamic languages. –  AmigoNico Jun 27 '13 at 3:36
add comment

While the Turing tarpit is unavoidable (by which I mean "any language can perform the actions of any other language with sufficient expression parts"), statically-typed language implementations can reject correct (perfectly functional) programs which are not well-typed, whereas dynamically-typed language implementations will accept them, only rejecting when an actual live error occurs.

share|improve this answer
    
By error, do you mean bug? If an actual live error occurs in the sense of a bug, then obviously the code was not correct in the first place, no matter how functional it may have been 99% of the time. –  Robin Green Apr 15 '11 at 18:11
    
I was trying to use the precise technical term. Some errors arise due to faults in program logic. Others might arise due to external conditions not originally foreseen in the construction of the source expressions. Even a well-typed Haskell program which uses files that the underlying OS maps to a network file system can have a related runtime error that is debatably a bug. –  Brian T. Rice Apr 26 '11 at 1:31
add comment

I suggested the question to be moved to PSE because, as @Pete says, you'll get more and better answers there.

Normally, you can write many less lines of code when using dynamically typed languages, and that in itself has many benefits besides saving developer time. Dynamically typed languages tend to be more expressive, so you can say more, and say it more clearly, with less text.

The important discussions about typing systems (mostly about scalability and stability) are over projects that require large teams or several teams working for several months to be completed, or about maintainability once the original teams handed the project to maintenance.

Static typing is, among other things, a form of enforced documentation, and that is a good thing to have when you need to approach source code that nobody has changed in a while. Static typing may guide you about the rules you must know to change what you need to change, while a most systemic understanding may be required to change a program with dynamic typing.

Note the may, may, may in the above. It is because in the end it all depends on the design and the modularization. My own preference is for languages with inference of static types, because allow the style of coding dynamically-typed languages do, with the safeguards of static typing, but very few mainstream languages do that.

share|improve this answer
add comment

Is there any clear code example to show that this code is implemented in a dynamic typed languages and it can not be implemented using any statically typed languages.

I highly doubt it. Technically speaking anything one Turing complete language can implement can be done by any other Turing complete language. That's also a misrepresentation of the argument. The argument is that dynamically typed languages can be more expressive, to which I can only suggest that you look at code with similar functionality in various languages and make up your own mind. Rosetta Code is a good resource for this.

That said, I suspect that this question is far too subjective and contentious to admit of many good answers.

share|improve this answer
add comment

I would have a look at a framework like Ruby on Rails which makes use of the dynamical abilities of Ruby and the fact that you can add new methods to objects at runtime.

As a result you get a kind of seamless integration of your whole environment (Database, Plugins) into the language, enhancing it's features instead of being something "external" that needs to be queried via an interface.

just as one simple example: If I do an SQL query in a language like C++, I need to "ask" the resulting object for the value of a single field from a user table:

QSqlRecord myUser;
QVariant someValue = myUser.value(5);

It doesn't even know anything about the fields names and needs integer indices.

Rails has the ActiveRecord object, which simply is enhanced with methods that resemble the field names, so we can just write my_user.name

If those users have many phonenumbers in a second table, a simple

has_many :phone_numbers

and from there on I can use it like this:

my_user.phone_numbers.each do |phone|
    <%= phone.number %>

(Which would print a list of a users phone numbers)

I don't say, that it's impossible to do this in other languages or that it's the better solution in any case, but it allows for very terse end expressive code, that often enough is very near to natural languages

share|improve this answer
add comment

In a dynamically typed language the definition of a variable depends on the path used to reach it. This adds an order of complexity to the definition. You have to consider all possible paths in order to maintain the code.

IMHO, dynamically typed languages are good for getting something up and running very quickly. But they are more prone to bugs, and so are not good for large complex operations. If I need to get a web page up in a hurry I'll write the HTML myself. If HTML can't handle it, I'll use PHP. But I would not want to run a major project in PHP; Java is more bug-resistant.

So any SHORT example should show that a dynamically typed langauge is nice, but those languages tend to break down in very long tasks.

share|improve this answer
    
A lot of big sites are built with Ruby, which is a dynamic language. A few examples: Twitter, Basecamp, Scribd, Github, ... More examples: storecrowd.com/blog/top-50-ruby-on-rails-websites –  Kristof Claes Apr 15 '11 at 6:23
    
I think it's worth noting that a lot of "big" sites have lots of users, but are fundamentally extremely simple. Twitter, for example, has a huge number of users, but is fundamentally a pretty trivial system. Admittedly, scaling becomes non-trivial, but you don't have to work very hard to describe virtually all its behavior in a sentence or two. –  Jerry Coffin Apr 15 '11 at 14:17
    
Actually Twitter is moving away from Ruby, anyway. –  Robin Green Apr 15 '11 at 18:17
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.