This page is no longer maintained — Please continue to the home page at www.scala-lang.org

RE: Re: benefit of dynamic typing?

1 reply
Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.

Moved to debate...

>Certainly such things have an impact. But riddle me this batman: Then why
choose *any* new language to work in at all? Scala's support in IDEs is
still way behind Java's and started out with no support at all. Yet in the
imaginings of potential Scala users a glimmer of "a better way" emerged.
The dynamic language programmer sees the same thing in the toolchain they
are using. It does really come down to that.

Yeah, same thing. The disagreement is about the value one sees in one
toolchain or the other. About scala in particular, support is not that far
behind Java now but yes, it was 2-3 years ago and it sucked, but the sheer
numbers of brain cells simulated made it worth it :)

>OK, I'll bite: how about on-the-fly code augmentation, like instances of
objects being extended at run-time, as opposed to having to write all that
boiler plate or have a tool write it for you? How about code that adds
additional functionality only discoverable at run-time (where the IDE is
very much out of the picture)? Stuff like this is the life-blood of the
dynamic language programmer (whether that be Lisp, Lua, Ruby, or whatever):
writing code that writes the code, it really is nice. Despite desires to
the contrary it is surprisingly effective.

These patterns are not part of my vocabulary - I obviously must have other
ways to handle the problems which they address... or... refuse to
acknowledge said problems? It is possible that we are working in completely
different problem domains.

Even so, I don't really see that stuff used on a daily basis, to become the
reason why such languages exist and need to be used. Could it be that's just
a hammer you got used to using?

Cheers,
Razvan

-----Original Message-----
From: scala-user [at] googlegroups [dot] com [mailto:scala-user [at] googlegroups [dot] com] On
Behalf Of Jim Powers
Sent: February-09-11 6:39 PM
To: scala-user
Subject: [scala-user] Re: benefit of dynamic typing?

On Feb 9, 5:59 pm, Razvan Cojocaru

wrote:
> I don't quite see those as a benefit though. It just means the person is
less serious about programming (no knowledge of type systems) or about the
system (no design).

That is an unfortunate bias.

> If we're talking about rapid prototyping and rapid application
development, static typing is the least of one's worries.

I disagree. Static typing imposes that you make decisions "early"
often resulting in a poor type zoo. The point of a (literal) prototype is
to explore the solution space then possibly throw away the actual result and
move forward with some better understanding.

> Having an environment where the UI is designed quickly, persistency
generated automatically and all those other things one needs are automated,
that's what gives you whatever speed you're looking for here. If you just
want to hack text and syntax that may or may not work, then nothing can stop
you but don't tell me that's what makes you more efficient.
>
> That's not it! The environment, libraries and tools ( including automated
build and deployment tools) make the difference.

Certainly, all such goodness helps.

> Type swing java code in vi and you're just as hopeless and slow as doing
JavaScript web apps in whathaveyou. Once it compiles you know it *may* work
but throw nullpointers...While the JavaScript thing - well, there's no
knowing that it would even work.

No doubt about that, but typically this does not happen. There's a lot of
JS out there running on a lot of browsers and the world has not ended yet.

> Oh, instant results. Much like fixing java code in the middle of an
eclipse debugging session and continue with the fixed code, after eclipse
deployed the fix and instantly rolled back to the caller? Can your python
interpreter do that? Or it starts over again?

OK, I'll bite: how about on-the-fly code augmentation, like instances of
objects being extended at run-time, as opposed to having to write all that
boiler plate or have a tool write it for you? How about code that adds
additional functionality only discoverable at run-time (where the IDE is
very much out of the picture)? Stuff like this is the life-blood of the
dynamic language programmer (whether that be Lisp, Lua, Ruby, or whatever):
writing code that writes the code, it really is nice. Despite desires to
the contrary it is surprisingly effective.

I would presume (I cannot say for sure) that the example you cite above
about in-debugger updating of code could be applied to a number of other
languages on the JVM including, for instance, Clojure (I have no idea about
support to do this with Scala). It's really only a matter of man-hours to
achieving that goal. In the mean-time the Clojure programmer goes about
evolving their solution bit-by bit. It really isn't as bad as it is being
portrayed on this thread.

> I don't see a big difference between properly test-harnessed and
continuously integrated apps of either static or dynamic type.

In a "prototype" situation often test-harnesses are optional. One is
seeking to explore the solution space.

> So I don't think any of the things said here are what the real difference
is ...  The seriousness and completeness of the environment makes the
difference! The specificity and applicability of the language to the problem
domain, including libraries is!

Certainly such things have an impact. But riddle me this batman: Then why
choose *any* new language to work in at all? Scala's support in IDEs is
still way behind Java's and started out with no support at all. Yet in the
imaginings of potential Scala users a glimmer of "a better way" emerged.
The dynamic language programmer sees the same thing in the toolchain they
are using. It does really come down to that.

> Having said that, without a compiler to double check my wiring I feel
> like writing assembly on paper :)

Understood, but having done a fair bit of Ruby, Perl, and various forms of
Lisp programming it is possible to live a productive and healthy programming
life in dynamic language land.

> And as a last note, dynamic languages I've seen tend to *not* have the
level of development support usually associated or expected from static
ones.

That is merely a result of the man-power not being applied. That said,
languages like Ruby are really hard to "properly cover" in an IDE. Coverign
the basics of a typical script using stuff from known libraries, possibly,
covering all the cases of meta-programming that typical Ruby programs employ
is neigh impossible.

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: RE: Re: benefit of dynamic typing?

On Thu, Feb 10, 2011 at 5:37 AM, Razvan Cojocaru wrote:
> How about code that adds additional functionality only discoverable at run-time (where the IDE is very much out of the picture)?

I think this is an interesting prospect. But the problem isn't really
about static vs dynamic typing. This is more about offline or online
typing ;-D

The dichotomy of static vs dynamic languages seems like a red herring
to me. Why should it be inherent to the language whether we do static
or dynamic analysis of the program?

Take a typical SQL IDE as example. Would you call SQL statically or
dynamically typed? The IDE will use both static and dynamic analysis
to point out errors to you. The SQL language as such has a structure
that can be statically verified, but the most interesting analysis is
whether the queried relations actually contains the referenced
attributes, which requires a more dynamic analysis. Or is the catalog
of the database to be considered part of the static structure of the
system? It seems that the line become rather blurry and uninteresting
once we integrate the IDE with the runtime.

So my take on this: Forget about static or dynamic languages. Focus
instead on how to make the runtime available to the IDE.

BR,
John

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland