Believe it or not, there ARE people out there who are interested in this kind of detailed history. Simply because you're not interested doesn't mean that others don't want to read it.
And I'm one of them. But this is a book about OS X, not the Apple II.
This article is information overload in the extreme. What does Apple II DOS have to do with OS X? Or why Wozniak chose the 6502 over the 6800? Or the Apple III SOS or Apple II Prodos? Or Apple transitioning to PowerPC chips in 1994? Some of the newer stuff is interesting to know, for historical reasons, like the failed OS development projects that led up to OS X, but there's no way this should have been 140+ pages. It doesn't bode well for the rest of the book.
The problem with functional programming is that it's really only good for problems where you have a fixed set of input data and you aren't going to need any user input.
Wow, that's so completely...wrong. "Functional" doesn't mean "using mapping functions in the mathematical sense."
Look at Yaroze on PSOne and Linux on PS2. Amazing potential for opening up the market to independent game makers and hobbyists. And again, a total failure to deliver, leaving us with a games market where nobody will fund anything unless it's a $10m+ FPS.
But this had nothing whatsoever to do with Sony. Video games are hugely expensive to make, primarily because of content. Just making cheap development kits isn't any kind of magic bullet for that. If it were, then there would be free games for Linux of the quality of Battlefiend 2, World of Warcraft, and Half-Life 2.
To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.
And that's essentially what Agile development is: a way of getting things done quickly without overscheduling.
Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).
If by "new" you mean "12+ years old," then I agree with you.
I don't think it's true to describe Perl as an "interpreted language". Firstly because it's compiled, at run time before execution.
By that definition, almost no languages are interpreted. Perl/Python/Ruby/Lua, etc., are tranformed from text to an internal format: either a parse tree or bytecodes or a list of addresses (a.k.a. threaded code). Then that internal format is interpreted at runtime. None of these languages are compiled to machine code.
In a nutshell, programmers and computer scientists are uncomfortable with the fact that there's actual HARDWARE in the system, and this somehow taints their pure, beautiful software designs. That is to say, they unconsciously can't stand that software has to run on hardware. So, they've invented "virtual machines" to abstract away the icky hardware with all of its yucky "engineering hacks".
Nonsense. Embedded systems programmers deal with the hardware directly, and there are more embedded systems programmers than desktop PC programmers.
The reason for VMs is simply that, unlike a little 8051 CPU running a fuel injector, desktop hardware is not constant. Even on x86 systems, different models of Intel and AMD chips have different performance characteristics. You can't just pick one CPU and hardcode everything for it. You'd go insane. You isolate yourself from that level of things.
If you're making a pretty GUI, you may want to use an easy-to-use and portable language and may not care about performance as much. If you're creating a high-performance backend, or doing some realtime processing, an interpreted language is practially useless.
People said things like this when an 8MHz 68000 was the main CPU. They said it again when CPUs were 10x faster. People still say it with superscalar processors running at billions of cycles per second.
Slashdot not using CSS was the equivalent of someone still using an Amiga in 1999. It's not an indication of anything except Slashdot being waaaay behind the curve. CSS as been *the* way to go for a long time now.
Processor strategies straight out of the applied idiocy. Intel has excellent processor designers, but up until recently their roadmap sucked. They overlooked the point where pushing the GHz boundary did not make sense anymore.
If by "recently" you mean "several years ago," then I agree with you. Intel has been off the clockspeed-is-everything bandwagon for that long now.
People with little background in hardware-level programming and embedded systems are jumping on an out-of-context spec and contorting it. This number isn't what you think it is. It would be easy to show specs from other consoles that make people think "oh my goodness that's horribly slow" when in fact it is meaningless. Embedded systems programing is different than reading a PC hardware review site.
1. Perl/Python/Ruby: They attempt to provide every feature under the sun, with no pretense of doing one thing well.
2. Firefox: Okay, you could say the one thing it does well is "browsing the web," but that's far and away from clasic examples of how the UNIX philosophy is supposed to work. Firefox is not a collection of 20 small programs.
3. Inkscape, Sketch-Up, Blender...any big app, really.
Why teach programmers assembler? Most programmers will never use it. On the other hand it makes them better programmers.
I agree, but you wouldn't want to teach assembler as a first language. Ditto for not using an IDE: getting by without one at some point is a good idea, but don't make rank beginners suffer.
All this anti-IDE angst, so let me give the opposite view. Beginning students should be focused on *programming.* A good IDE makes some key things standard and invisible: jumping to errors, debugging, etc. Then the students can just worry about programming, and not vi configuration problems and make files and so on.
Using an IDE in school is nothing new. Back in the late 80s most of the college programming courses I took used Pascal, and Turbo Pascal 4 and 5, with integrated editors and compilers, were godsends. The alternative was to use a command line compiler on a VAX, which was horrible in comparison.
1. You get support for the full 3D pipeline in hardware, including shaders. This is tons better than having the CPU do all the work. Quartz Extreme benefits. 3. Less power needed (longer battery life). 4. Less heat generated.
Cons:
1. Performance is 1/3 the level of high-end, hot-running video cards, which is an issue if you want to play high-end games.
Has anyone else noticed that the Powerbooks/iBooks have gone the way of the dodo?
How could anyone NOT know? It's been the whole point of numerous Apple press releases and Slashdot stories. The MacBook Pro replaced the PowerBook, the MacBook replaced the iBook.
Display has way to small both resolution and dimension for that price. Damn thing is practicaly unusable.
All those people I see in coffeshops with the lower resolution iBook G4 seem happy enough. The MacBook has higher resolution, two processors, and the main reason for buying a Mac: OS X.
You wonder why? Because you have to give people something to show, visible to the world, that they have got for their money, and the more useless it is the better.
Or it simply could be that people would like a black MacBook:P
Why is perl the anti-thesis of the UNIX way. It is cryptic, it allows you to do one thing in as many ways as possible. It allows you to build your programs by re-using components (CPAN). It is very extendable.
The UNIX way was to write small programs, each doing one thing well. The Perl way was to put all features into one giant program.
It could be argued that the UNIX 'building block' concept was a sham from the beginning. All traditional shells implement lot's of commands like 'echo', 'kill' and 'printf' as builtins improve performance.
And of course take a look at Perl (and Python and Ruby). Perl is the antithesis of the UNIX way, and yet it has become the UNIX way.
Lots of big ideas in programming get pooh-poohed for being too resource intensive (a.k.a. big and slow), but eventually we look back and think how silly we were to be worried about such details, and that of course we should go with the cleaner, more reliable option. Some examples:
zbuffering - go back to any book from the 1970s, and it sounds like a pipe dream (more memory needed for a high-res zbuffer than in entire computer systems of the time)
Lisp, Prolog, and other high-level languages on home computers - these are fast and safe options, but were comically bloated on typical hardware of 20 years ago.
Operating systems not written in assembly language - lots of people never expected to see the day.
Slashdot Mirror
Believe it or not, there ARE people out there who are interested in this kind of detailed history. Simply because you're not interested doesn't mean that others don't want to read it.
And I'm one of them. But this is a book about OS X, not the Apple II.
This article is information overload in the extreme. What does Apple II DOS have to do with OS X? Or why Wozniak chose the 6502 over the 6800? Or the Apple III SOS or Apple II Prodos? Or Apple transitioning to PowerPC chips in 1994? Some of the newer stuff is interesting to know, for historical reasons, like the failed OS development projects that led up to OS X, but there's no way this should have been 140+ pages. It doesn't bode well for the rest of the book.
The problem with functional programming is that it's really only good for problems where you have a fixed set of input data and you aren't going to need any user input.
Wow, that's so completely...wrong. "Functional" doesn't mean "using mapping functions in the mathematical sense."
Look at Yaroze on PSOne and Linux on PS2. Amazing potential for opening up the market to independent game makers and hobbyists. And again, a total failure to deliver, leaving us with a games market where nobody will fund anything unless it's a $10m+ FPS.
But this had nothing whatsoever to do with Sony. Video games are hugely expensive to make, primarily because of content. Just making cheap development kits isn't any kind of magic bullet for that. If it were, then there would be free games for Linux of the quality of Battlefiend 2, World of Warcraft, and Half-Life 2.
To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.
And that's essentially what Agile development is: a way of getting things done quickly without overscheduling.
Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).
If by "new" you mean "12+ years old," then I agree with you.
I don't think it's true to describe Perl as an "interpreted language". Firstly because it's compiled, at run time before execution.
By that definition, almost no languages are interpreted. Perl/Python/Ruby/Lua, etc., are tranformed from text to an internal format: either a parse tree or bytecodes or a list of addresses (a.k.a. threaded code). Then that internal format is interpreted at runtime. None of these languages are compiled to machine code.
In a nutshell, programmers and computer scientists are uncomfortable with the fact that there's actual HARDWARE in the system, and this somehow taints their pure, beautiful software designs. That is to say, they unconsciously can't stand that software has to run on hardware. So, they've invented "virtual machines" to abstract away the icky hardware with all of its yucky "engineering hacks".
Nonsense. Embedded systems programmers deal with the hardware directly, and there are more embedded systems programmers than desktop PC programmers.
The reason for VMs is simply that, unlike a little 8051 CPU running a fuel injector, desktop hardware is not constant. Even on x86 systems, different models of Intel and AMD chips have different performance characteristics. You can't just pick one CPU and hardcode everything for it. You'd go insane. You isolate yourself from that level of things.
Remember the 90/10 rule - your application will probably spend 90% of its time in 10% of the code.
This is true for many types of applications, but not all. In high-performance apps it's not at all unusual to have a flat profile.
If you're making a pretty GUI, you may want to use an easy-to-use and portable language and may not care about performance as much. If you're creating a high-performance backend, or doing some realtime processing, an interpreted language is practially useless.
People said things like this when an 8MHz 68000 was the main CPU. They said it again when CPUs were 10x faster. People still say it with superscalar processors running at billions of cycles per second.
article here
Slashdot not using CSS was the equivalent of someone still using an Amiga in 1999. It's not an indication of anything except Slashdot being waaaay behind the curve. CSS as been *the* way to go for a long time now.
"Getting music for real cheap" is hardly in the same category as people fighting for freedom and civil rights :P
Processor strategies straight out of the applied idiocy. Intel has excellent processor designers, but up until recently their roadmap sucked. They overlooked the point where pushing the GHz boundary did not make sense anymore.
If by "recently" you mean "several years ago," then I agree with you. Intel has been off the clockspeed-is-everything bandwagon for that long now.
For the last 5-10 years, (Really since the Athlon was released) AMD was indisputably the price/performance king. Hands down, no competition.
A little research would show that the Athlon was released 7 years ago.
People with little background in hardware-level programming and embedded systems are jumping on an out-of-context spec and contorting it. This number isn't what you think it is. It would be easy to show specs from other consoles that make people think "oh my goodness that's horribly slow" when in fact it is meaningless. Embedded systems programing is different than reading a PC hardware review site.
Examples:
1. Perl/Python/Ruby: They attempt to provide every feature under the sun, with no pretense of doing one thing well.
2. Firefox: Okay, you could say the one thing it does well is "browsing the web," but that's far and away from clasic examples of how the UNIX philosophy is supposed to work. Firefox is not a collection of 20 small programs.
3. Inkscape, Sketch-Up, Blender...any big app, really.
Why teach programmers assembler? Most programmers will never use it. On the other hand it makes them better programmers.
I agree, but you wouldn't want to teach assembler as a first language. Ditto for not using an IDE: getting by without one at some point is a good idea, but don't make rank beginners suffer.
All this anti-IDE angst, so let me give the opposite view. Beginning students should be focused on *programming.* A good IDE makes some key things standard and invisible: jumping to errors, debugging, etc. Then the students can just worry about programming, and not vi configuration problems and make files and so on.
Using an IDE in school is nothing new. Back in the late 80s most of the college programming courses I took used Pascal, and Turbo Pascal 4 and 5, with integrated editors and compilers, were godsends. The alternative was to use a command line compiler on a VAX, which was horrible in comparison.
Pros:
1. You get support for the full 3D pipeline in hardware, including shaders. This is tons better than having the CPU do all the work. Quartz Extreme benefits.
3. Less power needed (longer battery life).
4. Less heat generated.
Cons:
1. Performance is 1/3 the level of high-end, hot-running video cards, which is an issue if you want to play high-end games.
Has anyone else noticed that the Powerbooks/iBooks have gone the way of the dodo?
How could anyone NOT know? It's been the whole point of numerous Apple press releases and Slashdot stories. The MacBook Pro replaced the PowerBook, the MacBook replaced the iBook.
Display has way to small both resolution and dimension for that price. Damn thing is practicaly unusable.
All those people I see in coffeshops with the lower resolution iBook G4 seem happy enough. The MacBook has higher resolution, two processors, and the main reason for buying a Mac: OS X.
You wonder why? Because you have to give people something to show, visible to the world, that they have got for their money, and the more useless it is the better.
:P
Or it simply could be that people would like a black MacBook
Why is perl the anti-thesis of the UNIX way. It is cryptic, it allows you to do one thing in as many ways as possible. It allows you to build your programs by re-using components (CPAN). It is very extendable.
The UNIX way was to write small programs, each doing one thing well. The Perl way was to put all features into one giant program.
It could be argued that the UNIX 'building block' concept was a sham from the beginning. All traditional shells implement lot's of commands like 'echo', 'kill' and 'printf' as builtins improve performance.
And of course take a look at Perl (and Python and Ruby). Perl is the antithesis of the UNIX way, and yet it has become the UNIX way.
zbuffering - go back to any book from the 1970s, and it sounds like a pipe dream (more memory needed for a high-res zbuffer than in entire computer systems of the time)
Lisp, Prolog, and other high-level languages on home computers - these are fast and safe options, but were comically bloated on typical hardware of 20 years ago.
Operating systems not written in assembly language - lots of people never expected to see the day.