Weblogs Forum - Programming with "Duh" Typing

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Programming with "Duh" Typing

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

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

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Programming with "Duh" Typing

Posted: Jul 13, 2007 11:22 PM

> 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

If you'd have reviewed at least one IDE in your quoted post and it's shortcommings your statement would have been more credible. But I guess the latest generation of web users is so concerned with blogging that it neither has time for programming nor for recherche.

BTW it is the language semantics that motivates the "typing faster" meme i.e. getting code that is simpler, requires less boilerplate and is more on the spot. It's not about how long it takes to select a method or rename instances. These are trivial efforts and nice to have at best.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: other tools

Posted: Jul 14, 2007 9:08 AM

James Watson wrote
> > 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.

Obviously I've failed in my attempts to communicate how pointless I think talking at this level of generality is - people don't understand the same thing by design or software design - we need to ground discussion in concrete detail.

> It's a constraint solver against sets and rules you
> u 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.

You must understand something particular by "really help you create a design" - but you haven't said what that is!

Previously I guessed that you hadn't actually tried to use Alloy to explore real software problems - have you?

I ask because it seems to me you are just being dismissive.

(Incidentally, I'm not selling Alloy - just using it as an example of something we might use before diving into code.)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools

Posted: Jul 14, 2007 2:50 PM

> James Watson wrote
> > > 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.
>
> Obviously I've failed in my attempts to communicate how
> pointless I think talking at this level of generality is -
> people don't understand the same thing by design or
> software design - we need to ground discussion in
> concrete detail.

Then be more specific.

> > It's a constraint solver against sets and rules you
> > u 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.
>
> You must understand something particular by "really
> help you create a design" - but you haven't said what that
> is!

It doesn't help you create a design. It verifies that the specifications that you represent in it's language are consistent. These specifications don't need to be a software design. Is that clear? Do you have any other semantical nits to pick?

> Previously I guessed that you hadn't actually tried to use
> Alloy to explore real software problems - have you?

I said yes, or was that unclear too. How can I be more clear?

I've started to and found it was required too much effort and got me too little along the path. I didn't need the kind of validation it required. It wasn't getting me enough benefit for the amount of work it required.

> I ask because it seems to me you are just being
> dismissive.

It seems to me that you are the one that is dismissive with apparently no sound reasons.

> (Incidentally, I'm not selling Alloy - just using it as an
> example of something we might use before diving into code.)

Have you used it to solve real problems?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 14, 2007 3:02 PM

> BTW it is the language semantics that motivates the
> "typing faster" meme i.e. getting code that is simpler,
> requires less boilerplate and is more on the spot. It's
> not about how long it takes to select a method or rename
> instances. These are trivial efforts and nice to have at
> best.

But these are just straw men. Renaming a method is only the most trivial of things that can be automated using the information in a static language.

I'm currently using Python for some fairly complex work. I started off feeling really good and I felt like I was really productive. But the other day, I started to regret using Python. As the code has become more complex, my progress has slowed rapidly. Simpler tasks are becoming mroe difficult to implement. Approaches that I chose in the beginning are starting to become cumbersome and changing them is daunting.

I'm not trying to say that I no longer will use Python. But I'm feel that as my task is getting larger, dynamic typing is becoming more of a burden than a benefit of using Python.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: other tools

Posted: Jul 14, 2007 6:47 PM

James Watson wrote
> Then be more specific.

I'm not in your head, I can't explicate what you mean to say.

> It doesn't help you create a design.

I think verifying a design iteratively and incrementally as we create a design "helps" us to create a design - so I've no idea what you're talking about.

> I said yes, or was that unclear too. How can I be more
> clear?
>
> I've started to and found it was required too much effort
> and got me too little along the path. I didn't need the
> kind of validation it required. It wasn't getting me
> enough benefit for the amount of work it required.

This yes was clear until what it meant changed to an explanation of why you stopped.

> Have you used it to solve real problems?

No.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools

Posted: Jul 14, 2007 7:29 PM

> > It doesn't help you create a design.
>
> I think verifying a design iteratively and incrementally
> as we create a design "helps" us to create a design - so
> I've no idea what you're talking about.

I don't care to help you understand at this point. It seems very simple to me but I've actually used the tool. Why don't you download Alloy and try to use it and if you feel that I am wrong, you can give specific reasons why. That would be a meaningful discussion. This is not.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Programming with "Duh" Typing

Posted: Jul 14, 2007 11:29 PM

> > BTW it is the language semantics that motivates the
> > "typing faster" meme i.e. getting code that is simpler,
> > requires less boilerplate and is more on the spot. It's
> > not about how long it takes to select a method or
> rename
> > instances. These are trivial efforts and nice to have
> at
> > best.
>
> But these are just straw men. Renaming a method is only
> the most trivial of things that can be automated using the
> information in a static language.

I guess all implementation difficulties with standard refactoring pattern can be put on the ground of alpha conversions. Counterexamples are welcome.

But Python is just halfway in reach of M.Fowlers book. So do we call in the end for more constrained languages that cripple our design for our own wealth or do we call for more advanced analysis techniques for whatever program in dynamically typed languages?

> I'm currently using Python for some fairly complex work.
> I started off feeling really good and I felt like I was
> really productive. But the other day, I started to
> regret using Python. As the code has become more complex,
> my progress has slowed rapidly. Simpler tasks are
> becoming mroe difficult to implement. Approaches that I
> chose in the beginning are starting to become cumbersome
> and changing them is daunting.
>
> I'm not trying to say that I no longer will use Python.
> But I'm feel that as my task is getting larger, dynamic
> typing is becoming more of a burden than a benefit of
> using Python.

It would be helpfull to make feelings more precise. Not so much for winning an argument but for those of us who undertake language level analysis and try to learn from user experiences - turning them into use cases.

As I pointed out in another post: decorating Python expressions with type annotations ( on AST / CST level ) is not that a big deal once you got some runtime data from your tests ( test driven type feedback = TDTF ). Than one might define constraints on them i.e. generate an ad hoc type checker of an ad hoc type system that cares at least for all "conservative" code transformations - I don't really believe this is sufficient since one has to adapt tests as well - but at least one won't change signatures or change them predictably within refactoring moves.

All of these problems will become accute with the migration of Python 2.6 [1] to Python 3.0. While there is a 2To3 tool written by Guido it doesn't address subtler conversions and will generate warnings if it gets stuck. I guess TDTF can help here and I hope I will have some working prototype at the end of the summer when the first Python 3.0 alpha is out.

[1] Python 2.6 as the successor of Python 2.5 provides tools and infrastructure for migration to Python 3.0. AFAIK it shall not provide new features otherwise.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 16, 2007 9:06 AM

> > > BTW it is the language semantics that motivates the
> > > "typing faster" meme i.e. getting code that is
> simpler,
> > > requires less boilerplate and is more on the spot.
> It's
> > > not about how long it takes to select a method or
> > rename
> > > instances. These are trivial efforts and nice to have
> > at
> > > best.
> >
> > But these are just straw men. Renaming a method is
> only
> > the most trivial of things that can be automated using
> the
> > information in a static language.
>
> I guess all implementation difficulties with standard
> refactoring pattern can be put on the ground of alpha
> conversions. Counterexamples are welcome.

Sorry, I'm not following you. Could you point me to a definition of 'alpha conversion'?

> But Python is just halfway in reach of M.Fowlers book. So
> do we call in the end for more constrained languages that
> cripple our design for our own wealth or do we call for
> more advanced analysis techniques for whatever program in
> dynamically typed languages?

Can you explain why static typing necessarily cripples a design?

> It would be helpfull to make feelings more precise. Not so
> much for winning an argument but for those of us who
> undertake language level analysis and try to learn from
> user experiences - turning them into use cases.

I think you are asking me to be more specific so I'll try to give a better idea with what I am dealing with. The company I work for has been using a gui tool to do a lot of development "without code". Now, something needs to change in the data model and we need to understand how a certain piece of data is used and where it is being replicated and how that is used and being replicated...

The tool doesn't provide this kind of 'explosion' search functionality and as the usage branches out, it becomes too time consuming to use what search capabilities it does provide. In other words, it's time to pay the piper.

The processes defined in this tool can be exported to XML and I am using XPath to recursively search through this data for references. Unfortunately, it's not really feasible to export everything into a single document and there are pieces of logic required to interpret the document that are hard (for me at least) to specify in Xquery or XPath.

So I am using Python (Jython) to build the logic and calling XPath to find the elements. The idea here is to be as quick as possible because this development is not officially sanctioned but I know this is common issue and I want to be able to reuse as much as possible.

The benefits of Python for this work are immediately obvious: overriding [] for attributes simplifies the code greatly, factory constructors move a lot of boilerplate to more basic parts of the code. For comprehensions and generators made things a lot quicker.

I was able to get some basic recursive searches done. But as I go down the rabbit hole, I'm finding more non-uniform aspects of the xml and how it is structured. Unfortunately there is no documentation and I'm having to discover the design as I go. A lot of this boils down to trial and error. When I hit a new type of element that I have not accounted for, I need to add that logic.

The problems I have had are: as I make changes, I often don't realize that I have made some trivial error until 5 minutes into the test, when that code is first hit. This is slow. Most of the time these are things that would have been immediately flagged in a static language. When I want to add a new type or logic for a new scenario, it takes me a good bit of recollection to figure out where things fit together; how I get from point A to point B. Often I get halfway through a change and I realize that the change is not compatible with something else that I have already done. Along with finding what needs to be changed, returning it to a previous state is basically ad-hoc. This might be relieved by a good IDE. I find myself staring at the screen trying to figure out a way to change things without having to take a full inventory of my work so far. I kind of feel like I'm driving a car with no reverse gear.

One of the things I miss but isn't a huge deal is being able to type a couple letters of a method name and select the correct method and have the IDE show me the arguments, their types and the documentation for the method. This also may be available in a Python IDE. I find that in some ways I'm doing more typing in Python than I do with Java.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 16, 2007 9:33 AM

James said:
The problems I have had are: as I make changes, I often don't realize that I have made some trivial error until 5 minutes into the test, when that code is first hit. This is slow. Most of the time these are things that would have been immediately flagged in a static language.

Five minutes isn't bad. I've had a similar experience where it could be a couple hours and then *poof*, some edge case was hit and an API gave me a DOMNode (or whatever they are called in whatever API you're using) or a tuple when I though I had a string or a number.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 3:20 AM

> The problems I have had are: as I make changes, I often
> don't realize that I have made some trivial error until 5
> minutes into the test, when that code is first hit. This
> is slow. Most of the time these are things that would
> have been immediately flagged in a static language.

Most probably it would not happen, and the reason is simple: in this day and age where most computer languages involve subtyping (i.e. inheritance from you OO folks), trivial errors can easily pass through through the subtyping mechanism. A static type system is almost useless in this case.

Programming usually goes down two routes:

1) the problem at hand is trivial. In this case, a static type system won't help because the problem is trivial.

2) the problem at hand is quite complex. In this case, a static type won't help as well, because the code will usually involve lots of subclasses and interfaces.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 4:44 AM

> > The problems I have had are: as I make changes, I often
> > don't realize that I have made some trivial error until
> 5
> > minutes into the test, when that code is first hit.
> This
> > is slow. Most of the time these are things that would
> > have been immediately flagged in a static language.
>
> Most probably it would not happen, and the reason is
> simple: in this day and age where most computer languages
> involve subtyping (i.e. inheritance from you OO folks),
> trivial errors can easily pass through through the
> subtyping mechanism. A static type system is almost
> useless in this case.
> Programming usually goes down two routes:
>
> 1) the problem at hand is trivial. In this case, a static
> type system won't help because the problem is trivial.
>
> 2) the problem at hand is quite complex. In this case, a
> static type won't help as well, because the code will
> usually involve lots of subclasses and interfaces.

I think you underestimate the penchant we mortals have for making stupid mistakes. Here's a common one (in rough Python):

<code>
#setup connection and execute query...
row = cursor.fetchone() #row is a tuple...
myObj.cost = row #should be row[0] to reference the first element of the tuple
</code>

I make those mistakes a lot. Maybe it comes from having a compiler yell at me for them, and having IDEs underline them, so I'm just sloppy in my typing.

The ones on the main paths of the code get weeded out quickly enough to not be too big of an issue. In that case unit testing is a reasonable substitute for static typing. But mistakes tend to linger in codepaths that you haven't tested. Ok, maybe tests should cover all code paths...but sometimes that takes too much time to do when the code is in a high state of flux and you don't know if it will ever really be used.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 5:14 AM

> Programming usually goes down two routes:
>
> 1) the problem at hand is trivial. In this case, a static
> type system won't help because the problem is trivial.
>
> 2) the problem at hand is quite complex. In this case, a
> static type won't help as well, because the code will
> usually involve lots of subclasses and interfaces.

Oh, that sounds like fun. Let me try!

1) The problem at hand is trivial. In this case, you won't have that many types since the program is trivial, so a statically typed language doesn't have any overhead and is safer.

2) The problem at hand is quite complex. In this case, you need types even more because the code will involve lots of subclasses and interfaces.

--
Cedric

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 6:31 AM

> The ones on the main paths of the code get weeded out
> quickly enough to not be too big of an issue.

I guess my point was that there's this assumption that developing in a dynamic language is inherently faster. I'm disputing that. As long as the scope of the program is small, I think this is definitely the case. But as the program becomes more complex, the information provided by the static typing becomes more useful. I think this can be mitigated by increasing documentation but this is as costly (if not more) as the adding the type declarations to the code.

> In that
> case unit testing is a reasonable substitute for static
> typing. But mistakes tend to linger in codepaths that you
> haven't tested. Ok, maybe tests should cover all code
> paths...

Just covering all code paths isn't really enough but I'm sure you know that.

> but sometimes that takes too much time to do when
> the code is in a high state of flux and you don't know if
> it will ever really be used.

In my case, I am just trying to automate some tedious work. I'm not writing an 'application' per se. The problem I think is that I underestimated the complexity of the task. I might have tried this with Scala had I known.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 7:04 AM

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 7:13 AM

John McCarthy has an interesting paper from 2000 in which he describes a language, call Elephant, he worked on. Here's a link to the paper: http://www-formal.stanford.edu/jmc/elephant.pdf .

I'm only a little way into it. (Darn requests from my employer keep getting in the way of reading!) His approach is in the part interpreted/part compiled camp. Here's a "food for thought" passage from it.

"3. Elephant programs do not require data structures, because program statements can refer directly to past events and states. An Elephant interpreter keeps a history list of past events, and an Elephant compiler constructs
whatever data structures in the object language are needed to remember the information needed for compiled program to behave as specified in the Elephant source program. However, it seems unlikely that it will be convenient
to omit data structures completely from the language."

Flat View: This topic has 370 replies on 25 pages [ « | 9 10 11 12 13 14 15 16 17 | » ]

Previous Topic

Next Topic