Apple berates M$ for using nonstandard scroll bars. But it's OK for them to do the same.
Where are nonstandard scrollbars used in Mac OS X? Even in the alternate "brushed metal" interface, the scrollbars are the same widget used in Aqua interfaces. In fact, all of the widgets are the same.
Speaking of the brushed metal interface, it *is* standard. It's not some hacked-up skinning kludge. It behaves almost exactly like the Aqua interface except that you can move it by clicking on the window background itself. I suspect this ability exists for Aqua windows, but has simply been disabled.
Have you tried actually using Mac OS X? Just click on the App/Doc separator in the Dock and drag up or down. The Dock resizes itself.
As for dialogs... almost all of the dialogs I've seen in Windows have taken up more screen real estate than comparable dialogs in OS X. Those that don't are usually overly cramped and unreadable.
I'm not necessarily suggesting they rewrite it so much as rethink it. It's not a matter of writing the source in C++ with some fancy library, or C#, or any other language. It's about shifting the culture to a point where security is important.
Shoe-horning security into their existing insecure codebase, whether they do a good job or not, is not a culture shift.
Actually, I wasn't talking about boot time, but rather the time between hitting enter after typing in the requisite login information, and getting something other than a blue screen, and being able to actually use the computer.
I've actually tried this with the other login, so I doubt it's a user account specific problem.
I have noticed that these machines boot quite quickly. My iMac boots rather slowly, but whn it almost never gets shut off, that becomes something of a moot point.:-)
Come to think of it, maybe it's a good thing Windows boots fast.
As I mentioned, the machines aren't networked yet. They're also brand new, with fresh installs of W2K, the only legacy parts being the floppy drives, as well as externals likes the mouse, keyboard and monitor.
Repeated tests of the hardware have shown that everything is working perfectly.
Microsoft's approach to operating systems and security has created an arms race between them and hackers(both malicious, and those legitimately testing the software).
The answer is not to make the OS more complex and create more special cases, but to streamline it, and offer a more consistent model for applications and users to interact with the operating system.
This is why pretty much everyone else these days uses some variant on Unix. More than anything else, the appeal of Unix is simplicity at a basic level.
Now, Microsoft doesn't have to ship a Unix-based or compatible OS by any means, but if they want to take security seriously, they need to take what they have now, and what they are planning on for five or ten years down the road, reduce it down to the most basic components that can still address all of those problems, and rethink how Windows is put together.
Also important is to get over their antipathy towards the open source "movement", and realize that it can be a tool. If they released a simplified, streamlined Windows kernel, they could let the world hack away at it, finding flaws, then take that work and put the components on top of it that would make it Windows. They've "borrowed" ideas from Apple and NeXT in the past, why not look at what OpenStep was, and what Darwin and Mac OS X have become and borrow that idea too?
In short, it takes more than saying to your developers, "ship bug fixes in a week rather than a month." They'll hae to really examine Windows, and where the flaws come in, and if there's some other way(and there always is) that those things could be done, then the old way has to go.
I mean, the Windows 2000, 1.6GHz Pentium 4 stand-alone, un-networked machines at our school, with 256MB of RAM and brand new ATA/133 40GB drives take a blazingly fast 3 minutes from hitting enter to actual log in! That's just frellin' amazing!
Oh wait, my 266MHz iMac, running OS X 10.1.5, with less than the required RAM, significantly more and more memory and processor intensive software, several user accounts(as opposed to 2 on the W2K machines), and a pokey 66MHz bus goes from hitting enter to actually logged in in 30 seconds.
Now that I think about it, something doesn't add up.
I can guess that it was probably the fact that Eiffel is just really really strict. It forces you to program in a certain way, and in the end you get a tighter program with far less potential for run-time bugs, but getting there can be an exercise in masochism.
The fact that functions and procedures are strictly separated means that something like(in Ruby):
class Stack
def initialize(*arr)
@array * arr
end
def pop
@array.pop # implicit return
end end
bar = Foo.new("hello", "world") puts bar.pop
Would require an intermediate step of binding the last item in the array to a buffer, removing the last item in the array, then accessing the buffer to get the item.
I don't know. I think if Apple were to go down this road, it'd be a distinct product alongside PPC machines, targeted at a market that can afford to primarily use Cocoa apps.
I don't think they'd be ordering millions of CPUs, and not at one time. More likely they'd place the CPU on a daughtercard and update it to keep pace with the rest of the x86 world.
Number 3 wouldn't surprise me in the slightest. After all, Microsoft's Mac Business Unit coded Office v.X using the Carbon API, yet it only runs on Mac OS X, thus negating the one reason to use Carbon rather than Cocoa(except of course for laziness, and an unwillingness to learn something that looks new).
Actually, the prices for an Apple-branded x86 machine would likely be higher, as processors from Intel and AMD are quite a bit higher than prices for PPC chips.
I'm not an expert on this subject, and this might be nothing more than uninformed speculation, but I'm guessing this is the price OEMs pay for having lots of frequent updates in processors. Intel and AMD spend a lot on R&D for these things, then have short, relatively low volume production runs leading to lower marginal profits on each unit sold.
Actually, as far as I know, hand-crafted PPC assembly is not necessary at all to optimize for the Altivec instruction set. Last I heard you simply used C functions like vec_add() and such.
This is not to say that rewriting the Altivec libraries to map to any of the x86 SIMD units would be easy, but it's easier than if everything were in assembly.
From what I've seen, the.NET CLR is biased towards statically-typed languages, while Parrot's goal was to run dynamically-typed languages like Perl6(and Python, Ruby, Tcl, etc.) better.
So I think they can live side by side. Also, with the runtime environment for Perl6 developed as a distinct VM, it becomes quite possible to write a Parrot ->.NET/JVM bytecode translator.
Of course, the fact that Perl simplifies the low-level stuff can encourage teaching in a top-down fashion.
It's actually a lot like Java - which has been widely embraced for teaching intro CS - in this way. Students learning Java don't worry about little stuff like how strings work. It's enough to know that they work, and students can focus on the higher-level logic of their program. The only difference is that Perl is usually quicker to type.
Seriously. Perl 5 will be around for a long, long time, and even after Perl 6 is out for awhile, Perl 5 will likely still be the standard with the more conservative(and mainstream) *nix OSes.
And at the same time, learn Perl 6(start now, at parrotcode.org). While some here will say Perl doesn't really have anything new, I say that isn't necessary. Sometimes it's enough to just do something better than it's ever been done before.:-)
"What more control could you want over scoping in Ruby?"
Oh, Ruby's good at this. But going back to Perl the last several months for reasons including Parrot, I've come to appreciate "my". Wile I generally like how Ruby handles scoping, every once in a while there's a problem where I think "everything else makes Ruby a good fit to this, but there's a really nifty Perl trick with my that I could apply here."
I fail to see why people feel that Perl and Ruby need to compete. Both can happily live side by side, and are not difficult to learn(at least the basics).
Learn both. They both have good points, and bad. I'd love an easier OO model in Perl5, but I'd also like more control over scoping in Ruby. The Ruby and Perl development communities are both listening to each other, from what I've seen, and drawing on their shared and unique experiences to further both languages. Why shouldn't the users of these languages do the same?
I like Eiffel for this purpose. Clean syntax, and straightforward, relatively simple rules.
Most importantly though, nothing takes place outside of a class. Consistency is good, as people tend to get confused when explaining exceptions to the rules.
If you're going to teach OOP, in my humble opinion, you need to stress thinking about problems in terms of classes and objects from the very first day.
The other approach I've given serious thought to is using a language like Perl to start out by showing how things can be done in a quick and dirty way, but then expand the "hello, world"(output) script to saying "hello" to a person(input), and so on and so on, and show how modules and classes can make expanding a small program much easier. At the same time, as you construct a class, you can demonstrate arrays, associative arrays, looping, conditionals, etc.
I'm still debating which is the better approach.
Re:What does this mean for OS X?
on
GCC 3.2 Released
·
· Score: 2
Ahem.... Objective-C may not be as popular as C or C++, but popularity doesn't have a thing to do with the technical merits of a system.
Just look at Windows.
Apple isn't behind, they've just done things in a slightly different way than most people do it.
The local community college here uses almost pure MS crap in teaching CS. Not just specific skills, either, but general computer science.
I intend to appeal to the chairperson of the department to support me in setting up free(or very low cost) "workshops" for students(and faculty if they're interested) on other programming languages and environments. We have a Linux lab, but it typically goes unused since none of the faculty know enough to teach the students how to use it.
The key is to change that. Spread thw word that there are alternatives.
Not to mention moving the optical drives to the middle of the case, which makes them much more accessible for people who keep their PowerMacs on their desk/workspace.
It's been mentioned here that it wasn't fair to use a system restore disk provided by Sony as a comparison to a fresh install of RedHat.
It's also been mentioned that Windows in most cases comes already installed.
Isn't this the perfect comparison then? For the vast majority of people, the only Windows install they'll ever do is via a system restore disk. And since Linux wasn't pre-installed, the only Linux install they're likely to do is a fresh install.
Slashdot Mirror
Where are nonstandard scrollbars used in Mac OS X? Even in the alternate "brushed metal" interface, the scrollbars are the same widget used in Aqua interfaces. In fact, all of the widgets are the same.
Speaking of the brushed metal interface, it *is* standard. It's not some hacked-up skinning kludge. It behaves almost exactly like the Aqua interface except that you can move it by clicking on the window background itself. I suspect this ability exists for Aqua windows, but has simply been disabled.
I use Mac OS X at home, an Win2K at school.
Have you tried actually using Mac OS X? Just click on the App/Doc separator in the Dock and drag up or down. The Dock resizes itself.
As for dialogs... almost all of the dialogs I've seen in Windows have taken up more screen real estate than comparable dialogs in OS X. Those that don't are usually overly cramped and unreadable.
I'm not necessarily suggesting they rewrite it so much as rethink it. It's not a matter of writing the source in C++ with some fancy library, or C#, or any other language. It's about shifting the culture to a point where security is important.
Shoe-horning security into their existing insecure codebase, whether they do a good job or not, is not a culture shift.
Actually, I wasn't talking about boot time, but rather the time between hitting enter after typing in the requisite login information, and getting something other than a blue screen, and being able to actually use the computer.
:-)
I've actually tried this with the other login, so I doubt it's a user account specific problem.
I have noticed that these machines boot quite quickly. My iMac boots rather slowly, but whn it almost never gets shut off, that becomes something of a moot point.
Come to think of it, maybe it's a good thing Windows boots fast.
As I mentioned, the machines aren't networked yet. They're also brand new, with fresh installs of W2K, the only legacy parts being the floppy drives, as well as externals likes the mouse, keyboard and monitor.
Repeated tests of the hardware have shown that everything is working perfectly.
Microsoft's approach to operating systems and security has created an arms race between them and hackers(both malicious, and those legitimately testing the software).
The answer is not to make the OS more complex and create more special cases, but to streamline it, and offer a more consistent model for applications and users to interact with the operating system.
This is why pretty much everyone else these days uses some variant on Unix. More than anything else, the appeal of Unix is simplicity at a basic level.
Now, Microsoft doesn't have to ship a Unix-based or compatible OS by any means, but if they want to take security seriously, they need to take what they have now, and what they are planning on for five or ten years down the road, reduce it down to the most basic components that can still address all of those problems, and rethink how Windows is put together.
Also important is to get over their antipathy towards the open source "movement", and realize that it can be a tool. If they released a simplified, streamlined Windows kernel, they could let the world hack away at it, finding flaws, then take that work and put the components on top of it that would make it Windows. They've "borrowed" ideas from Apple and NeXT in the past, why not look at what OpenStep was, and what Darwin and Mac OS X have become and borrow that idea too?
In short, it takes more than saying to your developers, "ship bug fixes in a week rather than a month." They'll hae to really examine Windows, and where the flaws come in, and if there's some other way(and there always is) that those things could be done, then the old way has to go.
Yeah!
I mean, the Windows 2000, 1.6GHz Pentium 4 stand-alone, un-networked machines at our school, with 256MB of RAM and brand new ATA/133 40GB drives take a blazingly fast 3 minutes from hitting enter to actual log in! That's just frellin' amazing!
Oh wait, my 266MHz iMac, running OS X 10.1.5, with less than the required RAM, significantly more and more memory and processor intensive software, several user accounts(as opposed to 2 on the W2K machines), and a pokey 66MHz bus goes from hitting enter to actually logged in in 30 seconds.
Now that I think about it, something doesn't add up.
I can guess that it was probably the fact that Eiffel is just really really strict. It forces you to program in a certain way, and in the end you get a tighter program with far less potential for run-time bugs, but getting there can be an exercise in masochism.
The fact that functions and procedures are strictly separated means that something like(in Ruby):
class Stack
def initialize(*arr)
@array * arr
end
def pop
@array.pop # implicit return
end
end
bar = Foo.new("hello", "world")
puts bar.pop
Would require an intermediate step of binding the last item in the array to a buffer, removing the last item in the array, then accessing the buffer to get the item.
I don't know. I think if Apple were to go down this road, it'd be a distinct product alongside PPC machines, targeted at a market that can afford to primarily use Cocoa apps.
I don't think they'd be ordering millions of CPUs, and not at one time. More likely they'd place the CPU on a daughtercard and update it to keep pace with the rest of the x86 world.
Hell to debug, though. :-)
And I'm not talking about being able to read it.
Thank goodness for optional strong typing in Perl6, and what looks like some decent contract support.
Number 3 wouldn't surprise me in the slightest. After all, Microsoft's Mac Business Unit coded Office v.X using the Carbon API, yet it only runs on Mac OS X, thus negating the one reason to use Carbon rather than Cocoa(except of course for laziness, and an unwillingness to learn something that looks new).
Actually, the prices for an Apple-branded x86 machine would likely be higher, as processors from Intel and AMD are quite a bit higher than prices for PPC chips.
I'm not an expert on this subject, and this might be nothing more than uninformed speculation, but I'm guessing this is the price OEMs pay for having lots of frequent updates in processors. Intel and AMD spend a lot on R&D for these things, then have short, relatively low volume production runs leading to lower marginal profits on each unit sold.
Actually, as far as I know, hand-crafted PPC assembly is not necessary at all to optimize for the Altivec instruction set. Last I heard you simply used C functions like vec_add() and such.
This is not to say that rewriting the Altivec libraries to map to any of the x86 SIMD units would be easy, but it's easier than if everything were in assembly.
srcCounter ++;
destCounter = srcCounter;
Since the assignment makes the incrementing of destCounter irrelevant.
Of course, in all seriousness, the key issue here is operator precedence, and programmers have to figure that out eventually.
From what I've seen, the .NET CLR is biased towards statically-typed languages, while Parrot's goal was to run dynamically-typed languages like Perl6(and Python, Ruby, Tcl, etc.) better.
.NET/JVM bytecode translator.
So I think they can live side by side. Also, with the runtime environment for Perl6 developed as a distinct VM, it becomes quite possible to write a Parrot ->
Of course, the fact that Perl simplifies the low-level stuff can encourage teaching in a top-down fashion.
It's actually a lot like Java - which has been widely embraced for teaching intro CS - in this way. Students learning Java don't worry about little stuff like how strings work. It's enough to know that they work, and students can focus on the higher-level logic of their program. The only difference is that Perl is usually quicker to type.
Seriously. Perl 5 will be around for a long, long time, and even after Perl 6 is out for awhile, Perl 5 will likely still be the standard with the more conservative(and mainstream) *nix OSes.
:-)
And at the same time, learn Perl 6(start now, at parrotcode.org). While some here will say Perl doesn't really have anything new, I say that isn't necessary. Sometimes it's enough to just do something better than it's ever been done before.
Replying to the question just once:
"What more control could you want over scoping in Ruby?"
Oh, Ruby's good at this. But going back to Perl the last several months for reasons including Parrot, I've come to appreciate "my". Wile I generally like how Ruby handles scoping, every once in a while there's a problem where I think "everything else makes Ruby a good fit to this, but there's a really nifty Perl trick with my that I could apply here."
I fail to see why people feel that Perl and Ruby need to compete. Both can happily live side by side, and are not difficult to learn(at least the basics).
Learn both. They both have good points, and bad. I'd love an easier OO model in Perl5, but I'd also like more control over scoping in Ruby. The Ruby and Perl development communities are both listening to each other, from what I've seen, and drawing on their shared and unique experiences to further both languages. Why shouldn't the users of these languages do the same?
Computers don't think at all. Does that mean programmers shouldn't?
Because even Assembly is an abstraction, and once you start down that road, you might as well go all the way.
The third line pretends that their are strict lines drawn between procedural, functional, and OO programming paradigms.
And how are methods anything other than functions or procedures which operate on an encapsulated set of variables?
I like Eiffel for this purpose. Clean syntax, and straightforward, relatively simple rules.
Most importantly though, nothing takes place outside of a class. Consistency is good, as people tend to get confused when explaining exceptions to the rules.
If you're going to teach OOP, in my humble opinion, you need to stress thinking about problems in terms of classes and objects from the very first day.
The other approach I've given serious thought to is using a language like Perl to start out by showing how things can be done in a quick and dirty way, but then expand the "hello, world"(output) script to saying "hello" to a person(input), and so on and so on, and show how modules and classes can make expanding a small program much easier. At the same time, as you construct a class, you can demonstrate arrays, associative arrays, looping, conditionals, etc.
I'm still debating which is the better approach.
Ahem.... Objective-C may not be as popular as C or C++, but popularity doesn't have a thing to do with the technical merits of a system.
Just look at Windows.
Apple isn't behind, they've just done things in a slightly different way than most people do it.
The local community college here uses almost pure MS crap in teaching CS. Not just specific skills, either, but general computer science.
I intend to appeal to the chairperson of the department to support me in setting up free(or very low cost) "workshops" for students(and faculty if they're interested) on other programming languages and environments. We have a Linux lab, but it typically goes unused since none of the faculty know enough to teach the students how to use it.
The key is to change that. Spread thw word that there are alternatives.
Not to mention moving the optical drives to the middle of the case, which makes them much more accessible for people who keep their PowerMacs on their desk/workspace.
It's been mentioned here that it wasn't fair to use a system restore disk provided by Sony as a comparison to a fresh install of RedHat.
It's also been mentioned that Windows in most cases comes already installed.
Isn't this the perfect comparison then? For the vast majority of people, the only Windows install they'll ever do is via a system restore disk. And since Linux wasn't pre-installed, the only Linux install they're likely to do is a fresh install.