Re: Python and Flaming Thunder
On Jun 7, 10:24 am, Sam Denton [EMAIL PROTECTED] wrote: I've long believed that '=' should be banned from programming languages. Use '==' for equality tests, and ':=' for assignments. That's an interesting suggestion that I don't recall hearing anyone else ever mention. On Jun 7, 10:24 am, Sam Denton [EMAIL PROTECTED] wrote: John Salerno wrote: Dave Parker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: --- For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. --- Aw, come on. I'm a novice programmer but even after reading the most basic of introductions to a programming language I can tell that x is being assigned one value, then another. I've long believed that '=' should be banned from programming languages. Use '==' for equality tests, and ':=' for assignments.- Hide quoted text - - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
John Salerno wrote: Dave Parker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: --- For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. --- Aw, come on. I'm a novice programmer but even after reading the most basic of introductions to a programming language I can tell that x is being assigned one value, then another. I've long believed that '=' should be banned from programming languages. Use '==' for equality tests, and ':=' for assignments. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Kind of like how this year's program won't work on next year's Python? Except Flaming Thunder is faster. ;) To be fair (and accurate), Python 3.0 has been in development for a long time without being marketed for production use. Furthermore, there is no reason to think 3.0 will take over next year. It's already been stated that it may be years before it does, and meanwhile 2.x will continue to be developed. Also, and this is purely my novice opinion, it seems like the incompatibilites are mainly going to come from program written in older versions of Python. The big, noticeable changes in 3.0 hardly seem to affect anything you'll write in recent versions of Python (and that 2to3 won't fix otherwise). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: --- For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. --- Aw, come on. I'm a novice programmer but even after reading the most basic of introductions to a programming language I can tell that x is being assigned one value, then another. It doesn't seem fair to take statements like the above out of the context of a program and then ask teachers and students about it. This statement: 2 + 2 = 4 means something in the context of an elementary math class, but is clearly not an assignment statement in Python. But I've never encountered anyone who was confused by this distinction, as long as you know where this line belongs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Thu, Jun 5, 2008 at 9:43 AM, John Salerno [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: --- For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. --- Aw, come on. I'm a novice programmer but even after reading the most basic of introductions to a programming language I can tell that x is being assigned one value, then another. It doesn't seem fair to take statements like the above out of the context of a program and then ask teachers and students about it. This statement: 2 + 2 = 4 means something in the context of an elementary math class, but is clearly not an assignment statement in Python. But I've never encountered anyone who was confused by this distinction, as long as you know where this line belongs. Yeah, that's sort of like I mentioned earlier in the thread about there being a time dependence between the two. Not only that, but I just realized that Dave has trotted out several times the notion of representing (and solving) a quadratic equation in FT. Well, let's see... (x-9)**2 - 1 = (too lazy to do the expansion to write in ax**2 + bx + c format) = 0... solve solve solve... wait, x = 8 and x = 10! But how can that be, Dave? You and your elementary kids just told me I can't have two values for x... ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Jun 5, 7:57 am, Dan Upton [EMAIL PROTECTED] wrote: ... wait, x = 8 and x = 10! But how can that be, Dave? You and your elementary kids just told me I can't have two values for x... x = 8 OR x = 10. ;) By the way, realtime fullscreen 3D graphics are now up and running under Windows. Check out the News and Docs at http://www.flamingthunder.com/ On Jun 5, 7:57 am, Dan Upton [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 9:43 AM, John Salerno [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: --- For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. --- Aw, come on. I'm a novice programmer but even after reading the most basic of introductions to a programming language I can tell that x is being assigned one value, then another. It doesn't seem fair to take statements like the above out of the context of a program and then ask teachers and students about it. This statement: 2 + 2 = 4 means something in the context of an elementary math class, but is clearly not an assignment statement in Python. But I've never encountered anyone who was confused by this distinction, as long as you know where this line belongs. Yeah, that's sort of like I mentioned earlier in the thread about there being a time dependence between the two. Not only that, but I just realized that Dave has trotted out several times the notion of representing (and solving) a quadratic equation in FT. Well, let's see... (x-9)**2 - 1 = (too lazy to do the expansion to write in ax**2 + bx + c format) = 0... solve solve solve... wait, x = 8 and x = 10! But how can that be, Dave? You and your elementary kids just told me I can't have two values for x... ;)- Hide quoted text - - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Thu, 29 May 2008 17:57:45 -0400, D'Arcy J.M. Cain wrote: I guess I am still new to this group and don't understand its charter. I wasn't aware that it was a Flaming Blunder group. Can someone please point me to a newsgroup or mailing list dedicated to the Python programming language? By discussing language design of FT compared to other languages you can learn about Python. We all know that Python is brilliant -- here's the opportunity to think about why it is. :-) And it's basically only this very long thread, so it's easy to filter and ignore in a decent news reader. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: I guess I am still new to this group and don't understand its charter. I wasn't aware that it was a Flaming Blunder group. Can someone please point me to a newsgroup or mailing list dedicated to the Python programming language? A minor point of netiquette: it's fine to reply by email to a message if you want to make a point off group, but if you are following up to the newsgroup/mailing list please don't CC the original sender: they will see the message in any case on the newsgroup and getting it twice is just likely to annoy. I don't understand your problem: it's just a single thread so killfile or skip it. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Duncan Booth writes: [...] I don't understand your problem: it's just a single thread so killfile or skip it. Although I agree with you that there is no problem, *this* is not a good justification for this thread. One should stay on topic in *every* thread. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 2008-05-30, Torsten Bronger [EMAIL PROTECTED] wrote: Hall?chen! Duncan Booth writes: [...] I don't understand your problem: it's just a single thread so killfile or skip it. Although I agree with you that there is no problem, *this* is not a good justification for this thread. One should stay on topic in *every* thread. I've noticed that a lot of things that should be, aren't. The percentage of off-topic threads in c.l.p is extraordinarily low by normal Usenet standards. One oughtn't complain about it lest one jinx things and reduce c.l.p to the state of the rest of Usenet. I wouldn't even consider the thread all that OT, but maybe that's just me. -- Grant Edwards grante Yow! ! Everybody out of at the GENETIC POOL! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Grant Edwards writes: On 2008-05-30, Torsten Bronger [EMAIL PROTECTED] wrote: Duncan Booth writes: [...] I don't understand your problem: it's just a single thread so killfile or skip it. Although I agree with you that there is no problem, *this* is not a good justification for this thread. One should stay on topic in *every* thread. [...] I wouldn't even consider the thread all that OT, but maybe that's just me. Me too, and therefore I see no problem. But one shouldn't break the rules, relying on all others sticking to them. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker [EMAIL PROTECTED] wrote: Catch doesn't return just error types or numbers, it can return any object returned by the statements that are being caught; catch doesn't care what type they are. For example: Writeline catch(set x to hello world.). will write hello world. I really don't get this. Surely the point about an error being thrown to a catch statement is that the error path is separate from the normal execution path? What you are doing here is ensuring that unexpected errors have no chance at all of propagating up to the top level: they are invariably going to get caught by some other handler that was installed just because someone was too lazy to write a set statement followed by a writeline. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Thu, May 29, 2008 at 3:36 AM, Duncan Booth [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: Catch doesn't return just error types or numbers, it can return any object returned by the statements that are being caught; catch doesn't care what type they are. For example: Writeline catch(set x to hello world.). will write hello world. I really don't get this. Surely the point about an error being thrown to a catch statement is that the error path is separate from the normal execution path? What you are doing here is ensuring that unexpected errors have no chance at all of propagating up to the top level: they are invariably going to get caught by some other handler that was installed just because someone was too lazy to write a set statement followed by a writeline. It also looks like an overloading of catch, semantically similar to the C: int retcode; if( retcode = doSomethingThatReturns0or1() ) printf(Hello world); Again, I don't think you want to start overloading your exception-handling mechanism. If you want a set expression to be equal to the l-value at the end, that's fine, but there's no reason that catch should evaluate to an object or an integral- or real-valued exception in error cases, or of the last statement of the block if there's no error. (Evaluating a block to be equal to its last statement is okay, I guess; I know at least that there's a call in Scheme that lets you do a more imperative programming style in the functional language--whether that's a good thing is probably a holy war.) I just think if you're shooting for an easily understandable language, overloading error handling requires more thought on the programmer's part, not less, because they have to reason about all outcomes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dan Upton [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 3:36 AM, Duncan Booth [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: Catch doesn't return just error types or numbers, it can return any object returned by the statements that are being caught; catch doesn't care what type they are. For example: Writeline catch(set x to hello world.). will write hello world. I really don't get this. Surely the point about an error being thrown to a catch statement is that the error path is separate from the normal execution path? What you are doing here is ensuring that unexpected errors have no chance at all of propagating up to the top level: they are invariably going to get caught by some other handler that was installed just because someone was too lazy to write a set statement followed by a writeline. It also looks like an overloading of catch, semantically similar to the C: int retcode; if( retcode = doSomethingThatReturns0or1() ) printf(Hello world); Again, I don't think you want to start overloading your exception-handling mechanism. If you want a set expression to be equal to the l-value at the end, that's fine, but there's no reason that catch should evaluate to an object or an integral- or real-valued exception in error cases, or of the last statement of the block if there's no error. (Evaluating a block to be equal to its last statement is okay, I guess; I know at least that there's a call in Scheme that lets you do a more imperative programming style in the functional language--whether that's a good thing is probably a holy war.) I just think if you're shooting for an easily understandable language, overloading error handling requires more thought on the programmer's part, not less, because they have to reason about all outcomes. I like BCPL's way of handling block expressions: VALOF is followed by a block of statements and within that block RESULTIS gives the result. This lets you exit the block early (just like a return statement does), but without returning from the current procedure (unless of course the entire body of the procedure is a VALOF block). Naturally the result has to be explicitly specified (otherwise the value is undefined). Maybe FT should do something similar: Writeline value of (set x to hello world. Result is x.). and catch can then stick to catching errors. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 11:46 pm, Dave Parker [EMAIL PROTECTED] wrote: On May 28, 3:19 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: Kind of like how this year's program won't work on next year's Python? For somebody who has admitted to have only very rudimentary knowledge of python that's a pretty bold statement, don't you think? Everthing I know, I learned from Wikipedia. ;) http://en.wikipedia.org/wiki/Python_(programming_language)#Timeline_a... Like Perl 6, Python 3.0 will break backward compatibility. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail) ... Hi Dave, Why don't you use your own FT google group to explain why FT is so much better than other languages (python included). Then you post __once__ that you started such a conversation, and that's it. I'm sure all smart developers will have a look and they will all follow you. The other ones (the ones, including me, who are interested in reading about python) will keep on having narrow minded conversations about their favorite snake-oriented language. Poor guys that we are, we won't even realize how superior you are, how great your language is, how faster FT is, etc... We will be jobless in no time, and soon you will have 90% of the language market and make tons of money. I wish I could be smart enough to realize this. Unfortunately, I'm just s stupid. So please don't steal my brain-cpu cycles, I need them for better purposes. Thanks for helping me -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 11:46 pm, Dave Parker [EMAIL PROTECTED] wrote: On May 28, 3:19 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: Kind of like how this year's program won't work on next year's Python? Like Perl 6, Python 3.0 will break backward compatibility. There is no requirement that Python 2.x code will run unmodified on Python 3.0. See? 2.x - 3.x. Major version. Not next week's python, not next year's python, but the next mayor version of python. With a clean, well documented, upgrade path. Unlike next month's Flaming Thunder. (Unless you are producing a new major version every week, in which case I shut up, and may think about buying several versions only so you must keep maintaining all of them) -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
I guess I am still new to this group and don't understand its charter. I wasn't aware that it was a Flaming Blunder group. Can someone please point me to a newsgroup or mailing list dedicated to the Python programming language? -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Thu, May 29, 2008 at 5:57 PM, D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: I guess I am still new to this group and don't understand its charter. I wasn't aware that it was a Flaming Blunder group. Can someone please point me to a newsgroup or mailing list dedicated to the Python programming language? Yeah, but if you look past the FT is better than Python propaganda, there's some interesting discussion of language design. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dan Upton wrote: I just think if you're shooting for an easily understandable language, overloading error handling requires more thought on the programmer's part, not less, because they have to reason about all outcomes Duncan Booth wrote: Maybe FT should do something similar: Writeline value of (set x to hello world. Result is x.). I like the value of syntax. You guys have convinced me to reconsider overloading the error handling. Thank you both. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 30, 8:02 am, Dan Upton [EMAIL PROTECTED] wrote: Yeah, but if you look past the FT is better than Python propaganda, there's some interesting discussion of language design. Which is more appropriate on a group focused on such a topic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Does this mean that Flaming Thunder requires explicit checking rather than offering exceptions? Right now, yes, Flaming Thunder has minimal error handling. But error handling is rising on the list of priorities for the next few weeks (arrays, matrices, and 3D graphics are the hightest). I think in a month or two, Flaming Thunder will be using catch/throw exception and error handling. So, for example: Set result to catch(read x from input.txt.). If result is an error then go to quit. If not caught, errors will propagate up and if they they hit the top level, cause the program to write an error message and exit. Using only catch instead of try/catch has several advantages that I can see. 1) it gets rid of all the impotent try/catch/throw statements cluttering up Java, etc. 2) since all Flaming Thunder statements return values (like C statements), Catch also gives you a single, uniform, syntactically unambiguous way to embed statements (or whole statement lists) into expressions -- without causing the syntactic problems of = statements in if statements or the obfuscation of question mark notation, etc. For example: If catch(set x to y+z.) 0.1 then go to tinyanswer. On May 22, 4:19 pm, Brian Quinlan [EMAIL PROTECTED] wrote: Dave Parker wrote: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Hey Dave, Does this mean that Flaming Thunder requires explicit checking rather than offering exceptions? Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker [EMAIL PROTECTED] wrote: Catch also gives you a single, uniform, syntactically unambiguous way to embed statements (or whole statement lists) into expressions -- without causing the syntactic problems of = statements in if statements or the obfuscation of question mark notation, etc. For example: If catch(set x to y+z.) 0.1 then go to tinyanswer. So what does this do exactly if the set throws an error? Is the error message printed at the top level going to be telling you about the failed addition or the failed comparison? Why do you need the catch anyway, if a statement is just an expression why can't you just put the statement into parentheses? For that matter, is there any way to distinguish between different errors and only catch particular ones? A bare except clause in Python is usually a signal of bad code: when handling errors you only want the errors you have anticipated, and want to be sure that any unexpected errors don't get caught. You have a great opportunity to avoid making some of the same mistakes that Python is trying to get out of. For example as of Python 2.5 KeyboardInterrupt and SystemExit to longer inherit from Exception. That means a bare except in Python no longer catches either of those: if you want to handle either of these exceptions you have to be explicit about it. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... I enjoyed the discussion of how different languages handle the notion of =; I learned something new. Thanks. On May 22, 9:30 am, Nick Craig-Wood [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. This is a common feature in functional languages... Eg Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1 X = 8. 8 2 X = 10. ** exception error: no match of right hand side value 10 3 That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... -- Nick Craig-Wood [EMAIL PROTECTED] --http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
If catch(set x to y+z.) 0.1 then go to tinyanswer. So what does this do exactly if the set throws an error? I think the catch should catch the error thrown by set, compare it to 0.1, the comparison will not return true because the error is not less than 0.1, and so the go-to to tinyanswer will not be taken. Is the error message printed at the top level going to be telling you about the failed addition or the failed comparison? I don't think there will be an error message at the top in the case above, because I don't think the comparison should fail -- the comparision will return that it is not true that the error is less than 0.1. Why do you need the catch anyway, if a statement is just an expression why can't you just put the statement into parentheses? Statements return values, but statements are not just expressions. Statements are more about control-flow and side-effects; expressions are more about returning values. Putting a statement into parentheses in a context where expressions are also allowed in parentheses is (or can be) both lexically and visually ambiguous. That's why C had to resort to the confusing = vs == notation -- to disambiguate the two cases. The catch keyword unambiguously alerts the reader that the parenthesis contain a statement (or a whole list of statements). For that matter, is there any way to distinguish between different errors and only catch particular ones? I think the catch function should catch all of the errors (and the non- error result if no error occured), so I think distinguishing the error would have to come after. Maybe something like: Set result to catch(read x from input.txt.). If result = dividebyzeroerror then ... else throw result. I'm open to alternate suggestions, though. You have a great opportunity to avoid making some of the same mistakes that Python is trying to get out of. I'm sure that I'll make my own new and different errors. :) However, I really appreciate your comments because maybe I'll make fewer errors. Or at least, correct them faster. On May 28, 7:52 am, Duncan Booth [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: Catch also gives you a single, uniform, syntactically unambiguous way to embed statements (or whole statement lists) into expressions -- without causing the syntactic problems of = statements in if statements or the obfuscation of question mark notation, etc. For example: If catch(set x to y+z.) 0.1 then go to tinyanswer. So what does this do exactly if the set throws an error? Is the error message printed at the top level going to be telling you about the failed addition or the failed comparison? Why do you need the catch anyway, if a statement is just an expression why can't you just put the statement into parentheses? For that matter, is there any way to distinguish between different errors and only catch particular ones? A bare except clause in Python is usually a signal of bad code: when handling errors you only want the errors you have anticipated, and want to be sure that any unexpected errors don't get caught. You have a great opportunity to avoid making some of the same mistakes that Python is trying to get out of. For example as of Python 2.5 KeyboardInterrupt and SystemExit to longer inherit from Exception. That means a bare except in Python no longer catches either of those: if you want to handle either of these exceptions you have to be explicit about it. -- Duncan Boothhttp://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wednesday 28 May 2008 09:22:53 am Dave Parker wrote: I think in a month or two, Flaming Thunder will be using catch/throw exception and error handling. So, for example: Nice... Flaming Thunder sure evolves quickly. Too quickly to be considered a 'feature' of the language. Following your posts in this thread, I see that you 'plan to add soon' every cool feature that every other language seems to have. That means that I won't have to test my program only against every major versions of Flaming Thunder... i will have to test it with every week's version. With no certainty whatsoever that today's program will work on tomorrow's FT. Why don't you wait a bit, until Flaming Thunder is mature enough to be stable, before trying to advertise it to us? And in the meantime, some of us are going to keep trying to add all the features we've always wanted, to the next major version of Python. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, May 28, 2008 at 11:09 AM, Dave Parker [EMAIL PROTECTED] wrote: If catch(set x to y+z.) 0.1 then go to tinyanswer. So what does this do exactly if the set throws an error? I think the catch should catch the error thrown by set, compare it to 0.1, the comparison will not return true because the error is not less than 0.1, and so the go-to to tinyanswer will not be taken. The semantics you're describing aren't clear here. I suppose that's sort of reasonable, given that you haven't implemented it yet, but let's think about it for a second. You say the catch construct should catch the error thrown by set, but there's no reason set itself should throw any sort of error in the sense of an exception--in a statement like Set x to SomeFunctionThatCanBlowUp(), the semantics should clearly be that the error comes from the function. In a simple addition statement, that makes no sense. So then I considered that maybe you meant the error in the sense of some determination of floating point roundoff error, but that can't be it, since you've claimed recently a big win over Python with FT in that it has no roundoff error. So what, exactly, is the error you could even be catching in that? Assuming the answer is You're right, there's no actual error that could generated by that assignment, there are two options: the compiler optimizes it away, or you throw a compile-time error. The latter makes more sense, as someone trying to catch an exception where one can't possibly exist probably indicates a misunderstanding of what's going on. ... That's why C had to resort to the confusing = vs == notation -- to disambiguate the two cases. The catch keyword unambiguously alerts the reader that the parenthesis contain a statement (or a whole list of statements). However, I think overloading your catch error types to include objects (or integral values, I guess, your example below isn't clear) along with real values (ignoring the bit above about whether floating-point assignment could throw an error) makes things confusing. It's nice that catch(stuff) indicates that there's one or more statements inside, but so does indentation in Python, bracketing in C/C++, Begin/End in insert language here, and so forth, but it doesn't give any indication to what could come out and ideally, only one thing (or its descendants in a type hierarchy) can come out. (I suppose this can be solved by overloading your comparison operators.) Beyond that, I think you would want a good mechanism for comparing ranges of values if you want to make exceptions/errors real-valued. For that matter, is there any way to distinguish between different errors and only catch particular ones? I think the catch function should catch all of the errors (and the non- error result if no error occured), so I think distinguishing the error would have to come after. Maybe something like: Set result to catch(read x from input.txt.). If result = dividebyzeroerror then ... else throw result. I'm open to alternate suggestions, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 12:09 pm, Luis Zarrabeitia [EMAIL PROTECTED] wrote: Following your posts in this thread, I see that you 'plan to add soon' every cool feature that every other language seems to have. I've already added a lot of them. For example, loops that don't need looping variables: For 1000 times do ... Explicit infinite loops: For forever do ... I don't those are features that every other language seems to have, not even Python. Plus, by this weekend, built-in compiled fullscreen 3D graphics will be in, too. With no certainty whatsoever that today's program will work on tomorrow's FT. Kind of like how this year's program won't work on next year's Python? Except Flaming Thunder is faster. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Kind of like how this year's program won't work on next year's Python? For somebody who has admitted to have only very rudimentary knowledge of python that's a pretty bold statement, don't you think? Except Flaming Thunder is faster. ;) Faster in execution speed for a very limited domain of problems - maybe. But unless it grows support for structured data types, arrays and maybe even an object system - it's nothing but a toy language. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 12:48 pm, Dan Upton [EMAIL PROTECTED] wrote: there's no reason set itself should throw any sort of error in the sense of an exception--in a statement like Set x to SomeFunctionThatCanBlowUp(), the semantics should clearly be that the error comes from the function. In a simple addition statement, that makes no sense. For example: Set z to catch(somefunctionthatmightblowup(...)). If catch(set x to y+z.) 0.1 then go to tinyanswer. Or something like that. Or if you change the + to a / and z is 0.0, for example, then it could cause a divide-by-zero exception. There is no guarantee that the + won't cause an exception, given that there is no guarantee that y and z are both numeric. However, I think overloading your catch error types to include objects (or integral values, I guess, your example below isn't clear) along with real values (ignoring the bit above about whether floating-point assignment could throw an error) makes things confusing. Catch doesn't return just error types or numbers, it can return any object returned by the statements that are being caught; catch doesn't care what type they are. For example: Writeline catch(set x to hello world.). will write hello world. It's nice that catch(stuff) indicates that there's one or more statements inside, but so does indentation in Python, bracketing in C/C++, Begin/End in insert language here, and so forth, ... Except that in those languages, I don't think that the indentation, bracketing, Begin/End, etc, can be used in expressions. Catch can. For example, catch will return the final value of z: If catch(Set x to y+z. Set y to x+z. Set z to 1/(x+y).) 0.1 then go to tinyanswer. Beyond that, I think you would want a good mechanism for comparing ranges of values if you want to make exceptions/errors real-valued. I am thinking that exceptions/errors should have any kinds of values the programmer wants to give them. Some people prefer error numbers, some prefer error messages, some prefer error identifiers, etc. I am thinking that the Error function should simply take a list of whatever objects the user wants to throw, and throw them. For example, if the programmer wanted an error number and an error message for a particular error: If x 10 then throw error(10, Please enter a number = 10). They could then do something like: Set result to catch(funtionthatcouldblowup(...)). If result is an error then if result(1) = 10 then writeline result(2). Thank you for your comments, they are helping me to clarify my own thinking on error handling in general and on catch in particular. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 3:19 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: Kind of like how this year's program won't work on next year's Python? For somebody who has admitted to have only very rudimentary knowledge of python that's a pretty bold statement, don't you think? Everthing I know, I learned from Wikipedia. ;) http://en.wikipedia.org/wiki/Python_(programming_language)#Timeline_and_compatibility Like Perl 6, Python 3.0 will break backward compatibility. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail) ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 5:19 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: Kind of like how this year's program won't work on next year's Python? For somebody who has admitted to have only very rudimentary knowledge of python that's a pretty bold statement, don't you think? Except Flaming Thunder is faster. ;) Faster in execution speed for a very limited domain of problems - maybe. But unless it grows support for structured data types, arrays and maybe even an object system - it's nothing but a toy language. I wouldn't even call it a toy language, it seems more like a sandbox for fumbling around in compiler technology and language design (loosely speaking). Fun as a research or alpha-stage project but nowhere near production-ready. To be fair, the graphics look cool and the single-asset 8-by-8 shotgun cross compiler, written entirely in assembly language sounds impressive from an implementation point of view, in the sense that building Deep Blue with nothing but NAND gates would; utterly impressive and pointless at the same time. Which goes to prove that hardcore hackers don't necessarily make decent language designers. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker schrieb: On May 28, 3:19 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: Kind of like how this year's program won't work on next year's Python? For somebody who has admitted to have only very rudimentary knowledge of python that's a pretty bold statement, don't you think? Everthing I know, I learned from Wikipedia. ;) http://en.wikipedia.org/wiki/Python_(programming_language)#Timeline_and_compatibility Like Perl 6, Python 3.0 will break backward compatibility. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail) ... You should read further: However, a tool called 2to3 does most of the job of translation, pointing out areas where it wasn't sure using comments or warnings. Even in an alpha stage 2to3 appears to be fairly successful at performing the translation. And all this is about Py3k- nobody forces anybody to leave python 2.x series. I think you should contort yourself a bit wrt backwards compatibility and stability - given that FT is by no means an established and productive tool. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
To be fair, the graphics look cool and the single-asset 8-by-8 shotgun cross compiler, written entirely in assembly language sounds impressive from an implementation point of view, in the sense that building Deep Blue with nothing but NAND gates would; utterly impressive and pointless at the same time. Which goes to prove that hardcore hackers don't necessarily make decent language designers. The number 8 seems to play an important role for Dave - his graphics claims to be 8D. I wasn't aware that string-theory was available as practical application on my screen already... Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 28 Mag, 23:13, Dave Parker [EMAIL PROTECTED] wrote: On May 28, 12:09 pm, Luis Zarrabeitia [EMAIL PROTECTED] wrote: Following your posts in this thread, I see that you 'plan to add soon' every cool feature that every other language seems to have. I've already added a lot of them. For example, loops that don't need looping variables: For 1000 times do ... Explicit infinite loops: For forever do ... I don't those are features that every other language seems to have, not even Python. Plus, by this weekend, built-in compiled fullscreen 3D graphics will be in, too. With no certainty whatsoever that today's program will work on tomorrow's FT. Kind of like how this year's program won't work on next year's Python? Except Flaming Thunder is faster. ;) On 28 Mag, 23:13, Dave Parker [EMAIL PROTECTED] wrote: On May 28, 12:09 pm, Luis Zarrabeitia [EMAIL PROTECTED] wrote: Following your posts in this thread, I see that you 'plan to add soon' every cool feature that every other language seems to have. I've already added a lot of them. For example, loops that don't need looping variables: For 1000 times do ... Explicit infinite loops: For forever do ... I don't those are features that every other language seems to have, not even Python. Plus, by this weekend, built-in compiled fullscreen 3D graphics will be in, too. With no certainty whatsoever that today's program will work on tomorrow's FT. Kind of like how this year's program won't work on next year's Python? Except Flaming Thunder is faster. ;) This is nonsense. Python 2.x is around since... what is it? Almost 10 years? It lasted that long maintaining retro-compatibility between the various versions. It's very funny that you point your finger at Python's compatibility as a factor of weakness when your FT breaks it *every week*. Before trying to convince whoever that your FT is better than Python you should first decide what to do with your own product by starting to implement all that *basic* features which are common to all modern languages (arrays, OOP, error handling, data structures, Unicode support, etc...). Once you do that, ask yourself if the way you did it was good/ reliable, ask users what they think about it, and apply changes as necessary. At that point you'll be ready to start publicizing FT as an alternative in respect to other languages. Currenlty you're trying to push something which is not even a pre- alpha over something else (Python) which has been around since about 20 years and it is known to be one of the cleanest and more elegant languages around. --- Giampaolo http://code.google.com/p/pyftpdlib -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 23, 3:35 am, Charles Hixson [EMAIL PROTECTED] wrote: On Thursday 22 May 2008 13:30:07 Nick Craig-Wood wrote: ... From Armstrong's book: The expression Pattern = Expression causes Expression to be evaluated and the result matched against Pattern. The match either succeeds or fails. If the match succeeds any variables occurring in Pattern become bound. It is a very powerful idea and one which (along with the concurrency and message passing from Erlang) has been implemented for python :- http://candygram.sourceforge.net/ I've been reading the Erlang book and I have to say it has given me a lot of insight into python... Although when comparing Candygram with Erlang it's worth noting that Candygram is bound to one processor, where Erlang can operate on multiple processors. (I'd been planning on using Candygram for a project at one point, but this made it unusable.) lol, nice name. Also surprisingly relevant to the thread: candygrammar: n. A programming-language grammar that is mostly syntactic sugar; the term is also a play on ‘candygram’. COBOL, Apple's Hypertalk language, and a lot of the so-called ‘4GL’ database languages share this property. The usual intent of such designs is that they be as English- like as possible, on the theory that they will then be easier for unskilled people to program. This intention comes to grief on the reality that syntax isn't what makes programming hard; it's the mental effort and organization required to specify an algorithm precisely that costs. Thus the invariable result is that ‘candygrammar’ languages are just as difficult to program in as terser ones, and far more painful for the experienced hacker. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Brian Quinlan [EMAIL PROTECTED] wrote: Dave Parker wrote: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Hey Dave, Does this mean that Flaming Thunder requires explicit checking rather than offering exceptions? It looks that way but he doesn't seem to have got as far as documenting errors: the documentation gives several examples of that form and says that 'error' is a reserved word but says nothing about how you create an error of if you can distinguish one error from another: I'm guessing you can't as FT doesn't appear to have any concept of attributes on objects (or even any concept of objects): so far as I can see the only types are integers, rationals, intervals and strings (and real numbers if you pay real money for them). Maybe I'm missing something though, because I don't see how you can do anything useful with out at least some sort of arrays (unless you are supposed to store numbers in long strings). -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
I V [EMAIL PROTECTED] wrote: On Thu, 22 May 2008 19:35:50 -0700, Charles Hixson wrote: Although when comparing Candygram with Erlang it's worth noting that Candygram is bound to one processor, where Erlang can operate on multiple processors. (I'd been planning on using Candygram for a project at one point, but this made it unusable.) Really? The FAQ says it uses operating system threads, which I would have thought would mean it runs on multiple processors (modulo, I suppose, the issues with the GIL). I think candygram is crying out to be married with stackless or PyPy. It also needs an IPC channel to compete with Erlang directly. If you are interested in stackless python vs Erlang then take a look at this... http://muharem.wordpress.com/2007/07/31/erlang-vs-stackless-python-a-first-benchmark/ ...and read the discussion too! -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Torsten Bronger [EMAIL PROTECTED] wrote: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! You are surely aware of the fact that the C source of python also uses goto at tons of places. Is that Arf! too? In the hands of a skilled person who really knows what he/she does, it can be a useful statement. But this collides with the goals of FT, which claims to be simple to use. Besides, the above use case for a goto is definitively awful. My problem with the code isn't so much the 'go to', its the idea that you have to check the result of the read. That implies that any unchecked errors will go undetected. Ick. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Daniel Fetchinson a écrit : Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! You are surely aware of the fact that the C source of python also uses goto at tons of places. Is that Arf! too? C doesn't pretend to be anything else than a portable and a bit higher-level assembly. Nothing like FT. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 10:34 am, Dave Parker [EMAIL PROTECTED] wrote: On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: Personally, FT is a bit meh to me. The way you issue your statements I always think something is wrong, mainly because when I want to define, say, x, in python I'd go: x = whatever Instantly noting that I defined x. While in Flaming Thunder I'd have to type: Set x to whatever It just feels wrong. Actually, it felt wrong to me when I first started working on Flaming Thunder because I've been programming for decades and have had all of the programming idioms burned into my brain. But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. So it seems like you're designing a language for non-programmers. That's good, I've never heard about anyone so interested in teaching programming for kids and non-programmers. But in that case, you shouldn't even be comparing it to Python. Many computer languages conflate equality with assignment and then go to even more confusing measures to disambiguate them (such as using == for equality, or := for assignment). That stops being confusing after a few weeks of programming. (Actually, IMO, it's not confusing, but it's tricky because sometimes it's a hard typo to find. Though that will only be a syntax error in Python.) But again, that'll be great for the kids! ;-) Plus, symbols are more confusing for people to learn about than words. There are lots of people who are fluent in English, but dislike math. Learning the symbols of a programming language is one of the first and minimum requirements to learning any particular programming language-- we call that the syntax of the language. So, I opted for a simple, unambiguous, non-mathematical way of expressing assignment which makes sense even to the non- mathematically inclined: Set x to 8. That way, = can be reserved unambiguously and unconfusingly for the mathematical notion of equality -- because it's in their math classes that people learn what = means: Set QuadraticEquation to a*x^2 + b*x + c = 0. So it seems that you got a great language for math teachers, non- mathematicians, non-programmers, and kids! (what a great arsenal of people...). Maybe if I have a kid someday I'll teach him Flaming Thunder! (just kidding, you prick). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
[EMAIL PROTECTED] a écrit : (snip) Maybe if I have a kid someday I'll teach him Flaming Thunder! (just kidding, you prick). Err... Could we please avoid name calling, gentlemens ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker [EMAIL PROTECTED] wrote: But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. This is a common feature in functional languages... Eg Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1 X = 8. 8 2 X = 10. ** exception error: no match of right hand side value 10 3 That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 22, 10:30 am, Nick Craig-Wood [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. This is a common feature in functional languages... Eg Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1 X = 8. 8 2 X = 10. ** exception error: no match of right hand side value 10 3 That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... Are you saying that erlang treats 1 as an assignment, yet treats 2 as a comparison? That's inconsistent. No wonder nobody uses erlang. Why isn't erlang smart, like Python, and avoid such confusion? IDLE 1.2 X = 2**3 # assignment X == 8 # comparison True X == 10 False -- Nick Craig-Wood [EMAIL PROTECTED] --http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Mensanator wrote: On May 22, 10:30 am, Nick Craig-Wood [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. This is a common feature in functional languages... Eg Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1 X = 8. 8 2 X = 10. ** exception error: no match of right hand side value 10 3 That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... Are you saying that erlang treats 1 as an assignment, yet treats 2 as a comparison? That's inconsistent. No wonder nobody uses erlang. In Prolog terms, they're both unification. If X has never been defined you can define it as 8 with no chance of contradicting anything. Once X is 8, the proposition X is 10 is false. I act as though Erlang thinks the same. My Erlang chops aren't as good as my Prolog chops were. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 22 mai, 18:56, Mensanator [EMAIL PROTECTED] wrote: On May 22, 10:30 am, Nick Craig-Wood [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. This is a common feature in functional languages... Eg Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1 X = 8. 8 2 X = 10. ** exception error: no match of right hand side value 10 3 That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... Are you saying that erlang treats 1 as an assignment, yet treats 2 as a comparison? Nope. Both are treated as pattern matching. The first one binds X because it's by that time a free variable, the second fails because it doesn't match. That's inconsistent. That's consistent when you understand how Erlang works. No wonder nobody uses erlang. Strange enough, it seems that more and more developpers and company start to look at Erlang as a possible solution to massive scaling problems. Why isn't erlang smart, like Python, and avoid such confusion? Erlang *is* smart. It's just totally different from Python. And there's no confusion here (except on your side...). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Mel [EMAIL PROTECTED] wrote: Mensanator wrote: On May 22, 10:30??am, Nick Craig-Wood [EMAIL PROTECTED] wrote: Dave Parker [EMAIL PROTECTED] wrote: But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. This is a common feature in functional languages... Eg Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 ??(abort with ^G) 1 X = 8. 8 2 X = 10. ** exception error: no match of right hand side value 10 3 That error message is the erlang interpreter saying Hey I know X is 8, and you've said it is 10 - that can't be right, which is pretty much what math teachers say too... Are you saying that erlang treats 1 as an assignment, yet treats 2 as a comparison? That's inconsistent. No wonder nobody uses erlang. In Prolog terms, they're both unification. If X has never been defined you can define it as 8 with no chance of contradicting anything. Once X is 8, the proposition X is 10 is false. I act as though Erlang thinks the same. My Erlang chops aren't as good as my Prolog chops were. I had to look up the definition of unification, but yes you are right, erlang and prolog seem mean roughly the same thing by the = sign. It is called the pattern matching operator in erlang. From Armstrong's book: The expression Pattern = Expression causes Expression to be evaluated and the result matched against Pattern. The match either succeeds or fails. If the match succeeds any variables occurring in Pattern become bound. It is a very powerful idea and one which (along with the concurrency and message passing from Erlang) has been implemented for python :- http://candygram.sourceforge.net/ I've been reading the Erlang book and I have to say it has given me a lot of insight into python... -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
[EMAIL PROTECTED] wrote: So it seems like you're designing a language for non-programmers. That's good, I've never heard about anyone so interested in teaching programming for kids and non-programmers. But in that case, you shouldn't even be comparing it to Python. At one time, Guido was very keen on the idea of Python as a language to introduce non-programmers to (under the 'Computer Programming for Everybody' slogan). I think it's rather a shame that this has more-or-less fallen by the wayside. There are lots of people out there producing buggy spreadsheets to do things that would be easier to do in a programming language. -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Matthew Woodcraft writes: [...] At one time, Guido was very keen on the idea of Python as a language to introduce non-programmers to (under the 'Computer Programming for Everybody' slogan). I think it's rather a shame that this has more-or-less fallen by the wayside. There are lots of people out there producing buggy spreadsheets to do things that would be easier to do in a programming language. I don't think so. It's still reasonably simple to write short Python programs for e.g. the analysis of measurement results. But people simply don't trust cheap non-point'n'click programs which don't occupy two shelves in the bookstore. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker wrote: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Hey Dave, Does this mean that Flaming Thunder requires explicit checking rather than offering exceptions? Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Thursday 22 May 2008 13:30:07 Nick Craig-Wood wrote: ... From Armstrong's book: The expression Pattern = Expression causes Expression to be evaluated and the result matched against Pattern. The match either succeeds or fails. If the match succeeds any variables occurring in Pattern become bound. It is a very powerful idea and one which (along with the concurrency and message passing from Erlang) has been implemented for python :- http://candygram.sourceforge.net/ I've been reading the Erlang book and I have to say it has given me a lot of insight into python... Although when comparing Candygram with Erlang it's worth noting that Candygram is bound to one processor, where Erlang can operate on multiple processors. (I'd been planning on using Candygram for a project at one point, but this made it unusable.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Thu, 22 May 2008 19:35:50 -0700, Charles Hixson wrote: Although when comparing Candygram with Erlang it's worth noting that Candygram is bound to one processor, where Erlang can operate on multiple processors. (I'd been planning on using Candygram for a project at one point, but this made it unusable.) Really? The FAQ says it uses operating system threads, which I would have thought would mean it runs on multiple processors (modulo, I suppose, the issues with the GIL). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 13 Mai, 01:39, Dave Parker [EMAIL PROTECTED] wrote: I've read that one of the design goals of Python was to create an easy- to-use English-like language. That's also one of the design goals of Flaming Thunder athttp://www.flamingthunder.com/ , which has proven easy enough for even elementary school students, even though it is designed for scientists, mathematicians and engineers. Why on earth shall kids program and even more serious: why shall I program in a language for kids? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Personally (and borrowing from Python), I'd prefer something more like: Write Fa. Repeat 8 times: Write -la. I actually kind of prefer that, too. Or Repeat 8 times write -la. I'll think about it. Thank you for suggesting it. On May 20, 3:40 pm, MRAB [EMAIL PROTECTED] wrote: On May 20, 4:20 am, Dave Parker [EMAIL PROTECTED] wrote: I [EMAIL PROTECTED] wrote: Plus, me getting paid to work on Flaming Thunder is far more motivating than me not getting paid to work on Python. On May 14, 8:30 pm, John Salerno [EMAIL PROTECTED] wrote: That's truly disappointing. I guess I could have stated that better. Flaming Thunder is a labor of love for me. I've programmed in almost every language since FORTRAN and Lisp, and Flaming Thunder is the language I've always wished the others were. For one example, I've always preferred compiled languages because they're faster. So Flaming Thunder is compiled. For another example, I've always preferred languages that are English- like because it's easier to return to your code after several years and still know what you were doing (and it's easier for someone else to maintain your code). For over 5 years I've been working on Flaming Thunder unpaid and on my own, getting the back-end up and running. 8-by-8 shotgun cross compilers written in assembly language, that can fit all of the libraries for both the 32- and 64-bit versions of FreeBSD, Linux, Mac OS X and Windows into a single executable file that's less than 180K, aren't written overnight. So now that I've released it, it's extremely gratifying that people think it's cool enough to actually pay $19 for it. That gives me lots of motivation (and buys enough time) for me to add features to it as fast as possible. To whit: you pointed out the awkwardness in Python of having to declare a for-loop variable when you only wanted to loop a specific number of times and didn't need the variable. Last week, Flaming Thunder had the same awkwardness. If you wanted to loop 8 times: for i from 1 to 8 do statement you still had to use a variable (in this case, i). This week, I've added two new for-loop variations that fix that awkwardness, and also allow you to explicitly declare an infinite loop without having to rely on idiomatic constructs such as while-true. Examples of the two new variations (for-forever and for-expression-times): Write Fa. For 8 times do write -la. Personally (and borrowing from Python), I'd prefer something more like: Write Fa. Repeat 8 times: Write -la. For forever do ( Write Do you know the definition of insanity? . Read response. ). Repeat: Write Do you know the definition of insanity? . Read response.- Hide quoted text - - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Or when assigning a type to an identifier: HarmonicMean is a function(x, y) ... LoopCount is a variable ... By using = only for equality and is only for types, the Flaming Thunder compiler can detect when either is being used incorrectly because the syntax for the two is incompatible. That avoids the man- years of wasted debugging time spent on languages that accept statements that are easily confused, yet syntactically valid (e.g. the confusion between = and == in C if-statments, or the confusion between = (equality) and is (identity) in Python). On May 20, 3:41 pm, MRAB [EMAIL PROTECTED] wrote: On May 20, 4:33 am, Dave Parker [EMAIL PROTECTED] wrote: On May 14, 7:59 pm, John Salerno [EMAIL PROTECTED] wrote: Would it be valid to say: x = concrete or to say: if command (is) set to quit ?? I like the idea of: If command is set to quit ... Or just: If command is quit ... I've added it to my list of things to think about, and possibly implement.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker a écrit : Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! Or when assigning a type to an identifier: HarmonicMean is a function(x, y) ... LoopCount is a variable ... By using = only for equality and is only for types, the Flaming Thunder compiler can detect when either is being used incorrectly because the syntax for the two is incompatible. That avoids the man- years of wasted debugging time spent on languages that accept statements that are easily confused, yet syntactically valid (e.g. the confusion between = and == in C if-statments, or the confusion between = (equality) and is (identity) in Python). Actually in Python the equality test is '==', not '='. And since Python's types are objects - which is *definitively* a GoodThing(tm) in an OOPL -, your point here is moot. Also, you're overloading the meaning of 'is', which *is* (pun intented) confusing too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: Personally, FT is a bit meh to me. The way you issue your statements I always think something is wrong, mainly because when I want to define, say, x, in python I'd go: x = whatever Instantly noting that I defined x. While in Flaming Thunder I'd have to type: Set x to whatever It just feels wrong. Actually, it felt wrong to me when I first started working on Flaming Thunder because I've been programming for decades and have had all of the programming idioms burned into my brain. But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. Many computer languages conflate equality with assignment and then go to even more confusing measures to disambiguate them (such as using == for equality, or := for assignment). Plus, symbols are more confusing for people to learn about than words. There are lots of people who are fluent in English, but dislike math. So, I opted for a simple, unambiguous, non-mathematical way of expressing assignment which makes sense even to the non- mathematically inclined: Set x to 8. That way, = can be reserved unambiguously and unconfusingly for the mathematical notion of equality -- because it's in their math classes that people learn what = means: Set QuadraticEquation to a*x^2 + b*x + c = 0. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, May 21, 2008 at 11:34 AM, Dave Parker [EMAIL PROTECTED] wrote: For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. Sounds to me like the teacher is being difficult, and IIRC, you've talked about having elementary school kids write in FT -- I don't think asking does this make sense to you of elementary school kids is necessarily the best metric for PL syntax/semantics. Many computer languages conflate equality with assignment and then go to even more confusing measures to disambiguate them (such as using == for equality, or := for assignment). Plus, symbols are more confusing for people to learn about than words. There are lots of people who are fluent in English, but dislike math. If you can't do, or don't like, math, you probably shouldn't be programming. If you don't have any symbolic reasoning skills, you're largely limited to Hello, World. That way, = can be reserved unambiguously and unconfusingly for the mathematical notion of equality -- because it's in their math classes that people learn what = means: Set QuadraticEquation to a*x^2 + b*x + c = 0. You keep trotting out this quadratic equation example, but does FT actually have any kind of useful equation solver in it? Or does it just allow you to do something like Set QuadraticEquation to a*x^2 + b*x + c = 0. Set a to 1. Set b to 0. Set c to -25. Set x to 5. If QuadraticEquation is True then do -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 10:00 am, Dan Upton [EMAIL PROTECTED] wrote: Sounds to me like the teacher is being difficult, ... No, proof-by-contradiction is a common technique in math. If you can show that x=8 and x=10, then you have shown that your assumptions were incorrect. If you can't do, or don't like, math, you probably shouldn't be programming. Why not? Recipes are programs. I prefer to look at it the other way: an easy-to-use programming language might encourage more people to like math. You keep trotting out this quadratic equation example, but does FT actually have any kind of useful equation solver in it? Not yet, but it will. Probably around July. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! You are surely aware of the fact that the C source of python also uses goto at tons of places. Is that Arf! too? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, May 21, 2008 at 12:33 PM, Daniel Fetchinson [EMAIL PROTECTED] wrote: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! You are surely aware of the fact that the C source of python also uses goto at tons of places. Is that Arf! too? And in the Linux kernel, and probably lots of other places too--several places I've seen it used, they explain it as this helps clue in the optimizer or something to that effect. (That doesn't mean it's a good idea to use it in everyday code though.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Daniel Fetchinson writes: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! You are surely aware of the fact that the C source of python also uses goto at tons of places. Is that Arf! too? In the hands of a skilled person who really knows what he/she does, it can be a useful statement. But this collides with the goals of FT, which claims to be simple to use. Besides, the above use case for a goto is definitively awful. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 4:15 pm, Dave Parker [EMAIL PROTECTED] wrote: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Or when assigning a type to an identifier: HarmonicMean is a function(x, y) ... LoopCount is a variable ... By using = only for equality and is only for types, the Flaming Thunder compiler can detect when either is being used incorrectly because the syntax for the two is incompatible. That avoids the man- years of wasted debugging time spent on languages that accept statements that are easily confused, yet syntactically valid (e.g. the confusion between = and == in C if-statments, or the confusion between = (equality) and is (identity) in Python). [snip] I wonder whether is could be used both for x is value and x is a type without causing a problem: If command is a string ... If command is quit ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, May 21, 2008 at 12:11 PM, Dave Parker [EMAIL PROTECTED] wrote: On May 21, 10:00 am, Dan Upton [EMAIL PROTECTED] wrote: Sounds to me like the teacher is being difficult, ... No, proof-by-contradiction is a common technique in math. If you can show that x=8 and x=10, then you have shown that your assumptions were incorrect. Yes, I'm aware of proof by contradiction. However, I think there's a flaw in your use of this to justify your case--proof by contradiction would essentially be showing x=8 and x=10 simultaneously, whereas the sequence of instructions x=8 x=10 imply a time relation, and there's no contradiction that x equals something at one point in time, and something else at another point in time. (For any kid who is capable of understanding variables anyway, just tell them something to the effect of Plot the line y=x. Okay, now let 'y' be time. At no point in time does x take on two values, but it may take on different values at different points in time. Same concept.) If you can't do, or don't like, math, you probably shouldn't be programming. Why not? Recipes are programs. I prefer to look at it the other way: an easy-to-use programming language might encourage more people to like math. To continue your analogy, if a recipe is the program, a person is the computer. Following a recipe is (relatively) easy, making up a new recipe is relatively difficult unless you understand, or are at least willing to tinker with, things like interactions between ingredients and flavors. Likewise, it's tedious and time-consuming but not necessarily difficult to follow a program (assuming you understand the rules of the language; I suppose here you could make some argument it'd be easier to read it in English), but you need to understand more about symbolic reasoning and such to be able to do much in the way of programming. All the same, I suppose you might have a point there, if you can show somebody something cool while sneaking in the math and programming such that they learn without even realizing it--somewhat akin to the guy who a month or so ago wanted to sneakily teach his high school class programming fundamentals by teaching them game programming. You keep trotting out this quadratic equation example, but does FT actually have any kind of useful equation solver in it? Not yet, but it will. Probably around July. Maybe this should be your selling point, and maybe you should be drawing comparisons to programming in Matlab or Mathematica. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 1:14 pm, MRAB [EMAIL PROTECTED] wrote: I wonder whether is could be used both for x is value and x is a type without causing a problem: If command is a string ... If command is quit ... I think you are right. I like If command is quit For a user who wasn't mathemetically inclined and was doing mainly string manipulation, I think it might be easier to read than the equivalent If command = quit By making them exactly equivalent, I can't think of any confusion that might induce bugs. If you think of any drawbacks, please let me know. Otherwise, I'll put it in the next time I update the parser (probably this weekend). Thank you again for your suggestions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 1:29 pm, Dan Upton [EMAIL PROTECTED] wrote: ... --somewhat akin to the guy who a month or so ago wanted to sneakily teach his high school class programming fundamentals by teaching them game programming. Yep, that's kind of my plan, too. After I get enough computer languagey stuff running, I'm going to incorporate the 3D graphics from DPGraph. Maybe this should be your selling point, and maybe you should be drawing comparisons to programming in Matlab or Mathematica. That sounds like a good idea. Personally, the first thing I wanted to get running in Flaming Thunder was the ability to cross-compile CGI scripts for Linux under Windows, because some inexpensive web-hosting sites (such as GoDaddy) don't allow shell access, so I couldn't compile the CGI scripts natively. Also, the ability to cross-compile programs for the Mac since Macs often appear in educational settings. Now that those are up and running and Flaming Thunder is released to the public, I'm adding features as prioritized by customer requests. Currently, the highest big things on the list are arrays/matrices and 3D graphics. Next on the list is improved symbolics. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 10:30 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dave Parker schrieb: All of the calculators and textbooks that elementary school students use, use ^ for powers. I've never seen this symbol in textbooks. In textbooks, powers are written using superscript. Just like Flaming Thunder does. I haven't seen ** for powers since FORTRAN. I haven't seen any language using '^' as the power operator so far - but I've seen quite a lot of them using it as the bitwise XOR operator. Excel uses the caret as the power operator. Arguably the worlds most widely used programming environment... Michael Foord http://www.ironpythoninaction.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, May 21, 2008 at 5:27 PM, Fuzzyman [EMAIL PROTECTED] wrote: On May 14, 10:30 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dave Parker schrieb: All of the calculators and textbooks that elementary school students use, use ^ for powers. I've never seen this symbol in textbooks. In textbooks, powers are written using superscript. Just like Flaming Thunder does. I haven't seen ** for powers since FORTRAN. I haven't seen any language using '^' as the power operator so far - but I've seen quite a lot of them using it as the bitwise XOR operator. Excel uses the caret as the power operator. Arguably the worlds most widely used programming environment... I think BASIC did, too. I know I used to use it in some language and was confused when I first tried to use it in Java and didn't get what I was expecting. (Some language must be in the set (BASIC, C, Logo).) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker wrote: On May 20, 7:05 pm, Collin [EMAIL PROTECTED] wrote: Personally, FT is a bit meh to me. The way you issue your statements I always think something is wrong, mainly because when I want to define, say, x, in python I'd go: x = whatever Instantly noting that I defined x. While in Flaming Thunder I'd have to type: Set x to whatever It just feels wrong. Actually, it felt wrong to me when I first started working on Flaming Thunder because I've been programming for decades and have had all of the programming idioms burned into my brain. But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was one of those is wrong because x can't equal 2 different things at the same time. Many computer languages conflate equality with assignment and then go to even more confusing measures to disambiguate them (such as using == for equality, or := for assignment). Plus, symbols are more confusing for people to learn about than words. There are lots of people who are fluent in English, but dislike math. So, I opted for a simple, unambiguous, non-mathematical way of expressing assignment which makes sense even to the non- mathematically inclined: Set x to 8. That way, = can be reserved unambiguously and unconfusingly for the mathematical notion of equality -- because it's in their math classes that people learn what = means: Set QuadraticEquation to a*x^2 + b*x + c = 0. Then I guess the elementary school kids will use your FT system while we will use our naturally burned-in sense of syntax from other programming languages, eh? Not saying this as a negative or anything, I'm just saying that most of us have a habit, and it's not necessarily a bad nor good habit, of doing things the way most languages have them done. For example, x = 8 is extremely readable, to, I assume, most of us. Set x to 8, it takes some time getting used to. Why should we switch to a language that will take us time to get used and some more time to understand syntax when we already understand and can efficiently use our current languages? It's like going to the middle of London and screaming: HEY GUYS GUESS WHAT! I JUST INVENTED A NEW LANGUAGE AND IT'S VERY VERY EASY TO LEARN! And the people who would try the language would find the way you do everything is very different from English, or their native language, for that matter. Best let sleeping dogs lie. Collin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 8:34 pm, Dave Parker [EMAIL PROTECTED] wrote: On May 21, 1:14 pm, MRAB [EMAIL PROTECTED] wrote: I wonder whether is could be used both for x is value and x is a type without causing a problem: If command is a string ... If command is quit ... I think you are right. I like If command is quit For a user who wasn't mathemetically inclined and was doing mainly string manipulation, I think it might be easier to read than the equivalent If command = quit By making them exactly equivalent, I can't think of any confusion that might induce bugs. If you think of any drawbacks, please let me know. I've thought of one possible drawback: a and an can be used as variables, so the is a part might cause a problem. You'd need to check the parser to find out... Otherwise, I'll put it in the next time I update the parser (probably this weekend). Thank you again for your suggestions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 7:49 pm, MRAB [EMAIL PROTECTED] wrote: I've thought of one possible drawback: a and an can be used as variables, so the is a part might cause a problem. You'd need to check the parser to find out... Good point, I hadn't noticed that. I'll check it out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 21 Mag, 17:34, Dave Parker [EMAIL PROTECTED] wrote: [...] symbols are more confusing for people to learn about than words. There are lots of people who are fluent in English, but dislike math. So, I opted for a simple, unambiguous, non-mathematical way of expressing assignment which makes sense even to the non- mathematically inclined: Set x to 8. Sorry but... are you really trying to tell us that a person which is not able to understand x = 5 should use a programming language? Such a person shouldn't even use a computer and I strongly doubt that your syntax solution would make ring a bell in his head! Besides that what makes you think that: Set n to 1 Factorial is a function(n) doing if n = 0 then return 1 else return n*factorial(n-1). ...is more clear/intuitive than: n = 1 def factorial(n): this is a function doing: return 1 if n == 0 else n * factorial(n-1) ...? IMHO, it seems to me that you've just tried to mix comments and code into a single thing for no other reason than to be different. I'd be curious to see some code samples solving some - real world - problems instead of showing hot to calculate factorials, printing hello worlds or read from a file, which are the only code samples I've seen in the homepage and in the documentation. --- Giampaolo http://code.google.com/p/pyftpdlib -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 20, 4:20 am, Dave Parker [EMAIL PROTECTED] wrote: I [EMAIL PROTECTED] wrote: Plus, me getting paid to work on Flaming Thunder is far more motivating than me not getting paid to work on Python. On May 14, 8:30 pm, John Salerno [EMAIL PROTECTED] wrote: That's truly disappointing. I guess I could have stated that better. Flaming Thunder is a labor of love for me. I've programmed in almost every language since FORTRAN and Lisp, and Flaming Thunder is the language I've always wished the others were. For one example, I've always preferred compiled languages because they're faster. So Flaming Thunder is compiled. For another example, I've always preferred languages that are English- like because it's easier to return to your code after several years and still know what you were doing (and it's easier for someone else to maintain your code). For over 5 years I've been working on Flaming Thunder unpaid and on my own, getting the back-end up and running. 8-by-8 shotgun cross compilers written in assembly language, that can fit all of the libraries for both the 32- and 64-bit versions of FreeBSD, Linux, Mac OS X and Windows into a single executable file that's less than 180K, aren't written overnight. So now that I've released it, it's extremely gratifying that people think it's cool enough to actually pay $19 for it. That gives me lots of motivation (and buys enough time) for me to add features to it as fast as possible. To whit: you pointed out the awkwardness in Python of having to declare a for-loop variable when you only wanted to loop a specific number of times and didn't need the variable. Last week, Flaming Thunder had the same awkwardness. If you wanted to loop 8 times: for i from 1 to 8 do statement you still had to use a variable (in this case, i). This week, I've added two new for-loop variations that fix that awkwardness, and also allow you to explicitly declare an infinite loop without having to rely on idiomatic constructs such as while-true. Examples of the two new variations (for-forever and for-expression-times): Write Fa. For 8 times do write -la. Personally (and borrowing from Python), I'd prefer something more like: Write Fa. Repeat 8 times: Write -la. For forever do ( Write Do you know the definition of insanity? . Read response. ). Repeat: Write Do you know the definition of insanity? . Read response. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 20, 4:33 am, Dave Parker [EMAIL PROTECTED] wrote: On May 14, 7:59 pm, John Salerno [EMAIL PROTECTED] wrote: Would it be valid to say: x = concrete or to say: if command (is) set to quit ?? I like the idea of: If command is set to quit ... Or just: If command is quit ... I've added it to my list of things to think about, and possibly implement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker wrote: I've read that one of the design goals of Python was to create an easy- to-use English-like language. That's also one of the design goals of Flaming Thunder at http://www.flamingthunder.com/ , which has proven easy enough for even elementary school students, even though it is designed for scientists, mathematicians and engineers. Personally, FT is a bit meh to me. The way you issue your statements I always think something is wrong, mainly because when I want to define, say, x, in python I'd go: x = whatever Instantly noting that I defined x. While in Flaming Thunder I'd have to type: Set x to whatever It just feels wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
I [EMAIL PROTECTED] wrote: Plus, me getting paid to work on Flaming Thunder is far more motivating than me not getting paid to work on Python. On May 14, 8:30 pm, John Salerno [EMAIL PROTECTED] wrote: That's truly disappointing. I guess I could have stated that better. Flaming Thunder is a labor of love for me. I've programmed in almost every language since FORTRAN and Lisp, and Flaming Thunder is the language I've always wished the others were. For one example, I've always preferred compiled languages because they're faster. So Flaming Thunder is compiled. For another example, I've always preferred languages that are English- like because it's easier to return to your code after several years and still know what you were doing (and it's easier for someone else to maintain your code). For over 5 years I've been working on Flaming Thunder unpaid and on my own, getting the back-end up and running. 8-by-8 shotgun cross compilers written in assembly language, that can fit all of the libraries for both the 32- and 64-bit versions of FreeBSD, Linux, Mac OS X and Windows into a single executable file that's less than 180K, aren't written overnight. So now that I've released it, it's extremely gratifying that people think it's cool enough to actually pay $19 for it. That gives me lots of motivation (and buys enough time) for me to add features to it as fast as possible. To whit: you pointed out the awkwardness in Python of having to declare a for-loop variable when you only wanted to loop a specific number of times and didn't need the variable. Last week, Flaming Thunder had the same awkwardness. If you wanted to loop 8 times: for i from 1 to 8 do statement you still had to use a variable (in this case, i). This week, I've added two new for-loop variations that fix that awkwardness, and also allow you to explicitly declare an infinite loop without having to rely on idiomatic constructs such as while-true. Examples of the two new variations (for-forever and for-expression-times): Write Fa. For 8 times do write -la. For forever do ( Write Do you know the definition of insanity? . Read response. ). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 13, 11:42 am, Grant Edwards [EMAIL PROTECTED] wrote: Well, python will definitely never have a name that sounds like a slang term for happens after you get food poisioning at a Thai restaurant... :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 7:59 pm, John Salerno [EMAIL PROTECTED] wrote: Would it be valid to say: x = concrete or to say: if command (is) set to quit ?? I like the idea of: If command is set to quit ... I've added it to my list of things to think about, and possibly implement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Mon, 19 May 2008 20:20:28 -0700 (PDT) Dave Parker [EMAIL PROTECTED] wrote: To whit: you pointed out the awkwardness in Python of having to declare a for-loop variable when you only wanted to loop a specific number of times and didn't need the variable. Well, I wasn't so much trying to point out an awkwardness as I was asking if anyone really *found* it awkward. And of course, my question also raises the question of whether or not it's good programming to simply want to do something a certain number of times. I suppose that situation may come up, but I wonder if it can be implemented in a more significant way than simply doing something X number of times. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Mon, May 19, 2008 at 11:20 PM, Dave Parker [EMAIL PROTECTED] wrote: For another example, I've always preferred languages that are English- like because it's easier to return to your code after several years and still know what you were doing (and it's easier for someone else to maintain your code). Unless of course you use reasonable variable names and have good comments in your code. I don't think figuring out well-documented C code would be any easier if it were in a more English-like syntax--IMO, it's usually the understanding the interfaces or figuring out what's going on in functions that makes reading someone else's code tricky, not the difference between x= and set x to. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 16, 3:58 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 15 mai, 19:30, Lie [EMAIL PROTECTED] wrote: On May 15, 4:08 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 14 mai, 08:08, Lie [EMAIL PROTECTED] wrote: On May 14, 12:51 pm, Lie [EMAIL PROTECTED] wrote: And your 8 by 8 cross compiler doesn't impress me at all, they're all based on x86/IA-32 architecture which is quite similar, no PowerPC, SPARC, ARM, no other CISC or RISC architecture. And your compiler is a single language compiler instead of three dimensional compiler that GCC is (cross platform, cross target platform, cross language). And to add, I also need to mention that Python doesn't need to be compiled at all, No language needs compilation - it's an implementation problem, not a language problem. Now all the Python's implementations I know do use compilation (to byte-code). its py and pyo file is architecture independent. True, but this is not strictly related to being compiled or not. It's true, it's implementation problem whether a language is compiled or not, but what I was emphasizing was that Python's code is architecture independent at all stages (that is visible to the user and the programmer), on the other hand, a compiled code is a compiled code is a compiled code, Ever wondered what all these .pyc files were ? it cannot be architecture independent without packing multiple binaries in the same executable (like in Macintosh's universal binary) or using an emulation (with huge overheads) or at least using a compatibility layer (which doesn't always work) and all this is done in the layer that is visible to user and programmer (programmer having to compile against everything and user having to download the correct executable) instead of being done in a platform independent way that interpreted language like Python have. Python is not interpreted, because being interpreted is a feature of an implementation, not of a language. And so far, no known Python implementation is (strictly speaking) interpreted - they all compile to byte-code. compiled doesn't necessarily imply compiled to platform native binary code, you know. That's beside the point, the point is about platform independentness of the .py file. When I call Python is interpreted, I meant that the CPU doesn't directly interpret python codes (in most Python implementation). Ok, this may look like a bit on the splitting hairs side. But may I remind you that to run ever a .pyc file, you do need to have the Python runtime (VM + quite a lot of libs) installed one way (normal install) or another (packed in something that looks like an ordinary executable - whatever this means for the target platform) ? OTHO, it's true that a .pyc file is platform-independant - it just requires the correct versions of quite a lot of platform-dependant binaries. Wait... Isn't this code some kind of a visible to the user and programmer compatibilty layer ? With the same bit on being on the splitting hair side: It's the same with msvcrt in C or msvbvm60 in VB, programming language runtime is invisible to the user, it's visible to the system administrator (which, in many cases is also the user though). It is, however, invisible to both the user and the programmers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
2008/5/15 John Salerno [EMAIL PROTECTED]: On Tue, 13 May 2008 06:25:27 -0700 (PDT) Dave Parker [EMAIL PROTECTED] wrote: I'm pretty generally interested, but where can print layout take you? Not far, especially with books disappearing. Our library says that these days, only 25% of their checkouts are books; the other 75% are DVDs, CDs, etc. Sorry, but I must point out a logical flaw in this statement. Assuming your stats are even true, just because books are now only 25% of checkouts rather than, for example, 80%, doesn't necessarily imply that any less books are being checked out (i.e. disappearing). It can just as easily mean that *more* of the other things are being checked out while books remain the same. Example: Total number of items checked out:100 Total number of books checked out: 80 Percentage of books checked out: 80% Total number of items checked out:320 Total number of books checked out: 80 # same as above Percentage of books checked out: 25% -- http://mail.python.org/mailman/listinfo/python-list In France, the book market is bigger (in terms of money) than the DVD and CD market IIRC. That's strange, isn't it ? Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 15, 4:08 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 14 mai, 08:08, Lie [EMAIL PROTECTED] wrote: On May 14, 12:51 pm, Lie [EMAIL PROTECTED] wrote: And your 8 by 8 cross compiler doesn't impress me at all, they're all based on x86/IA-32 architecture which is quite similar, no PowerPC, SPARC, ARM, no other CISC or RISC architecture. And your compiler is a single language compiler instead of three dimensional compiler that GCC is (cross platform, cross target platform, cross language). And to add, I also need to mention that Python doesn't need to be compiled at all, No language needs compilation - it's an implementation problem, not a language problem. Now all the Python's implementations I know do use compilation (to byte-code). its py and pyo file is architecture independent. True, but this is not strictly related to being compiled or not. It's true, it's implementation problem whether a language is compiled or not, but what I was emphasizing was that Python's code is architecture independent at all stages (that is visible to the user and the programmer), on the other hand, a compiled code is a compiled code is a compiled code, it cannot be architecture independent without packing multiple binaries in the same executable (like in Macintosh's universal binary) or using an emulation (with huge overheads) or at least using a compatibility layer (which doesn't always work) and all this is done in the layer that is visible to user and programmer (programmer having to compile against everything and user having to download the correct executable) instead of being done in a platform independent way that interpreted language like Python have. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 15 mai, 19:30, Lie [EMAIL PROTECTED] wrote: On May 15, 4:08 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 14 mai, 08:08, Lie [EMAIL PROTECTED] wrote: On May 14, 12:51 pm, Lie [EMAIL PROTECTED] wrote: And your 8 by 8 cross compiler doesn't impress me at all, they're all based on x86/IA-32 architecture which is quite similar, no PowerPC, SPARC, ARM, no other CISC or RISC architecture. And your compiler is a single language compiler instead of three dimensional compiler that GCC is (cross platform, cross target platform, cross language). And to add, I also need to mention that Python doesn't need to be compiled at all, No language needs compilation - it's an implementation problem, not a language problem. Now all the Python's implementations I know do use compilation (to byte-code). its py and pyo file is architecture independent. True, but this is not strictly related to being compiled or not. It's true, it's implementation problem whether a language is compiled or not, but what I was emphasizing was that Python's code is architecture independent at all stages (that is visible to the user and the programmer), on the other hand, a compiled code is a compiled code is a compiled code, Ever wondered what all these .pyc files were ? it cannot be architecture independent without packing multiple binaries in the same executable (like in Macintosh's universal binary) or using an emulation (with huge overheads) or at least using a compatibility layer (which doesn't always work) and all this is done in the layer that is visible to user and programmer (programmer having to compile against everything and user having to download the correct executable) instead of being done in a platform independent way that interpreted language like Python have. Python is not interpreted, because being interpreted is a feature of an implementation, not of a language. And so far, no known Python implementation is (strictly speaking) interpreted - they all compile to byte-code. compiled doesn't necessarily imply compiled to platform native binary code, you know. Ok, this may look like a bit on the splitting hairs side. But may I remind you that to run ever a .pyc file, you do need to have the Python runtime (VM + quite a lot of libs) installed one way (normal install) or another (packed in something that looks like an ordinary executable - whatever this means for the target platform) ? OTHO, it's true that a .pyc file is platform-independant - it just requires the correct versions of quite a lot of platform-dependant binaries. Wait... Isn't this code some kind of a visible to the user and programmer compatibilty layer ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 11:25 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 09:36:28 -0700 (PDT), Dave Parker [EMAIL PROTECTED] declaimed the following in comp.lang.python: ... there's something that feels very unnatural about writing English as code. I think it is ironic that you think Flaming Thunder is unnatural because it is more English-like, when being English-like was one of Python's goals: Python was designed to be a highly readable language. It aims toward an uncluttered visual layout, using English keywords frequently where other languages use punctuation. http://en.wikipedia.org/wiki/Python_(programming_language)#Syntax_and... I'd consider the emphasis to be keywords ... punctuation, whereas English is just a qualifier... If you want to follow this to the limit, the ^ vs ** would disappear... let x be y raised to z I'm doubting that anyone would rely on a natural language programming language written by someone who has misunderstood other's post 3-4 times, and have misquoted news story several times because of his misunderstanding. If he can't even understand English text properly, how could he write a natural language parser? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 12:51 pm, Lie [EMAIL PROTECTED] wrote: And your 8 by 8 cross compiler doesn't impress me at all, they're all based on x86/IA-32 architecture which is quite similar, no PowerPC, SPARC, ARM, no other CISC or RISC architecture. And your compiler is a single language compiler instead of three dimensional compiler that GCC is (cross platform, cross target platform, cross language). And to add, I also need to mention that Python doesn't need to be compiled at all, its py and pyo file is architecture independent. Unlike some languages that still need to be compiled. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker a écrit : (snip spam) Please stop spamming here trying to sell your dumbass proprietary basic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Tue, 2008-05-13 at 10:33 -0700, Dave Parker wrote: You sound like a commercial. Get Flaming Thunder for only $19.95! It slices, it dices! And while programs and libraries written in assembly may be twice as fast as programs and libraries written in C, ... It's a myth that they're only twice as fast. An experienced assembly language programmer can usually get out at least a factor of 5 by using tricks such as cache-coherence, carry flag tricks, stack manipulations, etc. ... they're real hell to maintain. That's also a myth. For example, if C is easy to maintain, why is Flaming Thunder the only single-asset 8-by-8 shotgun cross compiler in the world? There should be lots of single-asset 8-by-8 shotgun cross compilers written in C, if C is easier to maintain. Not only is it the world's only single-asset 8-by-8 shotgun cross compiler, but according to google, it's also the world's only shotgun cross compiler period. But I guess if you make up your own terminology you're bound to be unique. :) Do you mind if I ask: what exactly is a single-asset 8x8 shotgun cross compiler, and what makes that of any value to me? Cheers, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 5:53 am, J. Clifford Dyer [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 10:33 -0700, Dave Parker wrote: You sound like a commercial. Get Flaming Thunder for only $19.95! It slices, it dices! And while programs and libraries written in assembly may be twice as fast as programs and libraries written in C, ... It's a myth that they're only twice as fast. An experienced assembly language programmer can usually get out at least a factor of 5 by using tricks such as cache-coherence, carry flag tricks, stack manipulations, etc. ... they're real hell to maintain. That's also a myth. For example, if C is easy to maintain, why is Flaming Thunder the only single-asset 8-by-8 shotgun cross compiler in the world? There should be lots of single-asset 8-by-8 shotgun cross compilers written in C, if C is easier to maintain. Not only is it the world's only single-asset 8-by-8 shotgun cross compiler, but according to google, it's also the world's only shotgun cross compiler period. But I guess if you make up your own terminology you're bound to be unique. :) Do you mind if I ask: what exactly is a single-asset 8x8 shotgun cross compiler, and what makes that of any value to me? Cheers, Cliff- Hide quoted text - - Show quoted text - You can examine those criteria by trying to buy a chair. Is Tron good practice for Opticals? Who wants a memory lane crossing? Is compiling bad? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, 14 May 2008 06:53:02 -0400, J. Clifford Dyer [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 10:33 -0700, Dave Parker wrote: You sound like a commercial. Get Flaming Thunder for only $19.95! It slices, it dices! And while programs and libraries written in assembly may be twice as fast as programs and libraries written in C, ... It's a myth that they're only twice as fast. An experienced assembly language programmer can usually get out at least a factor of 5 by using tricks such as cache-coherence, carry flag tricks, stack manipulations, etc. ... they're real hell to maintain. That's also a myth. For example, if C is easy to maintain, why is Flaming Thunder the only single-asset 8-by-8 shotgun cross compiler in the world? There should be lots of single-asset 8-by-8 shotgun cross compilers written in C, if C is easier to maintain. Not only is it the world's only single-asset 8-by-8 shotgun cross compiler, but according to google, it's also the world's only shotgun cross compiler period. But I guess if you make up your own terminology you're bound to be unique. :) Do you mind if I ask: what exactly is a single-asset 8x8 shotgun cross compiler, and what makes that of any value to me? The web page explains. It's a compiler that runs on 8 platforms and can generate executables for any of them on any of them. It's not _totally_ clear about what single-asset means, but it gives the impression (and the term somewhat suggests) that this means there's a single executable that does all of this (compare to gcc's design, where support for cross compiling to another arch is provided by a separate executable). Shotgun probably just sounds cool. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
That's also a myth. For example, if C is easy to maintain, why is Flaming Thunder the only single-asset 8-by-8 shotgun cross compiler in the world? There should be lots of single-asset 8-by-8 shotgun cross compilers written in C, if C is easier to maintain. Not only is it the world's only single-asset 8-by-8 shotgun cross compiler, but according to google, it's also the world's only shotgun cross compiler period. But I guess if you make up your own terminology you're bound to be unique. :) Do you mind if I ask: what exactly is a single-asset 8x8 shotgun cross compiler, and what makes that of any value to me? The web page explains. It's a compiler that runs on 8 platforms and can generate executables for any of them on any of them. It's not _totally_ clear about what single-asset means, but it gives the impression (and the term somewhat suggests) that this means there's a single executable that does all of this (compare to gcc's design, where support for cross compiling to another arch is provided by a separate executable). Which isn't too hard if all you have are simple datatypes as a handfull numerical types + strings. Besides, from what I see, the supported platforms all are x86, 32bit 64bit. And I bet GCC works pretty unmodified amongst these as well - only binary formats differ. But let Flaming Thunder grow a library system with dynamic loading, and I wonder how well his crosscompiler works.. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker a écrit : 5-10 times faster for what kind of code? Mostly numerical analysis Benches, please ? I mean : benches using Python's numpy or similar packages - that is, what anyone doing numerical intensive computation in Python would use. and CGI scripting. Is there anyone still doing cgi nowadays ??? I don't see anything that resembles OO features of python, ... True. But in Python, you don't see statically-linked pure-syscall CGI Hopefully. And you don't see much cgi script at all, because we figured much better ways to do web programming. For many people, being 5 to 10 times faster at numerical analysis and CGI scripting is reason enough to pay $19 per year. But maybe for other people, having slow, inefficient programs and websites is acceptable. Go tell this to google, youtube etc... Perhaps. But if elementary school students can easily understand why one programming language gives the answer 100 (Flaming Thunder): Write 10^2. but can't understand why another programming language gives the answer 8 (Python): Print 10^2 This doesn't give 8 - this raises a syntax error. Please RTFM : 1/ this is 'print', not 'Print' 2/ '^' is the bitwise XOR operator ok, so not only do you spam this newsgroup, but you're also a clueless troll. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 8:43 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: That's also a myth. For example, if C is easy to maintain, why is Flaming Thunder the only single-asset 8-by-8 shotgun cross compiler in the world? There should be lots of single-asset 8-by-8 shotgun cross compilers written in C, if C is easier to maintain. Not only is it the world's only single-asset 8-by-8 shotgun cross compiler, but according to google, it's also the world's only shotgun cross compiler period. But I guess if you make up your own terminology you're bound to be unique. :) Do you mind if I ask: what exactly is a single-asset 8x8 shotgun cross compiler, and what makes that of any value to me? The web page explains. It's a compiler that runs on 8 platforms and can generate executables for any of them on any of them. It's not _totally_ clear about what single-asset means, but it gives the impression (and the term somewhat suggests) that this means there's a single executable that does all of this (compare to gcc's design, where support for cross compiling to another arch is provided by a separate executable). Which isn't too hard if all you have are simple datatypes as a handfull numerical types + strings. Besides, from what I see, the supported platforms all are x86, 32bit 64bit. And I bet GCC works pretty unmodified amongst these as well - only binary formats differ. But let Flaming Thunder grow a library system with dynamic loading, and I wonder how well his crosscompiler works.. Diez- Hide quoted text - - Show quoted text - 8x8 is pretty easy to aim for. Turn on 16x16, and you're the laptop to stand on. FxF? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
2008/5/14 [EMAIL PROTECTED]: 8x8 is pretty easy to aim for. Turn on 16x16, and you're the laptop to stand on. FxF? I'll see your 16x16 and raise you 32x32. Any number is pretty easy to aim for when one can arbitrarily invent 2nx2n. Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Tuesday 13 May 2008 01:05:38 pm Dave Parker wrote: The websites owners might not be unhappy, but lots of customers complain about slow websites, so if the market is competitive then eventually the PHP fad will die out. On my [modest] experience, bandwidth trumps code speed by a large fraction. My experience is tainted, though, with me living in Cuba and Cuba having almost no bandwidth available. For example, Slashdot recently interviewed a successful website in a competitive market -- online newspapers -- and found that to enhance customer happiness the New York Times uses hand-coded HTML. He was asked how the Web site looks so consistently nice and polished no matter which browser or resolution is used to access it. His answer begins: 'It's our preference to use a text editor, like HomeSite, TextPad or TextMate, to hand code everything, rather than to use a wysiwyg (what you see is what you get) HTML and CSS authoring program, like Dreamweaver. We just find it yields better and faster results.' So, they edit the HTML code by hand. The interview explicitly mentions the features consistently nice and polished, not faster to compute. You can always throw more hardware when the problem is about speed. The real edge on your competitive marked should be the consistently nice and polished, and neither python, nor [I hope] Flaming Thunder is going to help you with that. Faster wins in a competitive market, so if a programming language can't deliver faster, it is a fad that will die out. I find it more likely that the users are more concerned about how quickly the latest tidbit reaches your frontpage than with the extra few milisenconds achieved by switching the programming language or throwing another server in the cluster. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 14 mai, 00:41, John Machin [EMAIL PROTECTED] wrote: (snip) IIRC the idea was so that managers could write programs in English. It failed because nobody could write a parser that would handle something like The bottom line is that the stakeholder group requires the situation going forward to be such as to facilitate the variable known as x to provide the same outcome when stimulated by dereferencing as the variable known as y. John, I usually don't agree much with both what you say and how you say it, but I must admit that this one is, well... just brillant !-) (IOW: rofl, keyboard, and +1 QOTW) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Wed, 2008-05-14 at 13:27 -0700, [EMAIL PROTECTED] wrote: On 14 mai, 00:41, John Machin [EMAIL PROTECTED] wrote: (snip) IIRC the idea was so that managers could write programs in English. It failed because nobody could write a parser that would handle something like The bottom line is that the stakeholder group requires the situation going forward to be such as to facilitate the variable known as x to provide the same outcome when stimulated by dereferencing as the variable known as y. John, I usually don't agree much with both what you say and how you say it, but I must admit that this one is, well... just brillant !-) (IOW: rofl, keyboard, and +1 QOTW) -- http://mail.python.org/mailman/listinfo/python-list Agreed. Best. Synonym. EVAR. (I won't give away the fun by saying what it's a synonym for) Cheers, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 14 mai, 08:08, Lie [EMAIL PROTECTED] wrote: On May 14, 12:51 pm, Lie [EMAIL PROTECTED] wrote: And your 8 by 8 cross compiler doesn't impress me at all, they're all based on x86/IA-32 architecture which is quite similar, no PowerPC, SPARC, ARM, no other CISC or RISC architecture. And your compiler is a single language compiler instead of three dimensional compiler that GCC is (cross platform, cross target platform, cross language). And to add, I also need to mention that Python doesn't need to be compiled at all, No language needs compilation - it's an implementation problem, not a language problem. Now all the Python's implementations I know do use compilation (to byte-code). its py and pyo file is architecture independent. True, but this is not strictly related to being compiled or not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 13 mai, 19:05, Dave Parker [EMAIL PROTECTED] wrote: Just to support this statement: PHP runs an order of magnitude slower than python. Yet a great deal (if not the majority) of dynamic sites out there run under PHP. All of these are unhappy customers? The websites owners might not be unhappy, but lots of customers complain about slow websites, so if the market is competitive then eventually the PHP fad will die out. Some of the slower websites I've seen where using Java - which is supposedly way faster than Python. And even a static (pure HTML) web site can become more than painfully slow if the server can't handle the load, as anyone working in the field could tell you. But this is obviously one more area where you are just totally clueless. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dave Parker schrieb: All of the calculators and textbooks that elementary school students use, use ^ for powers. I've never seen this symbol in textbooks. In textbooks, powers are written using superscript. Just like Flaming Thunder does. I haven't seen ** for powers since FORTRAN. I haven't seen any language using '^' as the power operator so far - but I've seen quite a lot of them using it as the bitwise XOR operator. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On 13 mai, 18:36, Dave Parker [EMAIL PROTECTED] wrote: (snip) Also, in Python how do you assign a symbolic equation to a variable? Like this? QuadraticEquation = a*x^2 + b*x + c = 0 quadratic_equation = lambda x, b, c : a*(x**2) + b*x + c == 0 or if x, b and c are supposed to be captured from the current namespace: quadratic_equation = lambda : a*(x**2) + b*x + c == 0 Set statements avoid the confusion of multiple equal signs when manipulating symbolic equations: using '=' for assignement and '==' for equality test does the same thing. And it's a very common pattern in programming languages. -- http://mail.python.org/mailman/listinfo/python-list
