Python and Flaming Thunder

M

MRAB

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

Dave Parker

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

Giampaolo Rodola'

[...] 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
 
B

Bruno Desthuilliers

Daniel Fetchinson a écrit :
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.
 
S

s0suk3

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

Bruno Desthuilliers

(e-mail address removed) 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 ?
 
M

Mensanator

Dave Parker said:
 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
 
M

Mel

Mensanator said:
Dave Parker said:
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.
 
B

bruno.desthuilliers

This is a common feature in functional languages...

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

Matthew Woodcraft

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

Brian Quinlan

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

Charles Hixson

...

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

I V

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

Kay Schluehr

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?"
 
I

Iain King

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

Dave Parker

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

Dave Parker

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.

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

Dave Parker

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

Luis Zarrabeitia

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

Dan Upton

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.
 

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,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top