Re: Python and Flaming Thunder

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.

Here's one of the tricks I use: I wrote an assembly language
preprocessor that takes 1 assembly language source file and generates
the library code for the 8 different target platforms. That's much
easier than maintaining quirky C code across 8 different platforms --
which is why GCC's support for cross-compilation is often so broken.

On May 13, 10:57 am, "Andrii V. Mishkovskyi" <misho...@xxxxxxxxx>
wrote:
You sound like a commercial. Is this your way of attracting costumers of FT?

2008/5/13 Dave Parker <davepar...@xxxxxxxxxxxxxxxxxx>:

5-10 times faster for what kind of code?

 Mostly numerical analysis and CGI scripting.  All of Flaming Thunder's
 library code is in assembly language, and Flaming Thunder creates
 statically-linked pure syscall CGI scripts.

 > I don't see anything that resembles OO features of python, ...

 True.  But in Python, you don't see statically-linked pure-syscall CGI
 scripts being cross-compiled under Windows for ftp'ing up to a Linux
 server.  And you don't see the speed of pure assembly language
 libraries.

I see your assembly language libraries and raise you C language libraries. :)
Python libraries have the speed of pure C language libraries. And
while programs and libraries written in assembly may be twice as fast
as programs and libraries written in C, they're real hell to maintain.
But that doesn't stop you from telling us, that:

 And I'll be willing to bet that Flaming Thunder will have
 OO features similar to Python before Python has the features that
 Flaming Thunder already does.

Well, we'll see. But, IMHO, this is highly unlikely.

 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.

Yeah, right, Python is sooooo slow. :) Show us some sites and programs
that were written in FT.



 > And what is really expensive is brain-cycles, not cpu-cycles.

 Depends on whether you're the programmer, or the customer.  I've found
 that customers prefer products that are 5 to 10 times faster, instead
 of products that were easy for the developer.

If I'm customer, than why should I care about FT?
If I'm a programmer, I'd better care about brain-cycles.



 And I disagree that Flaming Thunder requires more brain-cycles.
 Because it's based on leveraging existing English and math fluency
 (which was one of the original goals of Python, was it not?), I think
 that Flaming Thunder requires fewer brain-cycles because fewer brains
 cells have to be devoted to memorizing language peculiarities.

Not everybody has grown in English-speaking community, you know. And
knowing math quite good, I prefer writing "x = y" instead of "Set x to
y".







 > Let alone it is
 > very much a question of view-point if two different looping constructs or
 > keywords are more awkward than one general looping-concept with only one
 > keyword. It's a matter of taste.

 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

 then I think the comparison moves beyond a matter of taste into the
 realm of measurable ease-of-use.

'^' is a bitwise XOR. Python uses "x**y" for raising x to power of y.
What's your point here?







 On May 13, 9:50 am, "Diez B. Roggisch" <de...@xxxxxxxxxxxxx> wrote:
 > > Also, several users have rewritten their Python programs in Flaming
 > > Thunder, and found that Flaming Thunder was 5 to 10 times faster
 > > (Flaming Thunder compiles to native executables).  So again, since
 > > many people value their time at more than $0, I think that many people
 > > will find that Flaming Thunder is worth $19.95 per year.

 > 5-10 times faster for what kind of code? I don't see anything that resembles
 > OO features of python, let alone more advanced concepts like
 > meta-programming, higher-order functions and such. Which save tremendous
 > amounts of time coding. If FT grows these and *still* is 5-10 times faster,
 > I'll salut you.

 > And what is really expensive is brain-cycles, not cpu-cycles. Which above
 > described features save.

 > > Plus, me getting paid to work on Flaming Thunder is far more
 > > motivating than me not getting paid to work on Python.  This weekend,
 > > Python users will still be debating how to fix awkwardnesses in the
 > > languages (such as FOR loops where you're just counting the loops and
 > > not referencing the loop variable) -- but Flaming Thunder users will
 > > be getting work done using the REPEAT n TIMES constructs that I'll be
 > > implementing.

 > > Python has been around about 15 years, yet still has those
 > > awkwardnesses.  Flaming Thunder has been out less than 6 months and
 > > those awkwardnesses are already getting fixed.  The difference: I
 > > can't afford to ignore users.

 > Oh *please*! Try getting nearly as feature & library complete as python is
 > today - and *then* I'll point to all the akwardness of FT. Let alone it is
 > very much a question of view-point if two different looping constructs or
 > keywords are more awkward than one general looping-concept with only one
 > keyword. It's a matter of taste.

 > Diez

 --
 http://mail.python.org/mailman/listinfo/python-list

--
Wbr, Andrii Mishkovskyi.

He's got a heart of a little child, and he keeps it in a jar on his desk.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

.

Relevant Pages

  • Re: Python does not play well with others
    ... Python is quite capable in many areas, such that the people in the ... community with the expertise to extend the language and libraries, ... involve libraries, not some deficiency of the language. ...
    (comp.lang.python)
  • Re: Python does not play well with others
    ... you have to undestand that python is not like other languages. ... what some people actively developing the language are actually doing with it ... Libraries, on the other hand, ... Something like that happened to the C++ standards committee. ...
    (comp.lang.python)
  • Re: How Common Lisp sucks
    ... web server up and running using Python takes substantially less effort ... You're right, it's not an advantage of the language itself, but it's ... the effort required to locate the right libraries ... I think a lot of the advances that happen in programming languages ...
    (comp.lang.lisp)
  • Re: Why Lisp is not popular with average programmers
    ... If I want SMTP client support in my script, Python has it out of the box. ... In Python, the whole thing seems packaged together into a coherent whole, whereas in Lisp, it seems more like an exercise in trying to put square pegs in round holes. ... Libraries does not a language make. ...
    (comp.lang.lisp)
  • Re: Python and Flaming Thunder
    ... the cost of just one book on Python. ... looking at such a weird and unconventional language? ... Are Flaming Thunder books free? ... programmers are not customers of some clunky proprietary product, ...
    (comp.lang.python)