Um... Verilog has just barely C-esque syntax, but has entirely different semantics. It's a language for describing circuits, not a general purpose language.
Fonts that are hinted for screen display shouldn't be anti-aliased at small sizes. It makes them blurry. The font author has already essentially laid out the pixels exactly as they should appear for those sizes. At least give people the choice. (Do you play anti-aliased NES games on your emulator, or do you leave the pixels as-is?)
Second, it would be nice to have "ClearType" (that is, sub-pixel AA) on linux, too. Is anyone working on this?
I think that all it would take is for a nice MP3-sharing program with quality indexing and searching to be deployed on top of freenet. As long as it had a nice interface and was easy to install, you could easily get a bunch of freenet nodes off of people who care little about free speech, but who care lots about free music.
How does having it written in Java make it suffer? I ran a node for a while, and the performance was just fine. It's also nice to know it won't have any buffer overflows.
I can understand the desire for native-compiled code, but... C??
I'd love to, but Gnutella is crappy. The network is filled with bad and incomplete files, most stuff is misdescribed, and searching is totally lame. The gnutella folks really need to work on the availability and quality of content in the network.
I think maybe Gnutella is a good starting user base for some new evolution of the system, but right now it doesn't hold a candle to Morpheus (or especially, Napster).
> If people want speed, why don't they bootstrap > high-level languages from an interpreter to native > code?
Well, high-level languages have the ability to be fast in native code to varying degrees. For instance, lisp and scheme can both be quite fast, though dynamic tag checking and dynamic scope (in lisp) hurt performance. SML wins for speed here because it's statically typed, but still pays for array bounds checks (usually, but we're working on it;)) in order to guarantee safety. But of course you lose the ability to do certain tricks you can do in a highly dynamic language like scheme. Java suffers from a bloated class system and some language misdesign, so there's a lot of overhead no matter the implementation. Languages like perl where you can build string representations of program syntax and interpret them on the fly essentially need the compiler built into the language to have fast native code capabilities.
Of course, as you mention, none of them are so much slower than C that they wouldn't be appropriate for applications. And as I said in my post, when development is that much easier, that leaves more time for optimization. =)
> You want this kind of functionality you can find > it in a number of languages that exists today. > Those languages - their runtime libs and their > vm's, are built with c.
That's not necessarily true. SML compilers, for instance, usually compile directly to machine code. Sometimes we use C to interface to the operating system, but that's simply because the operating system is C-centric.
Regardless, hacking up virtual machines and garbage collectors sort of is C's domain. Kernel hacking, also C. (Though I wish we had a microkernel so that things like the filesystems, higher levels of the network stack, etc. could be written in modern languages.) Embedded systems, C. But most programmers don't write these things, they write applications -- and those are definitely not what C is good at.
Maybe you are simply taking issue with the title of my post, "Get rid of C!". I didn't really mean that. I mean, stop using C for application programming.
Just because a post is provocative doesn't mean it's a troll. A troll post usually says something that the author doesn't really believe, just to get people fired up. I actually believe this, and I think it's worthwhile for the C-centric slashdot crowd to think about it.
> It's the passing by value, which prevents the > compiler from inlining the function; the correct > way to write that function is:
I disagree that this "prevents" the compiler from inlining. It might force the compiler to call the copy constructor (if it can't deduce that it has no effect), but there's no reason it "prevents" inlining. It may be that the compiler just doesn't inline it, sure.
I don't really see why programming in C gives you any more clue about when a C++ compiler will perform inlining, since that's basically an arbitrary choice made by the compiler.
That said, I agree that there is definitely a place for learning C in a well-rounded programmer's education. I've taught programming enough to know that... Programmers that don't know low-level programming won't be able to do low-level optimizations. BUT, I think the emphasis that slashdot folks place on low-level efficiency is highly overrated. I feel that C actually encourages programming styles that are BAD for programming in general; I think it can do more harm than good for a programmer to learn "efficient" programming in C. So while it's a good idea for people to learn it, I don't necessarily think that it's smart to learn C *before* you learn other high-level languages.
> Your example, by the way, in which a loop that > increments elements of an array is parralelized > in hardware, is actually simpler than you > think.
Well, if you say so. People actually do their PhD theses on this kind of thing. In conversations with my friend, who actually works on these kinds of compilers, it seems that the problem is actually difficult. For instance, if there is almost any kind of memory write in the loop, then you need to do alias analysis to verify that it is not breaking the parallelism.
> Your particular example implies that the only > real way to solve parralelism is to define > parralel functions and human-solve them; this > clearly violates the distinction between > language and library, and doesn't really help
Well, let me reiterate my actual point: Instead of always working with C, languages should be adapted to the task at hand. C gives you an abstract view of a sequential machine -- and this is hardly how computers actually operate today (especially when compiling to hardware!) Having a language (even if like C) with a parallel array modification construct like SML's would make programs *easier* to write, and compilers better. I don't know what you mean by violating the distinction between language and library. Why should parallelism be a library??
For the record, I wasn't encouraging Object Oriented programming, which I think is a bit of a sham -- but that's a different argument entirely.;)
Re: Does the world need more C books
on
C
·
· Score: 2
> It's also _MUCH_ easier to write code without > side effects, which is a bane to programming.
Hmm. I agree with what you say about C++ -- I think the language is awful -- and I agree that side effects are a bane to programming, but I definitely don't agree that C is good for side-effectless (ie, functional) programming.
For instance, implementing something as simple as binary trees without side-effects almost *requires* a garbage collector in order to get reasonable performance. (Maybe you could do something tricky with lazy reference counting, I dunno.)
In fact, since memory allocation is a side effect, even string manipulation in C is hard to pull off without side-effects. (How do you return a variable-sized string from a function?) On the contrary, C++ has value-semantics strings that make this possible.
And since C lacks first class functions (really, I should say it lacks nested functions, since you can actually pass around pointers), lots of the functional idioms just don't work.
Goodness, this is an awfully empty review. Except for the comment about the author's native language (which humorously is followed up by an awkward if not ungrammatical sentence from the reviewer), this whole review could be applied to practically any programming book! What sets this book apart? If nothing, then why review it?
Anyway, the real reason I clicked on this article is because I just love a C debate. Since there's hardly anything to talk about with regard to the review, let's get to it!
Here's what I say: outside of the low-level systems crowd, C should die. We should *not* be teaching beginning programmers C or C++. C should not be the "default language" of computer programming.
Today, efficiency is no longer the primary concern about software. It has been ousted by robustness and ease/cost of development (modularity and reuse). C is awful for robustness (the language lets you "get away" with anything you want, though those things are seldom what you want in application software), and even worse for modularity and re-use. Modern languages, or even quasi-modern languages like Java, are far better than C for robustness and ease of development. They even win on some points which are typically seen as less important than efficiency: portability, elegance, etc.
Finally, the efficiency of high-level languages is comparable (though not as good as) C. Compiler technology is improving somewhat, as well. But since developing and debugging take less time, you have more time to optimize your program (if necessary), so I am not convinced that this is really a big deal. Yet, even if I need to concede the efficiency issue, I still believe modern languages beat C overall.
I'll be glad to argue about that stuff, but today I have a different point to make. C is also holding back the progress of other computer fields. Let me give you an example. My friend is working on compilers that compile high-level languages (to them, C is a high-level language) down to circuits. Here, discovering data parallelism in the code is probably the most difficult problem. Of course, the same issues arise in compiling to architectures like the IA-64 or even P4, where in order to get best
execution speed, the compiler needs to figure out what instructions can be executed in parallel.
When they compile C, they need to look for common idioms (certain patterns of for-loop use), then analyze them to extract the parallel algorithm. For instance, this simple C loop adds k to every integer in an array a of size s:
for (int i = 0; i < s; i++) {
a[i] += k;
}
The idea is that the compiler should be able to produce a circuit that does all of the adding in parallel, on silicon. Since you all probably
grew up on C, this seems like the totally natural way to write that code. In fact, it is short and it is straightforward. Unfortunately, it is less
straightforward to a compiler. The compiler needs to prove to itself that the for loop can be parallelized -- what if the programmer changed k or a or i in the loop body? The C code actually says to run each loop iteration sequentially.
Of course, compiler writers have gotten pretty good at catching this particular idiom, but when the code gets more complicated (especially when the compiler needs to do alias analysis), it is not so good.
The chief problem here is that the programmer is unable to effectively communicate his parallel algorithm to the compiler. The programmer takes something in his mind "add k to all elements in the list", sequentializes it for C "for (int i = 0...", and then the compiler has to *undo* this sequentialization to produce the parallel code. In the process of translating, some information is always lost.
Now look how this code would be written in SML (a so-called "modern language"):
Array.modify (fn x => x + k) a
(fn x => x + k) is a function expression (SML lets you pass around functions), and Array.modify simply applies the function to every element
in the array. Here, the compiler can very easily tell that my operation is parallel, because I used Array.modify! The code is also a bit shorter, and I also think that this code is a lot clearer. That's subjective, of course. BUT, I hope you will agree that for this example, the SML code is closer to what the programmer means, and easier for the compiler to understand.
Anyway, perhaps some of you will say that this particular issue is not a problem, or that it is already solved (I would like to hear the solution!). I merely mean to propose an example of a theme I have been observing over the past few years in many areas of computer science. Computer programming is about communicationg with the compiler or machine in such a way that it is easy for the human to create code, and easy for the machine to understand it. C was never particularly easy for a human to create (though we have become accustomed to it), and though it was once easy for a compiler to understand, this is becomming less and less true. When the language is neither optimal for humans nor optimal for compilers, doesn't that mean that something needs as change?
God, I hope that when we are programming internet-wide distributed applications we are not still programming at the level of memory addresses! That would be pretty damn awful...
Looks like you need to read the story more carefully -- if you get all your information from Slashdot's misleading headlines, you're going to be pretty misinformed!
This worm really has nothing to do with C# (or even.NET). It's just a regular e-mail worm that happens to also have a.NET payload, part of which is written in C#.
I don't think that Morpheus is telling the whole story.
Last week they wrote something like, "one of our software providers made updates without telling us that made Morpheus software unable to connect to the network."
It sounds to me like FastTrack upgraded protocol versions, or something?
I don't see why Morpheus would voluntarily move to gnutella, since gnutella is quite inferior and their new software is pretty crummy. I've been looking around their forums and everything, but I can't seem to figure out what's actually going on. Anyone know any more info?
Slashdot: If you want to stay afloat, you should do this as gradually as possible. If you dump lots of changes on us all at once, and we don't like 'em, that might be enough to make us unhappy, and make us stop visiting -- and there's nothing like a lack of readership on a user-driven site to send it spiraling down the drain.
If you're going to make *negative* changes like these, you might consider making *positive* changes to offset it -- clean up the design of the site (you don't have to get rid of the green, just streamline it for all of the old obsolete stuff), implement some features people have been asking for forever (submission queue), etc.
Despite all its problems, it would be a shame to see this site go. This change could really do it, so be careful!
I'm with you for Google and friends, but slashdot is NOT a good example of good web design.
First, the graphics are just ugly. I dunno, I guess this is a subjective thing, but I have to read in "light mode" (which I think actually has a rather usable interface even on real browsers) or my eyes will fall out.
Second, the front page is filled with all sorts of clutter that needn't be there -- especially stuff that is old and hardly ever changes.
However, I agree with you that the content is the most important thing.
Everyone needs to decide this on their own, I think. How can I know what you'll like?
I think that above all other traits, though, these days I want my music to be honest. (Made by people not trying to do what they think their boss wants, but what *they* want.) I found that mp3.com is good for finding music like that.
Seriously, who cares if the RIAA is making more or less money as a result of Napster? I would actually prefer that they make less money...
Either way, they are going to be raising CD prices and chasing down the file sharing services. They are scared, and they want to remain in control.
For context, I have over 300 CDs... most are from independent labels. (I've recorded a *ton* of music myself; over 15 albums and a thousand songs...)
I like to think that I am listening to music made by people who do it because they love music, not because they want to make money. In fact, I typically think that artists shouldn't be selling CDs at all. It seems to me that if they want people to hear their music, they should make it as widely available as possible! To me, that means putting it on the internet, or at least giving a license for others to do so for you. (An exception is these low-run CDs that people sell at their shows, which typically cost only about $5 to $10; this is often more convenient for the purchaser than trying to find obscure songs on the internet.)
Some people will say stuff like, "artists deserve to be paid!". I say, artists deserve to be paid for live performance, or for commissions, but nobody deserves to be paid for duplication (essentially free) of a recording that already exists. Furthermore, if music is primarily a *job* for an artist, then his work is more craft than art, and I say that's a good reason not to care about it as much. (Do you think of yourself as a consumer or a fan? Do you purchase products or appreciate their beauty?)
So my solution is to buy music when it's most convenient (rarely), to download lots of free music by amateurs at mp3.com and other places, and to make my own free music. If every music lover did this, boy, would the world be a better place!
Living in a RIAA-free world is good; it feels moral (even if it is not always legal), and it pisses the right people off.
> Um, some of us like select-to-copy and > middle-click-to-paste. To me, that's intuitive - > the Windows Ctrl-C/Ctrl-V combo is what's strange. > > I don't consider it a problem at all.
I don't consider that a problem either, the problem is that it doesn't always work! It's fine when cutting and pasting between Xterms, but between xterms, mozilla, acrobat, emacs? It's a nightmare.
Hey, I agree. Copy/paste is one of the worst usability problems with KDE (and other window managers I've used).
It works perfectly in windows.
I hope that this news reminds some people that there are still basic problems to be addressed before linux on the desktop can go mainstream.
(OTOH, I am pretty impressed with KDE. It has been running 160 days straight on this box, and 160 days ago was my first boot... other window managers I've used have not been so stable.)
> Because, being implemented in C, so has the JVM, > no doubt. But you were claiming that Java is > safe, and Perl is not.
The problem with this statement is that the perl language is essentially defined by its implementation. Therefore "perl" (the language) and "perl" (the program on my computer) are rather hard to distinguish. When I said that perl had buffer overflows, I was referring to the implementation. Of course, a JVM (at least one that doesn't do JIT compilation) is a lot simpler than the perl interpreter...
> So Java is more secure because it makes things > more difficult?
Yes, actually. It makes certain things more difficult, which is bad for scripting tasks, but good for security. Personally, I believe that outside a scripting domain (and this does NOT include programs that run websites), it should be difficult to execute commands on the system or otherwise run code from the user input.
I personally have exploited several perl-based web scripts. Just as buffer overflows are easy to make in C, these kinds of bugs are perhaps even easier. (For instance, shelling out to the mail command with a user-supplied e-mail address on the command line.) I know and you know that there are ways to avoid this; the point is that the language makes it easy to do.
I guess I can say "Java is more secure" and you can say "Perl is more secure" all day. I doubt anybody has done a study. But I conjecture that there have been far more exploits of perl scripts than java programs.
> How can anyone say there are no overflows in the > JVM? I can't see the code, or the development > process, therefore my trust level is fairly low.
You can see the code to the JVM. There are a bunch of open-source implementations. Or, you can compile to native code with one of the many open source native compilers.
Finally, I'd like to point out that we're working on a solution to this problem, though it's not really mature enough for me to suggest that people use it yet. You and I both keep bringing up that parts of the system written in low-level languages can't be trusted -- the idea is to make trusted low-level languages, in the form of typed assembly language. With this, compilers compile to native code, but provide type annotations that another program can use to verify that the code is safe. The verifier is very tiny, and it would be feasible to prove its correctness. In this scenario, there is no virtual machine to trust, and we don't need to trust the compiler any more because we verify its output.
We're pretty close to having certifying compilers done for some nice high-level languages. (A few exist already for safe C variants.)
OK, I'm with you then. I agree that the difference between C and practically any modern safe language is big enough to make quibbles between those modern languages seem much less important. I wish that people would like my favorite language, but if they all started using Java instead of C, that would cover 80% of my complaints...
Yes, syntax of Lisp is a real problem. I guess my point was just that lisp's syntax isn't representative of functional programming languages in general; it's just the way they chose to do it.
(As for me being academic -- it's true that I'm in grad school, and it's true that I'm idealistic, but I definitely do have a lot of experience writing code and building large programs!)
> Insofar as "its semantics... make it harder to > develop large programs", I can only believe you've > never used Python for a large program. Compared to > C or C++, Python is a gift from above.
Yes, I'm sure it's better than (especially) C and C++, but nothing compares to the module system of SML. It's true I don't know much python, but when I read about it, the ideas like dynamically adding methods to objects and such seemed good for hacking up scripts, but not good for big programs. There are probably ways they have for sealing off objects against this kind of programming, so maybe I just didn't read much into their modules system.
> or from elegance (LISP = Lots of Idiotic > Stupid Parenthesis)
I dunno what parentheses have to do with elegance, but I can tell you that LISP is not "as good as it gets" as far as elegant functional languages go.
I guess after that you say that programming functionally tends to produce better solutions (or "more elegant code")... that I will definitely agree with. =)
Slashdot Mirror
Um... Verilog has just barely C-esque syntax, but has entirely different semantics. It's a language for describing circuits, not a general purpose language.
Fonts that are hinted for screen display shouldn't be anti-aliased at small sizes. It makes them blurry. The font author has already essentially laid out the pixels exactly as they should appear for those sizes. At least give people the choice. (Do you play anti-aliased NES games on your emulator, or do you leave the pixels as-is?)
Second, it would be nice to have "ClearType" (that is, sub-pixel AA) on linux, too. Is anyone working on this?
I can reconstruct the image on my screen using the light coming off it, too.
I think that all it would take is for a nice MP3-sharing program with quality indexing and searching to be deployed on top of freenet. As long as it had a nice interface and was easy to install, you could easily get a bunch of freenet nodes off of people who care little about free speech, but who care lots about free music.
How does having it written in Java make it suffer? I ran a node for a while, and the performance was just fine. It's also nice to know it won't have any buffer overflows.
I can understand the desire for native-compiled code, but... C??
I'd love to, but Gnutella is crappy. The network is filled with bad and incomplete files, most stuff is misdescribed, and searching is totally lame. The gnutella folks really need to work on the availability and quality of content in the network.
I think maybe Gnutella is a good starting user base for some new evolution of the system, but right now it doesn't hold a candle to Morpheus (or especially, Napster).
Good call.
> If people want speed, why don't they bootstrap
> high-level languages from an interpreter to native
> code?
Well, high-level languages have the ability to be fast in native code to varying degrees. For instance, lisp and scheme can both be quite fast, though dynamic tag checking and dynamic scope (in lisp) hurt performance. SML wins for speed here because it's statically typed, but still pays for array bounds checks (usually, but we're working on it
Of course, as you mention, none of them are so much slower than C that they wouldn't be appropriate for applications. And as I said in my post, when development is that much easier, that leaves more time for optimization. =)
> You want this kind of functionality you can find
> it in a number of languages that exists today.
> Those languages - their runtime libs and their
> vm's, are built with c.
That's not necessarily true. SML compilers, for instance, usually compile directly to machine code. Sometimes we use C to interface to the operating system, but that's simply because the operating system is C-centric.
Regardless, hacking up virtual machines and garbage collectors sort of is C's domain. Kernel hacking, also C. (Though I wish we had a microkernel so that things like the filesystems, higher levels of the network stack, etc. could be written in modern languages.) Embedded systems, C. But most programmers don't write these things, they write applications -- and those are definitely not what C is good at.
Maybe you are simply taking issue with the title of my post, "Get rid of C!". I didn't really mean that. I mean, stop using C for application programming.
> Your post is definitely a troll
;)
Just because a post is provocative doesn't mean it's a troll. A troll post usually says something that the author doesn't really believe, just to get people fired up. I actually believe this, and I think it's worthwhile for the C-centric slashdot crowd to think about it.
> It's the passing by value, which prevents the
> compiler from inlining the function; the correct
> way to write that function is:
I disagree that this "prevents" the compiler from inlining. It might force the compiler to call the copy constructor (if it can't deduce that it has no effect), but there's no reason it "prevents" inlining. It may be that the compiler just doesn't inline it, sure.
I don't really see why programming in C gives you any more clue about when a C++ compiler will perform inlining, since that's basically an arbitrary choice made by the compiler.
That said, I agree that there is definitely a place for learning C in a well-rounded programmer's education. I've taught programming enough to know that... Programmers that don't know low-level programming won't be able to do low-level optimizations. BUT, I think the emphasis that slashdot folks place on low-level efficiency is highly overrated. I feel that C actually encourages programming styles that are BAD for programming in general; I think it can do more harm than good for a programmer to learn "efficient" programming in C. So while it's a good idea for people to learn it, I don't necessarily think that it's smart to learn C *before* you learn other high-level languages.
> Your example, by the way, in which a loop that
> increments elements of an array is parralelized
> in hardware, is actually simpler than you
> think.
Well, if you say so. People actually do their PhD theses on this kind of thing. In conversations with my friend, who actually works on these kinds of compilers, it seems that the problem is actually difficult. For instance, if there is almost any kind of memory write in the loop, then you need to do alias analysis to verify that it is not breaking the parallelism.
> Your particular example implies that the only
> real way to solve parralelism is to define
> parralel functions and human-solve them; this
> clearly violates the distinction between
> language and library, and doesn't really help
Well, let me reiterate my actual point: Instead of always working with C, languages should be adapted to the task at hand. C gives you an abstract view of a sequential machine -- and this is hardly how computers actually operate today (especially when compiling to hardware!) Having a language (even if like C) with a parallel array modification construct like SML's would make programs *easier* to write, and compilers better.
I don't know what you mean by violating the distinction between language and library. Why should parallelism be a library??
For the record, I wasn't encouraging Object Oriented programming, which I think is a bit of a sham -- but that's a different argument entirely.
> It's also _MUCH_ easier to write code without
> side effects, which is a bane to programming.
Hmm. I agree with what you say about C++ -- I think the language is awful -- and I agree that side effects are a bane to programming, but I definitely don't agree that C is good for side-effectless (ie, functional) programming.
For instance, implementing something as simple as binary trees without side-effects almost *requires* a garbage collector in order to get reasonable performance. (Maybe you could do something tricky with lazy reference counting, I dunno.)
In fact, since memory allocation is a side effect, even string manipulation in C is hard to pull off without side-effects. (How do you return a variable-sized string from a function?) On the contrary, C++ has value-semantics strings that make this possible.
And since C lacks first class functions (really, I should say it lacks nested functions, since you can actually pass around pointers), lots of the functional idioms just don't work.
What did you mean by this?
Goodness, this is an awfully empty review. Except for the comment about the author's native language (which humorously is followed up by an awkward if not ungrammatical sentence from the reviewer), this whole review could be applied to practically any programming book! What sets this book apart? If nothing, then why review it?
Anyway, the real reason I clicked on this article is because I just love a C debate. Since there's hardly anything to talk about with regard to the review, let's get to it!
Here's what I say: outside of the low-level systems crowd, C should die. We should *not* be teaching beginning programmers C or C++. C should not be the "default language" of computer programming.
Today, efficiency is no longer the primary concern about software. It has been ousted by robustness and ease/cost of development (modularity and reuse). C is awful for robustness (the language lets you "get away" with anything you want, though those things are seldom what you want in application software), and even worse for modularity and re-use. Modern languages, or even quasi-modern languages like Java, are far better than C for robustness and ease of development. They even win on some points which are typically seen as less important than efficiency: portability, elegance, etc.
Finally, the efficiency of high-level languages is comparable (though not as good as) C. Compiler technology is improving somewhat, as well. But since developing and debugging take less time, you have more time to optimize your program (if necessary), so I am not convinced that this is really a big deal. Yet, even if I need to concede the efficiency issue, I still believe modern languages beat C overall.
I'll be glad to argue about that stuff, but today I have a different point to make. C is also holding back the progress of other computer fields. Let me give you an example. My friend is working on compilers that compile high-level languages (to them, C is a high-level language) down to circuits. Here, discovering data parallelism in the code is probably the most difficult problem. Of course, the same issues arise in compiling to architectures like the IA-64 or even P4, where in order to get best execution speed, the compiler needs to figure out what instructions can be executed in parallel.
When they compile C, they need to look for common idioms (certain patterns of for-loop use), then analyze them to extract the parallel algorithm. For instance, this simple C loop adds k to every integer in an array a of size s:
for (int i = 0; i < s; i++) {
a[i] += k;
}
The idea is that the compiler should be able to produce a circuit that does all of the adding in parallel, on silicon. Since you all probably grew up on C, this seems like the totally natural way to write that code. In fact, it is short and it is straightforward. Unfortunately, it is less straightforward to a compiler. The compiler needs to prove to itself that the for loop can be parallelized -- what if the programmer changed k or a or i in the loop body? The C code actually says to run each loop iteration sequentially.
Of course, compiler writers have gotten pretty good at catching this particular idiom, but when the code gets more complicated (especially when the compiler needs to do alias analysis), it is not so good.
The chief problem here is that the programmer is unable to effectively communicate his parallel algorithm to the compiler. The programmer takes something in his mind "add k to all elements in the list", sequentializes it for C "for (int i = 0 ...", and then the compiler has to *undo* this sequentialization to produce the parallel code. In the process of translating, some information is always lost.
Now look how this code would be written in SML (a so-called "modern language"):
Array.modify (fn x => x + k) a
(fn x => x + k) is a function expression (SML lets you pass around functions), and Array.modify simply applies the function to every element in the array. Here, the compiler can very easily tell that my operation is parallel, because I used Array.modify! The code is also a bit shorter, and I also think that this code is a lot clearer. That's subjective, of course. BUT, I hope you will agree that for this example, the SML code is closer to what the programmer means, and easier for the compiler to understand.
Anyway, perhaps some of you will say that this particular issue is not a problem, or that it is already solved (I would like to hear the solution!). I merely mean to propose an example of a theme I have been observing over the past few years in many areas of computer science. Computer programming is about communicationg with the compiler or machine in such a way that it is easy for the human to create code, and easy for the machine to understand it. C was never particularly easy for a human to create (though we have become accustomed to it), and though it was once easy for a compiler to understand, this is becomming less and less true. When the language is neither optimal for humans nor optimal for compilers, doesn't that mean that something needs as change?
God, I hope that when we are programming internet-wide distributed applications we are not still programming at the level of memory addresses! That would be pretty damn awful...
Abstractions are where it's at, man.
This is totally dumb. The SSSCA is certainly a bad idea, but it's meant to force copy control mechanisms in hardware. It has nothing to do with this!
Looks like you need to read the story more carefully -- if you get all your information from Slashdot's misleading headlines, you're going to be pretty misinformed!
.NET). It's just a regular e-mail worm that happens to also have a .NET payload, part of which is written in C#.
This worm really has nothing to do with C# (or even
Same here. =)
I don't think that Morpheus is telling the whole story.
Last week they wrote something like, "one of our software providers made updates without telling us that made Morpheus software unable to connect to the network."
It sounds to me like FastTrack upgraded protocol versions, or something?
I don't see why Morpheus would voluntarily move to gnutella, since gnutella is quite inferior and their new software is pretty crummy. I've been looking around their forums and everything, but I can't seem to figure out what's actually going on. Anyone know any more info?
Slashdot: If you want to stay afloat, you should do this as gradually as possible. If you dump lots of changes on us all at once, and we don't like 'em, that might be enough to make us unhappy, and make us stop visiting -- and there's nothing like a lack of readership on a user-driven site to send it spiraling down the drain.
If you're going to make *negative* changes like these, you might consider making *positive* changes to offset it -- clean up the design of the site (you don't have to get rid of the green, just streamline it for all of the old obsolete stuff), implement some features people have been asking for forever (submission queue), etc.
Despite all its problems, it would be a shame to see this site go. This change could really do it, so be careful!
I'm with you for Google and friends, but slashdot is NOT a good example of good web design.
First, the graphics are just ugly. I dunno, I guess this is a subjective thing, but I have to read in "light mode" (which I think actually has a rather usable interface even on real browsers) or my eyes will fall out.
Second, the front page is filled with all sorts of clutter that needn't be there -- especially stuff that is old and hardly ever changes.
However, I agree with you that the content is the most important thing.
Everyone needs to decide this on their own, I think. How can I know what you'll like?
I think that above all other traits, though, these days I want my music to be honest. (Made by people not trying to do what they think their boss wants, but what *they* want.) I found that mp3.com is good for finding music like that.
Seriously, who cares if the RIAA is making more or less money as a result of Napster? I would actually prefer that they make less money...
Either way, they are going to be raising CD prices and chasing down the file sharing services. They are scared, and they want to remain in control.
For context, I have over 300 CDs... most are from independent labels. (I've recorded a *ton* of music myself; over 15 albums and a thousand songs...)
I like to think that I am listening to music made by people who do it because they love music, not because they want to make money. In fact, I typically think that artists shouldn't be selling CDs at all. It seems to me that if they want people to hear their music, they should make it as widely available as possible! To me, that means putting it on the internet, or at least giving a license for others to do so for you. (An exception is these low-run CDs that people sell at their shows, which typically cost only about $5 to $10; this is often more convenient for the purchaser than trying to find obscure songs on the internet.)
Some people will say stuff like, "artists deserve to be paid!". I say, artists deserve to be paid for live performance, or for commissions, but nobody deserves to be paid for duplication (essentially free) of a recording that already exists. Furthermore, if music is primarily a *job* for an artist, then his work is more craft than art, and I say that's a good reason not to care about it as much. (Do you think of yourself as a consumer or a fan? Do you purchase products or appreciate their beauty?)
So my solution is to buy music when it's most convenient (rarely), to download lots of free music by amateurs at mp3.com and other places, and to make my own free music. If every music lover did this, boy, would the world be a better place!
Living in a RIAA-free world is good; it feels moral (even if it is not always legal), and it pisses the right people off.
AC writes,
> Um, some of us like select-to-copy and
> middle-click-to-paste. To me, that's intuitive -
> the Windows Ctrl-C/Ctrl-V combo is what's strange.
>
> I don't consider it a problem at all.
I don't consider that a problem either, the problem is that it doesn't always work! It's fine when cutting and pasting between Xterms, but between xterms, mozilla, acrobat, emacs? It's a nightmare.
Hey, I agree. Copy/paste is one of the worst usability problems with KDE (and other window managers I've used).
It works perfectly in windows.
I hope that this news reminds some people that there are still basic problems to be addressed before linux on the desktop can go mainstream.
(OTOH, I am pretty impressed with KDE. It has been running 160 days straight on this box, and 160 days ago was my first boot... other window managers I've used have not been so stable.)
> Perl the language ...
> Because, being implemented in C, so has the JVM,
> no doubt. But you were claiming that Java is
> safe, and Perl is not.
The problem with this statement is that the perl language is essentially defined by its implementation. Therefore "perl" (the language) and "perl" (the program on my computer) are rather hard to distinguish. When I said that perl had buffer overflows, I was referring to the implementation. Of course, a JVM (at least one that doesn't do JIT compilation) is a lot simpler than the perl interpreter...
> So Java is more secure because it makes things
> more difficult?
Yes, actually. It makes certain things more difficult, which is bad for scripting tasks, but good for security. Personally, I believe that outside a scripting domain (and this does NOT include programs that run websites), it should be difficult to execute commands on the system or otherwise run code from the user input.
I personally have exploited several perl-based web scripts. Just as buffer overflows are easy to make in C, these kinds of bugs are perhaps even easier. (For instance, shelling out to the mail command with a user-supplied e-mail address on the command line.) I know and you know that there are ways to avoid this; the point is that the language makes it easy to do.
I guess I can say "Java is more secure" and you can say "Perl is more secure" all day. I doubt anybody has done a study. But I conjecture that there have been far more exploits of perl scripts than java programs.
> How can anyone say there are no overflows in the
> JVM? I can't see the code, or the development
> process, therefore my trust level is fairly low.
You can see the code to the JVM. There are a bunch of open-source implementations. Or, you can compile to native code with one of the many open source native compilers.
Finally, I'd like to point out that we're working on a solution to this problem, though it's not really mature enough for me to suggest that people use it yet. You and I both keep bringing up that parts of the system written in low-level languages can't be trusted -- the idea is to make trusted low-level languages, in the form of typed assembly language. With this, compilers compile to native code, but provide type annotations that another program can use to verify that the code is safe. The verifier is very tiny, and it would be feasible to prove its correctness. In this scenario, there is no virtual machine to trust, and we don't need to trust the compiler any more because we verify its output.
We're pretty close to having certifying compilers done for some nice high-level languages. (A few exist already for safe C variants.)
Here, check it out:
http://www.cs.cornell.edu/talc/
OK, I'm with you then. I agree that the difference between C and practically any modern safe language is big enough to make quibbles between those modern languages seem much less important. I wish that people would like my favorite language, but if they all started using Java instead of C, that would cover 80% of my complaints...
Yes, syntax of Lisp is a real problem. I guess my point was just that lisp's syntax isn't representative of functional programming languages in general; it's just the way they chose to do it.
(As for me being academic -- it's true that I'm in grad school, and it's true that I'm idealistic, but I definitely do have a lot of experience writing code and building large programs!)
> Insofar as "its semantics ... make it harder to
> develop large programs", I can only believe you've
> never used Python for a large program. Compared to
> C or C++, Python is a gift from above.
Yes, I'm sure it's better than (especially) C and C++, but nothing compares to the module system of SML. It's true I don't know much python, but when I read about it, the ideas like dynamically adding methods to objects and such seemed good for hacking up scripts, but not good for big programs. There are probably ways they have for sealing off objects against this kind of programming, so maybe I just didn't read much into their modules system.
> or from elegance (LISP = Lots of Idiotic
> Stupid Parenthesis)
I dunno what parentheses have to do with elegance, but I can tell you that LISP is not "as good as it gets" as far as elegant functional languages go.
I guess after that you say that programming functionally tends to produce better solutions (or "more elegant code")... that I will definitely agree with. =)