Your code transformation bit is right on (ML makes the tradeoff of a more powerful syntax instead of a simple and easily-manipulated abstract syntax tree), but the types thing is definitely bullshit. Types are not just about speed, they are vital to modularity and debugging. ML-family languages have the ability to write generic code (with type inference) just as easily as lisp, and do indeed allow you to easily "delay deciding types" with structured data types. (On the contrary, lisp does not let you statically assure that something has a particular type in the same powerful way as ML-family languages do.)
Lisp is a cool language; there's no war here (as there might be with the C++ folks;)) but I think you need a little more practice with a powerful type systems before you can make statements such as the one you made.
Really? This was one of my favorite adventure games. It was really cool all the different ways that you could complete it, and had some of the nicest pixel graphics I've seen...
You can submit statically linked executables, so you don't need to worry about what compilers they have installed (if you really want to use C++ for something like this!).
An AC flames, Right, this from the person who just said consumers will have a hard time diffrentiating Illustrator and Killustrator, is now saying only certain people who use vector art software will associate Illustrator with a particular kind of software (The irony is you said the answer right there, "a particular kind of software", versus saying "a particular software product". Lame.
Your argument is entirely inconsistent. I said that people will associate Illustrator with a particular software piece, NOT a particular kind of software. Look at the post again:
Unless you can successfully argue that there is not a significant group of people (ie, people who use vector art software) who associate "illustrator" with the particular software package, the court isn't going to care that you in particular didn't know about it!
What I am saying is that no significant amount of people who actually know about vector art software consider "Illustrator" to be a generic term describing the whole set (which would invalidate Adobe's claim); rather they know that it refers to the specific piece of software called Illustrator. Just being an english word does NOT MAKE IT GENERIC.
If you are following this thread closely enough to see replies to your AC posts, why don't you care enough to actually read the arguments made against you? Now *that* is lame. If you're just trying to troll, you should get some real content in there...
> It supports a pattern matching like Perl
> (although not as sophisticated).
Actually, it is perl's pattern matching which is not as sophisticated. Perl has regular expression matching, whereas Ocaml (and SML) have user-defined structured data types and pattern matching against them. Perl does have more convenient, but slower, regular expression matching.
AC writes,
Thats plain sick. Whats better for consumers is a better product, not a uniquely defined brand name. If Adobe really wants to seperate themselves from the rest, they should try something new like making a better product. But I guess that is just to simple.
Uniquely defined brand names help differentiate products, which leads to more accurate rewards for quality products. Just as you use "Adobe" to uniquely refer to the company in question, product brand names are important for uniquely referring to products. The KDE folks should be (and are) free to choose a new name and compete with Illustrator on the basis of quality; then, the consumer knows that the products are not related and she can make her choice more accurately.
Illustrator 9 actually is really good, by the way.
Unless you can successfully argue that there is not a significant group of people (ie, people who use vector art software) who associate "illustrator" with the particular software package, the court isn't going to care that you in particular didn't know about it!
I don't see it. It's an English word, sure, but when someone says "illustrator" in this context I immediately know that they're talking about that specific Adobe product. "vector" is a generic term. "office" might be (since that class of applications is often known as "office suites"). But nobody uses "illustrator" to talk about the set of vector drawing programs generally.
I think Adobe is in the right here. Trademark law is one of the few useful intellectual property facilities that the government provides; consumers should not be mislead by confusingly named products.
Perhaps, but does the average user know enough to "secure the system fully"? I was taking issue with the article's implication that this would revolutionize web serving and increase security at the same time. I maintain that increasing the size of the trusted code base does NOT increase security, in fact, at worst it does the opposite.
I'm not so sure putting the web server (ie, more code) in the kernel is a good route to better security; it increases the trusted codebase. Perhaps the simplicity of the server makes up for this, but that's because it's simple, not because it's in the kernel.
Kernel-space web servers are a good idea for people who need super high-volume serving of static content. Those people hopefully also have the resources to maintain something as potentially dangerous as that. It's good for benchmarks, too.
But most people do not need this kind of speed; serving up static content, I'm sure a T1 would max out before a modest desktop machine would max out its CPU running apache. What people do need is safe software which needs little maintenance -- experience has shown that many users do not stay up-to-date on patches. Therefore, I say that moving to yet lower levels than userspace C (ie, the kernel) is a bad idea, in fact, we should be moving to higher level languages where more safety properties are guaranteed. Presumably, while this might lead to slower web servers (I don't think it would be more than a few percent), it would also lead to fewer bugs and lower maintenance costs. That's the real cost of software, after all!
If they're clever, it would be possible to patch CDs. Though you probably can't update the physical media, downloading a few kilobytes of update each time you sign on wouldn't be too unreasonable. This could be cached on memory cards, maybe, and loaded on boot (similar to Intel's microcode updates).
Of course, making the system easily modifyable like this might make cheating that much easier.;)
One advantage that the employer gets is to direct its employees to produce software which meets its particular needs. Is that enough? I think so, but maybe there's more...
Go ahead and make arguments, but saying stuff like "GPV" and making overzealous analogies makes you sound like the kind of person who writes "Micro$oft"; that is, not very convincing.
There's are several big leaps here, but very little insight. How did you come to these conclusions?
The most glaring omission in my eyes is the fact that you don't reconcile the difference between altruisim with traditional goods (ones that have physical identitity and which "go away" when you give them to somebody) and the kind of sharing we do in the "open source" community. Here, "parasites" making copies of our work doesn't reduce our ability to use our own copies. (This is one of the founding principles of the GPL, in fact.) Therefore, parasites aren't much like parasites at all.
I think the GPL is great, personally, but I don't think I follow your argument.
I actually meant in terms of understanding how C works. (Like, why you can't return pointers to stack-allocated data.)
But you make a good point in opposition to using assembly, and that's that the lessons learned in assembly don't actually scale to higher level languages (C and especially not really high-level languages like Java).
Here are some reasons why you are bad (I have TA'd 7 CS classes at my university, so I am not just pulling this out of my ass):
- Many people who will not be getting a degree in Computer Science (but who might interact with programmers or write some MS Access scripts) take introductory programming classes. It is important to have these people learn the fundamentals of programming rather than their actual implementation -- assembly will be practically useless to them unless they take the time to take compilers, operating systems, etc...
- Assemblers (and I might even stick C in this category, if I was feeling snappy) do not support the abstraction and generic programming features important for writing interesting programs. (Except systems stuff.) Introductory programming classes typically focus on data structures and algorithms; if you make the students program these in assembly, you are limiting the amount of material you can cover (and therefore, how much they can learn).
- Assembly as an introductory language is going to scare people away from computer science. Systems programming is pretty fun, but it's not for everyone. Many computer scientists hardly ever program (let alone in assembler), and I would wager that most professional programmers do not need to write in assembly language. Assembly is a great enhancement to a programmer's (or scientist's) knowledge of computers, but understanding it is not a requirement for programming in high-level languages.
- The world will be a better place (fewer buffer overflows (thus security holes) and memory leaks, more portable software and code reuse, and shorter development cycles) if we encourage new students to move towards high-level, abstract languages. I'm not saying Java is the best choice for this (though it may be the most practical), but assembly certainly isn't.
Most people do not need assembly. It is an important fundamental, and it should be a part of every CS major's education, but it is not a requirement for understanding how to program in a high-level, abstract language. (It may be a requirement for writing good C code, however.) In fact, very many computer scientists hardly ever program. Programming fundamentals should be about the foundations of programming, not about the implementation on hardware.
My school now uses Java for its introductory classes. Since I TA'd these classes in both the C++ and Java versions, I think I can speak with a little authority. Java is a good language to use for introductory programming/algorithms.
The class particularly in question is called "Data Structures and Algorithms". In my experience, the students who took this course in Java had a much smoother experience than those who took it in C++ the year earlier. Programs crashed mysteriously less often, they didn't have to deal with memory leaks, they had less compatibility problems, and were able to write more sophisticated and interesting programs in the same amount of time. Since Java is simpler, we were actually able to teach almost everything in the language to them, where for C++ we had to leave out a significant amount of its core (such as templates, which meant that they couldn't really understand the string class, for instance).
All of the CS majors took "Systems programming" the next semester, which is a hard-core C programming class; most go on to take Operating Systems, in which they learn anything you'd hope they'd learn by struggling with C or C++ in the intro class. I agree totally that systems programming should be a significant part of any CS program. But systems programming is just *a part* of computer science (in the Slashdot/Linux crowd, perhaps it is the most popular). And in truth, things like manual memory management and hardware access are not important in most of the other parts of CS. For teaching algorithms and data structures, these things are a hindrance.
Personally, I'm waiting patiently for the day when only the most low-level software (a microkernel and hardware drivers) are written in C or assembly, with all of my applications written in a safe, GC language (perhaps Java, though there are better alternatives). It sure will be nice to be free from buffer overflows and memory leaks, finally! So while my recommendation of Java here is partially influenced by that goal, I think it is also quite justified for pragmatic reasons.
I agree with you 100% -- In fact, I think for me it was the mousewheel that did it. Since I shut that off, and started using the keyboard for everything but web browsing, my wrist has gotten a lot better. I second your comment!
Slashdot Mirror
declare -x PS1="C:\\\\\W> "
... just to amuse me and confuse onlookers. =)
Your code transformation bit is right on (ML makes the tradeoff of a more powerful syntax instead of a simple and easily-manipulated abstract syntax tree), but the types thing is definitely bullshit. Types are not just about speed, they are vital to modularity and debugging. ML-family languages have the ability to write generic code (with type inference) just as easily as lisp, and do indeed allow you to easily "delay deciding types" with structured data types. (On the contrary, lisp does not let you statically assure that something has a particular type in the same powerful way as ML-family languages do.)
;)) but I think you need a little more practice with a powerful type systems before you can make statements such as the one you made.
Lisp is a cool language; there's no war here (as there might be with the C++ folks
Really? This was one of my favorite adventure games. It was really cool all the different ways that you could complete it, and had some of the nicest pixel graphics I've seen...
You can submit statically linked executables, so you don't need to worry about what compilers they have installed (if you really want to use C++ for something like this!).
An AC flames, Right, this from the person who just said consumers will have a hard time diffrentiating Illustrator and Killustrator, is now saying only certain people who use vector art software will associate Illustrator with a particular kind of software (The irony is you said the answer right there, "a particular kind of software", versus saying "a particular software product". Lame.
Your argument is entirely inconsistent. I said that people will associate Illustrator with a particular software piece, NOT a particular kind of software. Look at the post again:
Unless you can successfully argue that there is not a significant group of people (ie, people who use vector art software) who associate "illustrator" with the particular software package, the court isn't going to care that you in particular didn't know about it!
What I am saying is that no significant amount of people who actually know about vector art software consider "Illustrator" to be a generic term describing the whole set (which would invalidate Adobe's claim); rather they know that it refers to the specific piece of software called Illustrator. Just being an english word does NOT MAKE IT GENERIC.
If you are following this thread closely enough to see replies to your AC posts, why don't you care enough to actually read the arguments made against you? Now *that* is lame. If you're just trying to troll, you should get some real content in there...
> It supports a pattern matching like Perl
> (although not as sophisticated).
Actually, it is perl's pattern matching which is not as sophisticated. Perl has regular expression matching, whereas Ocaml (and SML) have user-defined structured data types and pattern matching against them. Perl does have more convenient, but slower, regular expression matching.
AC writes, Thats plain sick. Whats better for consumers is a better product, not a uniquely defined brand name. If Adobe really wants to seperate themselves from the rest, they should try something new like making a better product. But I guess that is just to simple.
Uniquely defined brand names help differentiate products, which leads to more accurate rewards for quality products. Just as you use "Adobe" to uniquely refer to the company in question, product brand names are important for uniquely referring to products. The KDE folks should be (and are) free to choose a new name and compete with Illustrator on the basis of quality; then, the consumer knows that the products are not related and she can make her choice more accurately.
Illustrator 9 actually is really good, by the way.
Unless you can successfully argue that there is not a significant group of people (ie, people who use vector art software) who associate "illustrator" with the particular software package, the court isn't going to care that you in particular didn't know about it!
I don't see it. It's an English word, sure, but when someone says "illustrator" in this context I immediately know that they're talking about that specific Adobe product. "vector" is a generic term. "office" might be (since that class of applications is often known as "office suites"). But nobody uses "illustrator" to talk about the set of vector drawing programs generally.
I think Adobe is in the right here. Trademark law is one of the few useful intellectual property facilities that the government provides; consumers should not be mislead by confusingly named products.
Maybe if they also fixed his spelling mistakes it would be worth it. =)
Perhaps, but does the average user know enough to "secure the system fully"? I was taking issue with the article's implication that this would revolutionize web serving and increase security at the same time. I maintain that increasing the size of the trusted code base does NOT increase security, in fact, at worst it does the opposite.
I'm not so sure putting the web server (ie, more code) in the kernel is a good route to better security; it increases the trusted codebase. Perhaps the simplicity of the server makes up for this, but that's because it's simple, not because it's in the kernel.
Kernel-space web servers are a good idea for people who need super high-volume serving of static content. Those people hopefully also have the resources to maintain something as potentially dangerous as that. It's good for benchmarks, too.
But most people do not need this kind of speed; serving up static content, I'm sure a T1 would max out before a modest desktop machine would max out its CPU running apache. What people do need is safe software which needs little maintenance -- experience has shown that many users do not stay up-to-date on patches. Therefore, I say that moving to yet lower levels than userspace C (ie, the kernel) is a bad idea, in fact, we should be moving to higher level languages where more safety properties are guaranteed. Presumably, while this might lead to slower web servers (I don't think it would be more than a few percent), it would also lead to fewer bugs and lower maintenance costs. That's the real cost of software, after all!
What? Ever hear of CD-RW? ;)
If they're clever, it would be possible to patch CDs. Though you probably can't update the physical media, downloading a few kilobytes of update each time you sign on wouldn't be too unreasonable. This could be cached on memory cards, maybe, and loaded on boot (similar to Intel's microcode updates).
Of course, making the system easily modifyable like this might make cheating that much easier.
One advantage that the employer gets is to direct its employees to produce software which meets its particular needs. Is that enough? I think so, but maybe there's more...
These cubic watermelons look rather like they use Illegal Bansai Kitty Technology...
Go ahead and make arguments, but saying stuff like "GPV" and making overzealous analogies makes you sound like the kind of person who writes "Micro$oft"; that is, not very convincing.
There's are several big leaps here, but very little insight. How did you come to these conclusions?
The most glaring omission in my eyes is the fact that you don't reconcile the difference between altruisim with traditional goods (ones that have physical identitity and which "go away" when you give them to somebody) and the kind of sharing we do in the "open source" community. Here, "parasites" making copies of our work doesn't reduce our ability to use our own copies. (This is one of the founding principles of the GPL, in fact.) Therefore, parasites aren't much like parasites at all.
I think the GPL is great, personally, but I don't think I follow your argument.
"Here are some reasons why you are bad ..."
Of course I meant,
"Here are some reasons why you are wrong..."
or probably
"Here are some reasons why this is a bad idea..."
Sorry. =)
I actually meant in terms of understanding how C works. (Like, why you can't return pointers to stack-allocated data.)
But you make a good point in opposition to using assembly, and that's that the lessons learned in assembly don't actually scale to higher level languages (C and especially not really high-level languages like Java).
Here are some reasons why you are bad (I have TA'd 7 CS classes at my university, so I am not just pulling this out of my ass):
- Many people who will not be getting a degree in Computer Science (but who might interact with programmers or write some MS Access scripts) take introductory programming classes. It is important to have these people learn the fundamentals of programming rather than their actual implementation -- assembly will be practically useless to them unless they take the time to take compilers, operating systems, etc...
- Assemblers (and I might even stick C in this category, if I was feeling snappy) do not support the abstraction and generic programming features important for writing interesting programs. (Except systems stuff.) Introductory programming classes typically focus on data structures and algorithms; if you make the students program these in assembly, you are limiting the amount of material you can cover (and therefore, how much they can learn).
- Assembly as an introductory language is going to scare people away from computer science. Systems programming is pretty fun, but it's not for everyone. Many computer scientists hardly ever program (let alone in assembler), and I would wager that most professional programmers do not need to write in assembly language. Assembly is a great enhancement to a programmer's (or scientist's) knowledge of computers, but understanding it is not a requirement for programming in high-level languages.
- The world will be a better place (fewer buffer overflows (thus security holes) and memory leaks, more portable software and code reuse, and shorter development cycles) if we encourage new students to move towards high-level, abstract languages. I'm not saying Java is the best choice for this (though it may be the most practical), but assembly certainly isn't.
Most people do not need assembly. It is an important fundamental, and it should be a part of every CS major's education, but it is not a requirement for understanding how to program in a high-level, abstract language. (It may be a requirement for writing good C code, however.) In fact, very many computer scientists hardly ever program. Programming fundamentals should be about the foundations of programming, not about the implementation on hardware.
My school now uses Java for its introductory classes. Since I TA'd these classes in both the C++ and Java versions, I think I can speak with a little authority. Java is a good language to use for introductory programming/algorithms.
The class particularly in question is called "Data Structures and Algorithms". In my experience, the students who took this course in Java had a much smoother experience than those who took it in C++ the year earlier. Programs crashed mysteriously less often, they didn't have to deal with memory leaks, they had less compatibility problems, and were able to write more sophisticated and interesting programs in the same amount of time. Since Java is simpler, we were actually able to teach almost everything in the language to them, where for C++ we had to leave out a significant amount of its core (such as templates, which meant that they couldn't really understand the string class, for instance).
All of the CS majors took "Systems programming" the next semester, which is a hard-core C programming class; most go on to take Operating Systems, in which they learn anything you'd hope they'd learn by struggling with C or C++ in the intro class. I agree totally that systems programming should be a significant part of any CS program. But systems programming is just *a part* of computer science (in the Slashdot/Linux crowd, perhaps it is the most popular). And in truth, things like manual memory management and hardware access are not important in most of the other parts of CS. For teaching algorithms and data structures, these things are a hindrance.
Personally, I'm waiting patiently for the day when only the most low-level software (a microkernel and hardware drivers) are written in C or assembly, with all of my applications written in a safe, GC language (perhaps Java, though there are better alternatives). It sure will be nice to be free from buffer overflows and memory leaks, finally! So while my recommendation of Java here is partially influenced by that goal, I think it is also quite justified for pragmatic reasons.
I agree with you 100% -- In fact, I think for me it was the mousewheel that did it. Since I shut that off, and started using the keyboard for everything but web browsing, my wrist has gotten a lot better. I second your comment!
OK Moderators --
You modded down the 7th post as redundant. Please concentrate!