The Artima Developer Community
Sponsored Link

Weblogs Forum
Programming with "Duh" Typing

370 replies on 25 pages. Most recent reply: Aug 8, 2007 12:54 PM by James Watson

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 370 replies on 25 pages [ « | 1 ... 8 9 10 11 12 13 14 15 16 ... 25  | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools Posted: Jul 11, 2007 12:54 PM
Reply to this message Reply
Advertisement
> > I've looked at Alloy after reading about it in
> Scientific
> > American. In the end this is another programming
> > language. It's odd to me that this language aims to
> test
> > a design but doesn't make any attempt to bridge the gap
> > between design and working code.
>
> I don't wish to put words into your mouth, it seems like
> you're saying you don't understand the value of
> abstraction?

Not at all. I DO see value in not having to recreate what you have already done. Do you not see value in this?

> > To me, programming is primarily a design exercise
> > interspersed with technical problems. A good
> high-level
> > programming language gets me closer and closer to a
> design
> > language. To me, designing in one place and then
> > replicating it in another by hand is no less misguided
> > than printing out one document and typing the text into
> > another.
>
> Should we design a house by clearing ground and piling up
> bricks? Abstraction! :-)

These kinds of analogies break down at this point because software is not a physical object.

If I have a electronic file that specifies a design, why should a human have to take that design and type it into the computer? Why is this preferable to automation?

If we must use a physical object creation analogy, a better one would be a rapid prototyping machine such as a selective laser sintering (SLS) machine. You could build the SLS machine to take CAD drawings and produce the objects directly from those specifications. You seem to be arguing that this is not a desirable feature and that it would be better to have a human take the CAD drawings and respecify them in some other way to the SLS machine.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools Posted: Jul 11, 2007 1:00 PM
Reply to this message Reply
> I don't wish to put words into your mouth, it seems like
> you're saying you don't understand the value of
> abstraction?

I think I know where I have been unclear. I am a big proponent of up-front design. I do it all the time. However, I believe that a iterative approach to software is much more efficient and produces a better result than a simple waterfall model. It's hard, especially when addressing a new problem, to see the flaws in a design until they are found in development.

My other point is somewhat tangential and I have unintentionally changed the subject without informing you. That point is that design tools that are treated as silos are, in my mind, missing the point.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 3:11 PM
Reply to this message Reply
> > The difference with this, though, is that the base
> > language just looks like a dynamically typed language.
> It
> > should be complete in the sense that you can imagine it
> > executing and see the complete algorithm. The
> annotations
> > in another file would really act as constraints which
> > disallow certain conditions at compile or load time.
> They
> > would not add functionality.
>
> I guess when I look at your example, I have to question
> that. For example, you specify that successors and words
> are hash-based dictionaries. A hash-based dictionary can
> have subtle differences in behavior from a sorted
> dictionary especially depending on the types being placed
> in it. In general, any polymorphic language will allow a
> given operation to behave in different ways. So
> specifying the type could change the code especially since
> there would be nothing to prevent the developer from
> exploiting polymorphism in this way.

Yes, there are two different aspects in that code. If you specify the type for a created object, all of the options are open. You can do anything (it's like generics in that respect). But, if you add a type to a reference, you're constraining the type of objects that can be referred to by it. Not very easy to add functionality that way.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 3:21 PM
Reply to this message Reply
> Yes, there are two different aspects in that code. If you
> specify the type for a created object, all of the options
> are open. You can do anything (it's like generics in that
> respect). But, if you add a type to a reference, you're
> constraining the type of objects that can be referred to
> by it. Not very easy to add functionality that way.

It's also not very easy to maintain functionality when you write code that is dependent on having a sorted map data structure and some genious changes it to a hash-based data structure.

Pick your poison.

Jesse Kuhnert

Posts: 24
Nickname: jkuhnert
Registered: Aug, 2006

re: Tools Posted: Jul 11, 2007 11:53 PM
Reply to this message Reply
I wish someone could get the intellij guys in here to explain how they implemented this:

http://www.jetbrains.com/idea/features/javascript_editor.html#link2

I haven't actually gotten much of a chance to use that particular feature - and am sure that even if it works 90% of the time that 10% is still going to be unacceptable if it means someone might be calling you at 2am to say the whole systems fu%%@! and it's all your fault because you didn't see this one obscure section of code that did some special things on the side..

....but it would still be interesting to hear what the general plan of attack was for it and what kinds of thoughts about the hope(full)/(less) ness of being able to rely on dynamic languages in a large scale system are..

Is "close" good enough?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: re: Tools Posted: Jul 12, 2007 9:29 AM
Reply to this message Reply
> ....but it would still be interesting to hear what the
> general plan of attack was for it and what kinds of
> thoughts about the hope(full)/(less) ness of being able to
> rely on dynamic languages in a large scale system are..
>
> Is "close" good enough?

If you look back at the link Isaac posted about smalltalk refactoring they list the hours that the work took. In that case, the work to create the refactoring scripts took around 250 hours. The time to test was over 1000. I think that's basically the only realistic plan of attack in a dynamic language.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

not behaviour preserving - test test test Posted: Jul 12, 2007 11:08 AM
Reply to this message Reply
James Watson wrote
> If you look back at the link Isaac posted about smalltalk
> refactoring they list the hours that the work took. In
> that case, the work to create the refactoring scripts took
> around 250 hours. The time to test was over 1000. I
> think that's basically the only realistic plan of attack
> in a dynamic language.

Perhaps there was some misunderstanding - they were not refactoring - they were using the underlying functionality of the refactoring browser (the rewrite engine and rewrite rules) to systematically make many changes that they knew did not preserve behaviour - they were programming, the whole point was to change the behaviour.

After 17,000 changes I do hope we would spend a significant amount of time testing, although we'd used a statically checked language ;-)

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: imperative, and functional, and oo, ... Posted: Jul 13, 2007 1:51 PM
Reply to this message Reply
> That's why I was thinking that to do this well, you'd need
> basically two versions of the same language. One that was
> dynamic and another that was static. This should be
> possible, I think, given that it's possible to have
> optional typing. Outside of the typing, the features
> would be the same so that the resulting code would look
> like the original code with type declarations.

I think you're onto something here. I have to wonder if there's any researchers looking into this possibility. If times frees up, I'll do a search through IEEE and ACM libraries.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: other tools Posted: Jul 13, 2007 2:58 PM
Reply to this message Reply
James Watson wrote
> > I don't wish to put words into your mouth, it seems
> > like you're saying you don't understand the value of
> > abstraction?
>
> Not at all. I DO see value in not having to recreate what
> you have already done. Do you not see value in this?

We do 10 sketches of 5 different designs, we work out consistency issues for 2 designs using Alloy, we take one design and implement it - I don't see the "recreate what you have already done" cost as significant, compared to savings from doing lots of design iteration before we code.


> > Should we design a house by clearing ground and piling
> > up bricks? Abstraction! :-)
>
> These kinds of analogies break down at this point because
> software is not a physical object.

These kinds of analogies break down when they're stretched too far - all I meant was that the description misses out other design iteration techniques we could use before we dive into code.


> I think I know where I have been unclear. I am a big
> proponent of up-front design.

As I said - when we talk at this general level its really easy to completely misunderstand what's meant - and these days "up-front design" is little more than a strawman / cuss-word, the details really matter.

> I believe that a iterative approach to software is much more efficient

It's not a question of whether we do iterative design, it's a question of how much iteration can we get done in cheap ways before we dive into code.

> design tools that are treated as silos
> are, in my mind, missing the point

My guess is that is a conclusion based on theory rather than practice - you "looked at Alloy after reading about it in Scientific American" but have you tried to use it to explore real software problems?

Until we are adept at using other tools for design iteration how do we know that they miss the point - maybe they are a huge win?

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: imperative, and functional, and oo, ... Posted: Jul 13, 2007 3:40 PM
Reply to this message Reply
> Is there any merit to the possibility of using Python (for
> example) to "sketch out" an idea and then have a converter
> of some kind produce the "go live" code in Scala (for
> example)?

This question comes up from time to time in connection with type reconstruction.

Test driven type reconstruction + x-compilation might be part of the answer to your question but being still incomplete since it is unlikely that the whole of the program code can be converted. Instead one might have to factor code into convertible + inconvertible parts, translate the convertible parts and re-bind them as extension modules into the code of the source language. This addresses first of all only performance issues and omits the other ones having been discussed here. However I'm not sure about this as well. When you run UTs awfull lots of data including object ids and types can be recoded. This shall have an impact on how safe your refactoring transformations are. But those will not just depending on the language and the code but on additional data.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: imperative, and functional, and oo, ... Posted: Jul 13, 2007 4:28 PM
Reply to this message Reply
> This question comes up from time to time in connection
> with type reconstruction.
>
> Test driven type reconstruction + x-compilation might be
> part of the answer to your question but being still
> incomplete since it is unlikely that the whole of the
> program code can be converted. Instead one might have to
> factor code into convertible + inconvertible parts,
> translate the convertible parts and re-bind them as
> extension modules into the code of the source language.
> This addresses first of all only performance issues and
> omits the other ones having been discussed here. However
> I'm not sure about this as well. When you run UTs awfull
> lots of data including object ids and types can be
> recoded. This shall have an impact on how safe your
> refactoring transformations are. But those will not just
> depending on the language and the code but on additional
> data.

Thank you for the feedback. After reading the various posts, I feel a little more educated on the intricacies of a naive suggestion. James Watson flushed out some details that would make the suggestion more realistic, but it seems like there's a long way to go for anything like this.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools Posted: Jul 13, 2007 5:21 PM
Reply to this message Reply
> My guess is that is a conclusion based on theory rather
> than practice - you "looked at Alloy after reading about
> it in Scientific American" but have you tried to use it
> to explore real software problems?

Yes. It's a good tool for what it does but it misses the point. It's just like a taking drawings from a CAD tool and programming a SLS machine to do what's in the drawing. There's no reason it could not be used for automation.

> Until we are adept at using other tools for design
> iteration how do we know that they miss the point - maybe
> they are a huge win?

Because 'the point' is that computers are good at mundane tasks like taking information from one place in one format and converting it into another. Tools that specifically require human intervention to do this work are missing 'the point'.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: other tools Posted: Jul 13, 2007 8:58 PM
Reply to this message Reply
James Watson wrote
> > Until we are adept at using other tools for design
> > iteration how do we know that they miss the point -
> > maybe they are a huge win?
>
> Because 'the point' is that computers are good at mundane
> tasks like taking information from one place in one format
> and converting it into another. Tools that specifically
> require human intervention to do this work are missing
> 'the point'.

I hear you saying - if there isn't an automated flow between tools then they are worthless - that might not be what you mean but it is what I hear you say.

To me that just seems like bad accounting.

If we gain 100 on the tools and lose 10 on manual intervention we gain 90 - until we know what the benefits and costs actually are whose to say who is missing the point.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools Posted: Jul 13, 2007 9:27 PM
Reply to this message Reply
> James Watson wrote
> > > Until we are adept at using other tools for design
> > > iteration how do we know that they miss the point -
> > > maybe they are a huge win?
> >
> > Because 'the point' is that computers are good at
> mundane
> > tasks like taking information from one place in one
> format
> > and converting it into another. Tools that
> specifically
> > require human intervention to do this work are missing
> > 'the point'.
>
> I hear you saying - if there isn't an automated flow
> between tools then they are worthless - that might not be
> what you mean but it is what I hear you say.

No. I think the tool has value. First, you have to realize it's not really a software-design tool per-se. It's a constraint solver against sets and rules you create about those sets. It doesn't really help you create a design. It helps you verify your design. It's kind of like static type checking for a design. Really though, there's nothing really specific about software design in Alloy.

This clearly is worth the effort for projects where failure is not acceptable, like flight-control systems. But the time to create the declarations is substantial and requires learning a new language. This is costly and has a flaw in it that it's dependent on a human to create the declarations that match the software when the structure of the language tool is not based on any common programing paradigms. It's roughly similar to OO but they warn against becoming too comfortable in that simplification.

Now it's been a while since I looked into it and there may be people who have created tools to automate this kind of process. There are also other similar tools that may have more automation.

Juancarlo Añez

Posts: 12
Nickname: juanco
Registered: Aug, 2003

Re: Programming with "Duh" Typing Posted: Jul 14, 2007 1:45 AM
Reply to this message Reply
I wrote a small article about this same topic about a month ago:

http://blog.neogeny.org/2007/05/why-not-python.html

The conclusion is basically that language features like static typing (inferred preferably) are required for reasonable tooling, starting with IDEs.

I did some experiments in Python, and found that IDE support for it was so lacking that I actually write less (not less code) with Java/Eclipse, or C#/SharpDevelop, or Delphi.

Juanco

Flat View: This topic has 370 replies on 25 pages [ « | 8  9  10  11  12  13  14  15  16 | » ]
Topic: Programming with "Duh" Typing Previous Topic   Next Topic Topic: Python 3000 Plea for Help


Sponsored Links



Google
  Web Artima.com   

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