sommar@enea.se (Erland Sommarskog) (03/18/91)
David Gudeman claimed that you couldn't write a generic list handler in a staticly typed language, which he claimed would force you to write code for any type that was expected. I objected this and described how genericity works in Ada and Eiffel. >You aren't getting the same functionality that dynamic typing gives. >To get that functionality you would have to declare a tagged union of >every type in the program, and for each list function that deals with >list values you have to do the right thing with the member of the list >depending on it's actual type. To compare two values you have to >write code to check the type and do the right thing based on the type. >You have to (in general) write seperate code for every type that is >used in the program. OK, I cannot write a polymorphic list handler in Ada or Eiffel easily without a lot of extra code. On the other hand, in the general case you have to do that for a dynamicly typed language as well. Or? Well, say we have this polymorphic list handler which you wrote some day some years ago. Now, after some years of maintenance and modification we now get to the sitaution that we sort the the list. Next to each other happens to be an account statement and a security ("security" = item to trade with on the stock exchange), so you compare them. What happens? 1) Question is moot. You can't define your types in a dynamicly typed language, you can only use the builtins. I have to admit that such a language does not seem very expressive to me. 2) Comparison is not defined for the two objects, type error leading a crash, which may or may not be acceptable depending the reliability and accessability requirements. 3) Comparison is not defined for the two objects, but the language implicitly uses the comparison operations for the underlying types which are built-in to the language. This may or may not be logically correct. 4) Both account statements and securities are built-in types in your language, so what's the deal? 5) You have written operations that compares an account statement and a security to each other. Depending on the situation, 5 does not at all seem unlikely to me. If you really need a polymorphic list handler, and you need to compare the types from a non-general rule, you have to write a lot of code, may it be Icon or Eiffel. If you are using some more general rule, Ada is still out, but I wouldn't be too sure about Eiffel. Now in another article Gudeman says: >It isn't that completely polymorphic lists are so useful, in fact >they are rarely used. What is important is the ability to change the >types that can go in the list without making pervasive changes to the >program -- and without having to look for a declaration for the list. What a problem! If you are on VMS and have LSE/SCA on your system, just say GOTO DECLARATION and you're there. I assume Unix or GNU-Emacs something similar. And may I add, you rarely change the list declaration, possibly you modify the type that's in the list, add another field for instance. But you have to do that in a dynamicly typed language too, I guess. But if finding the declaration is too much for Gudeman, he isn't always that lazy. Look here, in yet another article: >Whenever you change the way a fuction >behaves, you (in general) have to check all the places it is used to >make sure the change is OK. All static type checking provides is a >compile-time warning if (1) you have missed any uses _and_ and (2) the First a correction: the compiler gives you a compile-time *error*. Here he isn't afraid of jumping around the code to find every single occurance. Sure he needs SCA or similar to do that, but it is definitely not consistent with his reluctance searching for one single declaration. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
cs450a03@uc780.umd.edu (03/18/91)
Dan Brnstd writes: >Emacs is written in C, with a very small percentage of ``helper'' code. >Until someone can explain how a dynamically typed language would remove >any length from Emacs other than in the helper code, I don't see why we >should accept claims of extra productivity or conciseness. Eh? You say that if someone does not re-write emacs, presumably with all it's features and internal variables, in a way that results in less code, dynamically typed languages are without merit. You graciously imply that if someone were to do such a thing, you MIGHT consider that dynamically typed languages allow productivity or conciseness? Ah, my friend, in the face of such logic, there is naught I can do but admit defeat--not only for myself, but for all of like mind. I should mention though that emacs-lisp is a dynamically typed language. Maybe a bit less concise than it could be. But in any event, emacs-lisp is used for productivity reasons. Even implying otherwise invites a religious flame war :) Or maybe you weren't talking about GNU emacs, but some other program? In which case I'll guarantee you it's less expressive. Your mileage may vary. Raul Rockwell
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/18/91)
In article <2840@enea.se> sommar@enea.se (Erland Sommarskog) writes: > OK, I cannot write a polymorphic list handler in Ada or Eiffel > easily without a lot of extra code. On the other hand, in the > general case you have to do that for a dynamicly typed language > as well. Huh? Your argument for this seems to be ``Sorting a polymorphic list doesn't make sense unless comparison is defined between arbitrary list elements''---which is obviously true but doesn't justify your point. My response to Dave is ``So what''? Polymorphic lists do not appear to be particularly useful in the vast majority of real-world programs. When they are necessary, they are easy enough to implement provided that the language has good enough syntax and a few semantic features. Emacs is written in C, with a very small percentage of ``helper'' code. Until someone can explain how a dynamically typed language would remove any length from Emacs other than in the helper code, I don't see why we should accept claims of extra productivity or conciseness. ---Dan
mhcoffin@watmsg.uwaterloo.ca (Michael Coffin) (03/18/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >... >Emacs is written in C, with a very small percentage of ``helper'' code. >Until someone can explain how a dynamically typed language would remove >any length from Emacs other than in the helper code, I don't see why we >should accept claims of extra productivity or conciseness. GNU Emacs is written mostly in elisp---a dynamically typed language--- with a small amount of helper code written in C. The helper code consists of a Lisp interpreter and a few low-level, speed-critical functions. So the explanation you're looking for is that a dynamically typed language has *already* removed a lot of length from emacs. And, although it's hard to document, it would surprise me a lot if a competent elisp programmer isn't several times as productive as a competent C programmer. Michael Coffin mhcoffin@watmsg.waterloo.edu Dept. of Computer Science office: (519) 885-1211 University of Waterloo home: (519) 725-5516 Waterloo, Ontario, Canada N2L 3G1
gudeman@cs.arizona.edu (David Gudeman) (03/19/91)
In article <2840@enea.se> Erland Sommarskog writes:
]
]OK, I cannot write a polymorphic list handler in Ada or Eiffel
]easily without a lot of extra code. On the other hand, in the
]general case you have to do that for a dynamicly typed language
]as well.
True. But there are many cases where you don't. In particular you
don't have to write typecase code for functions that just pass data
around without doing type-specific operations. This includes such
things as insert and delete functions which are quite common.
]... get to the sitaution that we sort the
]the list. Next to each other happens to be an account statement
]and a security ("security" = item to trade with on the stock exchange),
]so you compare them. What happens?
]1) Question is moot. You can't define your types in a dynamicly
] typed language...
Not true. In fact this is the exception rather than the rule.
]2) Comparison is not defined for the two objects, type error leading
] a crash, which may or may not be acceptable...
First, the programmer who was responsible for testing the sort
function gets fired for gross negligence (the most minimal testing
should have caught this). Then if error stops are unacceptable the
programmer who was responsible for execption handling may get fired
for gross negligence also, depending on the circumstances.
]3) Comparison is not defined for the two objects, but the language
] implicitly uses the comparison operations for the underlying
] types which are built-in to the language. This may or may not
] be logically correct.
Most likely it is correct. If you are sorting two objects with a
generic comparison then the actual ordering better not be important.
If the comparison is not logically correct, then you may have a third
programmer to fire. Be a little more careful in your hiring practices
in the future.
]Depending on the situation, 5 does not at all seem unlikely to
]me. If you really need a polymorphic list handler, and you need
]to compare the types from a non-general rule, you have to write a
]lot of code, may it be Icon or Eiffel.
Yes, but in Icon you didn't have to implement the list. And if you
_could_ use the generic comparison, then you wouldn't have to write
the sort either, you could just say new_list := sort(old_list). Or
you could use a dynamically typed language (like lisp) that lets you
specify in-place sorts and specify the comparison function.
]>... What is important is the ability to change the
]>types that can go in the list without making pervasive changes to the
]>program -- and without having to look for a declaration for the list.
]
]What a problem! If you are on VMS and have LSE/SCA on your system,
]just say GOTO DECLARATION and you're there. I assume Unix or
]GNU-Emacs something similar.
OK, that helps you find the declaration. Now you change the
declaration and you have to make pervasive changes throughout the
program.
]But if finding the declaration is too much for Gudeman, he isn't
]always that lazy. Look here, in yet another article:
]>Whenever you change the way a fuction
]>behaves, you (in general) have to check all the places it is used to
]>make sure the change is OK.
]
]Here he isn't afraid of jumping around the code to find every
]single occurance. Sure he needs SCA or similar to do that, but
]it is definitely not consistent with his reluctance searching
]for one single declaration.
This is bogus. When you change a function definition in _any_
language, you generally have to make sure all of its previous uses are
still correct.
And my complaint was not that it is too much work to find a single
declaration. The problem with having to keep all your declarations
consistent is that (1) you sometimes forget to do it, wasting a
compile-debug cycle, (2) when you change a declaration you have to
make pervasive changes throughout a program, which is not only time
consuming itself but also (3) it tends to provoke further errors. All
this combined with the observation that (4) it isn't necessary.
Obviously (1) through (3) may be applied to the situation of changing
a function definition, but in that case it _is_ necessary to update
all uses of the function, so why complain about it? Actually,
although you can't elminate this problem you can reduce it either by
using a hierarchical type system or by dynamic typing (or a
combination).
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudemanrsalz@bbn.com (Rich Salz) (03/23/91)
In <1991Mar18.143601.13385@watmath.waterloo.edu> mhcoffin@watmsg.uwaterloo.ca (Michael Coffin) writes: >And, although it's hard to document, it would surprise me a >lot if a competent elisp programmer isn't several times as productive >as a competent C programmer. No -- it depends on the problem being solved. Seen any Lisp device drivers or avionics systems? Got a good (fast!) DES implementation in Lisp? -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) (03/23/91)
In article <3444@litchi.bbn.com> rsalz@bbn.com (Rich Salz) writes: >mhcoffin@watmsg.uwaterloo.ca (Michael Coffin) writes: >>And, although it's hard to document, it would surprise me a >>lot if a competent elisp programmer isn't several times as productive >>as a competent C programmer. >No -- it depends on the problem being solved. Seen any Lisp device drivers or >avionics systems? Got a good (fast!) DES implementation in Lisp? Granted. I should have been more clear. There are certainly problems with real-time constraints for which nothing but assembly language or its moral equivalent is fast enough. My sloppy response was to the rhetorical question "If dynamically typed languages are so good, why don't you write emacs in one?" I was just pointing out that GNU emacs *is* written mostly in lisp and that it seems to be a good language for the purpose. Michael Coffin mhcoffin@watmsg.waterloo.edu Dept. of Computer Science office: (519) 885-1211 University of Waterloo home: (519) 725-5516 Waterloo, Ontario, Canada N2L 3G1