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 | » ]
Paul Martin

Posts: 1
Nickname: pmartin
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 13, 2003 2:20 PM
Reply to this message Reply
Advertisement
Do you end up moving many tests from unit tests to system/integration tests if you have no static typing?

For example, if you have a Server class that uses Customer class objects:

- the Customer class can be unit tested in isolation
- but the Server class must be tested with Customer objects. To avoid effectively system testing here, you might use 'mock objects', effectively using a MockCustomer class instead.

But if you don't have static typing, how do you know that the Customer class actually supports the methods that the Server requires without testing the system as a whole? Wouldn't this degenerate in large systems? And isn't such system testing necessarily harder to do because there are so many combinations of test conditions?

Perhaps loosening the constraints of static typing, so that the checks are only 'like a' (i.e. supports the methods, but isn't necessarily derived from) instead of 'a kind of' might increase flexibility. Likewise, making static typing optional, with the idea that static typing is required at the 'component' (public API) level, and only gradually introduced elsewhere.

If you are going to document the interface anyway, then put it in the code!

Markus Gaelli

Posts: 2
Nickname: markusg
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 13, 2003 2:57 PM
Reply to this message Reply
> I can't see TDD as a replacement for static type checking
> for one simple reason. Static type checking is done by
> the compiler, and TDD is done by the developer.
>

Would you use a dynamically taped language/environment,
where you were forced to provide a fully qualified example
of the receiver and each parameter of a method, before being
able to "compile" the method?

Cheers,

Markus Gaelli

> I am sure I could be successful with this replacement if
> my development team was made up of Bob Martin's, but alas,
> it isn't. It is made up of a mix of people and skills,
> some of whom have technical ability far below that of
> Bob.
>
> I have seen cases where tests written by these folks pass
> on empty implementations, and they don't ever get around
> to fixing it.
>
> In a "typical" development group, such a substitution
> would most certainly fail. In a "advanced" group, I think
> it would be successful. But then so would almost anything
> you throw at an advanced group.

Markus Gaelli

Posts: 2
Nickname: markusg
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 13, 2003 3:11 PM
Reply to this message Reply
> Would you use a dynamically taped language/environment,
> where you were forced to provide a fully qualified
> example of the receiver and each parameter of a method, before
> being able to "compile" the method?
...I typed "dynamically typed" a bit to dynamically ;-)

MichaelKirby

Posts: 3
Nickname: mpkirby
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 14, 2003 8:12 AM
Reply to this message Reply
> > I can't see TDD as a replacement for static type
> checking
> > for one simple reason. Static type checking is done by
> > the compiler, and TDD is done by the developer.
> >
>
> Would you use a dynamically taped language/environment,
> where you were forced to provide a fully qualified
> example
> of the receiver and each parameter of a method, before
> being
> able to "compile" the method?

That would be better. It would be an interesting language though. And I still have the problem of the poorly written test case.

For example, if I had coverage checking for automated testing that would enforce a project specificed coverage limit, that might help as well (e.g. 80% coverage, or it doesn't go into the baseline).

Mike

Robert Haar

Posts: 1
Nickname: coho
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 22, 2003 12:47 AM
Reply to this message Reply
I have been a software developer for 30 years, and have also been a strong advocate of strongly typed languages. About a year ago I started programming in Python. I am building a fairly large system in Python. When things started to get large and go a bit pear-shaped, I put unit tests on all my modules. Every thing has been pretty stable since then.

I agree with your assessment completely, and find it quite interesting that a lot of software developers are coming to this conclusion with a sort of synchronicity. I love the quickness with which I can develop in Python and that there appears to be a module for interfacing to everything. The system I am developing is for analysing stock data, and interfaces with a database (PostGreSQL) and a data analysis package (R), and the integration is nearly seamless. Later, it will have an interface to display the results in a browsable form and that should be seamless, also, with PHP.

matthias felleisen

Posts: 5
Nickname: matthias
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 22, 2003 8:17 PM
Reply to this message Reply
Some remarks on this topic in general:

1. Statically type checking a function gives you the guarantee that it uses the proper operations for all input values. Notice the for-all part, but also note that this is only true for safe type systems. Contrary to rumors, C++ is not safe.

2. Dynamically type checking (in say Scheme) means that you guarantee that you only check for those values that the function is actually applied to. So in future runs, it may actually fail.

3. Having said that, I strongly believe that building a test suite before you write your program finds far more errors quickly than a static type system, including powerful systems like those in Cayenne, Haskell, or ML. This is also what I teach in my introductory courses and what I wish to instill as a culture in those courses. Take a look at http://www.htdp.org/ and look for all the design recipes to see what I mean. (The book is on-line but also in paper.)

4. A static type system, especially an inference system, comes with a huge problem. Nobody has found a way to provide good feedback when the system discovers type errors. (First research efforts on this: POPL 1986!). So yes programs run when they type check but until they type check, you can't use the debugger or any other tool to find the problem.

5. We (the PLT crew) have developed an alternative to address exactly this dichotomy. The idea is to develop auxiliary value flow analysis tools for dynamically typed languages. If you write a script to add a header line to each file, you don't even think about it. If you have a prototype that you want to turn into a product, you carefully get each portion "type right".

6. We also addressed the error reporting issue. We explain the error that our inference tool finds via flow diagrams that we draw atop the program. It shows how a bad value might end up in a position where it violates a primitive function. The programmer can then figure out whether this is a weakness in the analysis tool or the program (usually).

7. We accomplished this by giving up on equational reasoning a la ML and use subset reasoning instead. We find it more natural. The cost is that the complexity of the algorithm is high.

8. We're in the process of re-engineering MrSpidey now. We are
also exploring an ML-like alternative again, simply to find out whether we can tame it, too.

9. If you're interested, go to my home page and peruse some of our publications on Soft Scheme, MrSpidey, and MrFlow:
http://www.ccs.neu.edu/home/matthias/

-- Matthias Felleisen

Sonam Chauhan

Posts: 1
Nickname: sonam
Registered: Aug, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Aug 3, 2003 7:51 AM
Reply to this message Reply

Thomas Gagne

Posts: 3
Nickname: tgagne
Registered: Aug, 2003

Re: Typing, Dependency Tracing and Refactoring Posted: Aug 6, 2003 12:34 PM
Reply to this message Reply
That is the fault of a deficient IDE, not a (missing) feature of dynamically typed languages. I think you'd be amazed what can be done inside a good IDE, like those available for Smalltalk.

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 2:45 AM
Reply to this message Reply
This is dealt with very effectively in any Lisp or Smalltalk system. You can find all the callers of any method. You can find the implementors of any method, etc.

All built in...

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 3:01 AM
Reply to this message Reply
Mr. Martin,

As a long time Dynamic language user frustrated by having to us strongly typed systems and having lived thru the whole C++ strongly typed arguments, etc. about safety, performance, etc. it is so refreshing to see that many of that group are coming around to see the power that those of us who have used and lived in dynamic systems for the last 30 years have gotten to expierence. It is now possible for you to see why we were frustrated at having to go "backwards" if you will....

Anyway, I propose this funny thing I've noticed.....

Almost every cool feature or idea that we love today about using computers was created or investigate first on a dynamic system/language. GUI's, Ethernet, OO, etc. Most done at PARC and most in Lisp and Smalltalk. Even more interesting is that this duality of approach is almost as old as computers themselves. Fortran and Lisp are the two oldest still widely used languages. Fortran - strongly typed and optimized for specific set of problems and types.... Lisp - weak typing and oriented towards investigation. Now having noticed that, Fortran could never incorporate the more dynamic features of Lisp b/c of it's inherient structure and choices about what to be, but Lisp has very easily added every new computing idea and feature over the years all while maintaining architectural purity toward it's orginal goal and that includes typeing of the variables and getting extremely optimized code that in the case of Numerics could compete with Fortran. Most Lisp systems will even dump the assembly code for any given function for you to see what the compilier is generating while you code..... and if you want you can take that assembly and hand optimize it and Lisp will then use your optimized assembly for that particular function. Now that is truely the ultimate in dynamic behavior and allows you as developer to make the choice about what and when to optimze at any level.... Combine that with the test and experiment approach that characterizes how people who've worked in those systems have worked and you can see why people like me long for the rest of the world to get to that point.....

Welcome to the future, which is actually just catching up to the past......

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 3:15 AM
Reply to this message Reply
Well said - The Smalltalk environment is itself written in Smalltalk and provides much more than Eclispe. Truth be told the people who did the first versions of Eclipse are the very same people who used to do the incredible Smalltalk version/source control system "Envy".

OTI (Object Technology Internation) was bought by IBM a few years ago and Eclipse is the result of a group of Smalltalk programmers deciding that they wanted everything they had in Smalltalk available for Java and going about creating a tool to do that.

Now having told you about that, to do the same thiing that Smalltalk did has taken 4+ times as much code and the run time environments are much greater than a Smalltalk environment.

Believe me Smalltalk and Lisp have done all this a long time ago.... Smalltalk and Lisp both in the 70's had what you are just enjoying with Java today....

Welcome the the future which is actually catching up to the past....

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 3:28 AM
Reply to this message Reply
Yahoo Stores was written in Lisp as is the Orbitz online Airfare system that all the major airlines are investors in.


Dynmaic and powerful and shorter developement times.....

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 3:32 AM
Reply to this message Reply
Common Lisp lets you do this...

You can type any variable for any functiona if you want and if the compilier sees that you did that it will type check it and generate more efficant code.

Sam Griffith Jr.

Posts: 9
Nickname: staypufd
Registered: Sep, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 3:32 AM
Reply to this message Reply
Common Lisp lets you do this...

You can type any variable for any functiona if you want and if the compilier sees that you did that it will type check it and generate more efficant code.

Tiago Antao

Posts: 26
Nickname: tiago
Registered: Feb, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: Sep 27, 2003 12:50 PM
Reply to this message Reply
> type
> > *inferring* language -- one in which I get the reduced
> Something like OCaml ?

I would like to comment on type infering in general and OCaml in particular.

Caveat: I don't use OCaml for lots of years, things might be better on the type infering side.

Imagine that you have code like

function declaration A
...
B: function application of A (with a bug on usage)
...
C: function application of A (OK)

The compiler would do A, B (at this point infer the type - incorrectly) and return a compile error on C. Although the problem was detected on C, it was really caused by B. Now imagine looking at all applications of A to discover where is the error. And it might not be trivial that the problem is on B, because it might be that something calling B that was creating a type constraint, a few stack levels away....

I nightmare, I remember.

Again, this was long ago, maybe now is better. Because apart from this, OCaml was very interesting.

Flat View: This topic has 83 replies on 6 pages [ « | 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