I'm not even going to attempt to argue the point any more. If you're actively opposed to the social contract, I refuse to recognize you as part of legitimate human society. Goodbye.
It would be very unbecoming of me to expect anybody to guarantee anything to me...without a signed contract anyway. By the same token, I offer none.
In a perfect world, that would work. The sad truth is that the majority of the world disagrees with you, and would get justifiably angry if you don't offer certain guarantees to others without signed contracts. In fact, if you live in a country that's a signatory to the Berne Convention, you are bound by international laws to offer guarantees to others without signed contracts.
The point of the Free Software Movement is to use further legalese to cancel the effects of copyright, restoring things to the way they should be. The debates between the various licenses are merely worries over what's the most effective way to accomplish this goal.
Licenses are for lawyers. Not for regular people, or computers. A simple "created by..." is good enough.
They're also for coders. A lot of coders will refuse to code if the result is going to be placed under an unfavorable license.
And for consumers. I think you like the guarantee that your software will be reasonably priced (probably free) and that if the original developers give up, someone else will maintain the software so your documents don't bitrot when you move to a different computer architecture, etc.
Nobody can take the code away.
Um, didn't you read about the recent Google pinyin fiasco, where they did take the code away?
Perhaps, but the common idiom is "sneaking suspicion", not "sneaky suspicion". Google lists many times more uses of the former, as well as actual definitions of the phrase.
"Trickle down" doesn't exist. It's bullshit made up by an actor who played President to justify to poor people why he was handing rich people and corporations tax cuts.
I might believe you if you had some argument against it other than a mere ad hominem - and a weak one, at that. "Trickle-down economics" is merely one way of viewing laissez-faire economics. And, uh, laissez-faire exists. (It's up to debate how well it works, but it does have some positive effects, and it certainly "exist"s.)
Also, while we're on the subject of irrelevant arguments, "irregardless" is not a word.
Really? How many viruses can be transmitted through simply mounting a drive?
Windows will run arbitrary code upon mounting a removable device. I think with some effort and luck, you could convince an OS X or Linux user to run code from the drive unwittingly.
More importantly, a little rectangle with a USB port doesn't have to present itself as a removable disk. It can present itself as, say, an input device, and then type arbitrary strings into the user's computer. I believe it can present itself as a video output device without difficulty, in which case it can be used to spy on the computer. It can probably present itself as a network device and engage in some MitM attacks that way. It can attempt to just exploit a buffer overflow or something in the OS's USB drivers.
Actively malicious peripherals are a serious security problem.
I always give my girlfriend shit when something bad happens on her mac, I say, "That doesn't happen on PCs." And now her 6-month old Powerbook is slowly crapping out, and as it dies, I will be vindicated. Ahhhh, sweet vindication.
How can you possibly love your platform more than your girlfriend? Even if my girlfriend were using a Commodore 64, I'd still support her choice of platform.
You can be a master of x86 assembly and still be considered somewhat of a newbie in a Java programming curriculum. But in case you already know Java, you will start ahead, and have a better chance at mastering the much more important higher-level, language-neutral concepts such as proper design, understanding of algorithms, data structures, etc.
Thanks to its JVM, you have enough layers of abstraction that what you're saying is probably right for Java. But if you're working in any language that compiles to native code, it's worth having a general understanding of how machine languages work, so you know why certain coding constructs are much more efficient than others, so you understand how and why pointer/array arithmetic works, so you understand exactly the difference between local, global, static, etc. variables, and so forth.
Just as much as one should always respect the abstraction barrier, one should try to know what's actually going on under it. Not only will it make you a better coder in your own software, but it'll help you understand exactly why the abstraction exposes a certain interface and exhibits certain characteristics.
If they don't track IP addresses, what's to stop the students from trying to break into, say, the registar office's servers to alter their grades?
Presumably UNL's network department can request logs much more quickly than the RIAA's legal department can. And if the logs are as a matter of policy destroyed if they're a few days old....
Penn State with draconian AUPs that require MAC addresses
And an MIT? Can you honestly tell me that MIT, in the People's Republic of Cambridge, home of the Free Software Movement, the Berkeley of the East Coast, has pro-RIAA network policies?
MIT maps usernames to MAC addresses. However, the RIAA doesn't (and can't) see MAC addresses, only IP addresses, and in the time between noticing activity and sending a subpoena, the temporary logs are long gone. The purpose of tracking MAC addresses at MIT -- and presumably at Penn State -- is to be able to identify a user with a misconfigured or malicious network port and contact him/her after terminating the connection. It is most certainly NOT to create easily-subpoenable IP-to-person logs.
Was single sign-on invented at MIT? Was instant messaging invented at MIT? Was the first modern windowing system - and, to date, the only network-aware windowing system - invented at MIT?
So yes, blame Java, if you're trying to teach memory allocation or algorithm design with it.
That's like saying "Blame the paint you can buy at Home Depot if you're trying to teach a person to paint a painting"
You can teach algorithm design with Java, what prevents you from doing so?
Exactly like you said. To teach someone painting, you teach them theory, not how to deal with the guy who sells you paint buckets and rollers. Once you know the theory you can start worrying about the tools.
So yes, you can use Java, and many colleges seem to do just fine with it, and many CS students start out with Java or a similar language - but it's much easier to teach with Scheme, which has far, far less syntax.
but you can make an emulator of your processor in Java
The professor for 6.004 has done exactly this; it's called JSim. We don't worry about how it's implemented, though, since the focus in that class is the processor itself. We do get to compilers/emulators in other classes, and did have a taste of it already (as the metacircular evaluator) in 6.001. So I'm not sure what your point is.
Our undergrads don't need to know what the difference between a spinlock and a semaphore is. Heck, our undergrads aren't even taught the differnece between C++ and C. Language-teaching comes up almost never. Our undergrads are computer scientists, not coders.
When they get a job that requires them to use one of the two, they'll be able to pick up the difference and choose the right tool, with far more accuracy and foresight than someone who merely learned it as a tool in class.
This is like complaining that half of MIT's linguistics grads can't explain the diference between Malayalam and Tamil. So what? I'd rather a linguist who can analyze for me the difference between any two closely related languages, as well as make sense of the extant literature, than a linguist who spent years studying the South Indian languages just because.
I think this seems a little redundant. I don't like EE and I'm not interested in it. I really don't care about how a computer works internally and I shouldn't really have to if my focus is on software engineering. Circuits don't directly affect me in my career one bit and I doubt many CS people think about them.
I didn't think I'd be interested in EE either, and I certainly will be going to advanced studies in CS, not EE, but you'd be surprised how quickly it does turn into essentially math and algorithmic design. Optimizing the Boolean logic for a processor and its ALU is much more math and CS than it is EE.
And please don't say that CS students are getting soft because of algorithm libraries - all languages have libraries to make things easier, not just Java.
They're only getting soft if they're taught "call library->standardfunction() and it'll do the magic for you". Once you can write the library if you wanted to, go ahead and use it.
This is a reply to all those "you and your fancy MIT" comments.
It doesn't matter whether it's MIT or not. It's only that MIT by being MIT has managed by and large to get their curriculum right, so it's a convenient...reference implementation for CS education, if you will. If you can get the same type of curriculum at a less "prestigious" university, and can come out with the same knowledge, more power to you. The end goal is the knowledge, not the stamp from a fancy university.
Now if your college wants to teach all their classes in C or Java, except for a couple of advanced study classes that happen after you've already been indoctrinated as a coder, then you should consider learning a thing or two from MIT.
I oppose this. MIT teaches Scheme, a LISP dialect, in its intro CS class. And the admissions requirements don't include knowledge of programming, and many non-EECS majors take the class. (Well, they're now offering a Python class simply as intro programming. But that's mainly for people who've never seen code before.)
Get yourself a copy of The Little Schemer, and read through it. It's a nicely different way of looking at CS and coding.
The normal course of action is to blame Java, since it has led to a simplistic approach to CS assignments.
You should blame Java. And you should blame C++, Python, and any other similar medium-high level language, if that's the intro language and your sole teaching language.
Here at MIT we have 4 intro courses. The first, the famous Structure and Interpretation of Computer Programs, is taught entirely in Scheme, a purer and more pedagogical dialect of Lisp. You learn how to do all the high-level algorithms (e.g., sorting) in a purely mathematical/logical fashion, since Scheme has automatic object creation / memory handling, no code-data distinction, etc. At the end of the class you work with a Scheme interpreter in Scheme (the metacircular evaluator), which, modulo lexing, teaches you how parsing and compiling programs works.
The next two are EE courses. The fourth starts EE and quickly moves to CS. You use a SPICE-like simulator to build gates directly from transistors. (You've done so in real life in previous classes.) Then you use the gate simulator to build up more interesting circuits, culminating in an entire, usable CPU. From gates. Which you built from transistors. The end result is, not only are you intimately famliar with assembly, you know exactly why assembly works the way it does and what sort of electrical signals are occurring inside your processor.
Once you know the highest of high-level languages and the math behind it, and the lowest of low-level languages and the electronics behind it, you're free to go ahead and use Java or whichever other language you like. (Indeed, the most time-consuming CS class is a regular OO Java software design project.) You're not going to get confused by either theory or implementation at this point.
So yes, blame Java, if you're trying to teach memory allocation or algorithm design with it.
I wrote it about 15 seconds before falling sound asleep.
DbC is nothing more than extending strong typing
Precisely. If my function can be written as
uppercase_char[4] foo(int(0...10) x) {...}
I'd use it. If I can define my function as
char[4]:isUpper foo(int x:(lambda (x) (0
then I might consider it. If I have to write my function as
string foo(int x) {
assert(0
then there's no way I'm using it. I already have my language do the strong type checking for me. I'm not going to implement my own type system on top of it.
You know the aphorism about how any CS problem can be solved by another layer of indirection -- except the problem of too many layers of indirection. That's what design-by-contract is. Instead of having the intrinsic type-safety checks and the social trust that the code author has run unit tests if necessary and makes the code do something reasonable, design-by-contract formalizes all this and makes you specify conditions on the code manually. That's quite a bit of effort for relatively little advantage. The popular design-by-informal-agreement works almost as well and doesn't have the extra, unneeded layer of indirection.
For example, he defended Catholicism for Dummies as an accurate source, saying, "This is a text I often require for my students, and I would hang my own Ph.D. on it's credibility." [1] It turned out that the Dummies book, or perhaps his interpretation of it, was quite wrong in this matter. And several times, he made the claim, "I am a Catholic scholar," to the effect of, "In my research as a scholar, I have not seen x, so it must be wrong" or "I can be trusted with this role on Wikipedia -- I'm a theologian." He was setting up argument-from-authority traps that people have been falling for.
Slashdot Mirror
I'm not even going to attempt to argue the point any more. If you're actively opposed to the social contract, I refuse to recognize you as part of legitimate human society. Goodbye.
It would be very unbecoming of me to expect anybody to guarantee anything to me...without a signed contract anyway. By the same token, I offer none.
In a perfect world, that would work. The sad truth is that the majority of the world disagrees with you, and would get justifiably angry if you don't offer certain guarantees to others without signed contracts. In fact, if you live in a country that's a signatory to the Berne Convention, you are bound by international laws to offer guarantees to others without signed contracts.
The point of the Free Software Movement is to use further legalese to cancel the effects of copyright, restoring things to the way they should be. The debates between the various licenses are merely worries over what's the most effective way to accomplish this goal.
Licenses are for lawyers. Not for regular people, or computers. A simple "created by..." is good enough.
They're also for coders. A lot of coders will refuse to code if the result is going to be placed under an unfavorable license.
And for consumers. I think you like the guarantee that your software will be reasonably priced (probably free) and that if the original developers give up, someone else will maintain the software so your documents don't bitrot when you move to a different computer architecture, etc.
Nobody can take the code away.
Um, didn't you read about the recent Google pinyin fiasco, where they did take the code away?
Perhaps, but the common idiom is "sneaking suspicion", not "sneaky suspicion". Google lists many times more uses of the former, as well as actual definitions of the phrase.
Um, he hasn't been linking to his own sites for over a year, I think.
"Means." You keep using that word. I do not think it means what you think it means.
In particular, the English language is defined by common use, not by some hypothetical Academie Anglaise, and certainly not by Slashdotters.
Tagged "!boycottroland", because, um, it's not his website that he's linking to....
"Trickle down" doesn't exist. It's bullshit made up by an actor who played President to justify to poor people why he was handing rich people and corporations tax cuts.
I might believe you if you had some argument against it other than a mere ad hominem - and a weak one, at that. "Trickle-down economics" is merely one way of viewing laissez-faire economics. And, uh, laissez-faire exists. (It's up to debate how well it works, but it does have some positive effects, and it certainly "exist"s.)
Also, while we're on the subject of irrelevant arguments, "irregardless" is not a word.
Really? How many viruses can be transmitted through simply mounting a drive?
Windows will run arbitrary code upon mounting a removable device. I think with some effort and luck, you could convince an OS X or Linux user to run code from the drive unwittingly.
More importantly, a little rectangle with a USB port doesn't have to present itself as a removable disk. It can present itself as, say, an input device, and then type arbitrary strings into the user's computer. I believe it can present itself as a video output device without difficulty, in which case it can be used to spy on the computer. It can probably present itself as a network device and engage in some MitM attacks that way. It can attempt to just exploit a buffer overflow or something in the OS's USB drivers.
Actively malicious peripherals are a serious security problem.
I always give my girlfriend shit when something bad happens on her mac, I say, "That doesn't happen on PCs." And now her 6-month old Powerbook is slowly crapping out, and as it dies, I will be vindicated. Ahhhh, sweet vindication.
How can you possibly love your platform more than your girlfriend? Even if my girlfriend were using a Commodore 64, I'd still support her choice of platform.
You can be a master of x86 assembly and still be considered somewhat of a newbie in a Java programming curriculum. But in case you already know Java, you will start ahead, and have a better chance at mastering the much more important higher-level, language-neutral concepts such as proper design, understanding of algorithms, data structures, etc.
Thanks to its JVM, you have enough layers of abstraction that what you're saying is probably right for Java. But if you're working in any language that compiles to native code, it's worth having a general understanding of how machine languages work, so you know why certain coding constructs are much more efficient than others, so you understand how and why pointer/array arithmetic works, so you understand exactly the difference between local, global, static, etc. variables, and so forth.
Just as much as one should always respect the abstraction barrier, one should try to know what's actually going on under it. Not only will it make you a better coder in your own software, but it'll help you understand exactly why the abstraction exposes a certain interface and exhibits certain characteristics.
If they don't track IP addresses, what's to stop the students from trying to break into, say, the registar office's servers to alter their grades?
Presumably UNL's network department can request logs much more quickly than the RIAA's legal department can. And if the logs are as a matter of policy destroyed if they're a few days old....
Penn State with draconian AUPs that require MAC addresses
And an MIT? Can you honestly tell me that MIT, in the People's Republic of Cambridge, home of the Free Software Movement, the Berkeley of the East Coast, has pro-RIAA network policies?
MIT maps usernames to MAC addresses. However, the RIAA doesn't (and can't) see MAC addresses, only IP addresses, and in the time between noticing activity and sending a subpoena, the temporary logs are long gone. The purpose of tracking MAC addresses at MIT -- and presumably at Penn State -- is to be able to identify a user with a misconfigured or malicious network port and contact him/her after terminating the connection. It is most certainly NOT to create easily-subpoenable IP-to-person logs.
How does one "invent" a company?
Was single sign-on invented at MIT?
Was instant messaging invented at MIT?
Was the first modern windowing system - and, to date, the only network-aware windowing system - invented at MIT?
I'm not going to reply twice.
So yes, blame Java, if you're trying to teach memory allocation or algorithm design with it.
That's like saying "Blame the paint you can buy at Home Depot if you're trying to teach a person to paint a painting"
You can teach algorithm design with Java, what prevents you from doing so?
Exactly like you said. To teach someone painting, you teach them theory, not how to deal with the guy who sells you paint buckets and rollers. Once you know the theory you can start worrying about the tools.
So yes, you can use Java, and many colleges seem to do just fine with it, and many CS students start out with Java or a similar language - but it's much easier to teach with Scheme, which has far, far less syntax.
but you can make an emulator of your processor in Java
The professor for 6.004 has done exactly this; it's called JSim. We don't worry about how it's implemented, though, since the focus in that class is the processor itself. We do get to compilers/emulators in other classes, and did have a taste of it already (as the metacircular evaluator) in 6.001. So I'm not sure what your point is.
Our undergrads don't need to know what the difference between a spinlock and a semaphore is. Heck, our undergrads aren't even taught the differnece between C++ and C. Language-teaching comes up almost never. Our undergrads are computer scientists, not coders.
When they get a job that requires them to use one of the two, they'll be able to pick up the difference and choose the right tool, with far more accuracy and foresight than someone who merely learned it as a tool in class.
This is like complaining that half of MIT's linguistics grads can't explain the diference between Malayalam and Tamil. So what? I'd rather a linguist who can analyze for me the difference between any two closely related languages, as well as make sense of the extant literature, than a linguist who spent years studying the South Indian languages just because.
I think this seems a little redundant. I don't like EE and I'm not interested in it. I really don't care about how a computer works internally and I shouldn't really have to if my focus is on software engineering. Circuits don't directly affect me in my career one bit and I doubt many CS people think about them.
I didn't think I'd be interested in EE either, and I certainly will be going to advanced studies in CS, not EE, but you'd be surprised how quickly it does turn into essentially math and algorithmic design. Optimizing the Boolean logic for a processor and its ALU is much more math and CS than it is EE.
And please don't say that CS students are getting soft because of algorithm libraries - all languages have libraries to make things easier, not just Java.
They're only getting soft if they're taught "call library->standardfunction() and it'll do the magic for you". Once you can write the library if you wanted to, go ahead and use it.
This is a reply to all those "you and your fancy MIT" comments.
It doesn't matter whether it's MIT or not. It's only that MIT by being MIT has managed by and large to get their curriculum right, so it's a convenient...reference implementation for CS education, if you will. If you can get the same type of curriculum at a less "prestigious" university, and can come out with the same knowledge, more power to you. The end goal is the knowledge, not the stamp from a fancy university.
Now if your college wants to teach all their classes in C or Java, except for a couple of advanced study classes that happen after you've already been indoctrinated as a coder, then you should consider learning a thing or two from MIT.
Waiting. LISP is a great first or second language.
when you're ready, LISP
I oppose this. MIT teaches Scheme, a LISP dialect, in its intro CS class. And the admissions requirements don't include knowledge of programming, and many non-EECS majors take the class. (Well, they're now offering a Python class simply as intro programming. But that's mainly for people who've never seen code before.)
Get yourself a copy of The Little Schemer, and read through it. It's a nicely different way of looking at CS and coding.
The normal course of action is to blame Java, since it has led to a simplistic approach to CS assignments.
You should blame Java. And you should blame C++, Python, and any other similar medium-high level language, if that's the intro language and your sole teaching language.
Here at MIT we have 4 intro courses. The first, the famous Structure and Interpretation of Computer Programs, is taught entirely in Scheme, a purer and more pedagogical dialect of Lisp. You learn how to do all the high-level algorithms (e.g., sorting) in a purely mathematical/logical fashion, since Scheme has automatic object creation / memory handling, no code-data distinction, etc. At the end of the class you work with a Scheme interpreter in Scheme (the metacircular evaluator), which, modulo lexing, teaches you how parsing and compiling programs works.
The next two are EE courses. The fourth starts EE and quickly moves to CS. You use a SPICE-like simulator to build gates directly from transistors. (You've done so in real life in previous classes.) Then you use the gate simulator to build up more interesting circuits, culminating in an entire, usable CPU. From gates. Which you built from transistors. The end result is, not only are you intimately famliar with assembly, you know exactly why assembly works the way it does and what sort of electrical signals are occurring inside your processor.
Once you know the highest of high-level languages and the math behind it, and the lowest of low-level languages and the electronics behind it, you're free to go ahead and use Java or whichever other language you like. (Indeed, the most time-consuming CS class is a regular OO Java software design project.) You're not going to get confused by either theory or implementation at this point.
So yes, blame Java, if you're trying to teach memory allocation or algorithm design with it.
Hi.
You should learn about the subjunctive.
Thanks.
Your post is making no sense at all.
I wrote it about 15 seconds before falling sound asleep.
DbC is nothing more than extending strong typing
Precisely. If my function can be written as
uppercase_char[4] foo(int(0...10) x) {...}
I'd use it. If I can define my function as
char[4]:isUpper foo(int x:(lambda (x) (0
then I might consider it. If I have to write my function as
string foo(int x) {
assert(0
then there's no way I'm using it. I already have my language do the strong type checking for me. I'm not going to implement my own type system on top of it.
You know the aphorism about how any CS problem can be solved by another layer of indirection -- except the problem of too many layers of indirection. That's what design-by-contract is. Instead of having the intrinsic type-safety checks and the social trust that the code author has run unit tests if necessary and makes the code do something reasonable, design-by-contract formalizes all this and makes you specify conditions on the code manually. That's quite a bit of effort for relatively little advantage. The popular design-by-informal-agreement works almost as well and doesn't have the extra, unneeded layer of indirection.
For example, he defended Catholicism for Dummies as an accurate source, saying, "This is a text I often require for my students, and I would hang my own Ph.D. on it's credibility." [1] It turned out that the Dummies book, or perhaps his interpretation of it, was quite wrong in this matter. And several times, he made the claim, "I am a Catholic scholar," to the effect of, "In my research as a scholar, I have not seen x, so it must be wrong" or "I can be trusted with this role on Wikipedia -- I'm a theologian." He was setting up argument-from-authority traps that people have been falling for.
[1] Talk:Imprimatur