Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual machine that can be used to execute bytecode compiled dynamic languages such as Perl6, but also Perl5. Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl.
Tools that simplify witting new languages excite me. I see many significant programming tasks as language interpretation or translation (compilation). The "language" doesn't have to be in the form of a concrete text file: interpretation could mean interpreting UI events; compilation could mean converting one data structure into another. From this perspective, meta programming (language authoring) is very important. Obviously not all parsing tasks are well served by lex and yacc, and similarly I wouldn't expect LLVM (or MLRISC, or whatever...) to be a perfect fit for all compilation tasks. But where they are a good fit I expect to be able to write software that is simpler, more robust, and more fully featured. That makes me happy.
Languages without "real" unification feel unexpressive or too low level. Whenever I program in something other than prolog (which is most of the time) I miss it.
Example: [foo(A,x)|B] = [foo([p,q],x),C,d,e]. which implies that A = [p,q], B = [C,d,e], and C remains unconstrained.
Writing a shader, especially one that requires multiple passes can be a hassle; that is why there are higher level shading languages and compilers being developed. This one for example is worth checking out, if only for the demos.
What I have seen done, which is more practical, especially for the hobbyist, is to use a small solar cell and a capacitor. When the capacitor is charged, move; when it is not, sit still and charge it. This works in lit indoor spaces as well as outdoors during the day.
My under educated opinion is that a subdivision surface scheme would make more sense than a NURBS or Bezier Patch one both from a modeling and a hardware implementation point of view. There was an interesting paper (http://24.19.151.16/RI_DSS.html) in the subdivision session at Siggraph this year which describes a technique the presenter claimed will be useful for a hardware implementation (this was supposedly in contrast to a similar paper which followed his in the same session: http://www.cs.caltech.edu/~ivguskov/papers.html#no rmalmeshes).
Slashdot Mirror
Not that /. is supposed to make sense or anything, but shouldn't the parent post be moderated "funny" rather than "interesting"?
Sadly, I am an embarrassingly incompetent speller. I had hopped no one would notice on /.
from the faq:
Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual machine that can be used to execute bytecode compiled dynamic languages such as Perl6, but also Perl5. Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl.
Tools that simplify witting new languages excite me. I see many significant programming tasks as language interpretation or translation (compilation). The "language" doesn't have to be in the form of a concrete text file: interpretation could mean interpreting UI events; compilation could mean converting one data structure into another. From this perspective, meta programming (language authoring) is very important. Obviously not all parsing tasks are well served by lex and yacc, and similarly I wouldn't expect LLVM (or MLRISC, or whatever...) to be a perfect fit for all compilation tasks. But where they are a good fit I expect to be able to write software that is simpler, more robust, and more fully featured. That makes me happy.
Languages without "real" unification feel unexpressive or too low level. Whenever I program in something other than prolog (which is most of the time) I miss it.
Example: [foo(A,x)|B] = [foo([p,q],x),C,d,e].
which implies that A = [p,q], B = [C,d,e], and C remains unconstrained.
?- name('What kind of self respecting geek uses a low level compiled language to convert lists of ascii codes to a readable string?',X).
I "clicked through" and made a purchase before even reading the comments (is it poor form to admit to reading the /. comments?).
somewhere in all the links:
"POE is a framework for creating multitasking programs in Perl."
I vote for replacing -nologo with its inverse first. Another good switch would be "-please-dont-core-dump-on-syntax-errors".
Writing a shader, especially one that requires multiple passes can be a hassle; that is why there are higher level shading languages and compilers being developed. This one for example is worth checking out, if only for the demos.
What I have seen done, which is more practical, especially for the hobbyist, is to use a small solar cell and a capacitor. When the capacitor is charged, move; when it is not, sit still and charge it. This works in lit indoor spaces as well as outdoors during the day.
My under educated opinion is that a subdivision surface scheme would make more sense than a NURBS or Bezier Patch one both from a modeling and a hardware implementation point of view. There was an interesting paper (http://24.19.151.16/RI_DSS.html) in the subdivision session at Siggraph this year which describes a technique the presenter claimed will be useful for a hardware implementation (this was supposedly in contrast to a similar paper which followed his in the same session: http://www.cs.caltech.edu/~ivguskov/papers.html#no rmalmeshes).