... just like yugos killed the western auto industry. so long as the western consumer is interested in paying top dollar for 'premium' goods (be it cars or 'puters), cheap-ass chinese computers will have almost no effect on m$' dominance.
"Even if you were to assume that my productivity were to go down 10% for every hour over 50 I worked, I'd still be *somewhat* productive at hour 80."
Yeah, but during the next week, you'll still be down 10%, maybe even for the whole week, due to building-up exhaustion and frustration. So your productivity takes an overall 10% hit - not just in the 80th hour as you suggest.
It really depends on the individual. Let's assume for the sake of argument that if I work a 16 hour day instead of an 8 hour day, my productivity will drop by 60%. And let's assume that this is a consistent 60% drop - not just in the Nth hour.
Now observe: let's say that I can crunch out X units of work in one hour if I had only did an 8 hour coding session. That means that if I work an 8 hour day, I'll get 8*X units of work done.
If I instead consistently work for 16 hours (getting less sleep, worse food, not getting laid as often, etc.), I will get 16*(1-0.6)*X = 6.4*X units of work done.
Hence, I am less productive. Think about it. It makes sense.
It's probably just a code generator, in which case the perl interpreter would not have to be included in Windows. Only non-perl code generated by a program written in perl would be in Windows, which wouldn't violate perl's license.
First of all, there's a "fourth" alternative that you did not mention: Carbon. It's a C API that represents a subset of the old Mac OS 9 APIs. It will give you access to Cocoa and CoreGraphics goodies while also giving you access to all of the wonderful Mach and BSD APIs.
However, Carbon is no fun, IMHO. It's just not as easy to work with as something like Cocoa or Swing.
Second, why do you say that Cocoa/Java is not well documented? Just look at developer.apple.com and read all about it... Besides, all Obj-C Cocoa APIs have equivalents in Cocoa/Java. So it shouldn't be that hard.
But, why use Java? Maybe you like it, in which case, go for it... But I think that if you have C and C++ experience you'll find Objective-C to be much more robust for Mac programming, simply because: 1) you can learn it quickly if you already know C/C++, and 2) you get a well thought-out API (Cocoa, formerly NeXT's AppKit) with access (both via Objective-C and via libc and other C APIs) to Mach, BSD, and Mac OS X specific goodies.
And, for the love of all that is good, pure, and holy, don't use Swing. It's disgusting. Someone needs to beat it into the ground and start from scratch. The only reason that I would see for using it (and, granted, it's a good reason) is for portability... But in that case, I highly recommend Qt (www.trolltech.com). It works nicely on Windows, Linux, and Mac OS X... Only problem is it isn't necessarily free. =(
Personally, I learned Objective-C in a couple of evenings after reading Apple's (formerly NeXT's) excellent book on Objective-C. It's available for download in PDF format from developer.apple.com.
So I say go for that, I'm sure you'll be impressed with the results you get.
Hurd is a real microkernel OS. That is, most of the stuff that you'd think of as being in the kernel on Linux is actually in "daemons" that run more-or-less in userland.
Darwin is Mach and the BSD kernel merged together. They both live in kernel space. So why are they using Mach? I dunno.
language comparison
on
Ask Larry Wall
·
· Score: 3, Interesting
How do you think Perl compares to languages such as Ruby, Python, or Lua? Where do you think Perl has its strengths, when these other languages are accounted for?
I can really relate - I'm a senior now in computer science and math, and I've had plenty of nasty problems thrown at me on exams (writing an implementation of malloc, multi-threaded priority-based message passing system, crap like that). Here's just some things I've found that work for me.
1) Make sure you do all projects to their fullest extent, and after doing them, make sure you think about all the things you could do to your solutions to improve them past what the prof asked for. Then study your solutions before the exam. I've found that profs are likely to ask programming questions that are extensions of what was asked on the projects and homework... so this has saved my butt a couple of times.
2) If your school has coding contests, get involved. Even if you lose every time. It's important to learn how to write complex code in a short amount of time for these exams - and coding contests have helped me out a *lot*. Probably 'cause in a coding contest you often have to get the code right the first time (which is what is needed for paper exams) in a short amount of time.
3) Don't be afraid to ask questions during the exam (if this is possible). Last semester I was in the top-ten for exam scores in my CS class. I was also the one asking the most questions. =) Not that I was able to get the solutions out of the prof, but I was able to narrow my parameters. I was able to find out how much error checking he wanted. And I was able to get a lot of ambiguity eliminated.
4) Just be a smart test-taker. =) I know, I know, that's way too general, but what I mean is: don't get pissed at the hard problems until you've done the easy ones, write *some* code down even if you have no f***ing clue, and get plenty of sleep, food, whatever beforehand, enter the test relaxed, and just hope for the best.
Maybe this isn't exactly what you're asking for, but for me, the first book that comes to mind when you start talking about "programming" from a more conceptual standpoint, is "The Pragmatic Programmer" by Andrew Hunt and David Thomas (Addison-Wesley).
Lots of good examples in that book of how to go about programming and how not to go about programming (not just writing code), and lots of great advice on how to improve your craft.
Maybe not too much about "conceptial models" as in functional versus imperative or procedural versus object-oriented, but it certainly is worth a look.
Slashdot Mirror
... just like yugos killed the western auto industry. so long as the western consumer is interested in paying top dollar for 'premium' goods (be it cars or 'puters), cheap-ass chinese computers will have almost no effect on m$' dominance.
Bullshit. The rate of security holes will be lower, yes. But type safety never guarantees correctness. As such, it never guarantees security.
Yeah, but during the next week, you'll still be down 10%, maybe even for the whole week, due to building-up exhaustion and frustration. So your productivity takes an overall 10% hit - not just in the 80th hour as you suggest.
It really depends on the individual. Let's assume for the sake of argument that if I work a 16 hour day instead of an 8 hour day, my productivity will drop by 60%. And let's assume that this is a consistent 60% drop - not just in the Nth hour.
Now observe: let's say that I can crunch out X units of work in one hour if I had only did an 8 hour coding session. That means that if I work an 8 hour day, I'll get 8*X units of work done. If I instead consistently work for 16 hours (getting less sleep, worse food, not getting laid as often, etc.), I will get 16*(1-0.6)*X = 6.4*X units of work done.
Hence, I am less productive. Think about it. It makes sense.
Those interested in photoblogging might be interested in photo.net's "no words" forums: http://www.photo.net/bboard/forum?topic_id=1801
It's probably just a code generator, in which case the perl interpreter would not have to be included in Windows. Only non-perl code generated by a program written in perl would be in Windows, which wouldn't violate perl's license.
Can anyone in the know tell me why you would need a field-programmable gate array on a PDA?
First of all, there's a "fourth" alternative that you did not mention: Carbon. It's a C API that represents a subset of the old Mac OS 9 APIs. It will give you access to Cocoa and CoreGraphics goodies while also giving you access to all of the wonderful Mach and BSD APIs.
However, Carbon is no fun, IMHO. It's just not as easy to work with as something like Cocoa or Swing.
Second, why do you say that Cocoa/Java is not well documented? Just look at developer.apple.com and read all about it... Besides, all Obj-C Cocoa APIs have equivalents in Cocoa/Java. So it shouldn't be that hard.
But, why use Java? Maybe you like it, in which case, go for it... But I think that if you have C and C++ experience you'll find Objective-C to be much more robust for Mac programming, simply because: 1) you can learn it quickly if you already know C/C++, and 2) you get a well thought-out API (Cocoa, formerly NeXT's AppKit) with access (both via Objective-C and via libc and other C APIs) to Mach, BSD, and Mac OS X specific goodies.
And, for the love of all that is good, pure, and holy, don't use Swing. It's disgusting. Someone needs to beat it into the ground and start from scratch. The only reason that I would see for using it (and, granted, it's a good reason) is for portability... But in that case, I highly recommend Qt (www.trolltech.com). It works nicely on Windows, Linux, and Mac OS X... Only problem is it isn't necessarily free. =(
Personally, I learned Objective-C in a couple of evenings after reading Apple's (formerly NeXT's) excellent book on Objective-C. It's available for download in PDF format from developer.apple.com.
So I say go for that, I'm sure you'll be impressed with the results you get.
This is what I kinda know:
Hurd is a real microkernel OS. That is, most of the stuff that you'd think of as being in the kernel on Linux is actually in "daemons" that run more-or-less in userland.
Darwin is Mach and the BSD kernel merged together. They both live in kernel space. So why are they using Mach? I dunno.
I don't know abou MkLinux.
http://www.geocrawler.com/lists/3/GNU/332/0/972458 8/
How do you think Perl compares to languages such as Ruby, Python, or Lua? Where do you think Perl has its strengths, when these other languages are accounted for?
Is it just me, or does the "transparent hippie girl" analogy to OSS strike you as f***ing weird?
I can really relate - I'm a senior now in computer science and math, and I've had plenty of nasty problems thrown at me on exams (writing an implementation of malloc, multi-threaded priority-based message passing system, crap like that). Here's just some things I've found that work for me.
1) Make sure you do all projects to their fullest extent, and after doing them, make sure you think about all the things you could do to your solutions to improve them past what the prof asked for. Then study your solutions before the exam. I've found that profs are likely to ask programming questions that are extensions of what was asked on the projects and homework... so this has saved my butt a couple of times.
2) If your school has coding contests, get involved. Even if you lose every time. It's important to learn how to write complex code in a short amount of time for these exams - and coding contests have helped me out a *lot*. Probably 'cause in a coding contest you often have to get the code right the first time (which is what is needed for paper exams) in a short amount of time.
3) Don't be afraid to ask questions during the exam (if this is possible). Last semester I was in the top-ten for exam scores in my CS class. I was also the one asking the most questions. =) Not that I was able to get the solutions out of the prof, but I was able to narrow my parameters. I was able to find out how much error checking he wanted. And I was able to get a lot of ambiguity eliminated.
4) Just be a smart test-taker. =) I know, I know, that's way too general, but what I mean is: don't get pissed at the hard problems until you've done the easy ones, write *some* code down even if you have no f***ing clue, and get plenty of sleep, food, whatever beforehand, enter the test relaxed, and just hope for the best.
Just my $.02
Maybe this isn't exactly what you're asking for, but for me, the first book that comes to mind when you start talking about "programming" from a more conceptual standpoint, is "The Pragmatic Programmer" by Andrew Hunt and David Thomas (Addison-Wesley). Lots of good examples in that book of how to go about programming and how not to go about programming (not just writing code), and lots of great advice on how to improve your craft. Maybe not too much about "conceptial models" as in functional versus imperative or procedural versus object-oriented, but it certainly is worth a look.