Re: [Visualpython-users] Future = (Vpython + Glowscript) | Glowscript | ???

[Bruce S. <Bru...@nc...>]

Very interesting. There is much in your message about which I have no
knowledge and no opinion. However, I can make some comments about the
Big Picture.

For a variety of reasons, I am personally committed to the further
development and maintenance of both VPython and GlowScript.

One of the reasons is more political than technical. With Ruth Chabay
I am the co-author of a textbook and curriculum for intro physics
(matterandinteractions.org) which includes an introduction to
computational modeling, in which students write VPython programs to
model physical systems. This reflects the fact that physics today
isn't just theory and experiment, it's theory and experiment and
computational modeling, but this important change has not been
reflected in physics education, one of the serious problems we are
addressing. Other problems include the fact that the intro physics
course taken by engineering and science students in college stops
around 1860, whereas we take a 20th-century perspective and even admit
that atoms exist.

There are a thousand excuses available to physics faculty for why one
shouldn't bring the intro physics course up to date. One of them is
that the physicist could probably find a card-carrying computer
scientist ready to testify that computer language X rots the brain.
Python however is in good esteem in the CS community, so it would be
difficult to find a computer scientist ready to testify that it's
terrible to use Python in the intro physics course.

Another issue is that (as you point out) there is little
infrastructure at present for the support of computation.in
JavaScript. This may change, but certainly Python has a far richer
computational ecology. VPython is attractive to scientists for
visualization purposes, and many scientists know and use Python. Few
scientists today know or use JavaScript.

I agree that Python as a language is far more attractive than
JavaScript. However, CoffeeScript (which is also supported in
GlowScript) has the good features of Python but compiles instantly to
JavaScript. In particular, CoffeeScript uses white space, thereby
eliminating lots of cluttering of braces. Moreover, CoffeeScript makes
it impossible to do the Bad Things that people regret about
JavaScript.

Recently I've been writing GlowScript examples in CoffeeScript, and I
like it for the same reasons that I like Python. If you go to
glowscript.org and click on "Example programs", you'll find some pairs
of examples, one in JavaScript and one in GlowScript; also the Rug
example is in CoffeeScript. Incidentally, I have no problem running
GlowScript in Ubuntu, using the proprietary NVIDIA driver.

As I've said, I'm dreaming of constructing a VPython+ that would
require a modern graphics card. If possible, I'd like to build it on
top of one of the newer Python frameworks that work cross-platform, in
particular to solve the menacing problem that Carbon on the Mac is not
available for 64-bit Python. I'm not able to tackle this immediately
because I have some major responsibilities to work on a fourth edition
of our physics textbook. I should mention that recently someone tried
to build VPython on a pure Python framework but, as I expected, it ran
about 50 times slower than VPython, so one has to choose the framework
carefully.

A very important simplification is possible. In GlowScript if you
write an infinite loop you MUST include a rate or similar statement to
allow the screen to be updated, as there is no interrupt possbility in
JavaScript. Most VPython animations include a rate statement, so I
judge it wouldn't be terrible to require one, thereby eliminating the
rather complex threading that is currently at the heart of VPython,
and which is the reason that David Scherer and I were unable to
implement VPython in Cocoa on the Mac.

On the first page of the Help at glowscript.org you'll find some
comments addressed at those familiar with VPython, including
side-by-side comparisons of Python and JavaScript elements. There is
even a VPython -> GlowScript converter I wrote in Python which does
much of the grunt work but still requires some manual conversion of
the resulting JS code. This converter is much less sophisticated than
pyjs, as my goal was just to assist, not do the enormous amount of
work required to do the full job.

I wasn't aware of the pypy.org project, and certainly running 5 times
faster than CPython is important. What is "co", which you mention?

Bruce Sherwood

On Fri, Jun 8, 2012 at 10:50 PM, C Anthony Risinger <an...@xt...> wrote:
> On Wed, Jun 6, 2012 at 6:40 PM, Bruce Sherwood <Bru...@nc...> wrote:
>>
>> [...] JavaScript is slower than C++ but
>> considerably faster than Python. To my knowledge, there is no
>> possibility for something like numpy, which runs at the speed of C.
>
> once numpy and co can run on pypy, will visual?  pypy.org has been
> raising money for the numpy port ... ~45k of 60k.
>
>> Another speed issue to consider is that because GlowScript uses WebGL,
>> which requires the use of modern GPU-type graphics cards, many kinds
>> of graphics can be significantly faster than in VPython, which
>> currently uses GPUs only optionally, for textures. I've been dreaming
>> of a VPython+ that would also require the use of a modern graphics
>> card.
>
> so, as someone who as lurked this list for probably 4+ years now, this
> is something i've been wondering since the inception of glowscript and
> all the chatter/activity around it compared to vpython ...
>
> how does glowscript and vpython fit together in the "big picture"?
> has interest in the python module diminished (none? some? all?) in
> favor of JS?
>
> this is not really a criticism, whatever you answer; i'm mostly
> curious because i'm doing a short presentation next week on vpython to
> my company (~40-60 other developers, JS/Python/.NET/C#), and i'm
> writing up a demo program (visualization of message queue data! yay!)
> and supporting materials this weekend.  i haven't actually ran
> glowscript successfully on my archlinux machines, in any browser, but
> i planned on giving it an honorable mention as i know several JS
> developers will be interested.  primarily, i just want to give a good
> representation of what visual is, and what is to come.
>
> i know it's a pretty open ended question, but it's been on my mind for
> awhile.  i wrote JS for many years before learning (and instantly
> embracing) python; it goes without saying that IMO ...
>
> Python > JS**10
>
> ... alas, i'm almost assuredly biased, as i work on projects like
> pyjs.org translating Python-to-JS (for the goodness of all ;-) ... i
> was even considering implementing a pyjs wrapper to glowscript,
> "theoretically" allowing vpython programs to run unmodified in the
> browser.  all-in-all, JS/ECMAscript, as implemented in browsers at
> least, is a wonderfully powerful language but offers no supporting
> infrastructure whatsoever. with the advent of pypy, any performance
> gaps are probably not so large (unconfirmed), should they exist at all
> (absolutely unfounded).
>
> what say you!?!? :-) again, while i prefer and champion the python
> side of things, i completely understand the
> benefit/opportunity/convenience of glowscript -- both are super-cool
> and vpython is loads of fun.
>
> thanks,
>
> --
>
> C Anthony
>
> aside: at pyjs.org we've tried to bring python to the web via
> translation, but also direct bindings to the layout engine
> (Trident/XULRunner/WebKit), some of which are very successful.  we are
> looking for a more universal way to achieve direct bindings, say via a
> plugin toolkit like Firebreath, or similar.  perhaps you can better
> merge the two projects by doing the same -- use a browser to render
> vpython.  if you drive the browser's WebGL engine directly you can get
> all the benefits (hardware accel/etc) in vpython for free.  the
> Trident engine (Windows) is the most stable for us, accessed via COM
> interface, and the GObject WebKit bindings are the next promising
> method for other platforms.  there are also mature ObjC bindings to
> WebKit.  not sure how/if WebGL is exposed currently, but it might be
> worth pursuing.