1) you are exaggerating the "big run-time hit." Testing for overflow in addition of fixed-size integers is going to be easily pipelined. Sure, when you actually overflow, you will have to branch and transform your representation, but the alternative was to get the wrong answer?
2) Your for loop example is exactly the kind of case that a compiler will optimize to be kept in fixed size registers.
As usual, we see the "New Jersey" design technique. Better to be "fast" and sometimes wrong than always right.
I find it interesting that counting the number of entries in a database is somehow a "specialized" operation. So anytime I want to count anything that there might be "a lot" of, I have to use some non-built-in multiple precision arithmetic package---who knows how well it was optimized, or whether it's buggy---instead of a vendor-provided, standard-mandated ability of the language?
If shared ownership is not a good model (which it is not with any node based data structure), then don't use it. For a linked list, the obvious ownership strategy is for the list to own the nodes.
And if an object is in more than one list? It has to be copied anew? What if it doesn't make sense to copy/clone it? Clue: there is no single definition to "copy" which makes sense for all applications. The notion of "copy" has to do with the notion of "identity" which is not a fixed concept. Again, you are forced to fit your abstraction to the need to track ownership.
I'm interested in your comment that Lisp and C++ have different design goals. Common Lisp is designed to provide the programmer with a flexible, robust, object-oriented environment, suitable for large programming tasks. How does that differ from C++'s stated goals?
1) having to distinguish between different kinds of ownership means you have to restrict your design to fit the memory management model. This is progress? In Lisp, it is relatively common, for instance, to create circular lists to represent arbitrarily-long periodic sequences. With reference counting, your "list" abstraction either isn't abstract enough to handle this, or this usage has to be forbidden or made a special case.
2) overhead at assignment: this is exactly my point. The reason you go to GC is that assignment is common enough that you can't explicitly keep track of ownership without making a mistake or going crazy. In reference counting, you spend time incrementing and decrementing counters even if the thing never becomes garbage. An object only becomes garbage once (ignoring certain finalization or "weak pointer" issues), but you pay many times.
It basically boils down to this: GC was basically invented by and most researched by the Lisp community. Not a single Lisp implementation I know of uses reference counting because its run-time performance is dominated by true GC.
It's truly amazing to see the turnaround. The beef against Lisp used to be "perhaps powerful, but too bloated and slow." Now, 20 years later, Lisp has gained (in relative terms) in speed by aggressively pursuing compiler and GC technology, and has (in absolute terms) stayed about the same in memory consumption as RAM prices have plummeted. Now we find out it is all right to give up speed and memory consumption as long as you support ugly notation that has to use every punctuation character in *at least* one way.
The true alternative is multiple-precision integers, transparently equivalent to small integers. Such as in Lisp. Lisp integers are limited only by available memory.
Of course, C programmers are used to a world where "+" means addition modulo some arbitrary power of 2. The 2038 bug isn't a bug after all---it's just where time starts to repeat, right?
1) reference counting cannot handle circular references. Of course, C++ programmers hardly ever want to create anything able to handle such abstraction.
2) you have ignored any time performance. Reference counting adds overhead even if you never accumulate a significant amount of garbage.
My interviews are confirmations. I know a person is qualified before I even sit down. My only question is "can you do the work?"
How do you know a person is qualified before talking to them? You believe that your needs can be met with some checklist of requirements?
Lists 8 programming languages---if you, or anyone, is hiring on some "language count" metric, you are being ill-served. Much more important are issues of judgment: "What advantages/disadvantages are there to each language? How do you go about choosing what languages to use?" or ability: "How do you feel most comfortable learning a 9th computer language?"
If a hiring manager doesn't know what he needs, then he is totally unaware of his situation, and wouldn't be able to manage. Why does he go through the enormous effort of screening candidates if he doesn't have some idea of what work needs to be done that doesn't yet have a person to do it?
If as you say, office politics and dealing with people are "paramount to the completion of even the most trivial task once they are hired" why shouldn't the interviewer discriminate on that basis? Anyone who can't deal with other people would be missing the paramount qualification!
You seem to be bitter about the job search process, perhaps justifiably so. But complaining about how the real world works does not qualify as a strategy for achieving much in that world.
No, what I said is MEANT to be torturous. I have been through at least one torturous interview, but that was because the interviewer was asking me about technical issues that I had gotten very rusty on. Fair, obviously important to the interviewer, and not meant to torture me. My response was to make sure for the second interview that I had boned up on the issues he raised.
The process eventually ended in a job offer.
What you describe (the psychological tests, etc.) is certainly objectionable, but I wouldn't call it torturous. Just boneheaded, and a good sign that you wouldn't want to work there.
Sure! Don't hire them because they know their work, hire them because they did a REALLY GOOD JOB of LOOKING for work. Of course!
....Interviews are a waste of time. All managers use them for is to amuse themselves like they are tormenting a small animal. "Let's see what he says to *this*"
A job search and interview is about marketing yourself. If you can't convince someone else that you can do the job, you expect them to hire out of a sense of charity, to pay your bills? Or use ESP to determine that you are indeed qualified? You expect a "direct mail campaign" of hundreds of resumes to get a response rate better than junk mail (i.e., a few percent)?
I've never been in a job interview that was meant to be torturous. I've given job interviews that might have been perceived as torturous, but were merely my effort to determine if the people I was interviewing were right for the job. I wish those candidates had been much better at marketing themselves, so I could tell they were right without torture!
Marketing means finding out what the hiring manager needs, and demonstrating that you have what it takes. "Techies" may complain that requiring this is somehow "unfair" or "pointy-haired behavior." Wake up. People, unlike computers, are convinced to make decisions by people, not by lines written on a piece of paper.
Furthermore, they have to work with the people they've hired, not the resume. If you are surly and suffering from a sense of entitlement, you might not be so pleasant to work with, so why take the chance of hiring you?
Nit to pick: you mean time-reversal invariance, not time-translation. Symmetry under time-translation is related to conservation of energy, not reversibility.
Look, the point is not whether Alan Cox believes he is taking a principled stance, and whether anyone believes he should rather be apathetic.
The point, for me, is that it would be preferable for Alan to do what is possible to help Linux be a real success. It seems to me that AOL/TW buying RH would go a great distance toward convincing potential *paying* customers for RH Linux that RH as a company will continue to exist. That can only help Linux's adoption by real-world companies.
UTICA and DMCA have very little to do with Linux's success.
There is sometimes a fine line between principled stance-taking and immature whining. If Alan took a stance "I'm not working for AOL/TW because the CEO bought his wife a fur coat. They're animal killers!" it would be counterproductive.
Does this stance give a potential PAYING customer more or less confidence in Alan Cox's ability to deliver a robust, stable kernel for enterprise software?
I wonder if any systems have enough introspection that you can capture the call stack in a variable before dumping, for later inspection in the image?
The problem of the OS core dump that I was thinking about is somewhat more subtle: when you dump core, the PC is at the point where you are making the system call. When you bring the core image up in the debugger, can you continue executing machine code where that system call *would have* returned? Because then, in your code, you could have something like
;;; this is my runtime error handler
(progn (dump-core) (invoke-debugger))
of course, dump-core doesn't return in the normal execution flow, but later in the core debugger, can you simply continue execution into the Lisp debugger, and then get full access to the backtrace inspection, etc.?
That is a fascinating question. You might try to ask it on comp.lang.lisp to get the response of people who have built long-lived Lisp systems, but you might just cause a ruckus.
Obviously, for errors that are foreseen, you can set up proper error-handlers in a robust, flexible way, as usual for Common Lisp. The problem is unforeseen errors, such as stupid typos in code that were never exercised, and cause run-time type errors. The default action in Lisp is to present the debugger prompt.
A "core dump" is an OS-dependent concept--a C program does not know what to do when it dumps core, the OS does. However, you can typically "save" an executable image of a Lisp session.
One can provide a value for *debugger-hook*, a special variable that contains a function which will be called before the debugger is entered. In that handler function, one could include a "save image" command, then a jump to some "reset" point in the main program loop, to start from scratch.
Then, one can probably debug the saved image at your leisure. I have never tried this, so I don't know if most vendors' Common Lisp implementations can get you to the debugger in the error condition , preserving the call stack so that you know where the error occured.
Alternatively, you could call a system command to dump your core for you. What your debugger does with such a core file is a good question.
More seriously, the people who wrote Orbitz didn't pick Lisp just to make a theoretical point. They picked Lisp because they did not want to face the daunting task of solving their problem in C/C++. You might not believe it, but they did---and they are the ones making big bucks from it.
Visit the sites of major Lisp vendors (Xanalys.com, allegro.com) and they have many examples, often involving heavy-duty logistics or information management. Basically, everyone who can solve their problem using C++ uses C++. Anyone who has problems that can't be solved using C++, uses Lisp, decides to live with their problem, or creates more of a problem by trying to create a C++ solution.
There are many capabilities of Lisp that let it solve daunting problems; the fact that macros can manipulate code using code written in Lisp is a big one.
"struct": obviously, you've never experienced real multiple value returns. As if Lisp doesn't have structures also.
Multiple value returns in Lisp are more flexible than structs because the caller does not have to accept all of the values that are being returned. If you just want the first value returned, simply call the function. If you want to capture multiple values, do so. Furthermore, multiple values propagate painlessly through the function call chain.
With structs, you have only a single return value, the type of which has to be recognized by every function in the call chain in order for the values to be captured.
Primary example: getting a value from a hash table. There are really two things you want back: the value corresponding to your key, and whether the key actually had an associated value.
Lisp: "return two values: the value, and whether the key was present in the table" No call by reference needed. No pointers.
Other useful examples: the Lisp floor and ceiling function return two values: the integer part and the fractional part that was truncated. Usually, you ignore the fractional part, but sometimes, it is convenient to have.
I find the bit-twiddling abilities of Common Lisp to be pretty advanced compared to C.
Granted, this depends on what you mean by "bit-twiddling"--smashing memory based on a pointer given to you by the OS is going to be implementation-dependent.
However, for actually pulling bits out of data and re-arranging them, I find the Common Lisp routines to be great. You can assign/extract integer values to/from any consecutive block of bits, without having to compute the masks and shifts yourself. I've found this quite nice in creating code that converts to/from native IEEE floats from/to other floating-point formats.
I'm no expert, but my best guess for "sudden" is the Planck time (derived from G, Planck's constant, and the speed of light) which is 5 x 10^-44 seconds.
The only other possibility I could imagine is the size of the universe divided by the speed of light, which is something like the age of the universe. That of course, would have been sudden when the universe was celebrating it's Planck's time birthday, but pretty darn sluggish today.
Uh, the world was (except for Antarctica) colonized in prehistoric times, mostly by foot, and otherwise by small boats. The world just isn't very big.
The solar system, not to mention the galaxy is a far, far larger place. Given that we don't yet know of any habitable planet outside our solar system, a glib confidence that we will somehow colonize the galaxy is preposterous.
Re:"reasonable" to use version control with binary
on
Writing Documentation
·
· Score: 2
It can be reasonable to use version control with binary files.
I believe what you mean to say is
"is it reasonable to use version control when you give up the following benefits:
1) compact storage by using deltas
2) easy 'diff'-type comparison between versions
3) machine assistance in merging branches."
(1) these days is hardly noticeable.
(2) and (3) are, admittedly, the big problems.
The primary function of version control is to maintain a snapshot of files at multiple checkpoints. There doesn't have to be parseable data to do that.
The evidence for Heisenberg's knowledge is very sketchy, and his own reports are possibly self-serving.
Did Heisenberg have an accurate calculation of the critical mass? Was he misled by poor experimental data, or bad theory? Did he think too much enriched uranium was needed for a bomb for Germany to make? Or did he know the true amount but hide it from his superiors because he was so noble?
Once he knew the Americans had done it, and gotten over his surprise, he was able to describe pretty accurately what was involved. But could he have described it as accurately *beforehand*, or did he only then recognize an important mistake?
No one knows; but historians, laymen, and playwrights will enjoy arguing about these questions for a long time.
Slashdot Mirror
1) you are exaggerating the "big run-time hit." Testing for overflow in addition of fixed-size integers is going to be easily pipelined. Sure, when you actually overflow, you will have to branch and transform your representation, but the alternative was to get the wrong answer?
2) Your for loop example is exactly the kind of case that a compiler will optimize to be kept in fixed size registers.
As usual, we see the "New Jersey" design technique. Better to be "fast" and sometimes wrong than always right.
I find it interesting that counting the number of entries in a database is somehow a "specialized" operation. So anytime I want to count anything that there might be "a lot" of, I have to use some non-built-in multiple precision arithmetic package---who knows how well it was optimized, or whether it's buggy---instead of a vendor-provided, standard-mandated ability of the language?
If shared ownership is not a good model (which it is not with any node based data structure), then don't use it. For a linked list, the obvious ownership strategy is for the list to own the nodes.
And if an object is in more than one list? It has to be copied anew? What if it doesn't make sense to copy/clone it? Clue: there is no single definition to "copy" which makes sense for all applications. The notion of "copy" has to do with the notion of "identity" which is not a fixed concept. Again, you are forced to fit your abstraction to the need to track ownership.
I'm interested in your comment that Lisp and C++ have different design goals. Common Lisp is designed to provide the programmer with a flexible, robust, object-oriented environment, suitable for large programming tasks. How does that differ from C++'s stated goals?
1) having to distinguish between different kinds of ownership means you have to restrict your design to fit the memory management model. This is progress? In Lisp, it is relatively common, for instance, to create circular lists to represent arbitrarily-long periodic sequences. With reference counting, your "list" abstraction either isn't abstract enough to handle this, or this usage has to be forbidden or made a special case.
2) overhead at assignment: this is exactly my point. The reason you go to GC is that assignment is common enough that you can't explicitly keep track of ownership without making a mistake or going crazy. In reference counting, you spend time incrementing and decrementing counters even if the thing never becomes garbage. An object only becomes garbage once (ignoring certain finalization or "weak pointer" issues), but you pay many times.
It basically boils down to this: GC was basically invented by and most researched by the Lisp community. Not a single Lisp implementation I know of uses reference counting because its run-time performance is dominated by true GC.
It's truly amazing to see the turnaround. The beef against Lisp used to be "perhaps powerful, but too bloated and slow." Now, 20 years later, Lisp has gained (in relative terms) in speed by aggressively pursuing compiler and GC technology, and has (in absolute terms) stayed about the same in memory consumption as RAM prices have plummeted. Now we find out it is all right to give up speed and memory consumption as long as you support ugly notation that has to use every punctuation character in *at least* one way.
The true alternative is multiple-precision integers, transparently equivalent to small integers. Such as in Lisp. Lisp integers are limited only by available memory.
Of course, C programmers are used to a world where "+" means addition modulo some arbitrary power of 2. The 2038 bug isn't a bug after all---it's just where time starts to repeat, right?
1) reference counting cannot handle circular references. Of course, C++ programmers hardly ever want to create anything able to handle such abstraction.
2) you have ignored any time performance. Reference counting adds overhead even if you never accumulate a significant amount of garbage.
What OS X can do that Linux can't?
You can't be serious.
1) Adobe applications
2) Microsoft office
3) iMovie, iPhoto, etc.
etc.
Don't bother saying that Linux can do the same thing with open source "substitutes." Margarine ain't butter.
My interviews are confirmations. I know a person is qualified before I even sit down. My only question is "can you do the work?"
How do you know a person is qualified before talking to them? You believe that your needs can be met with some checklist of requirements?
Lists 8 programming languages---if you, or anyone, is hiring on some "language count" metric, you are being ill-served. Much more important are issues of judgment: "What advantages/disadvantages are there to each language? How do you go about choosing what languages to use?" or ability: "How do you feel most comfortable learning a 9th computer language?"
If a hiring manager doesn't know what he needs, then he is totally unaware of his situation, and wouldn't be able to manage. Why does he go through the enormous effort of screening candidates if he doesn't have some idea of what work needs to be done that doesn't yet have a person to do it?
If as you say, office politics and dealing with people are "paramount to the completion of even the most trivial task once they are hired" why shouldn't the interviewer discriminate on that basis? Anyone who can't deal with other people would be missing the paramount qualification!
You seem to be bitter about the job search process, perhaps justifiably so. But complaining about how the real world works does not qualify as a strategy for achieving much in that world.
No, what I said is MEANT to be torturous. I have been through at least one torturous interview, but that was because the interviewer was asking me about technical issues that I had gotten very rusty on. Fair, obviously important to the interviewer, and not meant to torture me. My response was to make sure for the second interview that I had boned up on the issues he raised.
The process eventually ended in a job offer.
What you describe (the psychological tests, etc.) is certainly objectionable, but I wouldn't call it torturous. Just boneheaded, and a good sign that you wouldn't want to work there.
Sure! Don't hire them because they know their work, hire them because they did a REALLY GOOD JOB of LOOKING for work. Of course!
....Interviews are a waste of time. All managers use them for is to amuse themselves like they are tormenting a small animal. "Let's see what he says to *this*"
A job search and interview is about marketing yourself. If you can't convince someone else that you can do the job, you expect them to hire out of a sense of charity, to pay your bills? Or use ESP to determine that you are indeed qualified? You expect a "direct mail campaign" of hundreds of resumes to get a response rate better than junk mail (i.e., a few percent)?
I've never been in a job interview that was meant to be torturous. I've given job interviews that might have been perceived as torturous, but were merely my effort to determine if the people I was interviewing were right for the job. I wish those candidates had been much better at marketing themselves, so I could tell they were right without torture!
Marketing means finding out what the hiring manager needs, and demonstrating that you have what it takes. "Techies" may complain that requiring this is somehow "unfair" or "pointy-haired behavior." Wake up. People, unlike computers, are convinced to make decisions by people, not by lines written on a piece of paper.
Furthermore, they have to work with the people they've hired, not the resume. If you are surly and suffering from a sense of entitlement, you might not be so pleasant to work with, so why take the chance of hiring you?
Nit to pick: you mean time-reversal invariance, not time-translation. Symmetry under time-translation is related to conservation of energy, not reversibility.
Look, the point is not whether Alan Cox believes he is taking a principled stance, and whether anyone believes he should rather be apathetic.
The point, for me, is that it would be preferable for Alan to do what is possible to help Linux be a real success. It seems to me that AOL/TW buying RH would go a great distance toward convincing potential *paying* customers for RH Linux that RH as a company will continue to exist. That can only help Linux's adoption by real-world companies.
UTICA and DMCA have very little to do with Linux's success.
There is sometimes a fine line between principled stance-taking and immature whining. If Alan took a stance "I'm not working for AOL/TW because the CEO bought his wife a fur coat. They're animal killers!" it would be counterproductive.
Does this stance give a potential PAYING customer more or less confidence in Alan Cox's ability to deliver a robust, stable kernel for enterprise software?
This is an interesting problem.
I wonder if any systems have enough introspection that you can capture the call stack in a variable before dumping, for later inspection in the image?
The problem of the OS core dump that I was thinking about is somewhat more subtle: when you dump core, the PC is at the point where you are making the system call. When you bring the core image up in the debugger, can you continue executing machine code where that system call *would have* returned? Because then, in your code, you could have something like
;;; this is my runtime error handler
(progn (dump-core) (invoke-debugger))
of course, dump-core doesn't return in the normal execution flow, but later in the core debugger, can you simply continue execution into the Lisp debugger, and then get full access to the backtrace inspection, etc.?
That is a fascinating question. You might try to ask it on comp.lang.lisp to get the response of people who have built long-lived Lisp systems, but you might just cause a ruckus.
Obviously, for errors that are foreseen, you can set up proper error-handlers in a robust, flexible way, as usual for Common Lisp. The problem is unforeseen errors, such as stupid typos in code that were never exercised, and cause run-time type errors. The default action in Lisp is to present the debugger prompt.
A "core dump" is an OS-dependent concept--a C program does not know what to do when it dumps core, the OS does. However, you can typically "save" an executable image of a Lisp session.
One can provide a value for *debugger-hook*, a special variable that contains a function which will be called before the debugger is entered. In that handler function, one could include a "save image" command, then a jump to some "reset" point in the main program loop, to start from scratch.
Then, one can probably debug the saved image at your leisure. I have never tried this, so I don't know if most vendors' Common Lisp implementations can get you to the debugger in the error condition , preserving the call stack so that you know where the error occured.
Alternatively, you could call a system command to dump your core for you. What your debugger does with such a core file is a good question.
uhhh....Orbitz? As in the topic of the article?
More seriously, the people who wrote Orbitz didn't pick Lisp just to make a theoretical point. They picked Lisp because they did not want to face the daunting task of solving their problem in C/C++. You might not believe it, but they did---and they are the ones making big bucks from it.
Visit the sites of major Lisp vendors (Xanalys.com, allegro.com) and they have many examples, often involving heavy-duty logistics or information management. Basically, everyone who can solve their problem using C++ uses C++. Anyone who has problems that can't be solved using C++, uses Lisp, decides to live with their problem, or creates more of a problem by trying to create a C++ solution.
There are many capabilities of Lisp that let it solve daunting problems; the fact that macros can manipulate code using code written in Lisp is a big one.
"struct": obviously, you've never experienced real multiple value returns. As if Lisp doesn't have structures also.
Multiple value returns in Lisp are more flexible than structs because the caller does not have to accept all of the values that are being returned. If you just want the first value returned, simply call the function. If you want to capture multiple values, do so. Furthermore, multiple values propagate painlessly through the function call chain.
With structs, you have only a single return value, the type of which has to be recognized by every function in the call chain in order for the values to be captured.
Primary example: getting a value from a hash table. There are really two things you want back: the value corresponding to your key, and whether the key actually had an associated value.
Lisp: "return two values: the value, and whether the key was present in the table" No call by reference needed. No pointers.
Other useful examples: the Lisp floor and ceiling function return two values: the integer part and the fractional part that was truncated. Usually, you ignore the fractional part, but sometimes, it is convenient to have.
I find the bit-twiddling abilities of Common Lisp to be pretty advanced compared to C.
Granted, this depends on what you mean by "bit-twiddling"--smashing memory based on a pointer given to you by the OS is going to be implementation-dependent.
However, for actually pulling bits out of data and re-arranging them, I find the Common Lisp routines to be great. You can assign/extract integer values to/from any consecutive block of bits, without having to compute the masks and shifts yourself. I've found this quite nice in creating code that converts to/from native IEEE floats from/to other floating-point formats.
I'm no expert, but my best guess for "sudden" is the Planck time (derived from G, Planck's constant, and the speed of light) which is 5 x 10^-44 seconds.
The only other possibility I could imagine is the size of the universe divided by the speed of light, which is something like the age of the universe. That of course, would have been sudden when the universe was celebrating it's Planck's time birthday, but pretty darn sluggish today.
Uh, the world was (except for Antarctica) colonized in prehistoric times, mostly by foot, and otherwise by small boats. The world just isn't very big.
The solar system, not to mention the galaxy is a far, far larger place. Given that we don't yet know of any habitable planet outside our solar system, a glib confidence that we will somehow colonize the galaxy is preposterous.
It can be reasonable to use version control with binary files.
I believe what you mean to say is
"is it reasonable to use version control when you give up the following benefits:
1) compact storage by using deltas
2) easy 'diff'-type comparison between versions
3) machine assistance in merging branches."
(1) these days is hardly noticeable.
(2) and (3) are, admittedly, the big problems.
The primary function of version control is to maintain a snapshot of files at multiple checkpoints. There doesn't have to be parseable data to do that.
ED!
ED is the *standard* text editor!
You know the rest....
I think the study of history has enough problems determining the "what happened" and "why" to spend much serious effort on "what-if."
The evidence for Heisenberg's knowledge is very sketchy, and his own reports are possibly self-serving.
Did Heisenberg have an accurate calculation of the critical mass? Was he misled by poor experimental data, or bad theory? Did he think too much enriched uranium was needed for a bomb for Germany to make? Or did he know the true amount but hide it from his superiors because he was so noble?
Once he knew the Americans had done it, and gotten over his surprise, he was able to describe pretty accurately what was involved. But could he have described it as accurately *beforehand*, or did he only then recognize an important mistake?
No one knows; but historians, laymen, and playwrights will enjoy arguing about these questions for a long time.
That's probably somewhat misleading. The US didn't suffer "strategic" bombing late in the war like Germany did. What about 1943?
What everyone seems to have missed, (and I almost missed, listening to the keynote.)
5 (FIVE) USB ports. And 2 Firewire.
I'll agree about the women point, but you can develop RSI from handwriting just as from typing with poor technique.