Weblogs Forum - Getting Dynamic Productivity in a Static Language

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Getting Dynamic Productivity in a Static Language

78 replies on 6 pages. Most recent reply: Apr 5, 2009 3:19 PM by Cedric Beust

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 78 replies on 6 pages [ « | 1 ... 2 3 4 5 6 | » ]

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 8:42 AM

> > > This discussion reflects a general beef I have with
> the
> > > way Scala is presented. People say it has features A,
> B,
> > C
> > > and so on, until readers feel that it's really a very
> > > large language. It's not. The point is that Scala's
> > > features are really very general. The same feature
> can
> > be
> > > interpreted in many different ways. So people who
> don't
> > > know Scala come away with a wrong impression, that it
> > has
> > > much more different features than really is the case.
> > >
> > I don't know, Martin, I think from the user's
> perspective
> > these things feel like separate features, even if they
> may
> > be generalizations of each other. You mention that
> member
> > types can encode generics, so is your feeling is that
> > generics can be considered another representation for
> the
> > one feature of member types? I think to users they feel
> > like two features, because they have to learn two
> > different syntaxes and sets of rules. They feel quite
> > different.
>
> They do. It's more that once you know the language better
> you realize that they are just different facets of the
> same core. Well, maybe not generics vs abstract types; we
> have not quite succeeded in unifying them completely
> (yet).
> But a lot of the other features such as structural types
> are just facets of more general construct. The problem is
> that beginning programmers see more the facets than the
> core, so come away with the feeling that there are lots of
> different things in Scala. Nevertheless, there's a payback
> even for beginning users: Because the facets come from a
> common core, there's a much higher probability that they
> will work well together, than if they had each been
> designed in individually.
>
I thought about this today, and I came up with a better example I think of what you're talking about than the generics and type members one. Basically some people do complain that Scala has a lot of features, but you as the language designer look at these other languages that don't get this complaint, and note that they actually have a lot more special support for special cases. Whereas in Scala there are actually fewer primitives that can be applied in different ways. The example I came across today was the syntax for assigning multiple variables at once. In Ruby, they have a special syntax for this (thanks to Daniel Spiewak for the code):


# this is Ruby
include Math

def constants
  [PI, E]
end

a, b = constants

In Scala the syntax look somewhat similar:


// this is Scala
import Math._

def constants = (PI, E)

val (a, b) = constants

The difference is that Ruby's a, b is special language support just for this feature, whereas Scala's (a, b) is a pattern, which is a general concept used in many places in the language. In fact plain old single variable assignment could be seen as a pattern, right? So even that's not a special case.

I suspect that's the kind of thing you're thinking about, and it may just take some amount of experience with the language for beginners to realize that some of these "features" really are "facets" of the same core concept.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 8:54 AM

> > But I still see a difference, in that this is always
> the
> > case with structural typing. I think the root cause is
> > that structural typing, like duck typing, doesn't
> involve
> > a semantic contract that is implied by a nominal type.
>
>
> Not so. Consider
>
Not not so!

> trait Something {
> /** Implementations of this method should not murder
> er kittens */
> def doIt : Unit
> }
>
> vs
>
> /** @arg x: the doIt method should not murder kittens */
> def foo(x : {def doIt : Unit}) = ...
>
This isn't placing a contract on { def doIt: Unit }, right? It's placing a contract on foo.

> Both have a semantic restriction that the user is
> responsible for following. And both are just as easy to
> break
>
> class Evil extends Something {
> def doIt = murderKittens
> }
>
> foo(new Evil)
>
> * Note, no actual kittens were harmed during the writing
> of this message
>
Thank goodness. You're right that just being an instance of a class or trait doesn't mean you're a valid one in terms of the contract, and sometimes the contract isn't clear or explicit. Bugs are usually contract violations, and we see bugs all the time. Misunderstandings of the contract also occur, and that causes contract violations.

In further reflection, I think the important difference may not be contracts at all, though, but rather that a class declares its intent to be an instance of its superclasses and the traits it mixes in. Whereas it doesn't declare its intent to be any of the many structural types it would be a subytype of. So if you refactor one of the traits it mixes in by changing a method name, you pretty much can say that the same method name in that class should change, and anyone calling that method on that class should change, so long as there isn't some other trait also mixed in that declares the same method signature.

But if such a change breaks some code somewhere where that type is being used as a structural subtype, it isn't as clear what to do.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 9:37 AM

> So that was the history, and so I was asking him what it was that made him
> feel so productive in Smalltalk, and one of the things he said is he didn't
> have to waste time thinking about types.

This is a fundamental mistake that a lot of dynamic enthusiasts (short for "dyamically typed language enthusiasts") keep making over and over.

The fact is: you always have to think about types when you write code, period.

Dynamic enthusiasts are convinced that they can ignore this aspect of development altogether, but it always comes back to bite you, either when

- you write tests for your code
- you try to refactor it
- somebody else needs to modify it

Eventually, you look at an object and you have to figure out what methods or messages it responds to, and I find that this problem is much easier to solve when the answer is in the source code in a form that can be enforced by the compiler.

--
Cedric

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 10:27 AM

Excellent point Cedric.

But you forgot the most important bullet point:

- somebody else needs to *use* it

In a dynamically typed language a *user* must have knowledge of the structural type of everything. There's just no escaping that.

For instance, a method call in a dynamic language uses duck typing on the parameters. If I want to call a method successfully, I must know the structure of each and every parameter, as well as that of the return type. Essentially, I must have an intimate understanding of its implementation details, or it must be thoroughly documented in terms of the implied interfaces of each parameter. When a program grows beyond small-scale, the former is just not productive. And typically the latter is never maintained. If there were only some way for a language to enforce the annotation of types on parameters and return types...

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 3:39 PM

> > So that was the history, and so I was asking him what it
> was that made him
> > feel so productive in Smalltalk, and one of the things
> he said is he didn't
> > have to spend time thinking about types.
>
> This is a fundamental mistake that a lot of dynamic
> enthusiasts (short for "dyamically typed language
> enthusiasts") keep making over and over.
>
> The fact is: you always have to think about types when you
> write code, period.
>
> Dynamic enthusiasts are convinced that they can ignore
> this aspect of development altogether, but it always comes
> back to bite you, either when
>
> - you write tests for your code
> - you try to refactor it
> - somebody else needs to modify it
>
Well I think the evidence shows that people can build software with dynamic languages, including large systems. Yes, they may need to write more tests. They don't get deterministic refactoring, but they may have some heuristic refactoring tools that take them much of the way there, and they have grep after that. And if a bug slips out the door after a refactor, why bugs slip out the door in static languages too. And when someone needs to modify the code, they may need to work a bit harder to figure out how to modify some code, but other things may have been easier, and it is possible. We know it's possible because people do it all the time.

> Eventually, you look at an object and you have to figure
> out what methods or messages it responds to, and I find
> that this problem is much easier to solve when the answer
> is in the source code in a form that can be enforced by
> the compiler.
>
I think ultimately it comes down to personal preference. You find it easier to solve the problem in a static language. I do too. But other people, who are smart and fully understand the tradeoffs involved, would rather work with the bag of tradeoffs that is dynamic typing than the bag of tradeoffs that is static typing.

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 6:26 PM

>> they may need to work a bit harder to figure out how to
>> modify some code, but other things may have been easier

Like what??? A large system, say a million lines of code, written in a dynamic language is quite a thing. If you can point out where the benefits of a dynamic language offset the horrific downsides, such as poor discoverability, please enlighten me.

The trouble is most language pundits haven't had the necessary experience fully leveraging a tool like IDEA on a large system involving teams of devs over many versions to know firsthand of the huge productivity benefits. Without this knowledge they tend not to consider the broader picture which must include the whole development environment. As a consequence critics (from both sides) primarily compare language features, which is not useful. Sadly, most commentary regarding static v. dynamic languages fall into this category.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 8:29 PM

> >> they may need to work a bit harder to figure out how to
>
> >> modify some code, but other things may have been
> easier
>
> Like what??? A large system, say a million lines of code,
> written in a dynamic language is quite a thing. If you can
> point out where the benefits of a dynamic language offset
> the horrific downsides, such as poor discoverability,
> please enlighten me.
>
I'm not a good one to answer, because I haven't ever built anything big in a dynamic language, because I prefer static typing for that. I expect if I did try and build something big in a dynamic language I'd eventually have a similar reaction to you, wishing I had the refactoring, code completion, hopping around, etc., support I'm used to in IDEA. But that said, I do see the productivity advantages of dynamic typing, and from your comment it sounds like you do to. But you and I feel that the downsides outweight the benefits, especially for larger projects. Other people make the opposite conclusion. I've met many such people, and they are otherwise intelligent and I have confidence they know what they are talking about. And they say they are able to manage.

Michele Simionato

Posts: 222
Nickname: micheles
Registered: Jun, 2008

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 2, 2009 9:12 PM

> A large system, say a million lines of code,
> written in a dynamic language is quite a thing. If you can
> point out where the benefits of a dynamic language offset
> the horrific downsides, such as poor discoverability,
> please enlighten me.

In my experience the problems of large code bases as mostly
sociological and language independent. Typically the problems are with legacy code. For instance:

- the business logic is extremely tricky, undocumented,
nobody remembers what the system was supposed to do
in the first place;
- the team who wrote the original code left the job years
ago;
- the new programmers have no idea of interrelations of
system, so changing X has unexpected effects on Y;
- the old logic maybe was originally correct but now
the system has changed and you are getting mysterious
bugs manifesting in your system;
- there are no tests and refactoring is very difficult;
- the old code is written using technologies that
have been dismissed and nobody uses anymore;
- the code was written very poorly in the first place,
perhaps by unexperienced programmers;
- the sheer size of the system is such that nobody
can keep the whole of it in his mind.

All these problems have nothing to do with the language
per se. A high level language closer to the business
logic, readable and concise is the thing that can help,
but even with the best language these issues are tough.

In my opinion, the larger the code base, the smaller
the relevance of the language on the productivity. Having
said that, I still prefer a dynamic language with strong introspection features, where I can tinker with the system
from the REPL trying to understand what the legacy code
is doing.

Andrew McVeigh

Posts: 29
Nickname: 55548
Registered: May, 2008

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 3, 2009 2:58 AM

> I'm not a good one to answer, because I haven't ever built
> anything big in a dynamic language, because I prefer
> static typing for that. I expect if I did try and build
> something big in a dynamic language I'd eventually have a
> similar reaction to you, wishing I had the refactoring,

one of the more difficult programming assignments I've ever done was when I was dropped into a 10kloc smalltalk system and asked to add certain features. maybe i'm a statically-typed sort of guy, but I found this work to be a nightmare. i spent literally ages trying to reconstruct a semblance of interfaces/types in my head. i was forever constructing classes which didn't quite implement the right part of the protocol and subsequently broke on further integration, or implemented too much.

in the end the only way I coped was to talk to the original developers and when i finally understood their mental model of the system I was able to understand how to add to the code properly. in effect, types would have given me a start on this mental model although clearly they are no substitute for full understanding.

towards the end of the work someone added some form of protocol / interface checking tool to VA smalltalk, which solved a lot of these problems, I think. i remember thinking at the time it was a nice match between keeping dynamic types and then being able to overlay interfaces on top when the code got stable.

there was a phrase bandied around at the company at the time. it was something like "strong typing is for people with weak memories" ;-) particularly in a team situation, not everyone will have these memories in any case as they won't be exposed to the whole system all the time.

> code completion, hopping around, etc., support I'm used to
> in IDEA. But that said, I do see the productivity
> advantages of dynamic typing, and from your comment it
> sounds like you do to. But you and I feel that the

I just don't think that the productivity advantages of dynamic typing, when actually measured on a system amount to more than 20%.

> downsides outweight the benefits, especially for larger
> projects. Other people make the opposite conclusion. I've
> met many such people, and they are otherwise intelligent
> and I have confidence they know what they are talking
> about. And they say they are able to manage.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 3, 2009 8:48 AM

> there was a phrase bandied around at the company at the
> time. it was something like "strong typing is for people
> with weak memories" ;-) particularly in a team situation,
> not everyone will have these memories in any case as they
> won't be exposed to the whole system all the time.

In addition, on many projects some of the original developers will leave and new ones will be added. In that case, they'll have a hard time coming up to speed regardless of their memory strength.

Actually, I think depending on strong memories should be considered a development anti-pattern for large projects.

Bill de hÓra

Posts: 1137
Nickname: dehora
Registered: May, 2003

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 3, 2009 2:36 PM

"The trouble is most language pundits haven't had the necessary experience fully leveraging a tool like IDEA on a large system involving teams of devs over many versions to know firsthand of the huge productivity benefits. Without this knowledge they tend not to consider the broader picture which must include the whole development environment. As a consequence critics (from both sides) primarily compare language features, which is not useful. Sadly, most commentary regarding static v. dynamic languages fall into this category"

I don't think that's the trouble. Having worked in both Java and Python with a variety of IDEs and editors, the type system of a programming language for me wasn't a first order effect on maintenance costs, (it's the type system that ultimately underpins the kind of tooling you get with things like IDEA).

I've seen that large systems built on something like Python will invent concepts like interfaces to tighten up API contracts and this a problem because you end up with a shadow language. Large Java systems will have overly specific APIs where automated refactoring doesn't actually find all callers, as you have to deal with published (v public) contracts and the consequent deploy/upgrade hell.

So I concur with Michele - "the larger the code base, the smaller the relevance of the language on the productivity.". The problems I've found are to do with structural complexity and behavioural unpredictability - things like non-locality of change, mind-numbing logic, lack of cohesion, monolithic codebases, unexplained wtfs, bad abstractions, the absence of a coherent "physics" for the system of the code. Plus the overall entropy and drag of poorly written code.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 3, 2009 3:49 PM

> > there was a phrase bandied around at the company at the
> > time. it was something like "strong typing is for
> people
> > with weak memories" ;-) particularly in a team
> situation,
> > not everyone will have these memories in any case as
> they
> > won't be exposed to the whole system all the time.
>
> In addition, on many projects some of the original
> developers will leave and new ones will be added. In that
> case, they'll have a hard time coming up to speed
> regardless of their memory strength.
>
> Actually, I think depending on strong memories should be
> considered a development anti-pattern for large projects.

yes to all of that, a thousand times, yes!

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 3, 2009 3:50 PM

> I think the root cause is
> that structural typing, like duck typing, doesn't involve
> a semantic contract that is implied by a nominal type.

cowboy, artist: draw!

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 4, 2009 10:20 PM

>> it's the type system that ultimately underpins the kind
>> of tooling you get with things like IDEA
...
>> So I concur with Michele - "the larger the code base,
>> the smaller the relevance of the language on the
>> productivity.". The problems I've found are to do with
>> structural complexity and behavioural unpredictability -
>> things like non-locality of change, mind-numbing
>> logic, lack of cohesion, monolithic codebases,
>> unexplained wtfs, bad abstractions, the absence of a
>> coherent "physics" for the system of the code. Plus the
>> overall entropy and drag of poorly written code.

Well, if the type system is static, you have tooling, otherwise you pretty much don't. On large systems the tools make or break productivity. So claiming "the larger the codebase, the smaller the relevance of the language on productivity" seems unreasonable.

For instance, all the problems you mention: structural complexity, etc. are all reasons we have static analysis tools. Most of your examples scream "refactor" e.g., extract interface, extract method, rename, modify signature, introduce variable, replace inheritance with delegation, etc. etc. While refactoring you need to find usages of types, methods, properties, etc. And you need to look for types, declarations, etc. Even if the large system is "perfect", you can't keep it all in your head, so you need code completion. And all these features must be reasonably deterministic in order for them to be reliable. You simply cannot achieve this level of sophistication with a dynamically typed language; by definition it's not possible.

The truth is there aren't any "perfect" large systems; none that stay perfect anyway. And, as it happens, successful software is often the least "perfect". To the uninitiated it evolves in "peculiar" ways, usually under pressures of competition and deadlines. After all customers don't pay for perfect software -- they pay for features that work for *them*. So we make trade-offs; we trade an ounce of perfection for a pound of features and we do it until we can't. Some realize we can't at the right time, some don't. In any case the code must evolve in a timely and accurate way to stay competitive. Tools in capable hands are what makes this happen.

Michele Simionato

Posts: 222
Nickname: micheles
Registered: Jun, 2008

Re: Getting Dynamic Productivity in a Static Language

Posted: Apr 4, 2009 10:59 PM

> Well, if the type system is static, you have tooling,
> otherwise you pretty much don't. On large systems the
> tools make or break productivity.

It seems to me you have a wrong idea of what is available
in terms of tools for dynamic languages. For instance, vim
can integrate a Python interpreter, so that you have
autocompletion at runtime for all your Python objects.
You can add even a method during a session of debugging
and see the completion for it live right after you defined
it. Emacs has pymacs. There is ipython. There are pylint
and pyflakes for static analysis. pychecker also does a
good job. I have being involved in very big refactoring
projects and tools where never the issue. The real
issue was the business logic, which was very tricky
to understand and to get right (it even contained bugs
in the first place). The issues with tools very nothing
compared to that. Even the problem of poor code is
not that serious.
One can fix poor code more or less automatically.
The real problems are with overengineered code,
code relying on side effects and boundary conditions
such as the status of the database and things like that.
Then you can spend days with a debugger trying to
understand what's happening and what is the logic behind
the code (I am speaking of thousands of lines with
plenty of ifs and tricky corner cases).

Flat View: This topic has 78 replies on 6 pages [ « | 2 3 4 5 6 | » ]

Previous Topic

Next Topic