Of course, it does end up slowing typing down because frequently used keys are where you need them.
I wonder is that's true. Breaking up common sequences so the characters were as far apart as possible would (probably) make it easier to alternate between hands (for those sequences), which should speed up typing. I expect it would have ergonomic advantages as well.
My point was that _if_ you are programming in a statically typed OO language then the problem of two objects with the same interface but not sharing a base class is unlikely to happen.
Mostly, I think, because the language prevents you from doing it easily. You're no more likely have a common base just in virtue of the static typing, but since that's the only practical way to do things in a static language, you don't have much choice. I don't have a problem with that (it's not a huge burden, and it's often worth it), but it's not a very convincing reason to try static typing if you're used to the alternative (just as informal protocols probably aren't very convincing reason to use pure dynamic typing if you're used to static languages).
I don't think the example of 'two objects in two hierarchies that understand a common set of messages' is particularly likely to happen in practice
My impression is that such things are fairly common in more dynamic OO languages, such as Smalltalk. The various collection classes are probably good candidates for that strategy, since they share little or no code but benefit from having a common protocol.
because in a statically typed OO language these objects would be written to have a common base class.
Right, but that sort of thing doesn't make as much sense in a language like Smalltalk or Lisp, precisely because they aren't statically typed. You probably aren't going to be able to verify at compile time that the children actually implement the interface defined by the base class, so unless the base contributes some code there isn't much benefit to having it. Inheritance in those languages is basically synonymous with implementation inheritance, and separate interface inheritance may be non-existent.
True, but irrelevant. A prefix syntax is one in which the operator precedes the operands. Smalltalk, like most OO languages, places the first operand, the subject of the method call, before the operator, and the remainder of the operands after, making it infix.
Compare that to a LISP version, say
Common Lisp's method call syntax is identical to the function call syntax, roughly (method arg0 arg1... argn). Not at all like Smalltalk. The only alternative syntaxes I've seen used for Lisp are (send object args...), which is still quite different, and [object args...] which was an exercise is macrology just to prove that Lisp was flexible enough to support Smalltalk's syntax.
To be fair, though, it's true that there is some infix syntactic sugar in SmallTalk: for example
a + b.
is an alias of
a add: b.
I fail to see why 'a add: b' is less infix than 'a + b'.
What really is the difference between strong and weak typing?
Strong typing means that typing is enforced: you can't apply operations to instances of types for which those operations are undefined. Weak typing is a lack of strong typing. It doesn't necessarily mean that there is no type checking at all, just that it's incomplete. C compilers, for example, generally do a fair amount of type checking, but it easy to bypass it using, e.g., void * and casts.
Sometimes, it really is easier to treat the first one as a prototype of what you'd really like, and then write that second one correctly, from scratch. Witness Mac Classic -> Mac OSX
I can't imagine how MacOS Classic could be considered a prototype for OS X (read 'NEXTSTEP').
Win9x -> WinNT
WinNT is older than Win95.
Perl5 -> Perl6
I thought you said the second try was supposed to get it right;-)
Mac Classic, Win9x/DOS, and Perl5 are all too inflexible for future use
MacOS I can see, and maybe DOS (it's amazing how much mileage people get out of that system), but Perl5? If Perl has ever had a problem, it's being too flexible in too many ways.
Their successors, however, are all designed with future expandability in mind, so that the "second system curse" can hopefully be avoided.
Of course that sort of expendability and flexibility may well be a second system effect itself.
Planning for future is a good idea, but in practice you can't do it beyond certain bounds -- something totally unanticipated is going to come along and screw everything up sooner (I would say 'or later', but it never is). What you can do is shoot yourself in the foot trying too hard to accommodate every possibility. Better, I think, to accept that you'll have to throw away every design eventually, and plan accordingly.
Between these three I saw about a 50% increase in downstream bandwidth (550kb/s to 800kb/s), but also a 65% decrease in upstream bandwidth (350kb/s to 100kb/s). This could be an unrelated ISP burp, or something unique to FreeBSD, but it is kinda weird and possible something to watch out for. tcp.recvsize is already 65536 on FreeBSD, so I didn't change it, but upping it might solve the problem.
net.inet.tcp.delayed_ack=0
This actually knocked me back to 600kb/s for some reason.
Actually, the values returned by main() are not laid out by the C specification. There is an arbitrary practice among many programmers that calls for the use of a return value of zero to indicate successful execution, but it is by no means mandatory.
Quoth ISO 9899:1999, section 7.20.4.3, paragraph 5, describing the behavior of exit() (other methods of returning from main() are defined in terms of exit()):
Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.
IOW, the standard defines 0 as signaling successful termination.
Use the maximize button to the right of the address bar (middle of the three). Not real intuitive since it can't restore fullscreen, but it seems to work.
For instance, whose idea was it to put color syntax highlighting in the help menu, and who decided to call it Global Font Lock?
Which version of Emacs are you using? GNU Emacs 21 has it as the first choice under the Options menu, listed as "Syntax Highlighting (Global Font Lock mode)". Or am I misunderstanding you?
Every cable system I've watched CN on in Oregon and Washington has been on the West Coast schedule. DirecTV does indeed use the East Coast feed here, and I generally watch that, then catch anything I miss on the local broadcast.
I just noticed that the Toonami schedule lists everything as, e.g., "5.0 PM [e/p]", which implies that they expect seperate feeds.
Well, MULTICS was the only OS to ever get an orange book A1 security rating.
No OS has recieved an A1 rating. Multics MR11.0 was rated at B2, an honor it shares with Trusted XENIX. Wang currently has several systems at B3, which, AFAICT, are the most secure general-purpose OSes yet evalutated. The only A1 rated products of any sort are a couple network devices and something else from Wang.
CISC (x86) , and RISC (PPC, Sparc) processors are two totally different beasts.
Which doesn't mean you can't compare them. The Veyron and your typical dump truck are very different, but you can still judge which is faster and which carries a heavier load. More important is the relationship between those results and your needs.
If you've noticed though, all RISC processors are behind CISC processors in terms of Mhz, I'm not sure exactly why, most likely pipeline issues or the like.
Or because those CISC processors are more RISCy than many people believe. Until recently the paragon of the 'more performance through clock speed' philosophy was (in my mind) the Alpha, and I've always considered it much more of a RISC philosophy. I'm more inclined to believe that Intel has a very successful RISC chip buried under a few miles mud than that they suddenly discovered that CISC could be beat RISC at it's own game. (Actually, I'm mostly inspired to say 'stop pretending "CISC" and "RISC" are really meaningful'.)
You can check out Multicians.org if you're curious about Multics. It began as a research project in '65 between MIT, GE, and Bell Labs, and was continued as a commercial product when GE sold it off to Honeywell in '70. It was actively developed till the 80's, and finally vanished in 2000, but is still quite influencial, of course (mostly by way of Unix).
1.) It's largely based on BSD. Despite what lawsuits say, BSD IS UNIX, and always has been.
The Open Group disagrees, and since they hold the trademark I tend to go with their opinions. For example, in their FAQ is a question regarding BSD/OS:
BSDI is an independent company that markets products derived from the Berkeley Systems Distribution (BSD), developed at the University of California at Berkeley in the 60's and 70's. It is the operating system of choice for many Internet service providers. It is, as with Linux, not a registered UNIX system, though in this case there is a common code heritage if one looks far enough back in history.
You can argue that it's "Unix", or "*nix", or whatever, but no BSD is UNIX. They could be, of course, if they were willing to foot the bill for certification, but apparently no one has.
2.) Apple's OS X got the UNIX (R) "certification a long time ago [slashdot.org] [slashdot.org]. So both technically and legally, OS X is UNIX.
I participated in that thread back on OSOpinion, before it was posted on/., and I don't recall anyone actually showing that OS X had been certified (actually, no one did on/. did either, if you read the thread). Apple islisted as a "Platform Vendor[] Supporting the Single UNIX Specification", but there is no mention of what OS that refers to, if in fact it has anything to do with UNIX licensing (I just scanned that section of the linked document, and it appears to be a list of vendors supporting that standard itself, rather than a platform that complies with the standard). There are no Apple OSes listed as certified UNIX systems under UNIX 98, 95, or 93, which seems to exclude both OS X and A/UX (which I had previously thought to be the best explanation for Apple involvement with the Single UNIX Spec).
It's true that Apple clearly implies that OS X is UNIX (I don't know if they say so outright or just stick to "UNIX-based"), but it appears that they're referring only to the kernel (not that they'll make that clear if they can help it). One the OS X pages states
The Mach 3.0 kernel in Darwin gives Mac OS X its robust UNIX base.
(at the bottom, under "Core OS"). This is, AFAIK, legitimate, since Mach 3.0 was the kernel developer for OSF/1, which was presumably UNIX, but I do think they're pushing the line quite hard in some places.
Slashdot Mirror
FVWM has supported gestures through LibStoke (apparently what wayV uses as well) for quite some time.
Symbolics keyboard, the commercialized space cadet.
Of course, it does end up slowing typing down because frequently used keys are where you need them.
I wonder is that's true. Breaking up common sequences so the characters were as far apart as possible would (probably) make it easier to alternate between hands (for those sequences), which should speed up typing. I expect it would have ergonomic advantages as well.
My point was that _if_ you are programming in a statically typed OO language then the problem of two objects with the same interface but not sharing a base class is unlikely to happen.
Mostly, I think, because the language prevents you from doing it easily. You're no more likely have a common base just in virtue of the static typing, but since that's the only practical way to do things in a static language, you don't have much choice. I don't have a problem with that (it's not a huge burden, and it's often worth it), but it's not a very convincing reason to try static typing if you're used to the alternative (just as informal protocols probably aren't very convincing reason to use pure dynamic typing if you're used to static languages).
I don't think the example of 'two objects in two hierarchies that understand a common set of messages' is particularly likely to happen in practice
My impression is that such things are fairly common in more dynamic OO languages, such as Smalltalk. The various collection classes are probably good candidates for that strategy, since they share little or no code but benefit from having a common protocol.
because in a statically typed OO language these objects would be written to have a common base class.
Right, but that sort of thing doesn't make as much sense in a language like Smalltalk or Lisp, precisely because they aren't statically typed. You probably aren't going to be able to verify at compile time that the children actually implement the interface defined by the base class, so unless the base contributes some code there isn't much benefit to having it. Inheritance in those languages is basically synonymous with implementation inheritance, and separate interface inheritance may be non-existent.
Not to be difficult or anything, but: wrong.
.
... argn). Not at all like Smalltalk. The only alternative syntaxes I've seen used for Lisp are (send object args...), which is still quite different, and [object args...] which was an exercise is macrology just to prove that Lisp was flexible enough to support Smalltalk's syntax.
.
.
anObject getsMessage: withArgument andAnother
is parsed purely left to right --
True, but irrelevant. A prefix syntax is one in which the operator precedes the operands. Smalltalk, like most OO languages, places the first operand, the subject of the method call, before the operator, and the remainder of the operands after, making it infix.
Compare that to a LISP version, say
Common Lisp's method call syntax is identical to the function call syntax, roughly (method arg0 arg1
To be fair, though, it's true that there is some infix syntactic sugar in SmallTalk: for example
a + b
is an alias of
a add: b
I fail to see why 'a add: b' is less infix than 'a + b'.
What really is the difference between strong and weak typing?
Strong typing means that typing is enforced: you can't apply operations to instances of types for which those operations are undefined. Weak typing is a lack of strong typing. It doesn't necessarily mean that there is no type checking at all, just that it's incomplete. C compilers, for example, generally do a fair amount of type checking, but it easy to bypass it using, e.g., void * and casts.
From CMUCL:
* (defun foo (x)
(declare (integer x))
(+ x 1))
FOO
* (compile 'foo)
Compiling LAMBDA (X):
Compiling Top-Level Form:
FOO
NIL
NIL
* (defun bar (x)
(declare (string x))
(foo x))
BAR
* (compile 'bar)
Compiling LAMBDA (X):
In: LAMBDA (X)
(FOO X)
==>
X
Warning: Result is a BASE-STRING, not a (VALUES &OPTIONAL INTEGER &REST T).
Compiling Top-Level Form:
Compilation unit finished.
1 warning
BAR
T
T
;;;; End
Not tremendously informative diagnostics if you don't know what you're looking for, but the type-checking is done.
Smalltalk, which is a pure prefix language like Lisp
Definitely not. If Smalltalk's syntax pure anything, it's infix.
Sometimes, it really is easier to treat the first one as a prototype of what you'd really like, and then write that second one correctly, from scratch. Witness Mac Classic -> Mac OSX
;-)
I can't imagine how MacOS Classic could be considered a prototype for OS X (read 'NEXTSTEP').
Win9x -> WinNT
WinNT is older than Win95.
Perl5 -> Perl6
I thought you said the second try was supposed to get it right
Mac Classic, Win9x/DOS, and Perl5 are all too inflexible for future use
MacOS I can see, and maybe DOS (it's amazing how much mileage people get out of that system), but Perl5? If Perl has ever had a problem, it's being too flexible in too many ways.
Their successors, however, are all designed with future expandability in mind, so that the "second system curse" can hopefully be avoided.
Of course that sort of expendability and flexibility may well be a second system effect itself.
Planning for future is a good idea, but in practice you can't do it beyond certain bounds -- something totally unanticipated is going to come along and screw everything up sooner (I would say 'or later', but it never is). What you can do is shoot yourself in the foot trying too hard to accommodate every possibility. Better, I think, to accept that you'll have to throw away every design eventually, and plan accordingly.
I did the usual net research, but discovered that data types like integer didn't have standardized sizes. [...] and C is for everything else.
C is far worse about unspecified integer ranges than Ada.
on which platforms do stacks NOT already grow downward?
Multics, according to a paper I have lying around here somewhere.
Being pedantic and all, that should actually be
#include <limits.h>
#include <stdio.h>
int
main(void)
{
printf("My computer is %zd bits\n", sizeof(void*) * CHAR_BIT);
return 0;
}
since there's no guaranty that you're machine will have 8-bit bytes.
Can't wait to see C# go the same path...
You mean like Mono and DotGNU?
And what would the list look like if Athlon XPs/MPs were added to the list?
The same. The Athlon trails the P4 on SPEC by a fair bit. It's in the high 700's or thereabouts, IIMN (SPEC.org if you're interested -- I'm not).
Well, I had to try this on my FreeBSD box.
s pace=73728
net.inet.tcp.sendspace=65536
net.inet.udp.recv
kern.ipc.maxsockbuf=524288
Between these three I saw about a 50% increase in downstream bandwidth (550kb/s to 800kb/s), but also a 65% decrease in upstream bandwidth (350kb/s to 100kb/s). This could be an unrelated ISP burp, or something unique to FreeBSD, but it is kinda weird and possible something to watch out for. tcp.recvsize is already 65536 on FreeBSD, so I didn't change it, but upping it might solve the problem.
net.inet.tcp.delayed_ack=0
This actually knocked me back to 600kb/s for some reason.
Quoth ISO 9899:1999, section 7.20.4.3, paragraph 5, describing the behavior of exit() (other methods of returning from main() are defined in terms of exit()):
IOW, the standard defines 0 as signaling successful termination.
Use the maximize button to the right of the address bar (middle of the three). Not real intuitive since it can't restore fullscreen, but it seems to work.
For instance, whose idea was it to put color syntax highlighting in the help menu, and who decided to call it Global Font Lock?
Which version of Emacs are you using? GNU Emacs 21 has it as the first choice under the Options menu, listed as "Syntax Highlighting (Global Font Lock mode)". Or am I misunderstanding you?
Every cable system I've watched CN on in Oregon and Washington has been on the West Coast schedule. DirecTV does indeed use the East Coast feed here, and I generally watch that, then catch anything I miss on the local broadcast.
I just noticed that the Toonami schedule lists everything as, e.g., "5.0 PM [e/p]", which implies that they expect seperate feeds.
It was updated in 1995, becoming the first standardized Object Oriented langugage
Nope: Common Lisp became a standard on December 8th, 1994.
No OS has recieved an A1 rating. Multics MR11.0 was rated at B2, an honor it shares with Trusted XENIX. Wang currently has several systems at B3, which, AFAICT, are the most secure general-purpose OSes yet evalutated. The only A1 rated products of any sort are a couple network devices and something else from Wang.
Which doesn't mean you can't compare them. The Veyron and your typical dump truck are very different, but you can still judge which is faster and which carries a heavier load. More important is the relationship between those results and your needs.
If you've noticed though, all RISC processors are behind CISC processors in terms of Mhz, I'm not sure exactly why, most likely pipeline issues or the like.
Or because those CISC processors are more RISCy than many people believe. Until recently the paragon of the 'more performance through clock speed' philosophy was (in my mind) the Alpha, and I've always considered it much more of a RISC philosophy. I'm more inclined to believe that Intel has a very successful RISC chip buried under a few miles mud than that they suddenly discovered that CISC could be beat RISC at it's own game. (Actually, I'm mostly inspired to say 'stop pretending "CISC" and "RISC" are really meaningful'.)
You can check out Multicians.org if you're curious about Multics. It began as a research project in '65 between MIT, GE, and Bell Labs, and was continued as a commercial product when GE sold it off to Honeywell in '70. It was actively developed till the 80's, and finally vanished in 2000, but is still quite influencial, of course (mostly by way of Unix).
1.) It's largely based on BSD. Despite what lawsuits say, BSD IS UNIX, and always has been.
The Open Group disagrees, and since they hold the trademark I tend to go with their opinions. For example, in their FAQ is a question regarding BSD/OS:
You can argue that it's "Unix", or "*nix", or whatever, but no BSD is UNIX. They could be, of course, if they were willing to foot the bill for certification, but apparently no one has.
2.) Apple's OS X got the UNIX (R) "certification a long time ago [slashdot.org] [slashdot.org]. So both technically and legally, OS X is UNIX.
I participated in that thread back on OSOpinion, before it was posted on /., and I don't recall anyone actually showing that OS X had been certified (actually, no one did on /. did either, if you read the thread). Apple is listed as a "Platform Vendor[] Supporting the Single UNIX Specification", but there is no mention of what OS that refers to, if in fact it has anything to do with UNIX licensing (I just scanned that section of the linked document, and it appears to be a list of vendors supporting that standard itself, rather than a platform that complies with the standard). There are no Apple OSes listed as certified UNIX systems under UNIX 98, 95, or 93, which seems to exclude both OS X and A/UX (which I had previously thought to be the best explanation for Apple involvement with the Single UNIX Spec).
It's true that Apple clearly implies that OS X is UNIX (I don't know if they say so outright or just stick to "UNIX-based"), but it appears that they're referring only to the kernel (not that they'll make that clear if they can help it). One the OS X pages states
(at the bottom, under "Core OS"). This is, AFAIK, legitimate, since Mach 3.0 was the kernel developer for OSF/1, which was presumably UNIX, but I do think they're pushing the line quite hard in some places.