You, uh, missed the point

Post #41,048 by JayMehaffey 6/4/02 1:27:01 AM Reply	You, uh, missed the point I'm not trying to argue that a program written in a more 'powerful' language isn't going to be smaller. What I'm arguing is that this won't actually save you much real programming time, if any at all. In my experience, for any non-trival program, the actual time spent typing is a fairly small portion of the time spent on the program. The design and analysis phase are usually both longer then the time spent in the physical typing and programming portion of the program. When you add in testing, debugging, documentation, and so on, you find that for complex problems the coding phase is often less then 25% of the overall project time. Thus even if your programming language can solve a problem in half the elements as another one it won't reduce the overall time to do the project by 50%. And that's assuming that a programming language with twice the number of elements is actually twice as powerful. This is itself an obviously flawed concept. At some point the number of elements in language becomes so large that it becomes impossible to remember or use them all effectivly. And in any case, there are factors other then number of elements involved in measuring how usefull a language really is. Lisp is a really good language, but the idea that it is better because it can solve problems in fewer elements is misguided. Jay
Post #41,065 by ben_tilly 6/4/02 8:07:20 AM Reply	And you missed the point My experience backs up Paul who got his idea from The Mythical Man-Month. Less code wins in a whole ton of ways, and typing is the least of them. It wins because there is less to keep in mind, and therefore you are more likely to get away with a small team (with all of the small team dynamics). It wins because there are fewer places you can make mistakes leading to fewer bugs to track down, speeding up the debugging phase. It wins because the reduction in size corresponds to an improved factoring of the problem, which has all sorts of ways of coming back and making you happy. And for the record, it seems that languages which allow shorter do not mainly do it by offering a ton more elements. They do it by getting rid of things that take up lots of space and thought (like memory management), and allowing for options that give you better ways to build on your own code-base (OO, native associative arrays, closures, macros). The result is that you cut code size in half while far less than doubling the complexity of the language. In fact it is quite possible for a simpler language to beat a more complex one. Well-integrated features and design can easily beat more features. Cheers, Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #41,101 by tuberculosis 6/4/02 12:08:12 PM Reply	Programming Time More powerful languages win hugely as programming time is much more than typing. The conceptual load is much lower in the more powerful (and simpler) language. Example: Assume list of integral, we want a subset of list with only non-negative values. In Java: Iterator it = list.iterator(); List newList = new ArrayList(); while(it.hasNext()) { Integer i = (Integer) it.next(); if(i.intValue() >= 0) { newList.add(i); } } The Smalltalk equivalent is: \| newList \| newList := list collect: [:x \| x >= 0]. The conceptual load in the Java version is an order of magnitude higher as I have to deal with setting up a loop, determining a good end condition, the duality of objects and primitives, the allocation of the new list container including the selection of an appropriate implementation, setting up the test that determines inclusion, doing the cast from Object down to Integer. There are a lot of things to get wrong in the Java version. In fact, the Java version will go terribly wrong if there is some other kind of number representation in the list, like a Long. Maybe I need to go back and check for that case. The average hunter gatherer works 20 hours a week. The average farmer works 40 hours a week. The average programmer works 60 hours a week. What the hell are we thinking?
Post #41,184 by tablizer 6/4/02 7:23:44 PM Reply	"Any sufficiently complex program reinvents the DB" How about select * from myList where x > 0 Or XBase: use myList set filter to x > 0 Smalltalk fans seem to delight in reinventing the database. However, the drawback of ST databases is that it is hard to share the data with other languages in real-time and you have to roll-your-own services like backups, contention management, etc. ________________ oop.ismad.com
Post #41,859 by tuberculosis 6/10/02 4:38:27 PM Reply	Proper abstraction Makes the same action work on both a database or in memory data store. So you use the same actions on both. So on one hand I sort of agree with you - set operations are lacking from most collections libraries and this is sad since they are so useful in databases - OTOH, I view the db itself as implementation detail - maybe the data is persistent in a database or maybe its some stuff I happen to have in memory and I don't need to save. I don't care. So long as I have powerful set operations that work on the tuples in the collections. The average hunter gatherer works 20 hours a week. The average farmer works 40 hours a week. The average programmer works 60 hours a week. What the hell are we thinking?
Post #41,991 by tablizer 6/11/02 5:05:52 PM Reply	Persistence is not the main issue (* OTOH, I view the db itself as implementation detail - maybe the data is persistent in a database or maybe its some stuff I happen to have in memory and I don't need to save. I don't care. So long as I have powerful set operations that work on the tuples in the collections. *) Databases are about managing collections, period. Whether you save them or not is another matter. (Vendor support for virtual or temp tables varies. That is not my fault.) Anyhow, as long as you don't distinguish between "types" of collections, then we are pretty much saying the same thing. Whether we store the collection or keep it in a temporary buffer only (such as RAM) is also an "implementation detail". One should not have to alter their collection interface if they decide to "save" a collection for whatever reason, and visa versa (beyond setting an attribute or two).
Post #41,183 by tablizer 6/4/02 7:15:31 PM Reply	Organic software engineering? (* The design and analysis phase are usually both longer then the time spent in the physical typing and programming portion of the program. When you add in testing, debugging, documentation, and so on, you find that for complex problems the coding phase is often less then 25% of the overall project time. *) IIRC, Paul Graham suggested that he sort of "hacked his way into" his zillion-dollar application. IOW, an organic kind of growth rather than up-front planning. Also, he would probably say, "less code == less to debug". He also said something like, "There is less things to slow you down when you toss the suits out". [paraphrased] I would definitely agree with the suits claim. Well, maybe not toss them, but simply give them an information-finding role only. They have a habbit of sticking their fingers into the pie simply because they want their fingers in there. ________________ oop.ismad.com

Welcome to IWETHEY!