That is also nitpicking. How old was your grandfather when he created said data?...Fine, I'll use semantics. Your grandfather did lose all his data, by dying. He no longer has access to any of it. Not that making backups would've helped...
Do you have anything to back that up, or is it pure speculation?
Microsoft does, in fact, have a very interesting project to write everything in.NET -- but that's in their research labs. I very much doubt it was used at all in Vista.
I've never heard this before, and I don't quite understand why C couldn't generate bootloader code or particular drivers. In the sense that C is turing-complete, you could always write a bit of custom C code that outputs assembly and then runs it. But from what I understand, this is the kind of thing that it makes sense to do in assembly, the first time.
If you've got some new USB device, you won't be able to interface with it in Ruby. Well, in the sense that Ruby is written in C, there's no reason to believe this will always be the case. But it's also a case where you'd do it once -- you implement your USB library for Ruby, and you do that in C. Then you write the actual driver in Ruby.
But this problem doesn't really exist in C/C++, because you can always get to the hardware. In exactly the same sense that you can in Ruby. Unless I'm missing something, you're doing this with functions -- standard library functions, maybe, but functions nonetheless, some of which will be assembly.
The rest of the time, when people implement C/C++ code for a higher level language, they are using a heuristic approach. Something like "I think function X will be important, so I'll implement in C to make it faster." That is pretty obviously the wrong way to do it, yes. What you'd do instead is write it in Ruby, profile it, and rewrite the slowest parts in C -- assuming you even need that performance. But in standard libraries, I think it makes sense -- it mostly bothers me that Ruby is slow enough that C can be a significant improvement. I don't think this always has to be the case.
The day we get 2ghz 128 cores in a tiny usb stick for $40, will be the day we program in flow chart/gui thingos. You have no idea what you're talking about, do you?
Just like stargate... rack full of usb3 slots... Nope. No idea at all. (For the record, Stargate computer science has been pretty horrible, and what makes you think it'd be usb, and not FireWire or something else?)
But we have this kind of power now. People can, and do, program things intended to run on massive clusters/supercomputers. (Actually, it can be more challenging to make something do that much in parallel -- most programs won't take advantage of two cores, let alone 128.)
The fact is, there have been experiments in GUI-based programming. They almost universally sucked. We have enough problems with the languages we have right now -- I don't think we, as a species, quite grok how to design UIs of any kind.
And at the same time, my current language of choice for large projects is Ruby, which was designed to be programmer-friendly, even if that meant it was incredibly inefficient. Turns out, there are a lot of apps where performance doesn't matter at all, and a lot more where you can simply throw CPU at the problem -- sometimes literally; in a well-designed Ruby on Rails app, you can simply buy another server or ten if you get slashdotted.
Why do these programming language discussions always end with people professing their unhealthy obsession with assembly? I'm not sure, but if it bothers you, why not reply to one of them?
That was sarcasm. Read great-grandparent.
I don't see any justifiable reason for assembly to stick around except for the part where you C/C++ application switches to it when displaying disassembly code. There are things which C/C++ can't actually generate -- I believe chunks of bootloader code, and certain drivers. OS-level stuff.
And there are places where it makes sense to use inline assembly in an otherwise C/C++ program, just as there are places where it makes sense to compile a C/C++ extension for a language like Ruby, Python, or Perl. It's just not what you should be doing for most of the application.
There is a common belief that optimizing compilers negate the speed advantages of hand-coded assembly language. The MenuetOS project demonstrates quite clearly that this is not only false, but VERY false. Benchmarks, please.
Perhaps it's because it's such a small project, and hasn't yet built up years worth of cruft, inefficiency, and bad code?
When you further consider that it's a very small team of developers who have created that in a relatively short time, when compared to Linux, this becomes even more impressive. When you also consider that Linux was developed at a time when many of the concepts in that OS didn't exist, it also becomes irrelevant.
Yes, I am amazed at the project. I also think it is rather a pointless waste of time, somewhat akin to the hanoimania project.
Find a similar group of developers. Give them C, and allow assembly only where needed. See what they can come up with in a similar amount of time. Comparing to Linux is like comparing any modern OS to Vista -- how does it stack up against, oh, BeOS?
Let's also consider that anything you can do in any other language, you can, by definition, do in assembly language.... With the proper tools What kind of tools? A macro handler? A preprocessor? A little regex for better syntax, especially for commonly used patterns?
I know! I'll call it a "compiler"!
The differences start to show up when you code more complex programs -- you know, like actual software. At which point, the difficulty, verbosity, and fragility of hand-coded assembly might start to become prohibitive.
Simplest example: Remember that old discussion "GOTO considered harmful"? There are actually a few niche cases, in languages which can handle a GOTO cleanly, where it's cleaner and more efficient than structured code. But in the vast majority of cases, GOTO is more trouble than it's worth.
Plus, that super-optimized compiler code? Not many people do that, anyway. They've discovered the joy that is "fast enough".
most of what you've heard about assembly language programming (and C programming in comparison), is really very wrong So far, everything you've said has really only convinced me of how right it is -- at the very least, that whatever performance benefit I might gain from hand-coded ASM is not at all worth the development time versus C, let alone the complete non-portability of the code.
If you really want to argue it, give me some benchmarks of complex programs. Something reasonably complex, but standard enough that a benchmark might work -- I imagine a codec might work. Oh, and include development time, when possible.
Regardless of what you call it, assembly can't go away until the processor interface changes to something completely different It could, however, be relegated entirely to compliers. But people do use it elsewhere -- a tightest-of-the-tight-loops in your C++ app (probably a game), which you rewrite in assembly for performance reasons.
I was presenting assembly as an example of a low-level language that is considered pointless for 99.9% of software development, and really only has a few niche uses. C and C++ should be the same way, but instead, people still write whole apps in C++.
You can't use Java or C# to write a memory manager; they already assume you have one as part of the runtime. Nothing stopping the runtime from containing a memory manager -- which makes it a kernel of sorts, depending on how you define it. And, for that matter, it does contain a garbage collector, and I assume it maintains a heap such that it isn't calling malloc/free all the time -- maybe you could just tell it that it has all of RAM allocated to itself?
But there are things which are put in OS kernels today which really don't belong there. There's no reason you couldn't write a filesystem in Java -- or in Python, for that matter. But right now, just about all filesystems are in the kernel.
Given current kernel implementations and concepts, filesystems go in the kernel for performance reasons. But that's about it -- and many special-purpose filesystems end up being written for Fuse instead.
The majority of "OS code" these days could comfortably be written in C++ I'm going to argue that the majority of "OS code" doesn't need to be in the kernel, and we'd be better off if it was written in, well, anything but C. (Except C++, which is almost worse...)
This isn't a microkernel vs * debate, as that implies Unix-like concepts of processes vs threads, and shared vs protected memory -- the first might be irrelevant in other OSes, the second is a false dichotomy.
Sounds like Last Measure, the ultimate GNAA troll.
Regardless, I would be very suspect of any rds.yahoo.com links -- rds appears to be some sort of Yahoo redirection service. Treat it as you would tinyurl, etc.
Which is why most of the "new kids" -- Python, Perl, Ruby (though Perl is getting kind of old now) -- support C extensions.
Would I actually write h.264 encoding/decoding in Ruby? No, not really.
Would I write a video app in Ruby? Absolutely -- just call out to the existing h.264 library (and mjpeg, etc) when I need to do the performance-intensive (and also boring) stuff.
That doesn't mean it will be particularly popular, or very likely that you can get a job in doing nothing but assembly programming.
Really, with C especially, just about every advantage it has over more modern languages are advantages that C itself has over assembly. Assembly is still needed, but no one in their right mind would, say, write an entire OS in assembly.
The day is coming when no one in their right mind will write an entire OS in C or C++, or even an entire OS kernel -- depending on your definition of "kernel".
Further, there's a tech note that says using FileVault with software like iMovie or Final Cut is contra-indicated due to the additional overhead. And that is video editing software, which I'd imagine is a good deal more intensive than movie playing software.
Read Popular Mechanics from the late 1960s or 1970s. There was a flying car on the cover of one issue (the car was red, and looked like a Peuguot). Did it actually work, though? Did they actually fly a prototype around? Or was it just a concept?
I understand adobe's position. It's the same as sun's on java. Except Sun has, in fact, open-sourced the client.
They're afraid that by open-sourcing the player, people will fork the standard, and they'll lose the business value of the flash platform (write once, run anywhere). They've already lost that -- by keeping the client closed, you can now write once and run on very specific browsers, on very specific hardware. You can run it on the lowest common denominator, but that's true of straight ActiveX, also.
And the answer is even simpler: Provide a completely open source player, and keep the trademark. No one can make a third-party player and claim it's Flash. Allow webpages to detect what version the client is, and allow clients to lie about it.
They're not even consistent about that position -- take PDF, which is actually an open standard, with implementations everywhere, many of them not by Adobe. Yet they still sell PDF tools.
Anyway, I thought the point of the Flash platform was that it has strong developer tools, and that it does things HTML can't.
Still doesn't answer the question: Is it really worth it for $60/mo when VPN over wifi will do? Or is it that it's worth the $60/mo for the increased coverage?
Onto DVDs, onto large web services (Amazon AWS), or onto other hard drives.
Or you backup what you care about. Out of that 500 gig disk, is there actually 500 gigs you care about losing? 250 gigs? 100 gigs?
I'll bet you can find 10 gigs or so that you actually need -- figure another 10 gigs for the OS if you're on Vista, and 20 gigs is pretty easy to backup these days.
Second, this is telephony, meaning it is the infrastructure on which the internet is based. There's no dns tricks or tcp/ip you can use to send people to a different "server" if that server is the switch connected to your fiber backbone. Basically, there are points in the infrastructure where there are by necessity a single chokepoint. To summarize: Who load-balances the load-balancers? Linux makes a pretty decent load-balancer, but this would make it that much better.
One wonders how he manages to still be one of the richest bastards in the world, and yet lack so fundamental an understanding of the world from which he got his billions.
He's using the term "free software" in a context where it might be misinterpreted -- and using the term "open source" to refer to GPL'd software -- in other words, he has the terminology exactly backwards. He doesn't like free-as-in-freedom software, and he actually does take advantage of purely "open source" (the BSD stack).
And frankly, I think if you "invent" a "drug" by adding a little sugar to the one I'm already giving away for free, you shouldn't be able to charge for it without my permission. Is that so radical?
Slashdot Mirror
That is also nitpicking. How old was your grandfather when he created said data? ...Fine, I'll use semantics. Your grandfather did lose all his data, by dying. He no longer has access to any of it. Not that making backups would've helped...
Do you have anything to back that up, or is it pure speculation?
.NET -- but that's in their research labs. I very much doubt it was used at all in Vista.
Microsoft does, in fact, have a very interesting project to write everything in
But we have this kind of power now. People can, and do, program things intended to run on massive clusters/supercomputers. (Actually, it can be more challenging to make something do that much in parallel -- most programs won't take advantage of two cores, let alone 128.)
The fact is, there have been experiments in GUI-based programming. They almost universally sucked. We have enough problems with the languages we have right now -- I don't think we, as a species, quite grok how to design UIs of any kind.
And at the same time, my current language of choice for large projects is Ruby, which was designed to be programmer-friendly, even if that meant it was incredibly inefficient. Turns out, there are a lot of apps where performance doesn't matter at all, and a lot more where you can simply throw CPU at the problem -- sometimes literally; in a well-designed Ruby on Rails app, you can simply buy another server or ten if you get slashdotted.
That was sarcasm. Read great-grandparent. I don't see any justifiable reason for assembly to stick around except for the part where you C/C++ application switches to it when displaying disassembly code. There are things which C/C++ can't actually generate -- I believe chunks of bootloader code, and certain drivers. OS-level stuff.
And there are places where it makes sense to use inline assembly in an otherwise C/C++ program, just as there are places where it makes sense to compile a C/C++ extension for a language like Ruby, Python, or Perl. It's just not what you should be doing for most of the application.
Seriously, if I just need to dash off a quick little program, C is about the last thing I would use. Think Bash.
Perhaps it's because it's such a small project, and hasn't yet built up years worth of cruft, inefficiency, and bad code? When you further consider that it's a very small team of developers who have created that in a relatively short time, when compared to Linux, this becomes even more impressive. When you also consider that Linux was developed at a time when many of the concepts in that OS didn't exist, it also becomes irrelevant.
Yes, I am amazed at the project. I also think it is rather a pointless waste of time, somewhat akin to the hanoimania project.
Find a similar group of developers. Give them C, and allow assembly only where needed. See what they can come up with in a similar amount of time. Comparing to Linux is like comparing any modern OS to Vista -- how does it stack up against, oh, BeOS? Let's also consider that anything you can do in any other language, you can, by definition, do in assembly language.... With the proper tools What kind of tools? A macro handler? A preprocessor? A little regex for better syntax, especially for commonly used patterns?
I know! I'll call it a "compiler"! The differences start to show up when you code more complex programs -- you know, like actual software. At which point, the difficulty, verbosity, and fragility of hand-coded assembly might start to become prohibitive.
Simplest example: Remember that old discussion "GOTO considered harmful"? There are actually a few niche cases, in languages which can handle a GOTO cleanly, where it's cleaner and more efficient than structured code. But in the vast majority of cases, GOTO is more trouble than it's worth. Plus, that super-optimized compiler code? Not many people do that, anyway. They've discovered the joy that is "fast enough". most of what you've heard about assembly language programming (and C programming in comparison), is really very wrong So far, everything you've said has really only convinced me of how right it is -- at the very least, that whatever performance benefit I might gain from hand-coded ASM is not at all worth the development time versus C, let alone the complete non-portability of the code.
If you really want to argue it, give me some benchmarks of complex programs. Something reasonably complex, but standard enough that a benchmark might work -- I imagine a codec might work. Oh, and include development time, when possible.
I was presenting assembly as an example of a low-level language that is considered pointless for 99.9% of software development, and really only has a few niche uses. C and C++ should be the same way, but instead, people still write whole apps in C++. You can't use Java or C# to write a memory manager; they already assume you have one as part of the runtime. Nothing stopping the runtime from containing a memory manager -- which makes it a kernel of sorts, depending on how you define it. And, for that matter, it does contain a garbage collector, and I assume it maintains a heap such that it isn't calling malloc/free all the time -- maybe you could just tell it that it has all of RAM allocated to itself?
But there are things which are put in OS kernels today which really don't belong there. There's no reason you couldn't write a filesystem in Java -- or in Python, for that matter. But right now, just about all filesystems are in the kernel.
Given current kernel implementations and concepts, filesystems go in the kernel for performance reasons. But that's about it -- and many special-purpose filesystems end up being written for Fuse instead.
This isn't a microkernel vs * debate, as that implies Unix-like concepts of processes vs threads, and shared vs protected memory -- the first might be irrelevant in other OSes, the second is a false dichotomy.
I wonder if anyone else caught it... This should be:
"with C... just about every advantage it has over more modern languages are advantages that assembly has over C itself."
Yes, because any version of LOTR which doesn't stay true to the source, and have a dancing, singing Tom Bombadil, isn't worth watching.
Being from America, I really don't care where the director comes from.
This one in particular -- he did Pan's Labyrinth. He'll do a good job with the Hobbit.
Couldn't have said it better. The closest thing I've found to Tolkien is Dune.
If it's anything like Pan's Labyrinth, it'll be worth watching -- del Toro isn't bad.
Sounds like Last Measure, the ultimate GNAA troll.
Regardless, I would be very suspect of any rds.yahoo.com links -- rds appears to be some sort of Yahoo redirection service. Treat it as you would tinyurl, etc.
Which is why most of the "new kids" -- Python, Perl, Ruby (though Perl is getting kind of old now) -- support C extensions.
Would I actually write h.264 encoding/decoding in Ruby? No, not really.
Would I write a video app in Ruby? Absolutely -- just call out to the existing h.264 library (and mjpeg, etc) when I need to do the performance-intensive (and also boring) stuff.
Assembly will always be there. Period.
That doesn't mean it will be particularly popular, or very likely that you can get a job in doing nothing but assembly programming.
Really, with C especially, just about every advantage it has over more modern languages are advantages that C itself has over assembly. Assembly is still needed, but no one in their right mind would, say, write an entire OS in assembly.
The day is coming when no one in their right mind will write an entire OS in C or C++, or even an entire OS kernel -- depending on your definition of "kernel".
And the answer is even simpler: Provide a completely open source player, and keep the trademark. No one can make a third-party player and claim it's Flash. Allow webpages to detect what version the client is, and allow clients to lie about it.
They're not even consistent about that position -- take PDF, which is actually an open standard, with implementations everywhere, many of them not by Adobe. Yet they still sell PDF tools.
Anyway, I thought the point of the Flash platform was that it has strong developer tools, and that it does things HTML can't.
Still doesn't answer the question: Is it really worth it for $60/mo when VPN over wifi will do? Or is it that it's worth the $60/mo for the increased coverage?
Onto DVDs, onto large web services (Amazon AWS), or onto other hard drives.
Or you backup what you care about. Out of that 500 gig disk, is there actually 500 gigs you care about losing? 250 gigs? 100 gigs?
I'll bet you can find 10 gigs or so that you actually need -- figure another 10 gigs for the OS if you're on Vista, and 20 gigs is pretty easy to backup these days.
I updated the machines I really want to be ready some two days ago, and I won't touch apt-get for probably another two days.
So in the meantime, I'm actually getting some work done!
One wonders how he manages to still be one of the richest bastards in the world, and yet lack so fundamental an understanding of the world from which he got his billions.
He's using the term "free software" in a context where it might be misinterpreted -- and using the term "open source" to refer to GPL'd software -- in other words, he has the terminology exactly backwards. He doesn't like free-as-in-freedom software, and he actually does take advantage of purely "open source" (the BSD stack).
And frankly, I think if you "invent" a "drug" by adding a little sugar to the one I'm already giving away for free, you shouldn't be able to charge for it without my permission. Is that so radical?