Re:Wait wait wait wait wait...
on
A Tour of Pixar
·
· Score: 1
In film work, if you're clever, that can actually work for you.
An average Pixar frame might contain 2Gb of geometry data and 10Gb of texture data. Even on a gigabit network, that takes a nontrivial time to actually send to a farm machine. This can become a bottleneck in rendering.
Trying to make sure that frames that need the same data get computed on different CPUs on the same machine actually increases the amount of useful work that you can do. This suggests that the amount of time taken might even be less than 1/8th on some data sets.
My intuition suggests that the effects would even out, but my intuition also tells me never to trust my intuition.
Those times that it makes sense to program in a functional language are pretty much those times that you don't want imperative stuff getting in the way at all. Adding imperative features to a functional language is not the solution. Adding better support for developing software in multiple languages is.
Incidentally, ML was around years before Haskell. Its imperative features are very much historical. If monads as a programming construct had been considered 30 odd years ago, ML might be a much purer language than it is.
F#, on the other hand, is little more than a bastard child.
Well, if you want to be punctilious - I believe the bible has been originally been on parchment (i.e. processed horse-skin). I don't know if people are aware of this, but paper was invented in china many centuries later (600-900CE, i forgot), and not introduced to the west until even later.
You mean vellum, not parchment. Even then it's only partly true. The first copies of the New Testament, for example (certainly the oldest fragments that we have), were probably written on papyrus, which while not paper as we know it today, is close enough.
This, of course, misses the point of C++'s protection mechanisms.
Yes, it's easy to forge a C++ pointer, but a) it's usually not portable, and b) you have to go out of your way to do it. In C++, it's hard to inadvertantly forge a pointer (assuming you're really programming in C++ and not just C with single line comments; real C++ programmers avoid naked pointers unless they're absolutely necessary).
C++ protection mechanisms are to protect the programmer from themselves, not from an outside attacker. It's a safety net, not a padlock.
Context switches are very cheap if you're using any processor but an x86. Even on an x86, if you need this kind of speed you'd be crazy to use a machine with only one processor.
Blinn's Law is what those in the graphics industry know as the counterpoint to Moore's Law. It states, in its original form: The amount of time it takes to render a frame is constant over time.
The point is that computers are getting faster, but we're also asking them to do a lot more, and these effects cancel each other out. Consider, for example, how long it takes your word processor to load. It's probably the same amount of time that it took 15 years ago.
So how long until RAM-only databases are practical? For some databases, right now. The database which sits behind your typical weblog, for example, could probably work today. For your typical enterprise application, it will never happen, because what is "typical" is a constantly moving target.
Re:X (and other Window systems) reduce productivit
on
Who Needs XFree86?
·
· Score: 1
In my experience, firing up a windowing system
tends to reduce productivity.
My experience is the opposite.
I find my productivity to be directly proportional to the amount of information that I can see at once. On a decent windowing system, I can make my fonts as small as I want (especially if they're anti-aliased) and lay out my windows as I need. Unlike the twin approach, I don't waste a whole character width on window borders and captions.
The majority of the DMCA is uncontroversial. Thanks to this law you can, for example, install copyrighted software on someone's machine to fix it, so long as you delete it afterwards, and there's nothing the copyright holder can do about it. Thanks to the DMCA, your ISP can set up a web proxy and not be violating copyright (before the DMCA, this was technically "republishing").
The only controversial part of the DMCA is the anticircumvention provisions (aka Chapter 12). If your software does not use an anticircumvention device, you are not exercising the "bad part" of the DMCA. You may sleep soundly.
When I see The Matrix, I don't think philosophy, I think mythology.
Have you ever read Joseph Campbell's The Hero With A Thousand Faces? It treats mythology from a Jungian/Freudian psychoanalytic perspective. All of the major elements of classical mythology are present in films like Star Wars or The Matrix.
Taking the opening The Matrix as an example:
The hero (Neo) is given the call to adventure by an apparition (of Trinity). Compare with the hologram of Leia in Star Wars, angelic messengers from the Bible etc.
His initial refusal to heed the call results in disaster, in his case becoming spellbound ("unable to speak"). Compare with Sleeping Beauty, Narcissus, Lot's wife etc.
He meets the "old wise man" (Morpheus); the spiritual guide who gives him the equipment needed to cross the threshold. Compare with Obi Wan Kenobi, Gandalf, the sea hag from The Little Sea-Maid etc.
While I don't think you can discount the philosophical aspect, I don't think that this is necessarily even the point of The Matrix. There's not so much philosophy that you can present in 3600ft of film. On the other hand, as modern mythology, I think it works well.
As others have noted, you're talking about inexperienced programmers here, or programmers with no taste, not "most OOP programmers". The one exception I can think of is Java programmers, but they're in a different class (pun unintended) because the object is the only abstraction that Java really gives you.
One of the strengths of OOP, and one of the reasons why it really caught on, is that it came with a design methodology which was able to handle a bigger class of problems than previous approaches. This is, IMO, one reason why a lot of old or novice OO code tends to be over-objectised.
This isn't entirely true, of course, as there will always be some people who don't like or feel the need for things like OO, and who value the simplicity of C. For everyone else, the only remaining credible reason to stick with C over C++ is that its compilers optimize better, so it still has a slight performance edge, and even that gap is closing fast as C++ compiler technology evolves.
I think this is overstating it just a tad.
Off the top of my head:
Generated code is generally smaller, I believe due to exception handling. This is occasionally important, because old architectures don't die, they just get pushed down the food chain. Yesterday's minicomputer is today's boot sector or tomorrow's smart card.
C is sometimes easier to incorporate into legacy systems. Consider, for example, an operating system which needs to be statically linked to the application which it executes. (This is a common scenario in some kinds of embedded system.) If the operating system is written in C, the application had better be written in C too, otherwise your static initialisers won't get run, or exceptions will propagate into the OS.
C++ is less binary-compatible than C. This is getting better as ABIs mature, but right now, if you want to distribute a binary-only library, you often need to ship one for each compiler vendor. Or, if you want to allow people to write their own plug-ins, you need to mandate one compiler, or do something else (e.g. make the API C-based or use COM/CORBA/.NET/whatever).
The optimisation aspect, I think, is a myth. Most C compilers today are actually C++ compilers run with some flag set or with different compilation options. For the same code, you get the same degree of optimisation. I think it's true that it's harder to optimise C++-specific features, but I suspect that you would get better optimisation if you use them than if you try to simulate them in C.
I pretty much agree with the rest of your post, though.
I disagree. Common Lisp is a good choice for some kinds of OS. C++ is a good choice for others.
One issue with Common Lisp, for example, is that in a loaded OS, resources must be freed as quickly as possible. This means that you have to use a real-time garbage collector. This means extra accounting associated with each object and worse cache performance. This may not be a "problem" in general, but it's an issue to take into account.
BTW, I'm a functional programmer by design, but I like C++. It's not elegant, that's true. However, I cringe when I see my fellow declarative programmers use the same wrong arguments that I used to use against C++. Then I actually wrote a nontrivial application in C++. C++ is not pretty and it's not pure, but it's very pragmatic, and in the real world of budgets and deadlines, that can be more valuable.
Fiasco is an L4 microkernel. It doesn't have buffer cache, and it only barely has VM, too.
One of the good things about L4, though, is that it provides the bare necessities (threads, IPC and address spaces) and the rest is up to you. You can your file system code in whatever language you like.
There are two high level languages suitable for writing operating systems: C and Ada.
A sensible person would stop reading here, but I'm not sensible. The most suitable language for writing a given OS depends highly on internal (e.g. features) and external (e.g. linkability) constraints. We used to have operating systems written in assembler, PL/I and Oberon. Nowadays we have boot PROMs written in Forth. All of these decisions were certainly justifiable at the time.
Incidentally, I used to say pretty much the same things that you do about C++, until I wrote my first nontrivial application in C++. Nowadays I'm not a C++ zealot, but I'd far rather hack in C++ than in C any day.
It doesn't offer anything over a well written C program. If you write two identical programs on the same level as an OS in both C and C++, you'll end up with a lot of lines of code being about the same. Going through the extra trouble (and compilation overhead) involved in C++ isn't worth the bother when 99% of the code is the same.
Pull up your Linux source and have a look at fs/pipe.c.
Scroll down to do_pipe. Stare at the code for a moment.
All those gotos didn't write themselves.
Now scroll up to the file_operations structs. What you're looking at is a bunch of virtual function tables.
This type of code may not be much shorter in the equivalent C++, but it's going to be a lot more than 1% different, and the difference is almost all going to be in maintainability, which is far more precious than number of lines of code.
Factually, C++ is the most used programming language there is, but to a first approximation, all of this code is for Windows, and I don't count Windows.
I don't know where you've been. There are lot more job placements for Unix C++ programmers than Unix C programmers.
Epidurals are a godsend. We live in the 21st century. Modern medicine is a GOOD thing. Don't be afraid to take advantage of it.
This is very bad advice.
Don't get me wrong. Epidurals are great if a) you need one, and b) it works for you. However, there are some issues you need to consider.
First is the comment from the AC that epidurals do increase the risk of complications. This is true.
Secondly, they can be damn inconvenient. We went through a 36 hour labour (breech), and the doctor wanted the epidural in place just in case an emergency C-section was necessary. (Breech births rarely need a C-section, but it was prudent to have it in place.) Well, it was hell. Imagine sitting on your tailbone for 20 hours, unable to get up and walk around. Compare this with what women naturally want to do in labour (i.e. get up and walk around).
Thirdly, babies come when they want to. If you live in a small town, for example, your local hospital may not have an anaesthetist there 24 hours a day (on call for emergencies only), so the epidural may not be an option. You do not want to be in the position where you have to do a drug-free labour which you are not prepared for.
I recommend this site which was started by my wife during her pregnancy with our first child, and hacked up a lot since then. It's based on all the research which we did. Go look.
In fact there is much more efficient ways to factor large numbers than by trying to divide with each and every prime.
In principle, yes. It depends why you want to try to factor the number, though.
To a first approximation, for numbers n-bits long, roughly every nth number is prime. (To a second approximation, it's every n*ln(2).) If you're trying to find a random prime or near-prime in some range (e.g. for RSA key generation), then you will have to reject a few numbers before you get there.
Most of those rejected numbers will fail the "small primes" test, where you pick all primes smaller than some number (e.g. less than 1000) and try dividing. This, I believe, is what the poster meant by "first try[ing] the small primes". If your number passes the "small primes" test, then you can apply some algorithmically more expensive tests (e.g. Fermat testing).
Of course, if your number is not random, and have reason to believe that your number will pass the small primes test (e.g. if it's an RSA modulus), then this probably won't help you.
Slashdot Mirror
In film work, if you're clever, that can actually work for you.
An average Pixar frame might contain 2Gb of geometry data and 10Gb of texture data. Even on a gigabit network, that takes a nontrivial time to actually send to a farm machine. This can become a bottleneck in rendering.
Trying to make sure that frames that need the same data get computed on different CPUs on the same machine actually increases the amount of useful work that you can do. This suggests that the amount of time taken might even be less than 1/8th on some data sets.
My intuition suggests that the effects would even out, but my intuition also tells me never to trust my intuition.
Firstly, 8 hours is the peak amount of work (e.g. the "room with all the doors" from Monsters Inc). Most frames don't take quite that long.
Secondly, each frame is generally rendered more than once during the lighting process.
Thirdly, most animated films are only 85 or so minutes long. Shrek was even shorter.
I believe that it takes Pixar about a month to fully re-render a movie from start to finish in one burst. Even quicker for the DVD version.
I am so glad that someone else noticed this.
Those times that it makes sense to program in a functional language are pretty much those times that you don't want imperative stuff getting in the way at all. Adding imperative features to a functional language is not the solution. Adding better support for developing software in multiple languages is.
Incidentally, ML was around years before Haskell. Its imperative features are very much historical. If monads as a programming construct had been considered 30 odd years ago, ML might be a much purer language than it is.
F#, on the other hand, is little more than a bastard child.
You mean vellum, not parchment. Even then it's only partly true. The first copies of the New Testament, for example (certainly the oldest fragments that we have), were probably written on papyrus, which while not paper as we know it today, is close enough.
This, of course, misses the point of C++'s protection mechanisms.
Yes, it's easy to forge a C++ pointer, but a) it's usually not portable, and b) you have to go out of your way to do it. In C++, it's hard to inadvertantly forge a pointer (assuming you're really programming in C++ and not just C with single line comments; real C++ programmers avoid naked pointers unless they're absolutely necessary).
C++ protection mechanisms are to protect the programmer from themselves, not from an outside attacker. It's a safety net, not a padlock.
You're new around here, aren't you?
There's always under ground, near the Earth's core, where it's still warm. Live long enough, you might even see it...
Context switches are very cheap if you're using any processor but an x86. Even on an x86, if you need this kind of speed you'd be crazy to use a machine with only one processor.
Blinn's Law is what those in the graphics industry know as the counterpoint to Moore's Law. It states, in its original form: The amount of time it takes to render a frame is constant over time.
The point is that computers are getting faster, but we're also asking them to do a lot more, and these effects cancel each other out. Consider, for example, how long it takes your word processor to load. It's probably the same amount of time that it took 15 years ago.
So how long until RAM-only databases are practical? For some databases, right now. The database which sits behind your typical weblog, for example, could probably work today. For your typical enterprise application, it will never happen, because what is "typical" is a constantly moving target.
My experience is the opposite.
I find my productivity to be directly proportional to the amount of information that I can see at once. On a decent windowing system, I can make my fonts as small as I want (especially if they're anti-aliased) and lay out my windows as I need. Unlike the twin approach, I don't waste a whole character width on window borders and captions.
BTW, emacs suX0Rz and vi rUl3z. Hope this helps.
Probably the last time they were only shown in one theatre at a time.
The majority of the DMCA is uncontroversial. Thanks to this law you can, for example, install copyrighted software on someone's machine to fix it, so long as you delete it afterwards, and there's nothing the copyright holder can do about it. Thanks to the DMCA, your ISP can set up a web proxy and not be violating copyright (before the DMCA, this was technically "republishing").
The only controversial part of the DMCA is the anticircumvention provisions (aka Chapter 12). If your software does not use an anticircumvention device, you are not exercising the "bad part" of the DMCA. You may sleep soundly.
I'm curious as to what you think a story is. Certainly in the Robert McKee sense, they all have very strong stories.
When I see The Matrix, I don't think philosophy, I think mythology.
Have you ever read Joseph Campbell's The Hero With A Thousand Faces? It treats mythology from a Jungian/Freudian psychoanalytic perspective. All of the major elements of classical mythology are present in films like Star Wars or The Matrix.
Taking the opening The Matrix as an example:
While I don't think you can discount the philosophical aspect, I don't think that this is necessarily even the point of The Matrix. There's not so much philosophy that you can present in 3600ft of film. On the other hand, as modern mythology, I think it works well.
I re-read the article several times, and not once did I see the original poster say s/he was writing a web server. Did I miss something?
As others have noted, you're talking about inexperienced programmers here, or programmers with no taste, not "most OOP programmers". The one exception I can think of is Java programmers, but they're in a different class (pun unintended) because the object is the only abstraction that Java really gives you.
One of the strengths of OOP, and one of the reasons why it really caught on, is that it came with a design methodology which was able to handle a bigger class of problems than previous approaches. This is, IMO, one reason why a lot of old or novice OO code tends to be over-objectised.
I think this is overstating it just a tad.
Off the top of my head:
The optimisation aspect, I think, is a myth. Most C compilers today are actually C++ compilers run with some flag set or with different compilation options. For the same code, you get the same degree of optimisation. I think it's true that it's harder to optimise C++-specific features, but I suspect that you would get better optimisation if you use them than if you try to simulate them in C.
I pretty much agree with the rest of your post, though.
I disagree. Common Lisp is a good choice for some kinds of OS. C++ is a good choice for others.
One issue with Common Lisp, for example, is that in a loaded OS, resources must be freed as quickly as possible. This means that you have to use a real-time garbage collector. This means extra accounting associated with each object and worse cache performance. This may not be a "problem" in general, but it's an issue to take into account.
BTW, I'm a functional programmer by design, but I like C++. It's not elegant, that's true. However, I cringe when I see my fellow declarative programmers use the same wrong arguments that I used to use against C++. Then I actually wrote a nontrivial application in C++. C++ is not pretty and it's not pure, but it's very pragmatic, and in the real world of budgets and deadlines, that can be more valuable.
Fiasco is an L4 microkernel. It doesn't have buffer cache, and it only barely has VM, too.
One of the good things about L4, though, is that it provides the bare necessities (threads, IPC and address spaces) and the rest is up to you. You can your file system code in whatever language you like.
A sensible person would stop reading here, but I'm not sensible. The most suitable language for writing a given OS depends highly on internal (e.g. features) and external (e.g. linkability) constraints. We used to have operating systems written in assembler, PL/I and Oberon. Nowadays we have boot PROMs written in Forth. All of these decisions were certainly justifiable at the time.
Incidentally, I used to say pretty much the same things that you do about C++, until I wrote my first nontrivial application in C++. Nowadays I'm not a C++ zealot, but I'd far rather hack in C++ than in C any day.
Pull up your Linux source and have a look at fs/pipe.c. Scroll down to do_pipe. Stare at the code for a moment. All those gotos didn't write themselves.
Now scroll up to the file_operations structs. What you're looking at is a bunch of virtual function tables.
This type of code may not be much shorter in the equivalent C++, but it's going to be a lot more than 1% different, and the difference is almost all going to be in maintainability, which is far more precious than number of lines of code.
I don't know where you've been. There are lot more job placements for Unix C++ programmers than Unix C programmers.
This is offtopic, but I'm dying to know... you don't have a link explaining the ending of The Black Hole too, do you?
In Australia, we have a cattle ranch which is bigger than Texas. The odd thing is that it is owned by Texans.
No, this is not a joke.
This is very bad advice.
Don't get me wrong. Epidurals are great if a) you need one, and b) it works for you. However, there are some issues you need to consider.
First is the comment from the AC that epidurals do increase the risk of complications. This is true.
Secondly, they can be damn inconvenient. We went through a 36 hour labour (breech), and the doctor wanted the epidural in place just in case an emergency C-section was necessary. (Breech births rarely need a C-section, but it was prudent to have it in place.) Well, it was hell. Imagine sitting on your tailbone for 20 hours, unable to get up and walk around. Compare this with what women naturally want to do in labour (i.e. get up and walk around).
Thirdly, babies come when they want to. If you live in a small town, for example, your local hospital may not have an anaesthetist there 24 hours a day (on call for emergencies only), so the epidural may not be an option. You do not want to be in the position where you have to do a drug-free labour which you are not prepared for.
I recommend this site which was started by my wife during her pregnancy with our first child, and hacked up a lot since then. It's based on all the research which we did. Go look.
...BSD is not dying.
In principle, yes. It depends why you want to try to factor the number, though.
To a first approximation, for numbers n-bits long, roughly every nth number is prime. (To a second approximation, it's every n*ln(2).) If you're trying to find a random prime or near-prime in some range (e.g. for RSA key generation), then you will have to reject a few numbers before you get there.
Most of those rejected numbers will fail the "small primes" test, where you pick all primes smaller than some number (e.g. less than 1000) and try dividing. This, I believe, is what the poster meant by "first try[ing] the small primes". If your number passes the "small primes" test, then you can apply some algorithmically more expensive tests (e.g. Fermat testing).
Of course, if your number is not random, and have reason to believe that your number will pass the small primes test (e.g. if it's an RSA modulus), then this probably won't help you.