21 May
2010
21 May
'10
5:33 p.m.
On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
I agree with the Qt option, as it clearly produces
some nice & performant
music applications. But you're still programming in C++ which is tedious
because of memory management; also "hard realtime" often precludes the use
of Garbage collectors. Of course Java has RT garbage collectors available:
http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/ although
yeah...
Java RTS has an innovative pricing model that starts at $6500 per
socket/CPU for development or internal deployment.
well... thanks :S
some may find "soft realtime" garbage
collection as provided by the new G1
garbage collector sufficient:
http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf ... see also:
http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html
hmm... maybe this actually works.
still relies on some particular jvm.
effectivily throwing away the whole portability mumbojumbo.
Lots of interesting Java-based music apps exist, with GUIs:
http://jmusic.ci.qut.edu.au/applications.html
http://www.softsynth.com/links/java_music.html
GUI application programming might be a little more forgiving in Java,
although Java is a pain-in-the ass language, where you spend more time
building and understanding scaffolding than you actually do programming...
part of the scaffolding are the "design patterns" needed to work-around
fundamental issues with primitive strongly typed languages like Java and C++
(
http://www.tiagoluchini.eu/2007/07/28/strategy-pattern-comparing-java-x-lis…
).
i dont understand... are you seriously arguing that dynamic languages
are always better ?
this certeinly isnt the case for number crunching.
and i really find bigger programs pretty confusing in dynamic languages
where variables arent annotated with types.
The good thing is you don't need to use Java anymore, but can take advantage
of its portability, security, advanced garbage-collection options, and
just-in-time compiler advances that may give it a performance advantage,
these days.... But you don't have to program in Java, you write in
http://groovy.codehaus.org/ or http://clojure.org which means you can do
really high-level things with just a few lines of groovy code (
http://lists.xwiki.org/pipermail/users/2009-August/016937.html ).
Fortunately, several million unfortunate souls have slogged through all the
hard work and made a huge library of functionality for people to use, much
of it open source.
http://curious-attempt-bunny.blogspot.com/2009/01/simple-clojure-graphics-a…
is
a good example of the concision made possible by clojure...
i think that code is pretty hard to read.
and concision isnt always good.
there is a reason why people call perl a "write-only" language.
Clojure may be of particular interest in realtime
multiprocessor/multithreaded apps because of its high level., language-level
support for concurrency and multithreaded programming (
http://clojure.org/concurrent_programming ) as well as potential support
for Software Transactional Memory, which is analogous to garbage colleciton
for threads ( http://www.stanford.edu/class/cs242/readings/TMvsGC.pdf
http://java.ociweb.com/mark/stm/article.html ).
i really dont see any advantage over faust here.
au contraire. a quick glance on the clojure stuff tell me that
you still need to manage concurrency in some way.
while faust is able to parallelize any valid faust code.
overall when it comes to RT stuff.... either you use a language which
gives you control over heap allocation. or the language must be
specifically designed for RT operation.
so we end up with c/c++ again.
or faust.
and angelscript would be a valid interpreted language.
because it gives the hosting app complete control over all allocations
going on.
all this stuff you posted is nice... but i dont really have any hopes,
that this stuff would become useable in the next 2 years.
stop dreaming :)
--
torben Hohn