I think that's the difference between C and Python programmers - C programmers enjoy programming. Python programmers don't, at least everything my Python-loving collegues say suggests that the thing they like about it most is that they never get to understand what's going on under the hood.
In the interests of balance, here's the same workplace as seen from the Python programmer's point of view:
C programmers like engaging in dull, repetitive tasks, whereas Python programmers like having finished products created with the minimum of effort.
No, I don't believe that either the C programmer's or the Python programmer's respective spin are 100% correct.
I enjoy programming, but I don't enjoy the part that's non-creative. I do it because I have to. Just like how a music student may love playing the piano but hate the endless scales and exercises.
I am all for anything which takes the non-creative load off without me losing any of the creative advantages and freedoms of programming.
I'm baffled as to why you'd think "C gets in the way" [...]
I'm not the original poster, but I do agree that C gets in the way in many situations.
For example, consider implementing a sort algorithm, say, quicksort. Ideally, you only want to implement it once (e.g. using C's qsort()). However, comparison and swap operations for different types (e.g. integers vs structs) are quite different, and in some cases (e.g. integers or floats) can be made quite cheap. So if it matters, you definitely want to optimise for those cases.
You basically can't do this in C. You're forced to use macros, which are ugly, hard to maintain and provide zero safety, or perhaps write a program that generates C code, making a specialised version for each type that you care about. Languages which actually provide specialisation or code generation facilities as part of the language (C++ is but one example) can do this quite cheaply.
Another example is memory management. No, I'm not suggesting that you should use a garbage collected language, though this is arguably a good idea in many, possibly most, situations. However, in C, no matter what policy you use, if you do a lot of allocation, you need a lot of repetitive infrastructure to do it. C provides no help for you.
I know C is simple. That's great if you're writing a compiler for it. However, it is of little assistance if you're writing an application in it.
Let's invent a hypothetical unit of complexity, the "cu" (i.e. "complexity unit"). Suppose your application is 100cu. A simple language provides, say, 10cu, which means you have to write 90cu of complexity yourself. A less simple language might provide, say, 40cu of complexity, whihc means you only have to write 60cu yourself.
Given that the 30cu is almost certainly going to be dull, repetitive code, which would you rather write?
Now I'm not saying that C is obsolete, or people should ditch it wholesale for another language, but I am a professional programmer, and I write high-performance applications with a few million lines of code for a living, as well as medium-sized open source projects on the side, and I would never touch C again if I had the choice. At the very least I'd use C++, which has all the advantages of C plus a huge amount of additional stuff as well.
For the overwhelming majority of sufficiently large applications, writing them in a high-level language is going to be inadequate without at least implementing quite a few domain-specific primitives in a lower-level language.
When you think about it this way, you'll see that there's actually not a lot of difference between implementing the application in a high-level language and providing scripting. It's the same architecture: a low-level performance-sensitive "hard" layer and a high-level user-visible "soft" layer. The difference is that by using a very lightweight high-level language with domain-specific primitives, it can be more domain-specific than a more general language like Python. This can be an advantage in some circumstances.
I know this because I'm struggling with this issue myself at the moment. My application has a lot of performance-sensitive batch-processing-like code, plus a GUI layer which basically runs at the speed of the user. I solved the problem this by implementing a domain-specific scripting language which I use for the GUI, user scripting, initialisation and so on, and the script's operations and the application's inner loops are in C++. I get the best of both worlds.
RenderMan is a language to get modellers talking to renderers, just like PostScript is a language to get typesetters talking to printers. You're not supposed to work in raw RenderMan any more than you're supposed to work in raw PostScript.
Having said that, probably the closest system to what you're looking for is Steve May's AL. If you can get it to work, it will probably do exactly what you want.
Remember, though, that RenderMan is primarily an API. The bytestream version came later. It was originally a C API, but there are now bindings for many languages including Java, Perl, Python and ML. Why don't you pick one and use that?
None of this should dissuade you from using a real animation system, though. If you have some money to spend, it's well worth it, particularly if you're planning to do this a lot.
My wife is a fine art major. She is constantly pointing things out in paintings and sculptures that I would have no hope of finding on my own, though they're usually clear once pointed out. Even if I had the years of training, I doubt I'd get the knack, though I could be able to bluff convincingly.
Secondly, and most importantly, aptitude is 90% interest. A typical physicist already have hobbies that they'd far rather be spending their brainshare on. Being forced to do a PhD programme in something they don't care about would just make the situation worse.
It's probably a heresy on slashdot to suggest this, but: There are different kinds of intelligence. Science-type intelligence is only one such kind. It isn't a sufficient precondition for engaging in every kind of academic endeavour.
I was at the museum on the 31st. The "virtual room" amused me for about 30 seconds. Mind you, I was watching the brain show, not the bees. The bees might have been more fun.
I thought the Graeme Base exhibition was far more fun, but that's probably just me.
didn't you mean Turing complete instead of Turing hard
A system which is "Turing hard" can be used to implement a Turing machine. It is "Turing complete" if it can also be implemented on a Turing machine. It's the same as the difference between "NP-hard" and "NP-complete".
So yes, I meant "Turing hard", though for all of the systems we're talking about, they're also "Turing complete".
Hey. You know what? The other stuff in a public bar is more dangerous. 2nd-hand cigarette smoke and drunk driving is going to kill WAY more people than naked boobs.
Little known fact: Fiona Johnson, who played "the woman in the red dress" in The Matrix, caused a traffic accident during filming. A passing driver was distracted by her and hit a pole.
So while I agree with you that chemicals are more dangerous than naked boobs, don't underestimate how dangerous boobs can be.
It's more complicated than "nudity bad" vs "nudity good".
Let me put it this way: I am not really hung up about sex. However, talking about my sex life with my parents would make me extremely uncomfortable. I suspect that most people here (assuming they have a sex life, of course; this is slashdot, after all) would feel the same.
The point here is that context is very important. Public nudity doesn't weird me out. Porn websites don't bother me. Nude photo shoots are fine. A public photo shoot for a porn website, however, just seems wrong to me.
Having said that, I think a blanket law outlawing public nudity is wrong. As previously mentioned, I have no problem with public nudity in appropriate contexts. Also, the bar in question is not exactly a "public place". I don't know about the rules in Lincoln, but here, people under the age of 18 aren't allowed in bars. More serious is publically distributing the images without the proprietor's permission, but that's another issue.
Lambda calculus is easier to implement stuff in, but Turing machines are easier to implement. I re-read what I wrote and that's definitely what I said.
As an example, it's hard to implement full LC in the C++ template language (though you can get close for practical programming tasks), but it's straightforward to implement TMs. Hence, TMs are the tool of choice for showing that the template language is Turing-hard. This is true for most situations where you want to show that some language is Turing-hard, because TMs are so easy to implement.
By the way, I've never heard of Turing actually implementing his machine in hardware. It was a hardware design, implementable with pen and paper, but I don't think he actually went to the trouble of creating the machine. Got any refs for that?
Try his biography, Alan Turing: The Enigma. It's pretty clear that he considered the Manchester-1 an implementation of his theoretical machine.
BTW, I would dispute that Turing machines are "mostly entertainment value". They are an extremely valuable analytical tool, because they're usually the easiest Turing-hard model of computation to implement in whatever theoretical construct that you're trying to prove is Turing-hard. For example, it was straightforward to implement Turing machines in lambda calculus, but it took a couple of decades before theoreticians managed to formally implement lambda calculus in Turing machines (and hence prove their equivalence).
The difference between Church and Turing's formulations is that Turing's was able to be implemented in hardware. (With, of course, a non-infinite random-access "tape".)
Lambda calculus wasn't implemented in hardware until the 70s or 80s with the SKI machine.
What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot.
I hope they do too. An intermediate assembly language with actual registers would be an excellent thing.
I hope they don't just copy it, though. I've tried writing an optimiser for Parrot (I'm a compiler hack by trade) and I failed miserably. Parrot is defined for fast interpretation and good quality JIT, not for IL to IL optimisations. Not that there's anything wrong with that.
I still have my Comx-35, a micro sufficiently obscure that almost nobody has heard of it. It had a radiation-hardened RISC CPU; the same model put in Voyager. Every now and then I turn it on to see if it's become sentient yet...
Disney wasn't involved until 1991 - well after Pixar had made a name for itself.
Disney and Pixar first got involved in 1998, before Pixar won its first Academy Award and a eve before they started selling Photorealistic RenderMan to the general public. Yes, Pixar had made a name for itself, but it wasn't as big a name as it was in 1991.
They are both extremely talented on the technical side and, just as, if not more importantly, the storytelling side.
Make that MUCH, MUCH more importantly. A good story will beat a great technical achievement any day.
If you don't believe me, compare Final Fantasy: The Spirits Within with South Park: Bigger, Longer and Uncut. Both computer animation. One was a technical and visual marvel with a crap screenplay, and it tanked. The other was relatively technically easy with a very good screenplay, and it was a hit.
Oh, yes, I do so enjoy the diversity of choices taken by application writers. It's wonderful, isn't it, that some may choose to allow me to exit their application with ctrl-Q, some with alt-Q, some with just q, some with:q, and some with Ctrl-X Ctrl-C?
I don't know what you're talking about. Ctrl-Z-kill works fine for me no matter what editor I use.
Relational databases and full-text indexing are a poor fit once you have a lot of text to store. Yes, I know. Most SQL DBMS come with full-text indexing. That's not enough. Read on for the reason why.
Think about how a relational DBMS works. Internally, the major data structure is the "stream of tuples". A tuple is a virtual record which is made up of a number of fields, each of which has data in it.
When you search, you get back a stream of tuples, which is usually some projection of the record store. That is, you apply a function to each physical record which returns a tuple. This may be some subset of the physical fields, or may involve transforming them in some way.
Similarly, when you retrieve data back to the client, you get a stream of tuples. Everything conceptually works on these tuples.
Now think about how you work with a text database, such as Google. Google still has a record store. (See the "Google cache" for an example of what it might look like internally.) However, you don't see this. What you do is enter a search query and what is returned is the first ten results in summarised form. You hit "next" and you get the next ten. Typical searchers only look on one or two pages before they either go on to one of the results or refine their query.
What makes this feasable is that Google avoids hitting physical records unless the actual records are needed. To do this, its main internal data structure is a stream of record numbers, not a stream of tuples which contain data. (Z39.50, the successor to WAIS, calls this a "result set".) When you finally retrieve data, you can then go to the record store and retrieve the records associated with those record numbers.
This is why it's hard for relational databases to achieve the performance of native text databases: Text databases go to a lot of trouble to optimise the kinds of operations that text users want to do, which are very different from the kinds of operations that relational data users want to do. With text databases, searching, sorting, ranking and presenting data to the client are all conceptually different things, each with their own performance characteristics and access patterns. With relational databases, they are all intermingled, because relational database users tend not to need that kind of granularity.
XML is almost ideal for storing structured text in large quantities. Storing non-textual data, not so much. (This is one reason why XML gets a bad reputation for data representation; people are using it for tasks which are not textual markup-related.) For byte-by-byte searching... true enough, it sucks for that. But surely if you have text in large quantities, you're hardly going to search it using "grep". That would be insane whether it's stored in XML or plain text.
I honestly doubt that 29.2 Terabytes is the biggest database in the world.
Others have noted that there were two bigger databases in the list.
One thing to remember, though, is that you shouldn't confuse the amount of data that some organisation has to manage with the size of an individual database. Lexis-Nexis, for example, manages 40Tb or so, however it's a lot of individual databases, all running on different systems.
Slashdot Mirror
In the interests of balance, here's the same workplace as seen from the Python programmer's point of view:
No, I don't believe that either the C programmer's or the Python programmer's respective spin are 100% correct.
I enjoy programming, but I don't enjoy the part that's non-creative. I do it because I have to. Just like how a music student may love playing the piano but hate the endless scales and exercises.
I am all for anything which takes the non-creative load off without me losing any of the creative advantages and freedoms of programming.
I'm not the original poster, but I do agree that C gets in the way in many situations.
For example, consider implementing a sort algorithm, say, quicksort. Ideally, you only want to implement it once (e.g. using C's qsort()). However, comparison and swap operations for different types (e.g. integers vs structs) are quite different, and in some cases (e.g. integers or floats) can be made quite cheap. So if it matters, you definitely want to optimise for those cases.
You basically can't do this in C. You're forced to use macros, which are ugly, hard to maintain and provide zero safety, or perhaps write a program that generates C code, making a specialised version for each type that you care about. Languages which actually provide specialisation or code generation facilities as part of the language (C++ is but one example) can do this quite cheaply.
Another example is memory management. No, I'm not suggesting that you should use a garbage collected language, though this is arguably a good idea in many, possibly most, situations. However, in C, no matter what policy you use, if you do a lot of allocation, you need a lot of repetitive infrastructure to do it. C provides no help for you.
I know C is simple. That's great if you're writing a compiler for it. However, it is of little assistance if you're writing an application in it.
Let's invent a hypothetical unit of complexity, the "cu" (i.e. "complexity unit"). Suppose your application is 100cu. A simple language provides, say, 10cu, which means you have to write 90cu of complexity yourself. A less simple language might provide, say, 40cu of complexity, whihc means you only have to write 60cu yourself.
Given that the 30cu is almost certainly going to be dull, repetitive code, which would you rather write?
Now I'm not saying that C is obsolete, or people should ditch it wholesale for another language, but I am a professional programmer, and I write high-performance applications with a few million lines of code for a living, as well as medium-sized open source projects on the side, and I would never touch C again if I had the choice. At the very least I'd use C++, which has all the advantages of C plus a huge amount of additional stuff as well.
For the overwhelming majority of sufficiently large applications, writing them in a high-level language is going to be inadequate without at least implementing quite a few domain-specific primitives in a lower-level language.
When you think about it this way, you'll see that there's actually not a lot of difference between implementing the application in a high-level language and providing scripting. It's the same architecture: a low-level performance-sensitive "hard" layer and a high-level user-visible "soft" layer. The difference is that by using a very lightweight high-level language with domain-specific primitives, it can be more domain-specific than a more general language like Python. This can be an advantage in some circumstances.
I know this because I'm struggling with this issue myself at the moment. My application has a lot of performance-sensitive batch-processing-like code, plus a GUI layer which basically runs at the speed of the user. I solved the problem this by implementing a domain-specific scripting language which I use for the GUI, user scripting, initialisation and so on, and the script's operations and the application's inner loops are in C++. I get the best of both worlds.
RenderMan is a language to get modellers talking to renderers, just like PostScript is a language to get typesetters talking to printers. You're not supposed to work in raw RenderMan any more than you're supposed to work in raw PostScript.
Having said that, probably the closest system to what you're looking for is Steve May's AL. If you can get it to work, it will probably do exactly what you want.
Remember, though, that RenderMan is primarily an API. The bytestream version came later. It was originally a C API, but there are now bindings for many languages including Java, Perl, Python and ML. Why don't you pick one and use that?
None of this should dissuade you from using a real animation system, though. If you have some money to spend, it's well worth it, particularly if you're planning to do this a lot.
Good luck.
Don't waste money on MTOR. If you want Maya, get Liquid. Production-proven and open source. What more could you ask for?
Agreed completely.
My wife is a fine art major. She is constantly pointing things out in paintings and sculptures that I would have no hope of finding on my own, though they're usually clear once pointed out. Even if I had the years of training, I doubt I'd get the knack, though I could be able to bluff convincingly.
Secondly, and most importantly, aptitude is 90% interest. A typical physicist already have hobbies that they'd far rather be spending their brainshare on. Being forced to do a PhD programme in something they don't care about would just make the situation worse.
It's probably a heresy on slashdot to suggest this, but: There are different kinds of intelligence. Science-type intelligence is only one such kind. It isn't a sufficient precondition for engaging in every kind of academic endeavour.
I was at the museum on the 31st. The "virtual room" amused me for about 30 seconds. Mind you, I was watching the brain show, not the bees. The bees might have been more fun.
I thought the Graeme Base exhibition was far more fun, but that's probably just me.
A system which is "Turing hard" can be used to implement a Turing machine. It is "Turing complete" if it can also be implemented on a Turing machine. It's the same as the difference between "NP-hard" and "NP-complete".
So yes, I meant "Turing hard", though for all of the systems we're talking about, they're also "Turing complete".
Little known fact: Fiona Johnson, who played "the woman in the red dress" in The Matrix, caused a traffic accident during filming. A passing driver was distracted by her and hit a pole.
So while I agree with you that chemicals are more dangerous than naked boobs, don't underestimate how dangerous boobs can be.
It's more complicated than "nudity bad" vs "nudity good".
Let me put it this way: I am not really hung up about sex. However, talking about my sex life with my parents would make me extremely uncomfortable. I suspect that most people here (assuming they have a sex life, of course; this is slashdot, after all) would feel the same.
The point here is that context is very important. Public nudity doesn't weird me out. Porn websites don't bother me. Nude photo shoots are fine. A public photo shoot for a porn website, however, just seems wrong to me.
Having said that, I think a blanket law outlawing public nudity is wrong. As previously mentioned, I have no problem with public nudity in appropriate contexts. Also, the bar in question is not exactly a "public place". I don't know about the rules in Lincoln, but here, people under the age of 18 aren't allowed in bars. More serious is publically distributing the images without the proprietor's permission, but that's another issue.
Not only do we now have the Linux vs BSD flamefest, you've managed to work Windows into it as well! You, sir or madam, have my admiration. Well done!
Pass out the marshmallows. It's going to be a fiery one.
I think you misunderstood what I was saying.
Lambda calculus is easier to implement stuff in, but Turing machines are easier to implement. I re-read what I wrote and that's definitely what I said.
As an example, it's hard to implement full LC in the C++ template language (though you can get close for practical programming tasks), but it's straightforward to implement TMs. Hence, TMs are the tool of choice for showing that the template language is Turing-hard. This is true for most situations where you want to show that some language is Turing-hard, because TMs are so easy to implement.
Try his biography, Alan Turing: The Enigma. It's pretty clear that he considered the Manchester-1 an implementation of his theoretical machine.
BTW, I would dispute that Turing machines are "mostly entertainment value". They are an extremely valuable analytical tool, because they're usually the easiest Turing-hard model of computation to implement in whatever theoretical construct that you're trying to prove is Turing-hard. For example, it was straightforward to implement Turing machines in lambda calculus, but it took a couple of decades before theoreticians managed to formally implement lambda calculus in Turing machines (and hence prove their equivalence).
The difference between Church and Turing's formulations is that Turing's was able to be implemented in hardware. (With, of course, a non-infinite random-access "tape".)
Lambda calculus wasn't implemented in hardware until the 70s or 80s with the SKI machine.
I hope they do too. An intermediate assembly language with actual registers would be an excellent thing.
I hope they don't just copy it, though. I've tried writing an optimiser for Parrot (I'm a compiler hack by trade) and I failed miserably. Parrot is defined for fast interpretation and good quality JIT, not for IL to IL optimisations. Not that there's anything wrong with that.
It did. IFF (in a quite extended form) is still the binary format used by Maya.
I still have my Comx-35, a micro sufficiently obscure that almost nobody has heard of it. It had a radiation-hardened RISC CPU; the same model put in Voyager. Every now and then I turn it on to see if it's become sentient yet...
Disney and Pixar first got involved in 1998, before Pixar won its first Academy Award and a eve before they started selling Photorealistic RenderMan to the general public. Yes, Pixar had made a name for itself, but it wasn't as big a name as it was in 1991.
Make that MUCH, MUCH more importantly. A good story will beat a great technical achievement any day.
If you don't believe me, compare Final Fantasy: The Spirits Within with South Park: Bigger, Longer and Uncut. Both computer animation. One was a technical and visual marvel with a crap screenplay, and it tanked. The other was relatively technically easy with a very good screenplay, and it was a hit.
Too late.
I don't know what you're talking about. Ctrl-Z-kill works fine for me no matter what editor I use.
I do tend to lose data sometimes, though.
Both Perl and PHP already have Z39.50 support to connect to full-text search engines.
Relational databases and full-text indexing are a poor fit once you have a lot of text to store. Yes, I know. Most SQL DBMS come with full-text indexing. That's not enough. Read on for the reason why.
Think about how a relational DBMS works. Internally, the major data structure is the "stream of tuples". A tuple is a virtual record which is made up of a number of fields, each of which has data in it.
When you search, you get back a stream of tuples, which is usually some projection of the record store. That is, you apply a function to each physical record which returns a tuple. This may be some subset of the physical fields, or may involve transforming them in some way.
Similarly, when you retrieve data back to the client, you get a stream of tuples. Everything conceptually works on these tuples.
Now think about how you work with a text database, such as Google. Google still has a record store. (See the "Google cache" for an example of what it might look like internally.) However, you don't see this. What you do is enter a search query and what is returned is the first ten results in summarised form. You hit "next" and you get the next ten. Typical searchers only look on one or two pages before they either go on to one of the results or refine their query.
What makes this feasable is that Google avoids hitting physical records unless the actual records are needed. To do this, its main internal data structure is a stream of record numbers, not a stream of tuples which contain data. (Z39.50, the successor to WAIS, calls this a "result set".) When you finally retrieve data, you can then go to the record store and retrieve the records associated with those record numbers.
This is why it's hard for relational databases to achieve the performance of native text databases: Text databases go to a lot of trouble to optimise the kinds of operations that text users want to do, which are very different from the kinds of operations that relational data users want to do. With text databases, searching, sorting, ranking and presenting data to the client are all conceptually different things, each with their own performance characteristics and access patterns. With relational databases, they are all intermingled, because relational database users tend not to need that kind of granularity.
XML is almost ideal for storing structured text in large quantities. Storing non-textual data, not so much. (This is one reason why XML gets a bad reputation for data representation; people are using it for tasks which are not textual markup-related.) For byte-by-byte searching... true enough, it sucks for that. But surely if you have text in large quantities, you're hardly going to search it using "grep". That would be insane whether it's stored in XML or plain text.
Others have noted that there were two bigger databases in the list.
One thing to remember, though, is that you shouldn't confuse the amount of data that some organisation has to manage with the size of an individual database. Lexis-Nexis, for example, manages 40Tb or so, however it's a lot of individual databases, all running on different systems.