Re: Scheme as a virtual machine?
On 2010-11-25 11:30:12 -0500, Mario S. Mommer said: In the realm of pure logic, ad hominems are logically invalid, period. We don't live in the realm of pure logic (whatever that would mean - pretty sure no human beings exist in the realm of pure logic, so there is no homo hominis to make an ad hominem argument against in the land of pure logic...) Here in the real world, no amount of the rigid application of pure logic is going to substitute for the very necessary social skill of inferring the motives of a participant to a debate. Again, not all ad hominem arguments are ad hominem fallacies. JH has repeatedly trumpeted the virtues of languages whose adoption by others brings him financial gain, and repeatedly made pejorative statements about other languages in newsgroups for these other langauges, in a clear attempt to drum up clients for his training consultancy. Pure logic alone won't help you here; the ordinary human social skill of inferring a person's motives does. warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
On 2010-11-24 16:19:49 -0500, toby said: And furthermore, he has cooties. Once again, not all ad hominem arguments are ad hominem fallacies. Financial conflict of interest is a prime example of a perfectly valid ad hominem argument. People who parse patterns but not semantics are apt to fall into the error of believing that ad hominem automatically means logically invalid. This is not the case. warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
On 2010-11-23 11:34:14 -0500, Keith H Duggar said: You don't understand the implications of your own words: having a financial interest in the outcome of a debate makes anything that person says an advertisement for his financial interests, not a fair assessment. is substantially different from render his arguments in the debate inherently suspect. They are substantially the same, your jesuitical nit-picking notwithstanding; JH is an untrustworthy source on matters relating to the languages he sells training for. warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
On 2010-11-23 10:08:12 -0500, Keith H Duggar said: There is a well-known name for such illogical reasoning: ad hominem. You don't understand ad hominem: The ad hominem is a classic logical fallacy,[2] but it is not always fallacious. For in some instances, questions of personal conduct, character, motives, etc., are legitimate and relevant to the issue.[3] Source: http://en.wikipedia.org/wiki/Ad_hominem Sometimes the person's conduct and motives *are relevant* to the point under discussion. Financial conflict of interest is a perfect example where it *is* legitimate and relevant to explore a person's motives and conduct outside of the debate. In this case, JH's conduct outside of the debate (i.e., the fact that he earns his living by selling tools and training for a particular set of languages) and his motives (i.e., he is therefore financially motivated to present these languages in the best possible light and to trash-talk other languages), render his arguments in the debate inherently suspect. warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
On 2010-11-22 08:12:27 -0500, markhanif...@gmail.com said: All opinions are biased. All opinions show some bias. Not all opinions represent what is usually called a conflict of interest. Since JH makes his living selling tools and training for certain languages, he has a severe conflict of interest wrt asessing the value of various other languages. If these other languages are just as good or better than those he makes his living from, it would be very damaging to his livlihood for him to admit this fact. As a result, he is a completely unreliable source on the question. This is why judges must recuse themselves from both civil and criminal trials if they have some significant conflict of interest. The law recognizes that we cannot expect a fair judgement from someone who stands to profit significantly if the judgement goes one way or the other. Similarly, we cannot expect a fair judgement on the relative value of various language tools from a person whose livlihood depends on the audience choosing only those certain language tools that he sells services and training for. warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Scheme as a virtual machine?
On 2010-11-22 11:25:34 -0500, scattered said: And you don't think that [JH] could write a book about Haskell if he honestly came to think that it were a superior all-aroung language? Until he actually does, he has a financial interest in trash-talking Haskell. This makes anything he says about Haskell suspect. The fact that he *didn't* mindlessly reject [musical note lang] in favor of [Irish Ship Of The Desert] when [musical note lang] came out (despite the fact that at the time his company was deeply (exclusively?) invested in [Irish Ship Of The Desert] and arguably had a vested interest in having [musical note lang] fail to gain support) suggests that he is able to fairly evaluate the merits of other languages. No, it suggests that he saw that supporting the Irish Ship Of The Desert meant going up against Microsoft, so he jumped to the MS supported variant of the Donut Dromedary. You miss the fundamental point; having a financial interest in the outcome of a debate makes anything that person says an advertisement for his financial interests, not a fair assessment. Doubtless he has biases, but there is no reason to think that they are any greater than the bias of any programmer who has invested substantial amounts of time in becoming fluent in a particular language. Just the opposite. A person who makes his living by being paid to program in a language he has developed some expertise in (rather than selling books on it and training for it) has no financial interest in seeing others develop expertise in it - they would just represent competition. By contrast, one who sells training and books for a language profits directly when others take an interest in that language. Their financial interests are in fact opposite. JH profits when people take an interest in languages he sells training for; a working lisp programmer sees additional *competition* when someone else develops expertise in common lisp. But an advocate isn't a judge. Nobody is handing down binding decisions here - they are just advocating their positions. Now you're arguing our point; JH is an *advocate* with a clear conflict of interest which prevents him from presenting anything but the most one sided, and therefore largely useless, assessment. His writing should be seen as a paid advertisement, not as a fair treatment of programming languages. warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Strong typing vs. strong testing
On 2010-10-01 16:47:02 -0400, BartC said: I had a quick look at Lisp to see if your claims had any basis. I tried this program: (defun fib (n) (if ( n 2) n (+ n (fib (- n 1)) (fib (- n 2)) ) )) But it gave the wrong results and it took ages to figure out why. Even after downloading a working version for comparison, it's was difficult to spot the extraneous 'n' (I think I was concentrating on getting the round brackets all in the right places). I saw it immediately, but I'm familiar with lisp and you are not - those two parentheses (what you call round brackets) on a line by themselves are a dead giveaway. I thought you were saying that Lisp (and dynamic typing in general) was better for pointing out errors? The above error in C would have been picked up more easily I think (due to less parentheses clutter, and more obvious separators between terms). As for speed, executing fib(38) took about 60 seconds on my machine (gnu clisp with no switches set). (Compared with 3.5 seconds, for my own interpreted, dynamic language, and 0.6 seconds for C.) Compiled lisp is fast, but you need to actually compile it: CL-USER 96 (defun fib (n) (declare (optimize speed (debug 0))) (if ( n 2) n (+ (fib (- n 1)) (fib (- n 2) FIB CL-USER 97 (compile 'fib) FIB NIL NIL CL-USER 98 (time (fib 38)) Timing the evaluation of (FIB 38) User time=0.888 System time =0.002 Elapsed time =0.877 Allocation = 142568 bytes 0 Page faults 39088169 which is in the same range as your .6 seconds for your equivalent c program. What happens when you want fib(1000) or fib(100)? Then the naive recursive version isn't very useful (it's just too slow), and the result is going to overflow c integer types. in lisp: CL-USER 118 (defun fact (n) (if (zerop n) 1 (* n (fact (1- n) FACT CL-USER 119 (defun fib (n) (/ (loop for k from 1 to n by 2 sum (/ (* (expt 5 (/ (1- k) 2)) (fact n)) (fact k) (fact (- n k (expt 2 (1- n FIB CL-USER 120 (compile 'fact) FACT NIL NIL CL-USER 121 (compile 'fib) FIB NIL NIL CL-USER 122 (time (fib 1000)) Timing the evaluation of (FIB 1000) User time=0.760 System time =0.007 Elapsed time =0.748 Allocation = 474522008 bytes 147 Page faults 43466557686937456435688527675040625802564660517371780402481729089536555417949051890403879840079255169295922593080322634775209689623239873322471161642996440906533187938298969649928516003704476137795166849228875 warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Strong typing vs. strong testing
On 2010-10-01 22:44:11 -0400, Paul Rubin said: I have no idea what that fancy algorithm is doing, but the number it prints appears to be the 2000th Fibonacci number rather than the 1000th. I think you're mistaken. fib(0) = 0, fib(1) = 1, fib(2) = 1, fib(3) = 2 ... fib(11)= 89 ... fib(1000) = 43466557686937456435688527675040625802564660517371780402481729089536555417949051890403879840079255169295922593080322634775209689623239873322471161642996440906533187938298969649928516003704476137795166849228875 If you like we can do it iteratively instead, which, as in haskel, takes no perceptible time: CL-USER 133 (defun fib (x) (if ( x 1) 0 (loop repeat x for previous = 0 then result and result = 1 then (+ result previous) finally (return result FIB CL-USER 134 (compile 'fib) FIB NIL NIL CL-USER 135 (time (fib 1000)) Timing the evaluation of (FIB 1000) User time=0.000 System time =0.000 Elapsed time =0.000 Allocation = 60088 bytes 0 Page faults 43466557686937456435688527675040625802564660517371780402481729089536555417949051890403879840079255169295922593080322634775209689623239873322471161642996440906533187938298969649928516003704476137795166849228875 The relevant points are: 1. common lisp implementations produce fast code 2. the result of fib(1000) is going to overflow c integer types warmest regards, Ralph -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-26 09:16:39 -0400, a...@pythoncraft.com (Aahz) said: There are plenty of expert C++ programmers who switched to Python; plenty is an absolute term, not a relative term. I sincerely doubt that the majority of python users were formerly *expert* C++ programmers. your thesis only applies to the legions of people who found it difficult to learn C++ in the first place. No, my thesis applies to the overwhelming majority of programmers who found it more difficult to *master* (i.e., not merely use) C++ as opposed to mastering python. BTW, this is a *complement* not a dis; python is a better language than C++ precisely because it is more sensibly and elegantly designed than C++ and therefore easier to master. php represents the same process but farther down the ladder, as it were. There's often a tradeoff between ease of mastery and power. python hits a sweet spot for many tasks and many programmers, especially as compared to C++ (or even lisp, which though more powerful than python is more difficult to master. lisp beats C++ on both counts imho - more powerful *and* easier to master). php hits a sweet spot only in a very restricted domain. Beyond that, it is clearly inferior to python which has greater power, but is more difficult to master. -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-26 17:04:23 -0400, Roy Smith r...@panix.com said: One needs to have a very highly developed sense of theoretical purity to look down their noses at the language that drives one of the highest volume web sites on the planet. It's nothing to do with theoretical purity and everything to do with practicality. php has a limited range of utility. Within that range, it's clearly quite useful. Python is useful for a greater range of tasks which makes it a more generally useful (and in this sense, better) language. -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-25 00:55:26 -0400, Carl Banks pavlovevide...@gmail.com said: But please don't put it on the same level as PHP. Their situations have almost nothing in common. Their situations have much in common; Python attracted programmers away from (for example) C++, becuse python is easier to master; Then php came along and attracted programmers away from (for example) python, because php is easier to master. This doesn't mean they're on the same level - in fact, if you read carefully you'll see my original post said as much: python attracted average programmers; php attracted mediocre programmers and even some non-programmers, which means that php is clearly a lesser language than python. -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-23 13:15:00 -0400, Isaac Gouy igo...@yahoo.com said: I get the feeling I'm missing the joke? Yes, you are missing the joke. The point is that if python is 60x slower than C, even if there were not a GIL, it would require running the python program on a 60 core machine just reach parity with C. The existence of the GIL means that in reality you'd probably need a several hundred core machine running python just to equal what C can do on one core. Hence the 13375p34k pseudo quote - teh slowness on all ur cores! -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-23 23:51:02 -0400, Carl Banks pavlovevide...@gmail.com said: On Jul 23, 5:52 pm, Rui Maciel rui.mac...@gmail.com wrote: fft1976 wrote: How do you explain that something as inferior as Python beat Lisp in the market place despite starting 40 years later. Probably due to similar reasons that lead php to become remotely relevant . Well, the only reason PHP became relevant because it was an easy (emphasis added) to deploy solution in a single application domain, the web, that happened to explode. i.e., Python beat lisp because it is ~70% of lisp in a form that is much more palatable to the average programmer, just as php became popular because it is powerful enough to do websites and, most importantly, apprehensible to mediocre programmers and even some non-programmers. -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-21 05:37:27 -0400, milanj mil...@gmail.com said: Someone should mention Clozure CL - http://trac.clozure.com/openmcl As you can see there is os x, freebsd, linux, solaris and windows port and all of them use native threads (python still use green threads ?) and development is pretty alive, they did planty of developing last year[s], ccl licence permits you to deliver closed source programs ... CCL is promising bright feature to CL since looks like the insist of building stable implementation across most arch in use today Hear, hear! -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On 2009-07-21 19:06:02 -0400, Neil Hodgson nyamatongwe+thun...@gmail.com said: Python uses native threads. So it can be teh-slowness on all ur cores! http://shootout.alioth.debian.org/u64q/benchmark.php?test=nbodylang=all The global interpreter lock doesn't help much either. -- Raffael Cavallaro -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp for the C21
On 2007-05-04 11:32:14 -0400, Paul Rubin http://[EMAIL PROTECTED] said: Anyone who didn't love lisp in the 20th century has no heart. Anyone who still loves it in the 21st, has no head. By the same logic we should all be conservative Republicans. Given this implication, I'll stick with lisp, thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-17 07:54:28 -0500, Jon Harrop [EMAIL PROTECTED] said: What if eager impurity isn't the very nature of the problem but, rather, is the very nature of Tilton's chosen solution? That's the whole point which you keep missing - that a programming language is expressive precisely to the extent that it allows you to express the solution in the *programmer's* chosen form, not the paradigm imposed by the language. You look down your nose at cells, but if that's the way kenny conceived of the problem - as a graph of changing state, why should he be forced to reconceptualize it according to someone else's notion of programming correctness (be that pure functional or any other paradigm)? By asking this question you've implicitly admitted that to solve it *as he thought of it* in a pure functional language would require reconceptualizing it (i.e., the aforementioned jumping through hoops). We don't want to reconceptualize everything according to a particular paradigm, we want the flexibility to write the solution to the problem in the terms we think and talk about it, not the procrustean bed of pure functional semantics. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-17 07:54:28 -0500, Jon Harrop [EMAIL PROTECTED] said: After all, Haskell and OCaml are more popular that any given Lisp variant with similar features (e.g. pattern matching), AFAIK. What doublespeak! haskell and ocaml are more popular than any lisp library that tries to imitate Haskell and ocaml. So what! This only speaks to the relative unpopularity of imitating these features of haskell and ocaml when you already have lisp. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-17 12:49:46 -0500, Jon Harrop [EMAIL PROTECTED] said: For example, when faced with a problem best solved using pattern matching in Lisp, most Lisp programmers would reinvent an ad-hoc, informally specified and bug-ridden pattern matcher of their own. No, I think most of us would use an exising lisp pattern matcher, like cl-unification. By asking this question you've implicitly admitted that to solve it *as he thought of it* in a pure functional language would require reconceptualizing it (i.e., the aforementioned jumping through hoops). You are saying that solving it as he solved it requires a different solution. How does that make Lisp any different to the next language? Give kenny some credit for not being a complete idiot. Cells was originally designed to keep UI elements in sync with an internal application model. The UI domain is I/O, i.e., a side effect. To do this lazily invites situations where an inherently unpredictable user action forces a complex series of constraints to be computed before anything can be displayed to the user, so the user must wait while the lazy system catches up. To do this eagerly means that at any time, any unpredictable user action will cause already computed state to be displayed, because everything has been kept up to date automatically all along. I'm saying that he conceived of the problem in the most natural way - state with mutations - and implemented it that way. He was not forced by his language to reconceive it purely functionally, have haskell implement the default lazy semantics, only to require the programmer to find an escape hatch from this default laziness since what he really wants is eager evaluation of side effects (i.e., I/O - syncing of model state with GUI display). People habitually think of the world as state and mutations of state. We've been doing so for a minimum of tens of thousands of years, quite possibly a million or more. People are good at thinking about mutation. Maybe this should tell us something about the desirability of certain programming language semantics and that referential transparency is a bit overrated. We don't want to reconceptualize everything according to a particular paradigm, we want the flexibility to write the solution to the problem in the terms we think and talk about it, not the procrustean bed of pure functional semantics. Of the programming paradigms that can be implemented in Lisp, Lisp doesn't exactly make them easy. Moreover, every time you pick a random Lisp library off the wall to implement some feature already found in most other languages, you fragment the already tiny user base into even fewer people. Not all lisp programmers will be solving the same sorts of problems as each other, so naturally they'll be using different sets of libraries. This use of different sets of libraries for different tasks doesn't constitute laguage fragmentation. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-17 12:52:34 -0500, Jon Harrop [EMAIL PROTECTED] said: Implementing pattern matching does not mean imitating Haskell or OCaml. We were explicitly comparing lisp with haskell and ocaml. Adding features built into haskell and ocaml but not present in ANSI common lisp would therefore constitute imitating haskell and ocaml in the context of this discussion. Surely you don't think I'm unaware of the fact that haskell and ocaml weren't the first languages to use some form of pattern matching. I acutally used SNOBOL once upon a time. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-16 08:21:59 -0500, Paul Rubin http://[EMAIL PROTECTED] said: It never occurs to Lisp programmers that Lisp, too, might be a Blub. Of course it does - Thats why we try ocaml and haskell etc. It's just that we don't see the useful features of these languages as being sufficiently useful to compensate for their lack of the ability to easily do syntactic abstractions over a uniform syntax. There's no question that other languages have some features that common lisp does not (and vice versa). Lispers just can't abide being locked into a particular paradigm because a language doesn't have the basic features (macros and uniform syntax) necessary to provide new paradigms for ourselves when needed or wanted. For example, a common lisp with optional static typing on demand would be strictly more expressive than common lisp. But, take say, haskell; haskell's static typing is not optional (you can work around it, but you have to go out of your way to do so); haskell's pure functional semantics are not optional (again, workarounds possible to a limited extent). This requires you to conceive your problem solution (i.e., program) within the framework of a particular paradigm. This lock-in to a particular paradigm, however powerful, is what makes any such language strictly less expressive than one with syntactic abstraction over a uniform syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-16 13:58:37 -0500, Jon Harrop [EMAIL PROTECTED] said: Why do you think that uniform syntax is necessary to provide new paradigms when it is equivalent to infix syntax? Because it doesn't require one to write a parser for each new syntax for each new paradigm. In what way is Haskell's support for imperative programming limited? It requires one to frame everything in functional terms or to jump through the hoop of monads. Can you give an example of a Lisp macro that does something useful that you can't do in these other languages? It isn't a question of can't do in these other languages, it's a matter of can't do as easily in these other languages. Look at kenny tilton's cells. Its a dataflow paradigm built largely of macros. It goes completely against the semantics of haskell - cells is all about the eager evaluation of side effecting state mutation. Could you do it in haskell? Yes, in the greenspun/turing-completeness sense, but not nearly as easily as in common lisp, because the very paradigm - eager evaluation combined with side effecting state mutation - goes against the basic semantics of haskell. You'd have to jump through extra hoops to build a system whose very nature contradicts two of the semantic foundations of haskell - laziness and absense of side effects. Then there's the issue of the new syntax. Easy to build in lisp without learning another language - lisp macros use lisp. What little I've seen of caml4p looks like perlesque line noise. Ultimately I think that the defaults of both haskell and ocaml - functional, static typing, non-uniform syntax - are things I don't want as defaults, but as options for later in the development of only certain pieces of code. I don't want to be required to jump through the pure-functional, must-use-monads-for-any-side-effects, static-type, non-uniform-syntax hoops to express my ideas. It makes me less flexible in dealing with individual parts of a program differently. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On 2006-12-12 19:18:10 -0500, George Sakkis [EMAIL PROTECTED] said: If you mistakenly select an extra parenthesis or omit one, it's the same thing. Because you can't mistakenly select an extra paren or omit one in a lisp-aware editor. Whether its a commercial lisp IDE or emacs, you don't manually select s-expressions. You put your cursor/point at one paren and you tell the editor - with a keystroke or a mouse click - to find the matching paren and select everything contained between the two. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-17 07:03:19 -0400, Joachim Durchholz [EMAIL PROTECTED] said: I don't see static checking and explorative programming as opposites. Of course, in practice, environments that combine these don't seem to exist (except maybe in experimental or little-known state). Right. Unfortunately the philosophical leanings of those who design these two types of languages tend to show themselves as different tastes in development style - for example, static type advocates don't often want a very dynamic development environment that would allow a program to run for testing even when parts of it arent defined yet, and dynamic type advocates don't want a compiler preventing them from doing so because the program can't yet be proven statically correct. Dynamic typing advocates don't generally want a compiler error for ambiguous typing - for example, adding a float and an int - but static typing advocates generally do. Of course there's little reason one couldn't have a language that allowed the full range to be switchable so that programmers could tighten up compiler warnings and errors as the program becomes more fully formed. Unfortunately we're not quite there yet. For my tastes something like sbcl*, with its type inference and very detailed warnings and notes is as good as it gets for now. I can basically ignore warnings and notes early on, but use them to allow the compiler to improve the code it generates once the program is doing what I want correctly. [*] I don't mean to exclude other common lisp implementations that do type inference here - I just happen to use sbcl. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-16 05:22:08 -0400, Joachim Durchholz [EMAIL PROTECTED] said: And this is a typical dynamic type advocate's response when told that static typing has different needs: *I* don't see the usefulness of static typing so *you* shouldn't want it, either. But I haven't made this sort of argument. I never said you shouldn't use static typing if you want to. There are indeed types of software where one wants the guarantees provided by static type checks. For example, software that controls irreplaceable or very expensive equipment such as space craft, or software that can kill people if it fails such as software for aircraft or medical devices. The problem for static typing advocates is that most software is not of this type. There is a very large class of software where user inputs are unpredictable and/or where input data comes from an untrusted source. In these cases run-time checks are going to be needed anyway so the advantages of static type checking are greatly reduced - you end up doing run-time checks anyway, precisely the thing you were trying to avoid by doing static analysis. In software like this it isn't worth satisfying a static type checker because you don't get much of the benefit anyway as being able to run and test portions of a program before other parts are written (forward references to as yet nonexistent functions). Ideally one wants a language with switchable typing - static where possible and necessary, dynamic elsewhere. To a certain extent this is what common lisp does but it requires programmer declarations. Some implementations try to move beyond this by doing type inference and alerting the programmer to potential static guarantees that the programmer could make that would allow the compiler to do a better job. In effect the argument comes down to which kind of typing one thinks should be the default. Dynamic typing advocates think that static typing is the wrong default. The notion that static typing can prove program correctness is flawed - it can only prove that type constraints are not violated but not necessarily that program logic is correct. It seems to me that if we set aside that class of software where safety is paramount - mostly embedded software such as aircraft and medical devices - we are left mostly with efficiency concerns. The 80-20 rule suggests that most code doesn't really need the efficiency provided by static guarantees. So static typing should be invoked for that small portion of a program where efficiency is really needed and that dynamic typing should be the default elswhere. This is how common lisp works - dynamic typing by default with static guarantees available where one needs them. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-16 11:29:12 -0400, Raffael Cavallaro [EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com said: In software like this it isn't worth satisfying a static type checker because you don't get much of the benefit anyway text Dx¤ description £ text Dx¢ fromname as being able to run and test portions of a program before other parts are written (forward references to as yet nonexistent functions). I don't what bizarre key combination I accidentally hit here, but the original read: In software like this it isn't worth satisfying a static type checker because you don't get much of the benefit anyway and it means forgoing such advantages of dynamic typing as being able to run and test portions of a program before other parts are written (forward references to as yet nonexistent functions). -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-16 05:22:08 -0400, Joachim Durchholz [EMAIL PROTECTED] said: And this is a typical dynamic type advocate's response when told that static typing has different needs: *I* don't see the usefulness of static typing so *you* shouldn't want it, either. But I haven't made this sort of argument. I never said you shouldn't use static typing if you want to. There are indeed types of software where one wants the guarantees provided by static type checks. For example, software that controls irreplaceable or very expensive equipment such as space craft, or software that can kill people if it fails such as software for aircraft or medical devices. The problem for static typing advocates is that most software is not of this type. There is a very large class of software where user inputs are unpredictable and/or where input data comes from an untrusted source. In these cases run-time checks are going to be needed anyway so the advantages of static type checking are greatly reduced - you end up doing run-time checks anyway, precisely the thing you were trying to avoid by doing static analysis. In software like this it isn't worth satisfying a static type checker because you don't get much of the benefit anyway and it means forgoing such advantages of dynamic typing as being able to run and test portions of a program before other parts are written (forward references to as yet nonexistent functions). Ideally one wants a language with switchable typing - static where possible and necessary, dynamic elsewhere. To a certain extent this is what common lisp does but it requires programmer declarations. Some implementations try to move beyond this by doing type inference and alerting the programmer to potential static guarantees that the programmer could make that would allow the compiler to do a better job. In effect the argument comes down to which kind of typing one thinks should be the default. Dynamic typing advocates think that static typing is the wrong default. The notion that static typing can prove program correctness is flawed - it can only prove that type constraints are not violated but not necessarily that program logic is correct. It seems to me that if we set aside that class of software where safety is paramount - mostly embedded software such as aircraft and medical devices - we are left mostly with efficiency concerns. The 80-20 rule suggests that most code doesn't really need the efficiency provided by static guarantees. So static typing should be invoked for that small portion of a program where efficiency is really needed and that dynamic typing should be the default elswhere. This is how common lisp works - dynamic typing by default with static guarantees available where one needs them. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-16 05:22:08 -0400, Joachim Durchholz [EMAIL PROTECTED] said: And this is a typical dynamic type advocate's response when told that static typing has different needs: *I* don't see the usefulness of static typing so *you* shouldn't want it, either. But I haven't made this sort of argument. I never said you shouldn't use static typing if you want to. There are indeed types of software where one wants the guarantees provided by static type checks. For example, software that controls irreplaceable or very expensive equipment such as space craft, or software that can kill people if it fails such as software for aircraft or medical devices. The problem for static typing advocates is that most software is not of this type. There is a very large class of software where user inputs are unpredictable and/or where input data comes from an untrusted source. In these cases run-time checks are going to be needed anyway so the advantages of static type checking are greatly reduced - you end up doing run-time checks anyway, precisely the thing you were trying to avoid by doing static analysis. In software like this it isn't worth satisfying a static type checker because you don't get much of the benefit anyway and it means forgoing such advantages of dynamic typing as being able to run and test portions of a program before other parts are written (forward references to as yet nonexistent functions). Ideally one wants a language with switchable typing - static where possible and necessary, dynamic elsewhere. To a certain extent this is what common lisp does but it requires programmer declarations. Some implementations try to move beyond this by doing type inference and alerting the programmer to potential static guarantees that the programmer could make that would allow the compiler to do a better job. In effect the argument comes down to which kind of typing one thinks should be the default. Dynamic typing advocates think that static typing is the wrong default. The notion that static typing can prove program correctness is flawed - it can only prove that type constraints are not violated but not necessarily that program logic is correct. It seems to me that if we set aside that class of software where safety is paramount - mostly embedded software such as aircraft and medical devices - we are left mostly with efficiency concerns. The 80-20 rule suggests that most code doesn't really need the efficiency provided by static guarantees. So static typing should be invoked for that small portion of a program where efficiency is really needed and that dynamic typing should be the default elswhere. This is how common lisp works - dynamic typing by default with static guarantees available where one needs them. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-16 17:59:07 -0400, Joachim Durchholz [EMAIL PROTECTED] said: I think it's easier to start with a good (!) statically-typed language and relax the checking, than to start with a dynamically-typed one and add static checks. With the right restrictions, a language can make all kinds of strong guarantees, and it can make it easy to construct software where static guarantees abound. If the mechanisms are cleverly chosen, they interfere just minimally with the programming process. (A classical example it Hindley-Milner type inference systems. Typical reports from languages with HM systems say that you can have it verify thousand-line programs without a single type annotation in the code. That's actually far better than you'd need - you'd *want* to document the types at least on the major internal interfaces after all *grin*.) With a dynamically-typed language, programming style tends to evolve in directions that make it harder to give static guarantees. This is purely a matter of programming style. For explorative programming it is easier to start with dynamic typing and add static guarantees later rather than having to make decisions about representation and have stubs for everything right from the start. The lisp programming style is arguably all about using heterogenous lists and forward references in the repl for everything until you know what it is that you are doing, then choosing a more appropriate representation and filling in forward references once the program gels. Having to choose representation right from the start and needing working versions (even if only stubs) of *every* function you call may ensure type correctness, but many programmers find that it also ensures that you never find the right program to code in the first place. This is because you don't have the freedom to explore possible solutions without having to break your concentration to satisfy the nagging of a static type checker. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-14 16:36:52 -0400, Pascal Bourguignon [EMAIL PROTECTED] said: In lisp, all lists are homogenous: lists of T. CL-USER 123 (loop for elt in (list #\c 1 2.0d0 (/ 2 3)) collect (type-of elt)) (CHARACTER FIXNUM DOUBLE-FLOAT RATIO) i.e., heterogenous in the common lisp sense: having different dynamic types, not in the H-M sense in which all lisp values are of the single union type T. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-14 09:42:25 -0400, [EMAIL PROTECTED] (Torben Ægidius Mogensen) said: It takes longer for the average programmer to get the program working in the dynamically typed language. Though I agree with much of your post I would say that many here find the opposite to be true - it takes us longer to get a program working in a statically typed language because we have to keep adding/changing things to get the compiler to stop complaining and actually compile and run a program which would be perfectly permissible in a dynamically typed language such as common lisp - for example - heterogeneous lists and forward references to as yet non-existent functions. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
On 2006-06-14 15:04:34 -0400, Joachim Durchholz [EMAIL PROTECTED] said: Um... heterogenous lists are not necessarily a sign of expressiveness. The vast majority of cases can be transformed to homogenous lists (though these might then contain closures or OO objects). As to references to nonexistent functions - heck, I never missed these, not even in languages without type inference :-) I don't hold that they are a sign of *in*expressiveness either. They are just typical of highly dynamic programming environments such as Lisp or Smalltalk. This is a typical static type advocate's response when told that users of dynamically typed languages don't want their hands tied by a type checking compiler: *I* don't find those features expressive so *you* shouldn't want them. You'll have to excuse us poor dynamically typed language rubes - we find these features expressive and we don't want to give them up just to silence a compiler whose static type checks are of dubious value in a world where user inputs of an often unpredictable nature can come at a program from across a potentially malicious internet making run-time checks a practical necessity. -- http://mail.python.org/mailman/listinfo/python-list
Re: Only one obvious way...
On 2006-05-08 02:51:22 -0400, [EMAIL PROTECTED] said: The phrase only one obvious way... is nearly the most absurd marketing bullshit I have ever heard; topped only by it fits your brain. Why are so many clearly intelligent and apparently self-respecting hard-core software engineers repeating this kind of claptrap? Really should read only one obvious way to people with a similar background and little creativity or it fits your brain if you've mostly programmed in algol syntax languages and alternative ideas make said brain hurt. trimmed to c.l.python and c.l.lisp -- http://mail.python.org/mailman/listinfo/python-list
