Python and Flaming Thunder

D

Dave Parker

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. ;)
 
D

Diez B. Roggisch

Kind of like how this year's program won't work on next year's

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
 
D

Dave Parker

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.
 
D

Dave Parker

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) ..."
 
G

George Sakkis

For somebody who has admitted to have only very rudimentary knowledge of
python that's a pretty bold statement, don't you think?


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
 
D

Diez B. Roggisch

Dave said:
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
 
D

Diez B. Roggisch

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
 
G

Giampaolo Rodola'

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.


Kind of like how this year's program won't work on next year's
Python?  Except Flaming Thunder is faster. ;)

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.


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
 
D

Dan Upton

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.
 
D

D'Arcy J.M. Cain

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

Dan Upton

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.
 
D

Dave Parker

Dan said:
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 said:
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.
 
A

alex23

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.
 
M

Marc 'BlackJack' Rintsch

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
 
J

John Salerno

Dave Parker said:
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).
 
J

John Salerno

---
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.
 
D

Dan Upton

---
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...

;)
 
D

Dave Parker

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,008
Latest member
Rahul737

Latest Threads

Top