I don't offhand know of any papers on the subject, but like another poster pointed out, the current fashion in UI design has started to swing back towards context-sensetive menus to manage complexity. This is a very old UI design principle, dating back to Smalltalk (and maybe even before that). It was extensively used by Lisp Machines, which a few people still consider the pinnacle of efficient UI design (it's still the primary UI guideline in some Lisp apps like Mirai). I recently came across this book (Lisp Lore: A guide to programming the Lisp machine) at my uni library. I didn't borrow it for now (too much in the reading queue), but it did have a lot of text devoted to the GUI. Might be worth a look.
Nooface also might be a useful resource. If you do change your mind and decide to wade through code, check out Squeak, a Smalltalk VM/environment with a really consistent and fast GUI.
Before you mod me down, check out what these guyshave done. (The site hasn't been updated in a while, due to company problems and one of the main coders being on hiatus or something (fyi, his name is Larry Malone, he has been doing this ever since he modelled the sailing ships in Tron using custom-developed software at III, and has been writing graphics Lisp software at Symbolics and since afterwards)). Well, enough of the history lesson.
Common Lisp has a lot of benefits for this type of work. Since it is completely dynamic (ie - everything runs in an image with which you can interact, add code/compile and debug, all at run-time), the plug-in/scripting is taken care of from the start, and can have the full syntax of CL and access to any of the main program's features you choose to give it. CL will probably give you the most results per line/minute of code because of this dynamism.
Most CL implementations have pretty good foreign function interfaces for C and C++ libraries (Franz's Allegro CL even provides support for run-time Java objects.)
CL's performance is on par with C++ in general, and lags only in one major area - FP operations require "boxing" overhead when the symbol pointing to the numbers is dynamically typed (most compilers optimize statically typed declarations pretty well - which makes most of the overhead go away.)
Of course, before you go off on your great quest, you should probably read what some of the other posters have suggested. Writing graphics software like the type you describe is an incredible amount of work (I gave up my uber-Scheme system after 100 lines and settled for writing smaller utilities and plugins), and many have tried and miserably failed before.
All kidding aside, I would seriously love to see a good research paper on the reasons behind Fortran's (relatively) enormous success, especially compared to other languages of the era. I've briefly looked at some Fortran code, and I just can't understand why it's been consistently used for so long. Anyone have any links?
Considering the absolite shitter the movie digital FX industry has been in the past year, and the usual recruiting practices of some of the studios mentioned (Dreamworks is rumored to lay off the majority of artists after a big project - regardless whether they have another one lined up - and then aggressively recruit cheap, fresh art school grads), you'd think EA would just need to offer them a stable job (which they do, once in a while.)
In case anyone didn't notice, the whole article was just BS promotion for EA (I'm surprised there wasn't a paid advertisement notice at the end of it.) This, incidentally, reminds me of another gaming company *cough*Ionstormdallas*cough* that had nice posh offices and lots of BS press coverage, and not too long afterwards closed (thank god Eidos kept Ion Storm Austin, though), which is what I am hoping EA will do not too long after this (you can only release boring games for so long before everyone realises they are boring.)
Everyone remembers John Romero, right? The guy had to sell off his Hummer after Daikatana flopped, remember? You want the same thing to happen to those horrible people that decide to publish 100 identical, yet somehow subtly different (can it be the box art?) Sims expansions, don't you?
but I wonder what benefits it offers over the Linux version in binary compatibility mode right now (not that I don't want a native version). I'm running 6.02 on FreeBSD 4.3, and nothing seems to be broken (well, I don't have the JRE, don't need anything besides flash, and the file browser does the compat mode path redirection - typing the path works ok).
On a similar note, how well does Opera run on NetBSD's Linux (and I guess FreeBSD too now) binary compatibility system? I've recently decided to switch to NetBSD instead of upgrading.
We used MIT's StarLOGO for our intro class to programming at Stuyvesant high school over two years ago. Great program, BTW; there's nothing quite like programming (essentially) cellular automata for your first assignment =].
Another big plus for SGML-style tags is the fact that they can easily be processed with regular expressions. You need a parser that understands Lisp style lists to do anything with sexprs. This is probably the most tangible reason to go with tags over sexprs for shared data.
In defense of sexprs, they are much easier to type, can be more readable than tags, and (if you're using a Lisp) are very convenient to auto-generate. Really, tags and sexprs are completely interchangeable, and should be treated as such - the only thing that counts is the markup lingo.
Also, the comments on Lisp documentation in that link are a bit misguided. The only attempts at an sexpr-only documentation markup that I know of were made by the Lisp machine companies, and not exactly being standards, they died with those Lisp machine companies. Nowadays the docs are kept in Tex format because it's a good standard - it would be pretty stupid to make up a new typography system just for the Lisp community. Maybe if the author would bother to look at some of the Lisp systems, he'd find that they do contain excellent utilities for processing and converting Lisp lists to Tex (and from there to other formats), and vice-versa. Oh, and since when have XML people done anything for decades? And while I'm making fun of that link, it should be pointed out that the author apparently understands neither Lisp lists nor the hypothetical sexpr markup - the "Starting with Syntax" section makes me giggle.
"Integrating the language and the OS kills portability, robustness, and security."
Care to give any specific examples as to how it does so with Lisp, Smalltalk or Forth?
Exactly whose portability does the integration kill - the language's or the OS's? If the language needs OS functionality, then you need to write some form of a VM for it to run on other platforms anyway (as is the case with most Common Lisp and Smalltalk-80 implementations.) If you want to run foreign languages on the OS, you'll have to write a VM subset for them.
If the language provides adequate security concepts, and the underlying OS/VM is reliable, then the OS+programming language approach actually increases security.
Tell me, how would you go around circumventing lexical closures on a Lisp machine if you couldn't run microcode? Or generally, reference memory directly in any GCed/memory managed environment? The only things that kill security in open, multiuser systems are poor implementations (either of the OS, language, or user program) and manual memory management - something that C applications suffer plenty from, and BRiX (reputedly) and the languages you mentioned tend for the most part to avoid.
BRiX doesn't claim to be an integrated application development/delivery environment, and your statement doesn't make sense for Lisp and Smalltalk, on current architectures. Every Lisp and Smalltalk application has to be integrated with an "environment" on today's hardware - all memory managed, dynamically typed systems do! It doesn't matter whether it's at the OS or the VM level. As for broken VM implementations, the negative effect would be equivalent to a broken OS running a C program - except in the VM's case (if it's running on an OS with adequate protection), the damage is localized to its own memory space, instead of the entire machine.
I don't see how the abstraction you speak of can't be implemented in the languages you mentioned or BRiX. By most of the code I've seen, Lisp and Smalltalk are more modularized than C, because the languages encourage that type of abstraction. If they are run in a bug-free environment, there is no safety difference from bug-free C code.
Your claim of a compiler/OS/target program "hair ball" is complete BS, on the other hand. Maybe if the particular combination is very poorly implemented, but I've yet to run across such a thing. Lisp and Smalltalk have been designed and have evolved around the principle of abstracting the environment details from the application programmer. All the CL and Scheme "VMs" I've worked with provide a level of architecture, OS, compiler and environment (EMACS is king) abstraction that C programmers can only dream about.
Maybe you should at try the languages you're criticizing before doing so; you might be surprised.
The BRiX system, if properly implemented, can be a very safe, robust environment. Since Crush avoids automatic memory management, it should also be pretty fast. The database-file system also sounds like a neat idea.
I don't particularly like the fact that it can't run other languages natively, but keeping C compatibility would kill most of the system's goals and improvements.
Well, since the poster considered Matlab, Maxima is a Common Lisp, free-software (GPL) algebra system. It has a 2d and 3d graphing system, and is a descendant of DOE Macsyma, which, if my history is right, is the original codebase for the commercial Macsyma symbolic algebra system, which was the precursor to Mathematica and other symbolic math software.
Just to set the record straight about Thad's contradiction. The VFX/animation job market is really in the shitter right now, and no telling when it will pick up. Take his advise and go look for employment somewhere else, unless you really like Ramen noodles.
In the future, these archives may very well be used to produce lists of "undesirables"; your shopping records can be used to extract lifestyle and health information, and even identify your religion (ex. - Kosher products for Jews, no alcohol or pork for Muslims, and Vegan for Hindus.)
Of course you can just avoid those errors...
on
Valgrind 1.0.0 Released
·
· Score: 2, Informative
For most applications, it just makes better sense to avoid these errors altogether by using a good garbage collector.
An excellent implementation is the Boehm-Demers-Weiser (commonly referred to as just "Boehm gc") conservative gc. It can be used for C/C++, and is highly portable. It's a real-time, non-compacting (so you still get heap fragmentation like managing memory by hand, but the collection time is shorter and it's more portable), and uses a conservative mark-sweep algorithm (briefly, treats anything that looks like a pointer as a pointer, to avoid costly checks or increase portability in the case of C/C++.)
For a moderately large amount of garbage, the incremental collection pauses take less than about 5-10 milliseconds (hence why it's a real-time collector) on a PIII-500, the algorithm scales fairly well, and it's suitable for all but the most time-critical (anything video related) or memory-thrashing (I really don't know of any app that needs to be) programs. GC will speed up development time tremendously, and can eliminate segmentation faults and memory leaks for most programs. I really don't understand why more projects don't use it.
That being said, Valgrind does seem extremely useful for projects that do need to allocate memory manually. It looks very convenient to use, and the thoroughness of the checks is impressive. The implementation does seem a little uncomfortable to me - it's certainly a lot of effort to write a whole virtual machine just for the task! The portability prospects aren't appealing either.
If there is any book that fits this topic, it is SICP. What makes this book different from any other intro CS book I have read is that it focuses on the science of computation, not just on "programming." Solid knowledge of higher math and some logic are prerequesites for reading, but this is the best possible book for anyone who wants to skip the syntactical crud of usual CS courses and jump right into the theory and mechanics of computer programming.
While this may not be the best route for computer engineers, shame on anyone who thinks that this book isn't an important read for anyone studying towards a computer science degree. This book lays out all the necessary concepts for learning any further languages or programming methods.
Some people don't like this book because it uses Scheme. They're mostly wrong - the book uses Scheme as a pseudocode, and touches only a fraction of the R5 Scheme standard. The benefits of this are apparent right from the first chapter - the book weans you from thinking of loops in terms of rigid and clumsy constructs, instead demonstrating that tail-recursion can completely replace them. And I really pity the people who think static types would enhance either Lisp or the readability of this book, as Hemos seems to be convinced about in his review. PS, R5 Scheme does have looping constructs; do some research before complaining.
In short, if you like math for math's sake and want to learn computer science, read this book.
If you can get it (there's been trouble in this department, but someone close to the company seems to have recently sorted it), Izware'sMirai is a very good solution for at least your second problem.
This software (in it's previous incarnations as Nichimen's N-World and Symbolics' S-Graphics packages (it's virtually a direct descendant! ain't Lisp great?)), is where most of the current packages are leeching their modelling features from - first Subdivision surfaces modeller on the market, and because of the fact that it uses the Winged-Edge data structure to store geometry, the first with "edge loops."
While these edge loops aren't triangle strips per-se (I actually think it's a horrible idea to force triangle fans and strips at the tools level - leave that for converters and exporters!), they, as an edge control structure, will help form the proper polygon arrangements so you can exploit triangle strips later down the pipeline.
As for shaders, at this time I also thing it's a downright horrible idea - there aren't any implemented standards yet! At least wait for OpenGL 1.4 drivers to come out.
Mirai's next release should be ready for this, since it currently features a versatile materials "domain" editor that lets you painlessly transfer those material and texture properites that you define for the renderer onto OpenGL for previewing (well, everything that the domain permits), and later onto your target console (although the domains are for older systems - Mirai hasn't been updated in a while.), and vice-versa.
Besides that, you get 2d and 3d paint, advanced UV editing tools, rigging controls that will blow your mind (sure, Maya's poweful, until you start watching the time it takes to rig a skeleton fully with IK and FK solvers, and then throw on a couple of more controls to keep the skeleton in place - there's absolutely nothing like Mirai's "pin" joint system out there, and it's the only package where you can use skeletons to actually aid your modelling), the industry's first (despite SoftImage's claims, and IMO still the most useful) non-linear animation system, and a batch of Mo-Cap processing tools from TestaRossa, and a specially designed game-data export framework (Game Exchange). Oh, and did I mention it's all written in Common Lisp? Who needs a plugin interface, when you can run code directly from the Lisp image!
Is it really worth raving so much about? Hell yes.
Slashdot Mirror
Nooface also might be a useful resource. If you do change your mind and decide to wade through code, check out Squeak, a Smalltalk VM/environment with a really consistent and fast GUI.
Common Lisp has a lot of benefits for this type of work. Since it is completely dynamic (ie - everything runs in an image with which you can interact, add code/compile and debug, all at run-time), the plug-in/scripting is taken care of from the start, and can have the full syntax of CL and access to any of the main program's features you choose to give it. CL will probably give you the most results per line/minute of code because of this dynamism.
Most CL implementations have pretty good foreign function interfaces for C and C++ libraries (Franz's Allegro CL even provides support for run-time Java objects.)
CL's performance is on par with C++ in general, and lags only in one major area - FP operations require "boxing" overhead when the symbol pointing to the numbers is dynamically typed (most compilers optimize statically typed declarations pretty well - which makes most of the overhead go away.)
Of course, before you go off on your great quest, you should probably read what some of the other posters have suggested. Writing graphics software like the type you describe is an incredible amount of work (I gave up my uber-Scheme system after 100 lines and settled for writing smaller utilities and plugins), and many have tried and miserably failed before.
All kidding aside, I would seriously love to see a good research paper on the reasons behind Fortran's (relatively) enormous success, especially compared to other languages of the era. I've briefly looked at some Fortran code, and I just can't understand why it's been consistently used for so long. Anyone have any links?
In case anyone didn't notice, the whole article was just BS promotion for EA (I'm surprised there wasn't a paid advertisement notice at the end of it.) This, incidentally, reminds me of another gaming company *cough*Ionstormdallas*cough* that had nice posh offices and lots of BS press coverage, and not too long afterwards closed (thank god Eidos kept Ion Storm Austin, though), which is what I am hoping EA will do not too long after this (you can only release boring games for so long before everyone realises they are boring.)
Everyone remembers John Romero, right? The guy had to sell off his Hummer after Daikatana flopped, remember? You want the same thing to happen to those horrible people that decide to publish 100 identical, yet somehow subtly different (can it be the box art?) Sims expansions, don't you?
On a similar note, how well does Opera run on NetBSD's Linux (and I guess FreeBSD too now) binary compatibility system? I've recently decided to switch to NetBSD instead of upgrading.
We used MIT's StarLOGO for our intro class to programming at Stuyvesant high school over two years ago. Great program, BTW; there's nothing quite like programming (essentially) cellular automata for your first assignment =].
Nope, looks like a cool coincidence. Didn't know that one before. Here's a link about the pdp-10 clone III (Information International, Inc.) used for Tron. Supposedly it was the fastest pdp-10 system in the world.
Another big plus for SGML-style tags is the fact that they can easily be processed with regular expressions. You need a parser that understands Lisp style lists to do anything with sexprs. This is probably the most tangible reason to go with tags over sexprs for shared data.
In defense of sexprs, they are much easier to type, can be more readable than tags, and (if you're using a Lisp) are very convenient to auto-generate. Really, tags and sexprs are completely interchangeable, and should be treated as such - the only thing that counts is the markup lingo.
Also, the comments on Lisp documentation in that link are a bit misguided. The only attempts at an sexpr-only documentation markup that I know of were made by the Lisp machine companies, and not exactly being standards, they died with those Lisp machine companies. Nowadays the docs are kept in Tex format because it's a good standard - it would be pretty stupid to make up a new typography system just for the Lisp community. Maybe if the author would bother to look at some of the Lisp systems, he'd find that they do contain excellent utilities for processing and converting Lisp lists to Tex (and from there to other formats), and vice-versa. Oh, and since when have XML people done anything for decades? And while I'm making fun of that link, it should be pointed out that the author apparently understands neither Lisp lists nor the hypothetical sexpr markup - the "Starting with Syntax" section makes me giggle.
"Integrating the language and the OS kills portability, robustness, and security."
Care to give any specific examples as to how it does so with Lisp, Smalltalk or Forth?
Exactly whose portability does the integration kill - the language's or the OS's? If the language needs OS functionality, then you need to write some form of a VM for it to run on other platforms anyway (as is the case with most Common Lisp and Smalltalk-80 implementations.) If you want to run foreign languages on the OS, you'll have to write a VM subset for them.
If the language provides adequate security concepts, and the underlying OS/VM is reliable, then the OS+programming language approach actually increases security.
Tell me, how would you go around circumventing lexical closures on a Lisp machine if you couldn't run microcode? Or generally, reference memory directly in any GCed/memory managed environment? The only things that kill security in open, multiuser systems are poor implementations (either of the OS, language, or user program) and manual memory management - something that C applications suffer plenty from, and BRiX (reputedly) and the languages you mentioned tend for the most part to avoid.
BRiX doesn't claim to be an integrated application development/delivery environment, and your statement doesn't make sense for Lisp and Smalltalk, on current architectures. Every Lisp and Smalltalk application has to be integrated with an "environment" on today's hardware - all memory managed, dynamically typed systems do! It doesn't matter whether it's at the OS or the VM level. As for broken VM implementations, the negative effect would be equivalent to a broken OS running a C program - except in the VM's case (if it's running on an OS with adequate protection), the damage is localized to its own memory space, instead of the entire machine.
I don't see how the abstraction you speak of can't be implemented in the languages you mentioned or BRiX. By most of the code I've seen, Lisp and Smalltalk are more modularized than C, because the languages encourage that type of abstraction. If they are run in a bug-free environment, there is no safety difference from bug-free C code.
Your claim of a compiler/OS/target program "hair ball" is complete BS, on the other hand. Maybe if the particular combination is very poorly implemented, but I've yet to run across such a thing. Lisp and Smalltalk have been designed and have evolved around the principle of abstracting the environment details from the application programmer. All the CL and Scheme "VMs" I've worked with provide a level of architecture, OS, compiler and environment (EMACS is king) abstraction that C programmers can only dream about.
Maybe you should at try the languages you're criticizing before doing so; you might be surprised.
The BRiX system, if properly implemented, can be a very safe, robust environment. Since Crush avoids automatic memory management, it should also be pretty fast. The database-file system also sounds like a neat idea.
I don't particularly like the fact that it can't run other languages natively, but keeping C compatibility would kill most of the system's goals and improvements.
Car and cdr originate from the IBM 704 family of computers' address handling.
Well, since the poster considered Matlab, Maxima is a Common Lisp, free-software (GPL) algebra system. It has a 2d and 3d graphing system, and is a descendant of DOE Macsyma, which, if my history is right, is the original codebase for the commercial Macsyma symbolic algebra system, which was the precursor to Mathematica and other symbolic math software.
"This year's conference took place last week, and all of the big companies demonstrated vigorous recruiting efforts."
"If the sparse show floor weren't enough to remind you of the weak economy, a visit to the SIGGRAPH career center showed board after board of resumes, with job opportunities only posted in one small corner of the room."
"The job board was dominated with resumes from job-seekers but there were very few postings of jobs. Definitely a low-demand, high-supply type of market."
Just to set the record straight about Thad's contradiction. The VFX/animation job market is really in the shitter right now, and no telling when it will pick up. Take his advise and go look for employment somewhere else, unless you really like Ramen noodles.Hmmm, could this policy change possibly be because of this?
I'm surprised there is still so much animosity between Theo and the NetBSD core developers.how potentially harmful archives of this data can be in the right hands. Something as innocent as 100 year old marriage and baptismal records was used to systematically identify and round up hundreds of thousands of people for extermination, using nothing more than punch-card sorters.
In the future, these archives may very well be used to produce lists of "undesirables"; your shopping records can be used to extract lifestyle and health information, and even identify your religion (ex. - Kosher products for Jews, no alcohol or pork for Muslims, and Vegan for Hindus.)For most applications, it just makes better sense to avoid these errors altogether by using a good garbage collector.
An excellent implementation is the Boehm-Demers-Weiser (commonly referred to as just "Boehm gc") conservative gc. It can be used for C/C++, and is highly portable. It's a real-time, non-compacting (so you still get heap fragmentation like managing memory by hand, but the collection time is shorter and it's more portable), and uses a conservative mark-sweep algorithm (briefly, treats anything that looks like a pointer as a pointer, to avoid costly checks or increase portability in the case of C/C++.)
For a moderately large amount of garbage, the incremental collection pauses take less than about 5-10 milliseconds (hence why it's a real-time collector) on a PIII-500, the algorithm scales fairly well, and it's suitable for all but the most time-critical (anything video related) or memory-thrashing (I really don't know of any app that needs to be) programs. GC will speed up development time tremendously, and can eliminate segmentation faults and memory leaks for most programs. I really don't understand why more projects don't use it.
That being said, Valgrind does seem extremely useful for projects that do need to allocate memory manually. It looks very convenient to use, and the thoroughness of the checks is impressive. The implementation does seem a little uncomfortable to me - it's certainly a lot of effort to write a whole virtual machine just for the task! The portability prospects aren't appealing either.
If there is any book that fits this topic, it is SICP. What makes this book different from any other intro CS book I have read is that it focuses on the science of computation, not just on "programming." Solid knowledge of higher math and some logic are prerequesites for reading, but this is the best possible book for anyone who wants to skip the syntactical crud of usual CS courses and jump right into the theory and mechanics of computer programming.
While this may not be the best route for computer engineers, shame on anyone who thinks that this book isn't an important read for anyone studying towards a computer science degree. This book lays out all the necessary concepts for learning any further languages or programming methods.
Some people don't like this book because it uses Scheme. They're mostly wrong - the book uses Scheme as a pseudocode, and touches only a fraction of the R5 Scheme standard. The benefits of this are apparent right from the first chapter - the book weans you from thinking of loops in terms of rigid and clumsy constructs, instead demonstrating that tail-recursion can completely replace them. And I really pity the people who think static types would enhance either Lisp or the readability of this book, as Hemos seems to be convinced about in his review. PS, R5 Scheme does have looping constructs; do some research before complaining.
In short, if you like math for math's sake and want to learn computer science, read this book.
If you can get it (there's been trouble in this department, but someone close to the company seems to have recently sorted it), Izware's Mirai is a very good solution for at least your second problem.
This software (in it's previous incarnations as Nichimen's N-World and Symbolics' S-Graphics packages (it's virtually a direct descendant! ain't Lisp great?)), is where most of the current packages are leeching their modelling features from - first Subdivision surfaces modeller on the market, and because of the fact that it uses the Winged-Edge data structure to store geometry, the first with "edge loops."
While these edge loops aren't triangle strips per-se (I actually think it's a horrible idea to force triangle fans and strips at the tools level - leave that for converters and exporters!), they, as an edge control structure, will help form the proper polygon arrangements so you can exploit triangle strips later down the pipeline.
As for shaders, at this time I also thing it's a downright horrible idea - there aren't any implemented standards yet! At least wait for OpenGL 1.4 drivers to come out.
Mirai's next release should be ready for this, since it currently features a versatile materials "domain" editor that lets you painlessly transfer those material and texture properites that you define for the renderer onto OpenGL for previewing (well, everything that the domain permits), and later onto your target console (although the domains are for older systems - Mirai hasn't been updated in a while.), and vice-versa.
Besides that, you get 2d and 3d paint, advanced UV editing tools, rigging controls that will blow your mind (sure, Maya's poweful, until you start watching the time it takes to rig a skeleton fully with IK and FK solvers, and then throw on a couple of more controls to keep the skeleton in place - there's absolutely nothing like Mirai's "pin" joint system out there, and it's the only package where you can use skeletons to actually aid your modelling), the industry's first (despite SoftImage's claims, and IMO still the most useful) non-linear animation system, and a batch of Mo-Cap processing tools from TestaRossa, and a specially designed game-data export framework (Game Exchange). Oh, and did I mention it's all written in Common Lisp? Who needs a plugin interface, when you can run code directly from the Lisp image!
Is it really worth raving so much about? Hell yes.