The Artima Developer Community
Sponsored Link

Weblogs Forum
Are Dynamic Languages Going to Replace Static Languages?

83 replies on 6 pages. Most recent reply: Aug 6, 2010 11:26 AM by Stephen Monette

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 83 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]
Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Apr 30, 2003 10:29 AM
Reply to this message Reply
Advertisement
> > It is interesting to me, however, that you attribute
> > your "conversion" as being a result of your adopting
> > test driven development.
>
> Color me skeptical about claims like "we'll catch it in
> testing." History tells me that when schedule pressure
> hits, things that don't HAVE to be done fall on the floor.
> With static typing you don't get the option to be sloppy
> and find typing errors at runtime (often in production.)
>
> And I don't ascribe this to the thoughtful developers in
> this forum, but there are many who just won't follow
> through on the testing requirement, even without external
> pressures. They want to get things out quick and move on
> to the next bit of fun.

Sounds like you're not getting the gist of the post.
The gist is that most errors aren't caught by static
typing anyway.

Richard Davies

Posts: 7
Nickname: richardd
Registered: Apr, 2003

Test-inferred typing/DBC Posted: Apr 30, 2003 11:34 AM
Reply to this message Reply
Hi,
Why can't unit testing be used to add type (and DBC) information to an application after compilation? Imagine the following scenario:

You're using a runtime-typed langauge like Python.
The build process goes something like this:
1. Compile application and unit tests.
2. The test framework checks which bits of the application have
changed and automatically generates the test suite.
3. Run all required tests with code coverage to detect which
methods/fields have been touched (updating each unit test's list of
dependencies as we go).
4. Analyse the test results.

At this step, if there are either a) Any test failures or b) Any method/field of the application that is not tested, the build fails at this point. If not, continue on:

5. Infer types based on testing

Every field and method in the application must have been tested by this point. The application can then be modified (bytecode or source code) with the types inferred during testing being added in. For example if field x was only ever assigned integers during testing, it is statically typed as an integer.

Range constraints could also be added. For example, if a method has only recieved integer values between 1 and 10 during testing, an "assert arg >= 1 && arg <=10" could be added as a pre-condition. Likewise, invariants and post-conditions can alse be inferred (eg method X can only return a list of 0-9 objects of type Y or Z).

When the application is functionally tested / used by an
external program, the failures will require more tests
to be written to more clearly define its behaviour (or
the calling application to be fixed - and it should
have a pretty precise error message).

Is this approach pratical? Does it exist?

Regards,
Richard

Dennis Doubleday

Posts: 3
Nickname: ddoubleday
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Apr 30, 2003 1:37 PM
Reply to this message Reply
> Sounds like you're not getting the gist of the post.
> The gist is that most errors aren't caught by static
> typing anyway.

There is no single feature in ANY language that catches "most" errors. Static typing catches a large subset of errors that happen frequently, and it catches them so early that the cost of those errors is really low.

Arnold deVos

Posts: 18
Nickname: arnoldd
Registered: Dec, 2002

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Apr 30, 2003 8:50 PM
Reply to this message Reply
> > But how would you find the call sites in a dynamicaly
> > typed language? For what string would you grep?
>
> Even in a dynamically typed language you can usually use
> something like grep to find what you're looking for.

[snip]

Hmmm. I am refactoring some code right now and grepping for a method of a called set() in objects of class Resource. I get too many false positives from all the other objects with a set() method for this technique to be any good. Grepping for class Resource does not help to find objects of that type either (this is in python).


>
> > Putting it another way: a static type system, for all
> the
> > effort it requires of the programmer, creates a static
> > dependency graph for the program. And this is useful
> in
> > analysis and refactoring.
>
> This is also possible at least in Python, tho it can be
> compute intensive and to some extent relies on observing
> points of call for usage.

Is it possible? I thought determining the control flow (hence dependencies) in this situation this was in fact theoretically impossible. That said, most of us was settle for something near enough that was practical (see Don Roberts smalltalk refactoring browser for example). What tool do you have in mind for python? Perhaps bicyclerepairman?

Arnold deVos

Posts: 18
Nickname: arnoldd
Registered: Dec, 2002

Re: Test-inferred typing/DBC Posted: Apr 30, 2003 9:00 PM
Reply to this message Reply
> Hi,
> Why can't unit testing be used to add type (and DBC)
> information to an application after compilation? Imagine
> the following scenario:

[snip]

> Is this approach pratical? Does it exist?

Yes I think this is possible. Something like it is discussed in Don Roberts thesis on the smalltalk refactoring browser. I can imagine instrumenting python through its tracing hooks to collect the information.

Perhaps it would work better than static analysis for python. There have been a number attempts at the latter over the years but it somehow has not taken off.

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 6:07 AM
Reply to this message Reply
I wonder if the problem is really static type checking or rather too primitive and not very capable type systems. When you change the type of a method parameter, there are times when you actually want the compiler to tell you all the places where the method is called and there are times when you don't want it. You do want it, if the method actually depends on the properties that the parameter type promises. But if the method just passes the thing through, it's useless to change it. Say you have:

m1(){
&nbsp;&nbsp;&nbsp;MyClass obj = new MyClass();
&nbsp;&nbsp;&nbsp;m2(obj);
}

m2 (MyClass obj){
&nbsp;&nbsp;&nbsp;m3(obj);
}

m3 (MyClass obj){
&nbsp;&nbsp;&nbsp;obj.getThisProperty();
}

Now imagine m3() changes some requirements, say it wants to call obj.getThatOtherProperty() and therefore changes the class of its parameter to be MyOtherClass. What I really want in this situation is for the compiler to tell me that m1() needs to be changed but it will also tell me that I need to change m2() although m2() only passes the object through.

So the reason why static typing is sometimes unproductive is not that it tells you about the places you really need to change for semantic reasons but that it tells you about lots of places where the code needs to change only to satisfy the static type checkers own needs.

Let's call the first case a useful service and the second case useless bureaucracy. What I want is the compilers service without the bureaucracy.

I don't agree that TDD solves all the problems with dynamic typing. Static types are not only useful for checking the correctness of a program. They also convey meaning to the reader of the code. When I come across a method such as this:

doSomethingWithAFile(file){
&nbsp;&nbsp;&nbsp;//...100 lines of complicated algorithm
}

How do I know if what is called for here is a File object, the name of a file or some kind of stream object, without reading through the source code of the whole method? There are three possibilities:

* The author of the method could choose better names. For example, he could call the parameter fileName, fileObject or inputStream. But that would mean to encode the parameter type in the parameter name which is an even worse form of static typing than we have in statically typed languages.

* The method documentation could make it clear. But then you'd have to read the documentation just to know the parameter types instead of just looking at a list of methods in a class browser or in a code help pop-up.

* The test cases show it. Same problem as before, it's cumbersome to do just to get such simple information. And then, where are the test cases for all the functions and classes that come with the Python library for example?

For me, source code of dynamically typed languages is easy to write but hard to read. I keep hunting for the places where objects are created to find out about their types.

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 6:10 AM
Reply to this message Reply
I wonder if the problem is really static type checking or rather too primitive and not very capable type systems. When you change the type of a method parameter, there are times when you actually want the compiler to tell you all the places where the method is called and there are times when you don't want this. You do want it, if the method actually depends on the properties that the parameter type promises. But if the method just passes the thing through, it's useless to change it. Say you have:

m1(){
&nbsp;&nbsp;&nbsp;MyClass obj = new MyClass();
&nbsp;&nbsp;&nbsp;m2(obj);
}

m2 (MyClass obj){
&nbsp;&nbsp;&nbsp;m3(obj);
}

m3 (MyClass obj){
&nbsp;&nbsp;&nbsp;obj.getThisProperty();
}

Now imagine m3() changes some requirements, say it wants to call obj.getThatOtherProperty() and therefore changes the class of its parameter to be MyOtherClass. What I really want in this situation is for the compiler to tell me that m1() needs to be changed but it will also tell me that I need to change m2() although m2() only passes the object through.

So the reason why static typing is sometimes unproductive is not that it tells you about the places you really need to change for semantic reasons but that it tells you about lots of places where the code needs to change only to satisfy the static type checkers own needs.

Let's call the first case a useful service and the second case useless bureaucracy. What I want is the compilers service without the bureaucracy.

I don't agree that TDD solves all the problems with dynamic typing. Static types are not only useful for checking the correctness of a program. They also convey meaning to the reader of the code. When I come across a method such as this:

doSomethingWithAFile(file){
&nbsp;&nbsp;&nbsp;//...100 lines of complicated algorithm
}

How do I know if what is called for here is a File object, the name of a file or some kind of stream object, without reading through the source code of the whole method? There are three possibilities:

* The author of the method could choose better names. For example, he could call the parameter fileName, fileObject or inputStream. But that would mean to encode the parameter type in the parameter name which is an even worse form of static typing than we have in statically typed languages.

* The method documentation could make it clear. But then you'd have to read the documentation just to know the parameter types instead of just looking at a list of methods in a class browser or in a code help pop-up.

* The test cases show it. Same problem as before, it's cumbersome to do just to get such simple information. And then, where are the test cases for all the functions and classes that come with the Python library for example?

For me, source code of dynamically typed languages is easy to write but hard to read. I keep hunting for the places where objects are created to find out about their types.

Levi Cook

Posts: 8
Nickname: levicook
Registered: Feb, 2002

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 11:52 AM
Reply to this message Reply
> But how would you find the call sites in a dynamicaly
> typed language?

If you've truly stuck with TDD, then you simply run your tests, and watch your 100% of your out-of-date callers fail.

Chad Harrington

Posts: 1
Nickname: harrc
Registered: Feb, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 3:15 PM
Reply to this message Reply
> I have kind of been kicking around the
> idea of developing a "system" in Python, but haven't tried
> it yet. I won't really know how I'll feel about building a
> system with a dynamically typed language until I actually
> try that.

And that is exactly what you must do.

For two years I used Python as you have described in your commentaries: as a nice scripting language, but not using OO features or multiple files, and not for "system" development.

Then I stumbled into a large system project that seemed to require Python for a couple of key components that needed to be user-scriptable. I decided to try writing it all in Python and see how far I got. That is when my programming life changed. I can't overestimate how much developing a 3-tier, multi-user, distributed application in Python changed my perspective. In about 7,000 lines of Python code I created a very complex data collection and analysis system that would have taken (based on experience) ~50,000 lines of C++ or maybe ~30,000 lines of Java. The development was so much faster, more intuitive, and closer to the user domain.

Python also gently introduced me to using functional programming in a real-world program. Using Prolog or Scheme is kind of fun, but it's hard to interface with real-world toolkits, etc. Python's slight functional slant encourages using functional paradigms in domain-specific areas where they make sense, while still having the flexibility and toolkits of a widely used procedural language.

I always planned to replace any slow modules of the system with C++ extensions, but I never found any that merited it. I did write a C++ extension for doing threaded serial port access, since I needed more than Python's platform-independent threading library could provide.

A poster to comp.lang.py recently said something to the effect of, "Programming in C++ is premature optization." I couldn't agree more.

So, please write your next large system in Python. It will change your life.

Chad Harrington

Kent Frazier

Posts: 2
Nickname: ksf
Registered: Feb, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 4:56 PM
Reply to this message Reply
Strong typing, in addition to providing a "type" also serves to "explicitly define" a variable name. While it would be possible to "explicitly define" without "typing" in a language, languages like python (still my favorite to program in) with its implicit "define" makes it extremely easy to define new variables by mis-typing, which can be a difficult bug to find on occasion.

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 4:59 PM
Reply to this message Reply
> Strong typing, in addition to providing a "type" also
> serves to "explicitly define" a variable name. While it
> would be possible to "explicitly define" without "typing"
> in a language, languages like python (still my favorite to
> program in) with its implicit "define" makes it extremely
> easy to define new variables by mis-typing, which can be a
> difficult bug to find on occasion.

I hope you're aware of PyChecker -- a 3rd party tool
that finds such errors quite reliably.

Adriano Rodrigues Ferreira

Posts: 2
Nickname: arferreira
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 8:57 PM
Reply to this message Reply
"I don't believe that there's a Smalltalk program of comparable size to the Eclipse project."

I think a Smalltalk environment is comparable to the size of the Eclipse project. It is without a doubt comparable to the size of Java SDK with a lot more of functionality. There are debugging aids to find all callers of a method and a bunch of possibilities that would dazzle new programmers who think Java is one of a kind. All that "new" features date back to 1980 and have been rediscovered thanks to advertising campaigns of very rich companies (Sun, IBM, etc.). Not that Xerox was not rich enough, but it seems like it never believed what its researchers produced. The adoption of Smalltalk is more a social issue than technical: too much mentors were entrenched with conventional programming techniques and languages to spread the word. But OO now is here with a growing share for dynamically typed languages.

Dynamic languages do need to replace static languages: while static typing fits the mind of many excellent programmers and untyped programming means productivity for other, also excellent, developers, they can coexist and even work together. For instance, code generators written in dynamic languages (like Perl) can produce lot of almost perfect codes in static languages: dynamic works on metadata (for flexibility) and static does the final job (for performance). I just don't think easy to reverse roles here: static languages generating dynamic language code with advantages.

Adriano Rodrigues Ferreira

Posts: 2
Nickname: arferreira
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 1, 2003 9:00 PM
Reply to this message Reply
Oops! The first phrase of second paragraph should be: "Dynamic languages do not need to replace static languages:"

Antonio R. Rodriguez S.

Posts: 1
Nickname: tonin
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 2, 2003 3:11 AM
Reply to this message Reply
I have the same feeling like the author. I've made a similar experiment with Python and test driven development. I'm convinced that static type checking is'nt necessary, if we replace compilation through a test suite (a good one) run.

Tonin

Daniel Yokomizo

Posts: 22
Nickname: dyokomiso
Registered: Sep, 2002

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 3, 2003 1:53 PM
Reply to this message Reply
Although I agree with you that sometimes these issues are a problem, I believe they are signs of sloppy design/language. There are three primary issues here:


1. manifest typing
2. error handling
3. class dependencies


[1] is a pain in Java, but other static type systems (e.g. Haskell, O'Caml, even Eiffel with 'like' qualifiers) can reduce it considerably with type inference. But if you're changing a function argument's type in incompatible ways (e.g. changing from a pair of dates to a date + a amount of days), the type system helps you.


[2] can be a mess to deal with. Recently I did some J2EE/JCA modules, and the error propagation issues sucked, in the end we put everything under the ResourceException label. After that I did some asynchronous distributed programming and the checked exceptions helped me verify where I wasn't dealing correctly with the error conditions. These are very tricky to test (and I a huge fan of TDD, use it everywhere I can), but the compiler can pinpoint all the possible crash sites automatically. Of course we can improve enormously over Java's exception mechanism, but it still is nice to have sometimes.


[3] is inevitable, IMHO, if we design without paying attention to the dependencies (basically ignoring everything your articles talk about). Otherwise we can narrow the dependencies to high-level interfaces and get away with it. Manifest typing can slow us down here, but it's a problem of some type systems, not static type systems per se.


Static typing is a mess with we only know the C++/Java/C# way of life, but once we know about richer type systems things are different. I don't think dynamic languages are going to replace static languages, but today's static languages will evolve to better type-systems, narrowing the gap between static and dynamic typing.

Flat View: This topic has 83 replies on 6 pages [ « | 1  2  3  4  5  6 | » ]
Topic: Have Generics Killed Java? Previous Topic   Next Topic Topic: Adding Optional Static Typing to Python


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us