A natural language like English is, of course, the preferred means of communication for informal discourse. Natural languages, however, are often too ambiguous and verbose to function well when expressing precise algorithms.
Those of you who are programmers, you tell me: which is easier to understand, the DeCSS code in C, or the same code in haiku? (I think you can find the latter off Dr. Felten's homepage at Princeton.) Which is easier to work with?
Taken at its face value and out of context, the court's statement is going to be somewhat ridiculous, yes. However, that does not change the fact that programming languages are as useful for communicating algorithms between people as they are for communicating algorithms from a person to a computer.
LDA #$07
JSR $FDED
(Although I think you'd likely need a trailing invalid opcode or something to return control back to the system monitor.)
Cut my teeth on the Apple II series. I still remember that system fondly, even with all of its little quirks. (Remember how ``hi-res'' graphics were stored in memory? Backwards?)
(For those of you who want to try this out, get one of the free Apple emulators off the net, then type `call -151' at the BASIC prompt, then type in the hex numbers and command given upthread.)
Does anyone still remember the time when "virus" (or "virii or whatever) meant....
OK, pet peeve of mine. The correct plural form of "virus" is either "viruses" or "vira," NOT "virii."
Latin words ending in -us will frequently, though not always, form a plural by replacing the -us with -i, so I can understand why people might think the plural is "viri." The form "virii" has no basis in any sort of Latin; the corresponding singular would be "virius."
However, the Lewis & Short Latin Dictionary online at the Perseus Project, as well as my hardbound dictionary at home, indicates that this word is a little irregular:
vîrus, i, n. [Sanscr. visham; Gr. ios, poison], a slimy liquid, slime.
Since it's second-declension neuter, the plural is "vira."
We now return you to your regularly-scheduled Slashdot discussions....
Since the JVM is responsible for garbage collection, this implies that the concept of implementing memory management in the hardware is at least 4 years old.
As I understand it, it's a lot older than that. Many of the old LISP machines, I believe, used to have built-in GC. I don't know if it was in hardware or the OS, but it's the same basic idea.
What many people forget is that a GC is not entirely for finding and removing memory leaks. They also have the really nice property of preventing subtle aliasing bugs.
int *i, *j;
i = new int; j = i; delete i; printf("%d\n", *j);// AAAK!
I'm sending a response to this post to emin in private mail, as it's fairly lengthy. If others are interested, drop me a line and I'll send you a copy as well.
Pointers v. References (Re:Remember the VAX!)
on
The New Garbage Man
·
· Score: 2
java has references, which is different.. they are equiv. to handles (pointer pointers) where the middle pointer is a table to the location of the object - so things can be moved around without the actual pointer value in the program changing.
Well, more or less. As part of a programming languages class I took in school, I actually had to write a garbage collector for a Scheme-like language. While one could implement references in a Java/Scheme/LISP-like language in the above fashion, that's really slow; it adds another layer of indirection that isn't really necessary. If the run-time system provides information about the types of objects in memory (which is required for Java and Scheme anyway -- instanceof and symbol?), then the GC can reach in and directly change the pointer values within the program's stack or whatever.
From the point of view of the applications programmer, though, the two implementations are equivalent.
As far as I'm concerned, the primary difference between pointers and references is that with a reference to an object of type Foo, you are guaranteed that the object referred to is a valid instance of type Foo. This is not the case with pointers. In C/C++ terms, int i; float *pF; pF = (float *)(&i); The object at *pF is not a valid instance of a float.
(Yes, you can in fact break this guarantee in C++ using a series of really crufty typecasts. C++'s references are broken, in a number of respects.)
Of course, as MassacrE points out, references are almost always implemented internally in terms of pointers, because that's what the underlying architecture tends to support.
Evils of ref-count GCs (was Re:You Don't get it)
on
The New Garbage Man
·
· Score: 1
Others have pointed out that reference-counting GC's don't work with cyclical data structures (without special logic to handle those), so I won't repeat them.
One thing about ref-count GC's that's frequently overlooked is the performance impact. Consider that every time you manipulate a pointer (copy it, set it to null, etc.) you have to de-reference it and manipulate the object's refcount. Pointer copies are no longer register-to-register copies; they now involve going out to cache, main memory, or in the really pathological cases, swap space on disk.
Summary: ref-count GC's are a bad thing. There are lots of other GC algorithms which provide better results.
(Off-topic, but reason number 452 why linguists shouldn't be allowed to design programming languages without adult supervision: according to the camel book, Perl still uses a ref-count GC.)
Faith in technology? Misdirected.
on
Apocalypse Not
·
· Score: 1
Much more than their pundits or elected leaders, they put their faith in technology.
Faith in technology? Erm, no, not really. Try faith in humanity.
When you get right down to it, Y2K wasn't a technology issue. Granted, technology provided us the tools to create the situation. As a recent commentator on NPR pointed out, though, it was a human issue. Plain and simple. (Unfortunately, I don't recall the name of the commentator or his credentials, but he struck me as a person in a position to know well that of which he spoke. This is doubly unfortunate, as many of the points in the first list below are paraphrases of his editorial.)
Consider:
We decided to use 2 digits to represent dates, because
we thought the software wouldn't be around long enough for it to matter. This was probably the case, in part, because
we, or at least those in charge, kept (in some cases) outdated systems around far longer than intended or justified.
Many people either were unaware or simply ignored the problem until quite late.
Of course, many of us worked our butts off to fix the mistakes.
See? People. People caused the problem, and people fixed the problem.
My point? Well, it's a little nebulous, but I guess it's this: technology is great. It is not, however, a panacea. It is a tool, rather like the simple lever: it magnifies a little effort into large results. Of course, human error gets magnified as well. This is not sufficient to forswear technology and return to the Renaissance, or even the late Stone Age. (Don't you DARE take my Linux box away from me! ) However, I think we should be wary of those who do place faith in technology, rather than the humans who use it.
It's not going to die and is the *BEST* tool for writing programs. PERIOD. Linux is written in 'C'. Apache is written in 'C'. Gnome is written in 'C'. What more do you need?
Why, pray tell, do you feel that C is the best PL out there? And, while C's "resume," if you will, is impressive, how do these credits support your claim that it's the best language?
For that matter, how many other languages do you know? What's your basis for comparison?
Most of the preceeding arguments can be summed up like this: PERL is cool cuz it gots easy string handling.
True. But, as several posters have already remarked, CGI is mostly string handling. Use the right tool for the right job.
But *IF* you can handle the power, 'C' is for you!
Power? Where? Name three things that C can do that Perl can't. Perhaps more interestingly, try vice versa. Or, name three things that language X can do that C can't. Here's one for X = Scheme:
True lexical scope: nested functions, with all of the scoping rules that applies
First-class functions: treat functions just like ints: data to be operated on. Create new ones at runtime, pass them to other functions, etc.
first-class control flow: like Java's exception handling, but more powerful.
Don't get me wrong, I'm not claiming that everybody should immediately start using Scheme for CGI scripts. It's merely the language, besides C, with which I'm most familiar.
C generates fast code, true, but that's only because the language is already very very close to assembly. This, I suspect, is another reason people use Perl. The limiting factors tend to be server forking and slow transfer speeds. Given that situation, it's not unreasonable to use a high-level language. (Oh, and despite what a lot of people claim, C is not a high-level language. Neither is C++.)
HLLs allow the programmer to be efficient, perhaps at the expense of the computer. Subject to the situation's constraints, which would you prefer? Here's a clue: you don't pay the computer for its time!
At Rice University (my alma mater), the big servers are named after varieties of owl, the school mascot: great-grey, flammulated, horned, barn, snowy, great-horned, etc. The smaller machines (if an Ultra 5 can be considered small) located around campus were, for reasons nobody really explained, named after fish: chub, garibaldi, etc. -- a great many names, too obscure to remember.
And then we put in the new teaching lab. In order around the room, from the door, the names were one, two, red, blue, black, old, new, little-star, little-car, and so forth.
Took us a while to figure out where those names came from. Then we realized they were fish too! Check out Dr. Seuss! (Yes, in the poem, white would come after black, but since there really *is* a whitefish, the name had already been claimed across campus.)
Once they put ethernet in the dorms, the students could choose their own names. Mine was minbar (still is, actually), and my upstairs neighbor's was z-ha-dum. Lots of possibilities there.
I don't CARE what the difference is between 10W30 and 10W40 motor oil is. I don't care what my "CV joint" is. I don't have to know the difference between shocks and struts to drive my car. I never want to have to do more than put gas and windshield wiper fluid in my car in order to drive it. When I use my car, I want to get in, turn the key and go somewhere.
That's fine, and I respect that. I feel much the same way about my car, really. But I recognize that there are a number of people (who aren't mechanics) out there who don't. They want to know about CV joints, and the relative merits of the various viscosities of motor oils, and the differences between shocks and struts. These people generally get called `hobbyists.' They like the freedom of being able to work on, control, and repair their cars themselves. I bet they also like not having to be dependent on the local mechanics, who may happen to be incredibly sleazy and overcharge their customers for everything. (Disclaimer: yes, I know, there are honest mechanics out there; the above sleazeballs should not be interpreted as representative of the field.) I bet they'd go nuts if the car companies started welding their hoods shut so that only a "certified mechanic" could inspect, change, or repair the engine or other components.
With respect to computers, I'm a hobbyist, and I hate it when someone tries to take control from me. I'm willing to invest a fair amount of effort into learning how the system works and so forth in order to gain and exercise this control. That's why I run Linux. I realize, however, that there are those out there who don't want this much control.
I'd like to see the industry support both kinds of users: the hobbyists who want the control and are willing to invest the time learning how to use it, and the more casual users who just want to type a letter to Mom and balance their checkbook, without worrying about recompiling the kernel or fighting with ghostscript to get their printer to work or digging through startup scripts to find out why fvwm2 simply refuses to start on RH6 given their setup. The user should be allowed to choose which attitude they take, not be forced by some monopoly into one attitude or the other. There is a place in this industry for Microsoft (or, well, there would be if their software actually worked well and if they weren't determined to drive everyone else out of business).
The real problem, I think, is that we don't know how to design an interface which makes the common operations easy but does not obstruct the more common operations. This is, I believe, an active research area in computer science departments around the country, with some input from psychology departments.
Until we develop such an interface, though, we should continue to provide both alternatives. Actually, we should provide a whole range of alternatives, from (say) Debian at the lots-of-control-but-lots-of-learning extreme, through RedHat, Caldera, and so forth, on to Microsoft at the other end (well, kind of). Given the way most people react to computers (at least for now), this means that the Debians of the world will have, at best, a niche market, but I believe that they do have a market, and I hope that they continue to fill that need.
Occam's Razor (or Ockham's, or...). If there are multiple explanations which fit observed reality, choose the one which requires the least complicated theory. (Until, of course, it no longer explains reality.)
Another razor, which I have seen attributed to several people: "Never attribute to malice that which can adequately be explained by stupidity."
Re:X, windows and things like Berlin.
on
Fifteen Years of X
·
· Score: 1
This post should not be taken as gospel, because I'm not an X programmer. I believe, however, that I have a fairly good idea of what's going on, at a high level.
Yes, the X server is essentially a layer between the hardware (video, keyboard, mouse) and the clients. The clients include traditional window managers (twm, fvwm, etc), desktops like GNOME/KDE, and applications like Netscape, Emacs, or CivCTP.
Would it be faster without the layer in the middle? Probably. Why do we have it, then? A variety of reasons:
Remote displays: at work, I routinely fire up applications on my Ultra5 (Solaris 2.6) and have them display their windows on my Linux machine. Windows & Mac can't do this, although I understand there are after-market packages which allow this sort of thing on a Win32 platform. I don't think they work very well, though.
Hardware independence. Allowing the app to go straight to the hardware is much faster, but you have to recompile the app for every video card and every mouse. Most windowing systems do this.
Separating the policy from the mechanism. This is a fairly common idea in computer science. Here, the mechanism is the network independence stuff and the low-level graphics calls, and the policy is the actual look and feel of the client. This does result in a speed slowdown, to be sure, but I'll take the flexibility, thanks. A concrete example: Windows doesn't have this distinction between mechanism and policy, so if I decide that I don't like the way the title-bar buttons work, I'm SOL: I can't add a "maximize vertical" button, for instance. With X, if you're not happy with the features provided by the default window manager (which used to be twm, once upon a time!), you're free to use something else. (Presumably, this something else would be a window manager/environment like fvwm2 that allowed a "maximize vertical" button, if that's what you want.)
Perhaps another way of looking at it: the X requests serve roughly the same role as the core functions in the Win32 graphics API (for instance). The difference with X is that they're not (I believe) in a library, they're in a separate process, accessed by network-like communications. (This allows that network independence bit.)
Nah. This is what tipped me off, although the disclaimer at the bottom helped. I'm a (beginning) student of Classical Greek and Classical Sanskrit. The Greek alphabet is related to the Roman alphabet, but the Sanskrit writing system is nowhere close. (In fact, it's not strictly an alphabet!) I've done a fair amount of writing in both languages for a year and a half now, and I've developed no trouble writing in English.
Slashdot Mirror
``Code is for compilers, text is for people''?
No.
A natural language like English is, of course, the preferred means of communication for informal discourse. Natural languages, however, are often too ambiguous and verbose to function well when expressing precise algorithms.
Those of you who are programmers, you tell me: which is easier to understand, the DeCSS code in C, or the same code in haiku? (I think you can find the latter off Dr. Felten's homepage at Princeton.) Which is easier to work with?
Taken at its face value and out of context, the court's statement is going to be somewhat ridiculous, yes. However, that does not change the fact that programming languages are as useful for communicating algorithms between people as they are for communicating algorithms from a person to a computer.
Whoa---there's a blast from the past.
LDA #$07
JSR $FDED
(Although I think you'd likely need a trailing invalid opcode or something to return control back to the system monitor.)
Cut my teeth on the Apple II series. I still remember that system fondly, even with all of its little quirks. (Remember how ``hi-res'' graphics were stored in memory? Backwards?)
(For those of you who want to try this out, get one of the free Apple emulators off the net, then type `call -151' at the BASIC prompt, then type in the hex numbers and command given upthread.)
OK, pet peeve of mine. The correct plural form of "virus" is either "viruses" or "vira," NOT "virii."
Latin words ending in -us will frequently, though not always, form a plural by replacing the -us with -i, so I can understand why people might think the plural is "viri." The form "virii" has no basis in any sort of Latin; the corresponding singular would be "virius."
However, the Lewis & Short Latin Dictionary online at the Perseus Project, as well as my hardbound dictionary at home, indicates that this word is a little irregular:
Since it's second-declension neuter, the plural is "vira."We now return you to your regularly-scheduled Slashdot discussions....
As I understand it, it's a lot older than that. Many of the old LISP machines, I believe, used to have built-in GC. I don't know if it was in hardware or the OS, but it's the same basic idea.
What many people forget is that a GC is not entirely for finding and removing memory leaks. They also have the really nice property of preventing subtle aliasing bugs.
// AAAK!
int *i, *j;
i = new int;
j = i;
delete i;
printf("%d\n", *j);
Not an issue with a GC.
But if you have a GC, then this ``nasty situation'' isn't possible. By definition. If it happens, complain to your GC implementor.
I'm sending a response to this post to emin in private mail, as it's fairly lengthy. If others are interested, drop me a line and I'll send you a copy as well.
Well, more or less. As part of a programming languages class I took in school, I actually had to write a garbage collector for a Scheme-like language. While one could implement references in a Java/Scheme/LISP-like language in the above fashion, that's really slow; it adds another layer of indirection that isn't really necessary. If the run-time system provides information about the types of objects in memory (which is required for Java and Scheme anyway -- instanceof and symbol?), then the GC can reach in and directly change the pointer values within the program's stack or whatever.
From the point of view of the applications programmer, though, the two implementations are equivalent.
As far as I'm concerned, the primary difference between pointers and references is that with a reference to an object of type Foo, you are guaranteed that the object referred to is a valid instance of type Foo. This is not the case with pointers. In C/C++ terms, int i; float *pF; pF = (float *)(&i); The object at *pF is not a valid instance of a float.
(Yes, you can in fact break this guarantee in C++ using a series of really crufty typecasts. C++'s references are broken, in a number of respects.)
Of course, as MassacrE points out, references are almost always implemented internally in terms of pointers, because that's what the underlying architecture tends to support.
Others have pointed out that reference-counting GC's don't work with cyclical data structures (without special logic to handle those), so I won't repeat them.
One thing about ref-count GC's that's frequently overlooked is the performance impact. Consider that every time you manipulate a pointer (copy it, set it to null, etc.) you have to de-reference it and manipulate the object's refcount. Pointer copies are no longer register-to-register copies; they now involve going out to cache, main memory, or in the really pathological cases, swap space on disk.
Summary: ref-count GC's are a bad thing. There are lots of other GC algorithms which provide better results.
(Off-topic, but reason number 452 why linguists shouldn't be allowed to design programming languages without adult supervision: according to the camel book, Perl still uses a ref-count GC.)
Faith in technology? Erm, no, not really. Try faith in humanity.
When you get right down to it, Y2K wasn't a technology issue. Granted, technology provided us the tools to create the situation. As a recent commentator on NPR pointed out, though, it was a human issue. Plain and simple. (Unfortunately, I don't recall the name of the commentator or his credentials, but he struck me as a person in a position to know well that of which he spoke. This is doubly unfortunate, as many of the points in the first list below are paraphrases of his editorial.)
Consider:
Of course, many of us worked our butts off to fix the mistakes.
See? People. People caused the problem, and people fixed the problem.
My point? Well, it's a little nebulous, but I guess it's this: technology is great. It is not, however, a panacea. It is a tool, rather like the simple lever: it magnifies a little effort into large results. Of course, human error gets magnified as well. This is not sufficient to forswear technology and return to the Renaissance, or even the late Stone Age. (Don't you DARE take my Linux box away from me! ) However, I think we should be wary of those who do place faith in technology, rather than the humans who use it.
Why, pray tell, do you feel that C is the best PL out there? And, while C's "resume," if you will, is impressive, how do these credits support your claim that it's the best language?
For that matter, how many other languages do you know? What's your basis for comparison?
Most of the preceeding arguments can be summed up like this: PERL is cool cuz it gots easy string handling.
True. But, as several posters have already remarked, CGI is mostly string handling. Use the right tool for the right job.
But *IF* you can handle the power, 'C' is for you!
Power? Where? Name three things that C can do that Perl can't. Perhaps more interestingly, try vice versa. Or, name three things that language X can do that C can't. Here's one for X = Scheme:
Don't get me wrong, I'm not claiming that everybody should immediately start using Scheme for CGI scripts. It's merely the language, besides C, with which I'm most familiar.
C generates fast code, true, but that's only because the language is already very very close to assembly. This, I suspect, is another reason people use Perl. The limiting factors tend to be server forking and slow transfer speeds. Given that situation, it's not unreasonable to use a high-level language. (Oh, and despite what a lot of people claim, C is not a high-level language. Neither is C++.)
HLLs allow the programmer to be efficient, perhaps at the expense of the computer. Subject to the situation's constraints, which would you prefer? Here's a clue: you don't pay the computer for its time!
And then we put in the new teaching lab. In order around the room, from the door, the names were one, two, red, blue, black, old, new, little-star, little-car, and so forth.
Took us a while to figure out where those names came from. Then we realized they were fish too! Check out Dr. Seuss! (Yes, in the poem, white would come after black, but since there really *is* a whitefish, the name had already been claimed across campus.)
Once they put ethernet in the dorms, the students could choose their own names. Mine was minbar (still is, actually), and my upstairs neighbor's was z-ha-dum. Lots of possibilities there.
That's fine, and I respect that. I feel much the same way about my car, really. But I recognize that there are a number of people (who aren't mechanics) out there who don't. They want to know about CV joints, and the relative merits of the various viscosities of motor oils, and the differences between shocks and struts. These people generally get called `hobbyists.' They like the freedom of being able to work on, control, and repair their cars themselves. I bet they also like not having to be dependent on the local mechanics, who may happen to be incredibly sleazy and overcharge their customers for everything. (Disclaimer: yes, I know, there are honest mechanics out there; the above sleazeballs should not be interpreted as representative of the field.) I bet they'd go nuts if the car companies started welding their hoods shut so that only a "certified mechanic" could inspect, change, or repair the engine or other components.
With respect to computers, I'm a hobbyist, and I hate it when someone tries to take control from me. I'm willing to invest a fair amount of effort into learning how the system works and so forth in order to gain and exercise this control. That's why I run Linux. I realize, however, that there are those out there who don't want this much control.
I'd like to see the industry support both kinds of users: the hobbyists who want the control and are willing to invest the time learning how to use it, and the more casual users who just want to type a letter to Mom and balance their checkbook, without worrying about recompiling the kernel or fighting with ghostscript to get their printer to work or digging through startup scripts to find out why fvwm2 simply refuses to start on RH6 given their setup. The user should be allowed to choose which attitude they take, not be forced by some monopoly into one attitude or the other. There is a place in this industry for Microsoft (or, well, there would be if their software actually worked well and if they weren't determined to drive everyone else out of business).
The real problem, I think, is that we don't know how to design an interface which makes the common operations easy but does not obstruct the more common operations. This is, I believe, an active research area in computer science departments around the country, with some input from psychology departments.
Until we develop such an interface, though, we should continue to provide both alternatives. Actually, we should provide a whole range of alternatives, from (say) Debian at the lots-of-control-but-lots-of-learning extreme, through RedHat, Caldera, and so forth, on to Microsoft at the other end (well, kind of). Given the way most people react to computers (at least for now), this means that the Debians of the world will have, at best, a niche market, but I believe that they do have a market, and I hope that they continue to fill that need.
Yes, the X server is essentially a layer between the hardware (video, keyboard, mouse) and the clients. The clients include traditional window managers (twm, fvwm, etc), desktops like GNOME/KDE, and applications like Netscape, Emacs, or CivCTP.
Would it be faster without the layer in the middle? Probably. Why do we have it, then? A variety of reasons:
Perhaps another way of looking at it: the X requests serve roughly the same role as the core functions in the Win32 graphics API (for instance). The difference with X is that they're not (I believe) in a library, they're in a separate process, accessed by network-like communications. (This allows that network independence bit.)
HTH!
Nah. This is what tipped me off, although the disclaimer at the bottom helped. I'm a (beginning) student of Classical Greek and Classical Sanskrit. The Greek alphabet is related to the Roman alphabet, but the Sanskrit writing system is nowhere close. (In fact, it's not strictly an alphabet!) I've done a fair amount of writing in both languages for a year and a half now, and I've developed no trouble writing in English.