Re: Python and Flaming Thunder
True. But in Python, you don't see statically-linked pure-syscall CGI
Your bets don't count anything here. These things don't exist, so don't brag
on them being superior.
Quite a revealing statement I'd say. And unless you don't show any
real-world site running on FT that needs things like sessions, cookies,
database-connectivity, unicode and a ton more of stuff FT doesn't support
out-of-the-box or through 3rd-party-libs, I wouldn't mention "the people"
as well. So far, *all* that you've been showing on your site regarding CGI
are toy-scripts. Nothing more.
>
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.
This shows how much you don't know about customers, and their needs. A
customer gives a s**t about 5-10 times faster sites. They care if it is
*fast enough*, but beyond that they don't bother. But what *always* bothers
them is development time & flexibility. Because that directly affects the
price they pay.
And if a average man-day costs $600 (which is not expensive), and the
project is of average size of a couple of man-months - well, you care about
mathematics, do the math yourself what that means that FT lacks anything
but a simple CGI-interface.
It does require more, because it lacks all the libs and 3rdparty-libs. And
because it lacks features such as OO and other stuff, it will be harder to
write these as well as use them.
Show me how to beat a quickstarted TurboGears/Django webproject. *Then* you
can talk business here.
Who has conducted the research that supports that statement? And since when
is ^ the better operator for "to the power of" that **? Because latex uses
it? I need to see the elementary school students who use that...
Even *if* that would be true, how does a perceived advantage in one field FT
was explicitly created for show that it is the generally better one and
understandable one for more diverse applications?
Diez
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. 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.
server. And you don't see the speed of pure assembly language
libraries. 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.
on them being superior.
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.
CGI scripting is reason enough to pay $19 per year. But maybe for
other people, having slow, inefficient programs and websites is
acceptable.
real-world site running on FT that needs things like sessions, cookies,
database-connectivity, unicode and a ton more of stuff FT doesn't support
out-of-the-box or through 3rd-party-libs, I wouldn't mention "the people"
as well. So far, *all* that you've been showing on your site regarding CGI
are toy-scripts. Nothing more.
>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.
customer gives a s**t about 5-10 times faster sites. They care if it is
*fast enough*, but beyond that they don't bother. But what *always* bothers
them is development time & flexibility. Because that directly affects the
price they pay.
And if a average man-day costs $600 (which is not expensive), and the
project is of average size of a couple of man-months - well, you care about
mathematics, do the math yourself what that means that FT lacks anything
but a simple CGI-interface.
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.
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.
because it lacks features such as OO and other stuff, it will be harder to
write these as well as use them.
Show me how to beat a quickstarted TurboGears/Django webproject. *Then* you
can talk business here.
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.
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 ^ the better operator for "to the power of" that **? Because latex uses
it? I need to see the elementary school students who use that...
Even *if* that would be true, how does a perceived advantage in one field FT
was explicitly created for show that it is the generally better one and
understandable one for more diverse applications?
Diez
Comment