We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
Index › Suggestions & Bugs › Software,  Documentation,  Website Suggestions › Crummy syntax / Alternative languages
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1
Crummy syntax / Alternative languages (Read 1589 times)
Endolith
Crummy syntax / Alternative languages
May 16th, 2009, 10:00pm  
My first impression of Processing was good, but now that I'm trying to actually do something with it, I'm being held back from "sketching" by all the tedium of dealing with Java syntax.  It's frustrating to have things not work because of variable type or declarations or class re-declarations or whatever.

In the FAQ, it admits that the syntax is "crummy", and in the Tutorial calls it "somewhat bewildering", but it explains that one purpose of the language is "a point of transition to more complicated or difficult languages like full-blown Java or C++".  This is also in the "Getting Started" page:

Quote:
Processing was never intended as the ultimate language for programming visuals; instead, we set out to make something that was ... A stepping stone from scripting languages to more complicated or difficult languages such as full-blown Java or C++.

So my questions:
1. Why is this one of the goals of Processing?  Is it really one of the goals from the beginning, or was this just added in later to justify not changing the syntax? Smiley
2. If the syntax is never going to change, is there another language that meets the first two criteria, but not the third?  Something that is intended to be the ultimate language for programming visuals, with a syntax appropriate for this purpose?

Also, it says

Quote:
At the intersection of these points is a tradeoff between speed and simplicity of use. i.e. if we didn't care about speed, Python, Ruby or many other scripting languages would make far more sense (especially for the simplicity and education aspect of it).


Quote:
   Of course, strictly speaking, Java is itself an interpreted language, but its bytecode compilation brings it much closer to the "metal" than languages such as JavaScript, ActionScript, Python, or Ruby.


But isn't Python compiled to bytecode, too?  Is it that much slower for graphics stuff like this?  Seems like with a graphics library written in C it could be very fast.

Obviously a major benefit of Java (and processing.js) is that it can run in a browser, but it seems like that could be done with a different syntax going through a translator anyway.
Back to top
 
 
PhiLho 
Re: Crummy syntax / Alternative languages
Reply #1 - May 17th, 2009, 1:49am  
1) It is a syntax many people understand.
2) Going from Java, even more given the time Processing was designed, when there was no alternative language on the JVM, the simplifications made by Processing are a great progress: no need to define a class, a main() function, etc.
3) There are already some alternative Processing implementations, although most try more or less to follow this syntax.
4) Alternatives are listed in the main page of the site. There are more, eg. some game engines can be used for this (see LÖVE with Lua syntax, for example). And lot of languages (Python, Groovy, etc.) already have graphics libraries.
5) Currently, Java's bytecode is more optimized than Python's one (or other languages), partly because lot of effort have been put for years on optimizing the JVM, the JIT (compilation to native code), etc.
That's why JavaFX is much faster than Flash, for example. You can try it too, for an alternative syntax.
Back to top
 
WWW  
Endolith
Re: Crummy syntax / Alternative languages
Reply #2 - May 19th, 2009, 9:07pm  
So it looks like Ruby Processing is the most popular/developed?  But there's also some attempts at Python, and Scala...

http://hipstersinc.com/blog/2008/1/23/scala_and_processing/

http://i.document.m05.de/?p=483

http://github.com/bmander/prender/tree/master

I also found this quote by REAS, so I'm not insane in this:

Quote:
I agree entirely that Java syntax is not always ideal for the type of work that Processing is used for. Back in 2001, it was a choice between Java and Python and we selected Java for the Web benefits. The world of 2008 is different.


Back to top
« Last Edit: May 21st, 2009, 6:21pm by Endolith »  
 
Page Index Toggle Pages: 1
‹ Previous Topic | Next Topic ›