Maybe they should call the "Evil Bit" the DRM bit.
DRM packets are the only non-evil packets, of course.;-)
Also, it looks like/.'s implemented the bit already, and it's had a negative impact on TCP/IP retransmits. Particularly packets that result in an article being posted (and reposted) to/.
Stack based languages are cool for some things. I love my RPN calculator -- it's a lot more efficient for typical computation. After using one, I feel my brain contort when I try to use a standard algebraic calculator. It's as if I need to figure out how to "engineer" my expression into the constraints imposed by order of evaluation.
One word of warning, though: Stack-based machines have scalability problems when you try to make things high-performance.
That's due primarily to the inherently serial nature of stack accesses. The stack becomes an artificial synchronization point for otherwise independent operations.
Sure, you can use fancy techniques in order to reconstruct the original directed-acyclic graph (DAG) of instructions from the series of stack operations, but wouldn't you rather just start with the DAG to begin with? With a register-machine model, each register is essentially an edge (or set of edges) in the DAG.
Much more direct.
Ahhhh... but I digress.
As for first programming language: I agree, good I/O (including graphics, and some easy way to do both blocking and non-blocking input) is key to retaining interest. That's why LOGO and (old fashioned) BASIC are so good! It's easy to make it "do things", where "do things" is defined as stuff happening on the screen.
I wouldn't wait too long, though, before introducing your budding programmer to something more industrial strength. It took years for the dain brammage that BASIC gave me to subside. Even Pascal wasn't a complete cure. C was much better, since it's a language that's strong enough that it can implement the bulk of its own standard library within the language.
You can't do that with Pascal. You can't implement write/writeln within the language. You can't even write a function that accepts parameters in the same manner as writeln. In contrast, printf() is written pretty much entirely in C, except the final system call to hand the text off to the OS.
From that standpoint, C was a big step forward for me. It was the first language where you could really do just about everything yourself if you wanted to. You didn't have to rely on the compiler author to think of it ahead of time and provide a function for it in the language. Compare/contrast to BASIC, where the graphics commands are part of the language. Thus, I'd say that you shouldn't shield your kids from that sort of 'general language' for too long, otherwise the damage is hard to undo.
Now, on the topic of assembly language: I'd say 'Go for it', but only if your kids show interest. I learned assembly language from beginner books, teaching myself 9900, 6502 and eventually 8086 assembly language on the way from middle school (~6th grade) through high school. (In college, I learned 6805, 8052, and baseline 80386 assembler as a part of my course work. Nowadays, I program VLIW assembler on TMS320C6000 DSPs.) It really gave me a good feel for how the machine actually worked, and gave me a better appreciation for why MHz != performance. (A 1MHz 6502 beats the pants off a 4.77MHz 8088 on most typical tasks.) Having that level of appreciation for the capabilities of your CPU will lead to a much more informed and conscious programmer, longer term. Well, at least, hopefully. Especially if your kid tries to implement even something as simple as "printf()" in assembly language.:-)
When did you last try Ogg? I converted all my stuff to Ogg around RC2 time frame, between RC2
and the final 1.0, they fixed some very noticeable quality problems.
I know a couple of my tracks ran into these problems.
Uhm, on anything faster than a 486, MP3 decoding is not terribly taxing on the CPU. It used to take 100% of my 486DX2/66. (Technically, I was decoding MP2s at the time, but the processing requirements for decode are similar.) Now MP3 decoding takes about 5% of the CPU on my 6-year old Pentium II-300. I can't imagine it taking up more than 1% of a modern machine.
Perhaps you meant ripping and encoding? Both of those are much more CPU intensive. Or perhaps you mean "Running eye candy visualizations"?
Yeah, especially since size_t is generally an unsigned type, but you need signed types for a lot of things -- not the least of which are loops that
don't run forever accidentally because a signed vs. unsigned compare promotes to unsigned. Also, some system calls want to return a size_t, but return -1 on error. Hence you get weird things like ssize_t,
or lazy programmers who just use 'int' because it "just works for all my data".
As for coding quality -- yes, I admit I have a lot of implicit 32-bitness built into certain parts of my code. At least, I assume int/unsigned int are 32 bits. And I know I'm not alone.
You're 1/2 correct. While current 32-bit x86s can access an address space larger than 32 bits (36 bits currently, although I believe you can extend further to about 39 bits), you cannot address that additional space linearly. You end up with separate 4GB segments that you have to manage directly. Pointers start to get weird again if you try to address more than 4GB with a single process.
We've had large flat address spaces for so long, and they offer so many conveniences, that nobody's too excited about introducing "near" vs. "far" pointers and segments back into the programmer's model. Those aren't new -- 16-bit x86 code used these heavily -- but nobody was sad to see them go. Right now, those issues are hidden in kernel space, and tasks only see a nice, flat 4GB window on the world. RAM beyond 4GB is used across multiple tasks, for disk cache, and so on. A single task can access more than 4GB through creative mmap()'s and crap. Eew.
Thus, tasks that want many GBs of data in RAM really need to go to 64-bit pointers (or, at least, more than 32-bit pointers) for true efficiency. That essentially means transitioning to a 64-bit architecture.
Uhm, and what executes the byte code? The byte code interpreter.
Any executable code run on a machine that is not in the machine language of the underlying CPU is interpreted, at least with respect to that CPU. Even most early BASIC interpreters went through a tokenizing step. They're still interpreters.
And that's in a strict sense.
--Joe
Re:I can see how this will become.
on
Opencroquet
·
· Score: 1
Is it just me that envisions Foghorn Leghorn bossing you around your own desktop whenever you hear about Windows Longhorn?
I mean.. I say! You better put an action verb in that their sentence! Listen up when I talk to ya', boy! That ain't no way to write a sentence! I'm talkin' about punctuation! You need a period right here. Kids these days.
It seems even more apropos when you consider DRM and Palladium. I'll leave that to the imagination of the reader.
You're forgetting that he's turned a net cost into a net profit. That is, what probably used to cost him $700 a week now makes him $900 a week.
That's pretty impressive. That's equivalent to selling $1600 in milk.
Yes, and this is also why manure pits and other sorts of fermentation chambers where methane is present are deadly -- you suffocate before you realize that there isn't much oxygen. You don't notice the methane.
Uhm, this has to do with ACKs you generate yourself. I guess the real problem would be SYN's, wouldn't it, since SYNs are responded to with ACKs IIRC. (I'm not a TCP god, mind you.)
New and confusing interfaces? How about OLD and confusing interfaces. As I understand it, the 'info' utility is just Emacs info-mode broken out as a separate program. I'm pretty sure it predates most web browsers and the ubiquitous popularity of HTML.
This page seems to indicate that Info and texinfo has roots going back to the 70s, and that Info itself came about in the mid 80s.
The WAD stores everything in a palettized form internally. In fact, textures can have 'alpha' and be composed of multiple patches. The PPM business was probably to make the import tool easier to write.
Apple will survive once it realizes it's no longer a hardware company. What's made Apple unique, IMHO, is not its hardware, but its software. If it'd just get out of the hardware business...
What drives me nuts is that I know three otherJoseph Zbiciaks. Fortunately, I have a different middle name than any of them. I actually have two middle names. :-)
(Also, my grandfather -- one of us four Josephs -- passed away some time ago, leaving only three of us to be confused about "Which Joe?")
A young new PhD recently hired in as a member of the mathematics faculty at the local University. He was the youngest member of the faculty there by far, and most of the department had been there for years.
The new prof decided to hang around the lounge for a bit to try to get to know his new colleagues. As he sat there, he noticed that every so often, one of the professors would mention a number to another, and then they'd both chuckle -- without any other conversation. The new guy was bewildered by this. So, he pulls one of the other profs aside, and says "What's up with these numbers? You just said 129 to Dr. Finkle there and he just started laughing. What's so funny?"
"Well, you see, we have all been here so long, that we've all heard each other's jokes again and again. As we get older and slower, it just takes too much time to tell an entire joke. So, we decided to number them all instead! Now, when we want to crack wise, we just mention the number, and it's as if you told the whole joke. It's that much easier to have a good laugh."
Mystified, the new guy thanks his older colleague and leaves. The next day, he decided to head back to the lounge again, where he finds a few of his fellow math professors hanging out. He decides to give this number thing a try. He walks up to them, and says, "Hey guys, get this: -4."
At first they're stunned. They stop, look at each other, and then one by one they bust a gut laughing. The new guy is amazed. He goes up to one of the profs and says "Hey, I wasn't expecting that kind of response. What was so funny?"
The other side of the equation is to tell your kids to save up for the things they want to buy, rather than having you buy everything for them. If they have to handle their own money, they start to get a sense for "if money comes in at this rate, and I don't have enough for 'X', then I can save up and get 'X' in such-and-such amount of time." That's the first step.
That's pretty much my point. The GPL is "restrictive" only from the standpoint that it not as permissive as placing the code in the public domain. The reality is that the GPL relaxes restrictions, and that's what matters.
Slashdot Mirror
Maybe they should call the "Evil Bit" the DRM bit. DRM packets are the only non-evil packets, of course. ;-)
Also, it looks like /.'s implemented the bit already, and it's had a negative impact on TCP/IP retransmits. Particularly packets that result in an article being posted (and reposted) to /.
--JoeIncluding me...
Stack based languages are cool for some things. I love my RPN calculator -- it's a lot more efficient for typical computation. After using one, I feel my brain contort when I try to use a standard algebraic calculator. It's as if I need to figure out how to "engineer" my expression into the constraints imposed by order of evaluation.
One word of warning, though: Stack-based machines have scalability problems when you try to make things high-performance. That's due primarily to the inherently serial nature of stack accesses. The stack becomes an artificial synchronization point for otherwise independent operations. Sure, you can use fancy techniques in order to reconstruct the original directed-acyclic graph (DAG) of instructions from the series of stack operations, but wouldn't you rather just start with the DAG to begin with? With a register-machine model, each register is essentially an edge (or set of edges) in the DAG. Much more direct.
Ahhhh... but I digress.
As for first programming language: I agree, good I/O (including graphics, and some easy way to do both blocking and non-blocking input) is key to retaining interest. That's why LOGO and (old fashioned) BASIC are so good! It's easy to make it "do things", where "do things" is defined as stuff happening on the screen.
I wouldn't wait too long, though, before introducing your budding programmer to something more industrial strength. It took years for the dain brammage that BASIC gave me to subside. Even Pascal wasn't a complete cure. C was much better, since it's a language that's strong enough that it can implement the bulk of its own standard library within the language.
You can't do that with Pascal. You can't implement write/writeln within the language. You can't even write a function that accepts parameters in the same manner as writeln. In contrast, printf() is written pretty much entirely in C, except the final system call to hand the text off to the OS.
From that standpoint, C was a big step forward for me. It was the first language where you could really do just about everything yourself if you wanted to. You didn't have to rely on the compiler author to think of it ahead of time and provide a function for it in the language. Compare/contrast to BASIC, where the graphics commands are part of the language. Thus, I'd say that you shouldn't shield your kids from that sort of 'general language' for too long, otherwise the damage is hard to undo.
Now, on the topic of assembly language: I'd say 'Go for it', but only if your kids show interest. I learned assembly language from beginner books, teaching myself 9900, 6502 and eventually 8086 assembly language on the way from middle school (~6th grade) through high school. (In college, I learned 6805, 8052, and baseline 80386 assembler as a part of my course work. Nowadays, I program VLIW assembler on TMS320C6000 DSPs.) It really gave me a good feel for how the machine actually worked, and gave me a better appreciation for why MHz != performance. (A 1MHz 6502 beats the pants off a 4.77MHz 8088 on most typical tasks.) Having that level of appreciation for the capabilities of your CPU will lead to a much more informed and conscious programmer, longer term. Well, at least, hopefully. Especially if your kid tries to implement even something as simple as "printf()" in assembly language. :-)
--JoeWhen did you last try Ogg? I converted all my stuff to Ogg around RC2 time frame, between RC2 and the final 1.0, they fixed some very noticeable quality problems.
I know a couple of my tracks ran into these problems.
--JoeWhich part is patented: The encoding process, the bitstream syntax, or the decoding process?
As long as the decoding process is not patented, there isn't an issue.
Uhm, on anything faster than a 486, MP3 decoding is not terribly taxing on the CPU. It used to take 100% of my 486DX2/66. (Technically, I was decoding MP2s at the time, but the processing requirements for decode are similar.) Now MP3 decoding takes about 5% of the CPU on my 6-year old Pentium II-300. I can't imagine it taking up more than 1% of a modern machine.
Perhaps you meant ripping and encoding? Both of those are much more CPU intensive. Or perhaps you mean "Running eye candy visualizations"?
--JoeYeah, especially since size_t is generally an unsigned type, but you need signed types for a lot of things -- not the least of which are loops that don't run forever accidentally because a signed vs. unsigned compare promotes to unsigned. Also, some system calls want to return a size_t, but return -1 on error. Hence you get weird things like ssize_t, or lazy programmers who just use 'int' because it "just works for all my data".
As for coding quality -- yes, I admit I have a lot of implicit 32-bitness built into certain parts of my code. At least, I assume int/unsigned int are 32 bits. And I know I'm not alone.
--JoeYou're 1/2 correct. While current 32-bit x86s can access an address space larger than 32 bits (36 bits currently, although I believe you can extend further to about 39 bits), you cannot address that additional space linearly. You end up with separate 4GB segments that you have to manage directly. Pointers start to get weird again if you try to address more than 4GB with a single process.
We've had large flat address spaces for so long, and they offer so many conveniences, that nobody's too excited about introducing "near" vs. "far" pointers and segments back into the programmer's model. Those aren't new -- 16-bit x86 code used these heavily -- but nobody was sad to see them go. Right now, those issues are hidden in kernel space, and tasks only see a nice, flat 4GB window on the world. RAM beyond 4GB is used across multiple tasks, for disk cache, and so on. A single task can access more than 4GB through creative mmap()'s and crap. Eew.
Thus, tasks that want many GBs of data in RAM really need to go to 64-bit pointers (or, at least, more than 32-bit pointers) for true efficiency. That essentially means transitioning to a 64-bit architecture.
--JoeUhm, and what executes the byte code? The byte code interpreter.
Any executable code run on a machine that is not in the machine language of the underlying CPU is interpreted, at least with respect to that CPU. Even most early BASIC interpreters went through a tokenizing step. They're still interpreters.
And that's in a strict sense.
--JoeIs it just me that envisions Foghorn Leghorn bossing you around your own desktop whenever you hear about Windows Longhorn?
It seems even more apropos when you consider DRM and Palladium. I'll leave that to the imagination of the reader.
--JoeYou're forgetting that he's turned a net cost into a net profit. That is, what probably used to cost him $700 a week now makes him $900 a week. That's pretty impressive. That's equivalent to selling $1600 in milk.
--JoeYes, and this is also why manure pits and other sorts of fermentation chambers where methane is present are deadly -- you suffocate before you realize that there isn't much oxygen. You don't notice the methane.
--JoeUhm, no. Humans don't survive well for very long much above 140F, which is about 60C.
Remember, they're going to power this thing with a massive laser. All you have to do is change where the laser's pointing. ;-)
--JoeYes, but it wouldn't be much of a speedup, now would it? (Even in the case of competing against another stream, that is.)
--JoeUhm, this has to do with ACKs you generate yourself. I guess the real problem would be SYN's, wouldn't it, since SYNs are responded to with ACKs IIRC. (I'm not a TCP god, mind you.)
--JoeNew and confusing interfaces? How about OLD and confusing interfaces. As I understand it, the 'info' utility is just Emacs info-mode broken out as a separate program. I'm pretty sure it predates most web browsers and the ubiquitous popularity of HTML.
This page seems to indicate that Info and texinfo has roots going back to the 70s, and that Info itself came about in the mid 80s.
--JoeThe WAD stores everything in a palettized form internally. In fact, textures can have 'alpha' and be composed of multiple patches. The PPM business was probably to make the import tool easier to write.
Make that 64K of truly usable memory. As I recall it, you have to use "Mode X" if you want to effectively use all 256K.
Apple will survive once it realizes it's no longer a hardware company. What's made Apple unique, IMHO, is not its hardware, but its software. If it'd just get out of the hardware business...
There was a girl in my graduating class named "Heather Moredick", another potentially unfortunate surname.
What drives me nuts is that I know three other Joseph Zbiciaks. Fortunately, I have a different middle name than any of them. I actually have two middle names. :-)
(Also, my grandfather -- one of us four Josephs -- passed away some time ago, leaving only three of us to be confused about "Which Joe?")
--JoeOne of my favorites is this one:
--JoeThe other side of the equation is to tell your kids to save up for the things they want to buy, rather than having you buy everything for them. If they have to handle their own money, they start to get a sense for "if money comes in at this rate, and I don't have enough for 'X', then I can save up and get 'X' in such-and-such amount of time." That's the first step.
--JoeThat's pretty much my point. The GPL is "restrictive" only from the standpoint that it not as permissive as placing the code in the public domain. The reality is that the GPL relaxes restrictions, and that's what matters.
--Joe