Why JPython for the hard stuff? 
Author Message
 Why JPython for the hard stuff?


Quote:
> I've been on the JPython mailing list for a while now and periodically read
> this newsgroup.  My question is, with the level of sophistication and
> complexity of problems JPython developers are trying to solve, why not use a
> language like Java (or Smalltalk, delphi etc..)?  I thought the purpose of
> scripting languages were to make programming faster and easier as a result
> of their simpler conceptual model.  If you want to delve this deep, why not
> use an "industrial strength language" instead of trying to figure out how to
> get industrial strength solutions out of a scripting language?

Without getting into a "scripting language war" <wink> I think the
answer is that python transcends the "traditional" definition of a
scripting language --- which is something like VB for Applications, that
is design to only do a very limited set of functions.

QUite honestly, Python is much more of a RAD language than anything
else, and that's where it is often used.  Many times I can get something
running in Python in a day that would take a week+ in Java, and months
in C++/C.  Some of this is the fact that lots of things are included
inthe language that aren't really integrated fully in other languages
(dictionairies, etc), some of it is the dynamic nature of hte language
that lets me shove all kinds of things into a dictionairy or list and
not worry about what type they might be.

Often what JPython is being used for (I think) is prototyping Java
applications, getting the hard part done first (the logic/algorithms),
and then moving pieces into Java/whatever... same as what it's done in
Python in the rest of the world.

I have 3 projects that started out as pure Python, and are now 80%
Python, 20% C code (to do time sensitive things that I've found lacking
in the profiler), which has gotten me (I estimate) to within 10-15% of
what I would have gotten from pure C code in EASILY 1/100th the time.

I know people who have written (and maintained) Python applications over
10,000 lines, which would traslate to probably 100K lines of C code and
50K of Java, just a guess, and they're not even the least bit unweildy,
unlike some other "scripting" languages ...

THat's jut my view though, everyone else obviously disagrees, or I
wouldn't be locked in this cage!

rattling-the-bars-to-get-your-attention-ly'yours,
Chris
--
| Christopher Petrilli



Thu, 26 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

* Michael N. Christoff
|
| My question is, with the level of sophistication and complexity of
| problems JPython developers are trying to solve, why not use a
| language like Java (or SmallTalk, Delphi etc..)?

I think you've fallen for a very common misconception here. That a
language is simple does not mean that it's unsuitable for solving
complex problems, quite the contrary. If you want to solve something
complex you want to be able to use as much brainpower as possible on
your problem, and not have to keep thinking about the language you
solve it in.

In this sense Java and Delphi are rather unsuitable, since they force
you to think more about the language and less about the problem, and
C/C++ probably the worst possible choices except for assembler. (Of
the serious contenders, that is. Intercal would probably be even worse.)

Of course, simplicity is not the only thing one wants. In general,
what you want is the ability to model the problem as closely as
possible in your program and with as little effort as possible. And
for this purpose I'd say Python and especially Lisp are far more
powerful than Java or Delphi.

Indeed, in Lisp it is common to develop your own 'language' designed
for solving your particular problem, and then write your program in
that.

| If you want to delve this deep, why not use an "industrial strength
| language" instead of trying to figure out how to get industrial
| strength solutions out of a scripting language?

Well, this is another common misconception. Industrial strength does
not necessarily relate to complexity, but more to stability,
performance and scalability. (Or, in a word, reliability.) Because of
the way computers are designed, the end result is often complex, but
that is really accidental and not a necessity.

So the reason to use Java or C++ instead of Python for something
complex is simply that the end result will run faster, have less
chances of memory leaks (in Java) and use less memory (or at least in
a more controlled fashion).

Some people would also claim that strong typing and lots of
compile-time checks help, and while I think they do to some extent
they certainly carry a cost as well. This may be less troublesome in
languages like Standard ML and Haskell, though. (I haven't really
enough experience with them to tell.)

I think Gadfly is the perfect example of this. It's a nearly complete
RDBMS, something that's truly complex and industrial-strength, and
it's written in pure Python. The result requires a lot of memory and
is slow compared to say Oracle or Sybase, but it was written by one
single person in his spare time, which would be unthinkable for an
RDBMS developed in C/C++.

It's a common mistake in computing to equate complexity with power and
to think that simple languages that anyone can use must be unsuitable
for _real_ programming. I think the terrible design of languages like
Perl, tcl and VB that for some unfathomable reason were never intended
to scale has to take much of the blame for this.

In good scripting languages like Emacs Lisp, Smalltalk and Python
people often write huge programs and get them to work with less
trouble than one often has in Java/Delphi/C/C++/whathaveyou.

Thanks for asking this question. It was good to finally get this off
my chest. :-)

--Lars M.



Fri, 27 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

Quote:

>I've been on the JPython mailing list for a while now and periodically read
>this newsgroup.  My question is, with the level of sophistication and
>complexity of problems JPython developers are trying to solve, why not use a
>language like Java (or SmallTalk, Delphi etc..)?  I thought the purpose of
>scripting languages were to make programming faster and easier as a result
>of their simpler conceptual model.  If you want to delve this deep, why not
>use an "industrial strength language" instead of trying to figure out how to
>get industrial strength solutions out of a scripting language?

What makes you think Python is a scripting language?

Cheers /F

http://www.pythonware.com



Fri, 27 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

[On Python for RAD / prototyping]:

Quote:
> I have 3 projects that started out as pure Python, and are now 80%
> Python, 20% C code (to do time sensitive things that I've found
> lacking in the profiler), which has gotten me (I estimate) to within
> 10-15% of what I would have gotten from pure C code in EASILY
> 1/100th the time.

100% agreed. I have also (unscientifically) observed that, when
preceeded by a Python prototype, not only is the resulting C / C++ /
Java code done sooner and better, but it's much smaller than if
developed from scratch in the target language. I think this is
because when developing from scratch, one tends to use the target
language's idioms as your building blocks while Python lets you think
about the problem much more directly. This view would probably not be
appreciated by those who claim their favorite language's idiomatic
nature is an asset <snicker>.

Quote:
> THat's jut my view though, everyone else obviously disagrees, or I
> wouldn't be locked in this cage!

Didn't they tell you? That's just your table-manners <wink>.

- Gordon



Fri, 27 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

Quote:

> I've been on the JPython mailing list for a while now and periodically read
> this newsgroup.  My question is, with the level of sophistication and
> complexity of problems JPython developers are trying to solve, why not use a
> language like Java (or SmallTalk, Delphi etc..)?  I thought the purpose of
> scripting languages were to make programming faster and easier as a result
> of their simpler conceptual model.  If you want to delve this deep, why not
> use an "industrial strength language" instead of trying to figure out how to
> get industrial strength solutions out of a scripting language?

Because Python isn't a scripting language, it's a programming language.
One of the best (maybe THE best) programming languages ever made, IMHO.

Cheers,
-- Joe



Fri, 27 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?
I've been on the JPython mailing list for a while now and periodically read
this newsgroup.  My question is, with the level of sophistication and
complexity of problems JPython developers are trying to solve, why not use a
language like Java (or SmallTalk, Delphi etc..)?  I thought the purpose of
scripting languages were to make programming faster and easier as a result
of their simpler conceptual model.  If you want to delve this deep, why not
use an "industrial strength language" instead of trying to figure out how to
get industrial strength solutions out of a scripting language?

Just asking...
    l8r, mike



Fri, 27 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

* Lars Marius Garshol
|
| I think Gadfly is the perfect example of this. It's a nearly complete
| RDBMS, something that's truly complex and industrial-strength, and
| it's written in pure Python. The result requires a lot of memory and
| is slow compared to say Oracle or Sybase...

* Aaron Watters
|
| believe it or not I've had some reports that this is *not*
| the case under some circumstances.

I know. Sorry, I was a bit quick here, since I was focusing on
something else.

(Oh, and BTW, thanks for ruining my argument for why Python isn't
suited for everything. :)

| The problem of db benchmarking is very complex, with lots of
| dimensions, so given complete control of the parameters I think
| you could cook a benchmark that made gadfly look decent :).

Very likely, yes. :)

--Lars M.



Sat, 28 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

Quote:



> > I think Gadfly is the perfect example of this. It's a nearly complete
> > RDBMS, something that's truly complex and industrial-strength, and
> > it's written in pure Python. The result requires a lot of memory and
> > is slow compared to say Oracle or Sybase...
> believe it or not I've had some reports that this is *not*
> the case under some circumstances.  The slow part may be the
> start up and shut down and Oracle or Sybase can certainly handle
> db sizes that gadfly cannot, but once
> gadfly/cpython/kjbuckets is running, under
> some circumstances at least, it can have decent speed. YMMV.

ANd remember that as memory sizes get bigger, the size of the database
you can manage in memory gets larger too :-)  I have a Sun U60 w/2GB of
RAM, and I'm just itching to cram 1.5Gb of data into a Gadfly database
and benchmark it against Oracle :-)

Quote:
> The problem of db benchmarking is very complex, with lots of
> dimensions, so given complete control of the parameters I think
> you could cook a benchmark that made gadfly look decent :).

Never forget the words of a Southern gentleman:

        "Lies, damned lies, and statistics" -- Samuel Clements

Chris
--
| Christopher Petrilli



Sat, 28 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

Quote:

> Never forget the words of a Southern gentleman:

>         "Lies, damned lies, and statistics" -- Samuel Clements

"and benchmarks" -- Garry Hodgson

--
Garry Hodgson                   comes a time

Software Innovation Services    takes your hand, says,
AT&T Labs                   "don't you see?"



Sun, 29 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

Quote:
> > > Never forget the words of a Southern gentleman:
> > >         "Lies, damned lies, and statistics" -- Samuel Clements
> > "and benchmarks" -- Garry Hodgson
> Wasn't it Disraeli?

Chapman: I didn't expect a kind of Spanish Inquisition.

Ximenez:  NOOOBODY expects the Spanish Inquisition.
  Our chief kind of lie is just a lie.  A lie and a
  damned lie ... The two kinds of lies are lies and
  damned lies ... and statistics ... the *three* kinds
  of lies are lies, damned lies, and statistics ... and
  benchmarks.  The *four* ... um.   AMONGST the kinds
  of lies are such elements as lies, damned lies, statistics,
  quotation attributions ... and python sketch parodies.

Chapman: I didn't expect a kind of Spanish Inquisition.
--
    Xxxx Xxxxxxxx



Sun, 29 Jul 2001 03:00:00 GMT  
 Why JPython for the hard stuff?

Quote:




> > > Never forget the words of a Southern gentleman:

> > >         "Lies, damned lies, and statistics" -- Samuel Clements

> > "and benchmarks" -- Garry Hodgson

> Wasn't it Disraeli?

i don't recall Disraeli ever commenting on benchmarks.

--
Garry Hodgson                   comes a time

Software Innovation Services    takes your hand, says,
AT&T Labs                   "don't you see?"



Mon, 30 Jul 2001 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Hard Drive Serial Number & Stuff

2. Q: JPython crashing, why ?

3. Why is JPython so slow?

4. Why so hard to get started in Eiffel?

5. Why is Rexx hard to compile.

6. Why are Variables so hard to monitor?

7. why is tree-shaking hard?

8. why why why oh why why baby

9. New JPython domain and website (www.jpython.org)

10. jpython.main vs. PythonInterpreter under WinNT JPython

11. Hard disk problems - Hard ones :))

12. Hard disk I/O the hard way

 

 
Powered by phpBB® Forum Software