Yes, I agree. Not just functional, either; lots of their problems would be exquisitely tackled by a logic programming language like prolog or twelf. It saddens me that ACM is not progressive enough to encorporate even "known good languages" into their allowed set (yet would easily fall to Yet Another Procedural Language with corporate backing like Java).
There are lots of things that suck about the ACM contest, anyway. Personally, I think that the ICFP contest is much better, because:
- You can use any language, number of teammates, resources, etc.
- You get several days
- The problems are more interesting (sometimes unsolved)
- Work at home;)
I dunno, I thought the document was fine. It's not as good as an extremely formal (ie, practically executable) definition, but I was able to hack up a PDF writer in a few days from it. I remember what you say about the compression algoritms -- I just used code I found on the web called flate, and that worked. =)
I'll bet it is magnetic interference. One of my old offices was near a generator, and the monitor would go crazy all the time.
My friend's got this device that you use to amplify a telephone. You can also use it to listen to EM radiation -- put it near your monitor or electrical wires and hear a nice hum. If you get one of those (I'm sure they're pretty cheap) and hear a hum in the middle of your office with your equipment off, then you'll know you've got a problem.;)
> This seems to prove that the biggest part of lambda calculus isn't needed, doesn't it? Hardly a "win".
I don't know what you mean. All I'm saying is that the lambda calculus is a simpler and more foundational model of computation than turing machines. The fact that we can distill the essence of computation down to two closed lambda terms is a positive result!
> It certainly can be. I realize that any good OS has its memory protected, but there are > still many apps that allocate memory outside of their designated heap.
How do they do that? These days, a process has a large unified address space, and if it needs memory, it gets it from there. The OS cleans up afterwards. Or are you talking about other resources? (Other resources may typically leak, I will not deny that.)
Oh, what a sadly C-centric and mathematically unsophisticated world you live in! The point is to actually *implement* the turing machine (or combinatory logic reducer) in the language, not to simply spell the english words.
CDs are already the perfect size and rigidity, in my opinion. We should concentrate on packing more data into them (DVD, blue-laser, etc.), and making them more robust. I have never needed to bend a CD (what, am I going to put it through a fax machine?), nor would I like it if my CDs were bendy.
This is probably the most doomed pipe-dream OS I've ever seen.
First of all, their screenshot is a picture of gnome with an ugly color scheme and lots of stolen anime graphics.
Second, their website is uuugggggly. To make anyone care about a "cool" OS (or even window manager theme, if that's what they're actually doing), they're going to need it to look good, and that means having a graphic artist.
I agree with what you're saying in a sense. Right now the computer is most suitable for making electronic music. But -- I think electronic music is far more experimental than in the "real instruments" world. I think we've covered almost all of that territory, and most of it was done as far back as say, Beefheart.
For sure, digital instruments are not so good at replicating their analog equivalents. (Except perhaps for a nice digital piano.) I don't think anybody is claiming that.
One thing that the computer definitely does is make it cheaper for artists to record at home. I recorded about 200 songs last year, almost all were digitally multi-tracked, with effects and editing done on the computer. I used real instruments. But I was able to do it by myself, without a trip to an expensive studio... THAT certainly increased my ability to express myself.
I agree, and this is why I think we can finally do without the RIAA.
In fact -- I think we can do without copyright on music entirely; there are now plenty of people who can and do make music just for fun and distribute it at very low cost. In such a world, piracy is a feature, not a bug.
While I'm at it, here's my site of freeware plugins that you can use in most of these digital music programs: http://www.smartelectronix.com/~destroyfx/
> Perhaps we are talking about two very different things, I don't know. But I do know that > my original statement is quite correct. And somehow I think if I had just said that > Windows sucks and left Linux out of it that nobody would have challenged it.
If you had said Windows 98 sucks, yes, nobody would have argued with that. But NT, 2000, XP, and flavors of unix shouldn't have this problem.
I think the real problem is that your OS is not accurately reflecting how much memory is actually available. For instance, if it caches data read off the disk, it may very well keep the disk cache around after the process exits.
Whether I free() my memory or not, the operating system has the exact same job at the end of a process's life. This *can't* be an application problem.
> I don't think you see my point. Most objects simply belong on the stack. That doesn't > happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory > management.
Well, unfortunately Java has pretty dumb implementations. Some of my favorite implementations of garbage-collected languages like SML can allocate on the stack, and often do.
> Allocating dynamic memory is not always the answer and is much, much slower than just > using the heap.
What is the difference between "allocating dynamic memory" and "using the heap"? You mean the stack, right? (Otherwise I am confused..)
> Heap compaction is not nearly that important unless there is a great deal of allocation. > For most long running programs, allocation is rarely continuous. Usually, it is periodic, > in which, heap compaction does very little.
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs). A garbage collector can reclaim fragmented space in the heap that would be impossible to reclaim through standard uses of malloc. This reduces the working set and increases locality (for caches) which are of course good for performance.
Well, page rendering appears faster because of incremental reflows, but I don't think it is really faster. Anyway -- I agree that the slowest parts are starting the browser and opening a new window. Otherwise, Mozilla is actually quite fast.
Regardless of whether memory is "freed properly" in an application or not, it is the operating system's responsibility to return memory when the application ends. Fixing the memory leaks in mozilla will not change anything about what happens after mozilla exits.
It's pretty hard for me to believe that in a system with real virtual memory, that some physical memory would remain mapped to a process that doesn't even exist any more! And if it were, presumably it would be swapped to disk.
> While I do like memory safe languages and feel that C gives not only allows you to shoot > yourself in the foot this way, it also paints a bulls eye on your shoe, I'm afraid that > nothing will protect you from a bad programmer.
While it's true that nothing can really protect you from a bad programmer, it is still important to be able to isolate yourself from him -- to wrap his code up behind an abstraction boundary so that his bugs cannot make the rest of the program unstable. I think that fault detection and isolation is the key to large software design, and C fails miserably at this. (Any heap corruption bug can easily cause problems across abstraction boundaries.)
It's definitely slower than NS4.7, but that's mostly because its rendering engine supports a lot more. (And also because the architecture is pretty bloated, but there are some benefits to that.)
You might need a faster computer. I still use NS on my laptop, but Mozilla is nice and fast on my desktop.
Are you running windows 98 or something? When an application ends, the memory it consumed is freed. That's the operating system's job, and all of the modern operating systems (NT, 200, XP, Linux, OS X) do a fine job of that.
Now, imagine what would happen to productivity if you just programmed in a language where these kinds of bugs (and others that efence does not catch) simply couldn't happen! Don't forget that in order for efence or purify (or great circle, for that matter) to work, you need to be able to trigger the bug at run-time...
This should really be on the slashdot main page! Here are my comments.
To: senate.gov
I'm currently a PhD student at Carnegie Mellon University and a computer science researcher. I'm writing to express my dismay that the Senate is considering passing a law that would require DRM technologies to be built into hardware and software systems.
Honestly, I cannot imagine doing computer research in a country where computers and the software that runs them are built with tamper-proof components to implement DRM. We often need access to the internals of the computer, and we almost always work on consumer-level commodity hardware. Forcing us to purchase special hardware would dramatically increase our research costs and reduce the relevance of our research to real-world systems.
Several of my hobbies involve creating content: music, typefaces, and software that would likely to be subject to DRM. As a content developer, I am worried that mandated DRM will inhibit my ability to freely distribute content that I own the copyright for, by placing restrictions on content formats or requiring certificates from an external authority.
As a consumer, of course I dislike the increasing insistence of copyright holders to control the use of content that I "license" from them. I also would resent having to pay for the extra hardware and development overhead to include DRM in my electronic devices!
Copyright infringement will remain illegal whether or not DRM is legally mandated. But in a world with mandatory DRM, we lose the ability to exercise some rights we historically have enjoyed, such as fair use and the first sale doctrine. We also face the very strong possibility that our technology industries and research communities will be stifled. Mandated DRM is a bad choice on all counts!
I'm not sure what your point is -- C++ has value semantics strings by using reference counting, but the same trick does not scale well to something like a tree data structure.
> If good programmers weren't penalized by it, then I would full heartily support garbage > collection. Languages should not sacrifice in order to support user-error.
I guess the penalty is "not having to manage his/her own memory", or something like that? Though the loss of control can be significant for some applications (like the kernel or embedded devices), I really don't think it is important for most of the kinds of projects that people use C and C++ for. Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
If you mean a performance penalty, well, GC overhead can be very low, and can also improve the performance of applications (heap compaction is important for long-running apps, and allocation is typically faster than malloc in a GC system). (And just because the JVM is inefficient doesn't mean that all GC'd languages are!;)) Spending less time managing low-level details gives you more time to optimize algorithms, which all good programmers know is where the real speed gains are.
Again, I'm not really suggesting a garbage collector in the kernel, nor trying to write a monolithic kernel in a high level language. I think both would be possible, but they don't fit into the model that's currently used in, say, linux. I basically agree with what you're saying.
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
>> But either way, I don't think any "tradeoff" that sacrifices correctness for speed is >> really a "tradeoff", it's just a mistake. > > What is truely needed is a mechanism to perform allocation/deallocation during compile > time instead of run time. A mechanism to determine when a pointer is no longer valid > and then inserts a deallocation within the code at that point. Solving poor programming > during run-time is just a bad idea.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
But, a mechanism that is as you describe is "regions". You might read about that; it's a totally compile-time memory allocation inference scheme. (Unfortunately it is somewhat less flexible than garbage collection, but it does perform well.)
Slashdot Mirror
Yes, I agree. Not just functional, either; lots of their problems would be exquisitely tackled by a logic programming language like prolog or twelf. It saddens me that ACM is not progressive enough to encorporate even "known good languages" into their allowed set (yet would easily fall to Yet Another Procedural Language with corporate backing like Java).
;)
There are lots of things that suck about the ACM contest, anyway. Personally, I think that the ICFP contest is much better, because:
- You can use any language, number of teammates, resources, etc.
- You get several days
- The problems are more interesting (sometimes unsolved)
- Work at home
I dunno, I thought the document was fine. It's not as good as an extremely formal (ie, practically executable) definition, but I was able to hack up a PDF writer in a few days from it. I remember what you say about the compression algoritms -- I just used code I found on the web called flate, and that worked. =)
I'll bet it is magnetic interference. One of my old offices was near a generator, and the monitor would go crazy all the time.
;)
My friend's got this device that you use to amplify a telephone. You can also use it to listen to EM radiation -- put it near your monitor or electrical wires and hear a nice hum. If you get one of those (I'm sure they're pretty cheap) and hear a hum in the middle of your office with your equipment off, then you'll know you've got a problem.
Ah, good thing they've been holding off on Team Fortress 2 for YEARS in order to create this masterpiece.
Back to work, Valve!
> This seems to prove that the biggest part of lambda calculus isn't needed, doesn't it? Hardly a "win".
I don't know what you mean. All I'm saying is that the lambda calculus is a simpler and more foundational model of computation than turing machines. The fact that we can distill the essence of computation down to two closed lambda terms is a positive result!
> It certainly can be. I realize that any good OS has its memory protected, but there are
> still many apps that allocate memory outside of their designated heap.
How do they do that?
These days, a process has a large unified address space, and if it needs memory, it gets it from there. The OS cleans up afterwards. Or are you talking about other resources? (Other resources may typically leak, I will not deny that.)
Oh, what a sadly C-centric and mathematically unsophisticated world you live in!
The point is to actually *implement* the turing machine (or combinatory logic reducer) in the language, not to simply spell the english words.
More proof that lambda calculus IS the fundamental model of computation, NOT turing machines.
;)
Now, which one is your favorite programming language closer to?
Yeah, but that was only because it would hardly register your fingers unless you pressed hard. I think it could work if it accepted light touches..
CDs are already the perfect size and rigidity, in my opinion. We should concentrate on packing more data into them (DVD, blue-laser, etc.), and making them more robust. I have never needed to bend a CD (what, am I going to put it through a fax machine?), nor would I like it if my CDs were bendy.
This is probably the most doomed pipe-dream OS I've ever seen.
First of all, their screenshot is a picture of gnome with an ugly color scheme and lots of stolen anime graphics.
Second, their website is uuugggggly. To make anyone care about a "cool" OS (or even window manager theme, if that's what they're actually doing), they're going to need it to look good, and that means having a graphic artist.
Third, anime.
Goooood luck...
I agree with what you're saying in a sense. Right now the computer is most suitable for making electronic music. But -- I think electronic music is far more experimental than in the "real instruments" world. I think we've covered almost all of that territory, and most of it was done as far back as say, Beefheart.
... THAT certainly increased my ability to express myself.
For sure, digital instruments are not so good at replicating their analog equivalents. (Except perhaps for a nice digital piano.) I don't think anybody is claiming that.
One thing that the computer definitely does is make it cheaper for artists to record at home. I recorded about 200 songs last year, almost all were digitally multi-tracked, with effects and editing done on the computer. I used real instruments. But I was able to do it by myself, without a trip to an expensive studio
I still find it hilarious that kid 606's most popular song is one that Hrvatski made. Why not just link to Hrvatski? I think he is much more clever...
I agree, and this is why I think we can finally do without the RIAA. In fact -- I think we can do without copyright on music entirely; there are now plenty of people who can and do make music just for fun and distribute it at very low cost. In such a world, piracy is a feature, not a bug. While I'm at it, here's my site of freeware plugins that you can use in most of these digital music programs: http://www.smartelectronix.com/~destroyfx/
> Perhaps we are talking about two very different things, I don't know. But I do know that
> my original statement is quite correct. And somehow I think if I had just said that
> Windows sucks and left Linux out of it that nobody would have challenged it.
If you had said Windows 98 sucks, yes, nobody would have argued with that. But NT, 2000, XP, and flavors of unix shouldn't have this problem.
I think the real problem is that your OS is not accurately reflecting how much memory is actually available. For instance, if it caches data read off the disk, it may very well keep the disk cache around after the process exits.
Whether I free() my memory or not, the operating system has the exact same job at the end of a process's life. This *can't* be an application problem.
> I don't think you see my point. Most objects simply belong on the stack. That doesn't
> happen in Java. In fact, that is exactly why there is a stack, to provide automatic memory
> management.
Well, unfortunately Java has pretty dumb implementations. Some of my favorite implementations of garbage-collected languages like SML can allocate on the stack, and often do.
> Allocating dynamic memory is not always the answer and is much, much slower than just
> using the heap.
What is the difference between "allocating dynamic memory" and "using the heap"? You mean the stack, right? (Otherwise I am confused..)
> Heap compaction is not nearly that important unless there is a great deal of allocation.
> For most long running programs, allocation is rarely continuous. Usually, it is periodic,
> in which, heap compaction does very little.
I'd be interested in hearing your reasoning behind this. I believe that heap compaction helps especially in cases of long running programs that do infrequent allocation but have long-lived data (the common case for long-running programs). A garbage collector can reclaim fragmented space in the heap that would be impossible to reclaim through standard uses of malloc. This reduces the working set and increases locality (for caches) which are of course good for performance.
Well, page rendering appears faster because of incremental reflows, but I don't think it is really faster. Anyway -- I agree that the slowest parts are starting the browser and opening a new window. Otherwise, Mozilla is actually quite fast.
Regardless of whether memory is "freed properly" in an application or not, it is the operating system's responsibility to return memory when the application ends. Fixing the memory leaks in mozilla will not change anything about what happens after mozilla exits.
It's pretty hard for me to believe that in a system with real virtual memory, that some physical memory would remain mapped to a process that doesn't even exist any more! And if it were, presumably it would be swapped to disk.
> While I do like memory safe languages and feel that C gives not only allows you to shoot
> yourself in the foot this way, it also paints a bulls eye on your shoe, I'm afraid that
> nothing will protect you from a bad programmer.
While it's true that nothing can really protect you from a bad programmer, it is still important to be able to isolate yourself from him -- to wrap his code up behind an abstraction boundary so that his bugs cannot make the rest of the program unstable. I think that fault detection and isolation is the key to large software design, and C fails miserably at this. (Any heap corruption bug can easily cause problems across abstraction boundaries.)
That's how higher-level safe languages help.
It's definitely slower than NS4.7, but that's mostly because its rendering engine supports a lot more. (And also because the architecture is pretty bloated, but there are some benefits to that.)
You might need a faster computer. I still use NS on my laptop, but Mozilla is nice and fast on my desktop.
Are you running windows 98 or something?
When an application ends, the memory it consumed is freed. That's the operating system's job, and all of the modern operating systems (NT, 200, XP, Linux, OS X) do a fine job of that.
Now, imagine what would happen to productivity if you just programmed in a language where these kinds of bugs (and others that efence does not catch) simply couldn't happen! Don't forget that in order for efence or purify (or great circle, for that matter) to work, you need to be able to trigger the bug at run-time...
This should really be on the slashdot main page! Here are my comments.
To: senate.gov
I'm currently a PhD student at Carnegie Mellon University and a computer
science researcher. I'm writing to express my dismay that the Senate is
considering passing a law that would require DRM technologies to be built
into hardware and software systems.
Honestly, I cannot imagine doing computer research in a country where
computers and the software that runs them are built with tamper-proof
components to implement DRM. We often need access to the internals of the
computer, and we almost always work on consumer-level commodity hardware.
Forcing us to purchase special hardware would dramatically increase our
research costs and reduce the relevance of our research to real-world
systems.
Several of my hobbies involve creating content: music, typefaces, and
software that would likely to be subject to DRM. As a content developer,
I am worried that mandated DRM will inhibit my ability to freely
distribute content that I own the copyright for, by placing restrictions
on content formats or requiring certificates from an external authority.
As a consumer, of course I dislike the increasing insistence of copyright
holders to control the use of content that I "license" from them. I also
would resent having to pay for the extra hardware and development overhead
to include DRM in my electronic devices!
Copyright infringement will remain illegal whether or not DRM is legally
mandated. But in a world with mandatory DRM, we lose the ability to
exercise some rights we historically have enjoyed, such as fair use and
the first sale doctrine. We also face the very strong possibility that our
technology industries and research communities will be stifled. Mandated
DRM is a bad choice on all counts!
Sincerely,
Tom Murphy
I'm not sure what your point is -- C++ has value semantics strings by using reference counting, but the same trick does not scale well to something like a tree data structure.
;)) Spending less time managing low-level details gives you more time to optimize algorithms, which all good programmers know is where the real speed gains are.
> If good programmers weren't penalized by it, then I would full heartily support garbage
> collection. Languages should not sacrifice in order to support user-error.
I guess the penalty is "not having to manage his/her own memory", or something like that? Though the loss of control can be significant for some applications (like the kernel or embedded devices), I really don't think it is important for most of the kinds of projects that people use C and C++ for. Much more important is correctness, and as we see time and time again, even "good programmers" make mistakes that can sometimes be devastating.
If you mean a performance penalty, well, GC overhead can be very low, and can also improve the performance of applications (heap compaction is important for long-running apps, and allocation is typically faster than malloc in a GC system). (And just because the JVM is inefficient doesn't mean that all GC'd languages are!
Again, I'm not really suggesting a garbage collector in the kernel, nor trying to write a monolithic kernel in a high level language. I think both would be possible, but they don't fit into the model that's currently used in, say, linux. I basically agree with what you're saying.
Is it really true that malloc and free are not used in the kernel? I thought there was like kmalloc and kfree that acted just like those, and I would assume they are implemented in a similar way. I don't know, I've never actually worked on the linux kernel, but when I did my own kernel in school I had stuff like that.
>> But either way, I don't think any "tradeoff" that sacrifices correctness for speed is
>> really a "tradeoff", it's just a mistake.
>
> What is truely needed is a mechanism to perform allocation/deallocation during compile
> time instead of run time. A mechanism to determine when a pointer is no longer valid
> and then inserts a deallocation within the code at that point. Solving poor programming
> during run-time is just a bad idea.
Garbage collection doesn't solve "poor programming"; it's a feature that a language offers that makes it easier to write programs. Of course, you can write poor programs in a language with any set of features.
But, a mechanism that is as you describe is "regions". You might read about that; it's a totally compile-time memory allocation inference scheme. (Unfortunately it is somewhat less flexible than garbage collection, but it does perform well.)