Really, software is just a bunch of bytes on your HD. Change those bytes and you've got different software.
Much like cracked games that are actually modified (ah, the good ol' days). The PC gaming industry learned long ago that going against pirates is a losing battle.
I mean, DUH. How hard is it to change software for it to think that some code isn't there? To modify it so that it doesn't execute the 'bad' part of the conditional expression? I've done this for fun with shareware using a low-level debugger at runtime (one that lets you modify registers and see the assembly code as it's given to the CPU).
Hacking software is easier than anything. And once you've done it, you make a patch. I mean really, if they rely on this for counterfeit protection, they're making counterfeiting easier than ever.
duh duh duh duh. It's just like how DVD's CSS was sold to the movie industry as a secure technology. Obviously the developers who created it didn't give a rats ass.
I have started to use fractional clicks. You chumps are triple-clicking, but I get the same work done with 1/3 click!
Actually, the OS 9 Finder (not the X one that is total shit) let you click and a half to navigate volume contents. You'd click and then click and hold on an icon, and then the cursor would turn into a magnifying glass. If you continued to hold (or pushed the space bar to trigger immediately), the icon's window would open (the icon being some sort of container, such as a drive or folder). Within that window (which would pop up centred around the cursor), you could move the magnifying glass to another container and repeat the process until you've gotten to the window you want.
This isn't necessarily a way to fix your system, but it's some points to check to see what's there.
You'd want to check these directories for anything you don't recognize are doesn't seem like they belong,/Sys/Lib/Extensions/Sys/Lib/StartupItems/Sys/Lib/Frameworks//Sys/Lib/PrivateFrameworks - same goes for/Library
Now keep in mind that existing items can be modified, not just added. It's good to familiarize yourself with a base install. For anything that you don't recognize, check your Receipts directories to see if they were installed with some credibility.
You'd also want to check/etc/hostconfig,/etc/rc* . I poke with those files a lot so I have some familiarity with what they're supposed to be like.
You'd also like to examine dot-files and stuff. To make it short, there's a lot of places that shit can go in, but script kiddies aren't that smart and actions may be obvious./var/log/ can be useful stuff too, if you know the timeframe of when stuff happened (hackers aren't likely to clean up system logs that might have traced some actions unknowingly - by default, sudo commands are logged). Similarly, getting used to how dmesg is supposed to look and what ps -auxww is supposed to provide is important.
Keep in mind that/Library's contents (anywhere in it) can affect your system a lot, but most (all?) of those items aren't essential, you should be able to freely remove whatever you want.
To check your system without using it, you can always boot off of a OS 9 volume if your system supports that (it can fit on a CompactFlash card... with my old PowerBook I can at least boot from the PCMCIA slot). I also have 10.1 on another volume that's good for prodding my Panther system with.
NetInfo is a bit of a pickle to familiarize yourself with. Or at least, I haven't familiarized myself with most of the stuff in there yet:P
Anyway, none of this is a guaranteed way to find or fix problems, but it can reveal what's happened. If your system's been comprimised, your only recourse is to wipe it out. Don't even use your old User accounts, as dotfiles and ~/Library may have comprimised stuff. Keep it around with unknown:unknown ownership (and not in/Users) and move things over that you think you need.
The reward of becoming really good at a Mario or Zelda game is that of your friends sitting on the couch behind you saying "holy shit, that was awesome."
Um, how about, "holy shit, that was fun." If I wanted a game that let me numerically assess how good I'm at, I'd count my dribbling of a basket ball on the floor for a minute, and then try to beat that record.
My points were more to the tune that Nintendo does their best to bring products to the market that are well rounded and make relevant use of technology. My old Bally had analog controls, but they really weren't that useful. Nintendo created a complete 3D gaming package with the N64, with four controller ports because now they had more than enough power to do four independent on-screen graphics at the same time.
The Playstation had more great games than the N64 had games
I'd contest that, just saying that the N64 had fewer games but with larger punch, which has always been Nintendo's style. I'm not saying that the PSX had bad games, but one certainly didn't trump the other.
You mean Nintendo, the champion of online connectivity?
Also the only one who's done it right with the Nintendo DS? Nintendo has said for a long time that they have their own strategy for online gaming. Who wants a keyboard while you're in the middle of playing a game?
The first one that jumped to optical media?
And optical media is better than solid state? Optical media is only cheaper (more capacity is cheaper).
And who could forget how fast they made a color portable with a backlight.
Which is still more expensive and more costly than the portable they still sell without a backlight, and still has shorter battery life.
Don't forget that they're the first company with a system that did full 3D graphics and analog control with force feedback (with pixel shaders and anti-aliasing to boot), with 4 controller ports. And the company that set the standard for 3D third person games with Mario 64 and Zelda: Ocarina of Time. The first system to offer 1st party wireless control. And did optical storage right with fast load times. Hell, even the Dreamcast has far better load times than the PS2. And the 3DO has significantly better load times and far better audio than the PSX (SF2 for the 3DO lets you start a fight within 30 seconds of turning it on. PSX takes two minutes). Sony can't learn from their mistakes. How useful is two joysticks compared to analog L and R buttons, which started with the Dreamcast?
You can't develop everything; every feature has a trade-off. At least when Nintendo brings something to market, they do it right.
My advice is to never buy a turbo-charged car. I had one (a '90 Supra Turbo), they're glorious when they work and the engines don't give up (well over 100 km/h and they just keep going), but they WILL blow up. Turbos have a finite lifespan. A turbo forces an engine to do something that it doesn't want to do naturally; you're much better off buying a car that has that much power naturally-aspirated. The problem is, when turbos go, they have a tendency to take some of the engine with them.
You may save money bhp/$ in the short term, but the cost will catch up to you
I think everyone agrees that most x-platform tookits have one glaring weakness - all the platforms share the same user interface. Mozilla supports skinning, which is nice, but it doesn't feel like a Windows application or a Mac application. It feels like an XUL application. NeXT had fantastic x-platform support with OpenStep; it's also how it (and Cocoa) acheive localization. That technique should be able to be used with other toolkits, even if they don't have 'native' support for that technique.
Let's take a look at localization first. Typically, you generate a.strings file for each language. That kinda sucks because if you just did that, all localized versions would share the exact same window and control (widget) dimensions. The following is what Cocoa (OpenStep) does. Each application 'binary' is actually a directory with this kind of layout
Foo.app/Contents/ -/MacOS/ --Foo (executable) -/Windows/ --Foo.exe -/Sparc/ --F oo -/Resources/ --MainWindow.nib (interface file for the main window; controls and stuff) --ToolWindow.nib (interface for tool window; no french version) -/French/ --MainWindow.nib (french version of the main window) --Localized.strings (localized strings for the entire app, excluding those translated in MainWindow.nib)
Hopefully that's self-explanatory. Basically each platform gets its own version of an executable, and each language gets its own version of the interface (falling back to the basic definition in Resources/ if no version for a specific language is found). Well the next step is obvious. If you want to create a windows specific.nib, you create a MainWindow-windows.nib, which will only be used over MainWindow.nib on the Windows platform. Native controls are used on each platform, regardless if there's a platform-specific nib or not.
It's a shame that Cocoa is no longer x-platform (although the support is still there, it's just that the runtime isn't available on other platforms). But this should be possible with other platforms too; you just need to encapsulate resource loading and load the appropriate resource for each platform and localization.
I think I know what you're trying to say, but I'm pretty sure it's not what you've said. OO basically implies explicit interfaces via inheritance, and in that respect, types are everything. You can program very powerfully using generic techniques instead, but then you're not doing OO.
Inheritance is really only a convenience when implementing systems. It shouldn't be used to decide what objects can respond to what messages, but in C++ you don't have any other tool. Java has interfaces, which allows that. In C++ you'd have to use multiple inheritance, but you can only get away with that pattern if objects subclass from parent classes using the virtual keyword.
Types then aren't what's best for defining what an object does. In non-type based languages you'd simply query if your target object responds to a message if you need to (easy in Python or Objective-C). You can do it in Java, but it's more of a pain and it's a bit rare that you'd need to (since types/interfaces define what objects implement).
The confusion comes when you don't understand how to design a system in a non-type oriented environment. I mean really, if you've only used strong typing systems you can't really comment. In such an environment, the names of methods are the most important. A method called 'setObjects:objectList' or 'objects' are methods that take a sequence object and return a sequence object, respectively. Sequence objects respond to messages such as count, objectAtIndex:number, etc. Well defined and standardized method names are what's important in such a system. In strong typed systems you typically don't bother with proper method naming because it's the type that's important.
Strong typing limits you in ways that don't help. If you've only used languages that enforce it, you really won't see the problem with it. But if you take code written in a non-type enforced language such as Python, objective-c, smalltalk, ruby, etc, that takes advantage of that (or rather, implements code in the freedom provided by dynamic 'typing'), you'd be hard pressed to convert that code into a strong typing system; you'd have to redesign it. My point in saying that is that you lose something by using a strong-typing system.
I'm sorry, you lost me there. How does using the STL require any more RTTI to achieve dynamic binding than any other version of the same code?
The only way you can correctly make an object do something that its type doesn't define is to typecast it to another type that does define it, which means using dynamic_cast. RTTI is also the only method for object introspection. Like I said before, if you want to you can define 'interface' classes for multiple-inheritance that you can use to dynamically test, but it ends up failing on a large system because of the virtual base class problem.
If it looks like a duck, sounds like a duck, walks like a duck, it's a duck. It's actually not a duck, but you don't care. It does what you want.
The other way to get dynamic code is with a superclass defines a basic method interface, and a subclass defines a different implementation, which may be what lost you with my comment...
I don't care who invented the word, I care who invented the concept, and the C++ community has collectively contributed more to the OO concept over the years than just about any other.
They only contributed to the C++ concept:-/ C++ is a kind of programming in itself, with the goal of being strongly typed, and making all objects act like C's built-in types. The biggest benefit to OOD/OOP is abstraction, with black boxes working with other black boxes. But you don't have black boxes if you know the type of everything! Try taking two C++ libraries with different designs and make them work together. For example, CORBA's C++ system and anything you wrote. It's a royal pain, if not impossible. In the case that it is impossible, the only thing you can really
Yeah, right. One day you graduate to the level of Supreme Programming God, with the power to effortlessly remember the exact types of all the "void *" pointers they left lying around.
Only an idiot would use void* everywhere. C is not a language that lends itself to not being typesafe.
And of course, you don't need type safety when interfacing to other people's code, because you're just so damn intelligent, you instantly understand everything about their code and don't need those 'training wheels'.
In an object oriented system types are meaningless. What matters is what functionality other objects provide. OO systems have foundation classes that have well defined behaviours (lists, strings, dictionaries, etc). They define a common language that every other object can use to communicate with others. As long as you know you're getting a list, you don't care what type it is. You only care about what kind of model object you have. That's the whole point of MVC.
Because lord knows we all understand exactly what the other programmers mean and don't need no steenking type system to communicate what should and shouldn't be legal.
Good systems have good documentation and non-cryptic structure and method names. Calling a function apls24() is not helpful.
I love Slashdot for these kind of broad-brush statments. Which language uses exceptions or RTTI as its 'main tool'
STL requires you to deal with RTTI if you're going to do anything dynamic with it. Python requires exceptions for any error handling. So does Java.
exactly? And who the hell thinks exceptions and templates are more complicated than implementing the same features _without_ exceptions or templates.
With templates you spend more time programming the language than you do programming your system. Templates are a pain in the ass to code properly because you have to handle every case for every kind of object (for example, ~int() is valid in C++). Every time you use a template with a new type (like vector<int>, vector<char>, vector<object*>), the compiler generates code to implement the template class. Every time you want to use the template you need to declare the type (aren't containers generic?). If you want you can typedef that away. Either way you're programming the language and not your program. Have you tried writing an implementation of the STL? I have, and it proves how idiotic templates are (tell me, how do you create a template that constructs pointer objects (new Object()) and stack-based objects (object())?). C++ didn't have templates to begin with. When the language designed added it, someone else started the STL. Then they modified C++ templates as needed so the STL will work, and objects behave exactly like C's built-in types. To quote Alan Kay, "I invented the term object-oriented, and I did not have C++ in mind."
And you only want templates in a strongly-typed environment. A container shouldn't care what kind of object is stored in it, like Java and Python containers. Try using an object oriented language like Smalltalk or Python that doesn't have templates -- they don't need them.
My guess: someone who has never written a large program
You've obviously never used more than a handful of languages, and would probably use lisp like a procedural language. My guess is that you don't know the difference between functional and procedural programming. Someone who has written large systems knows the level of complexity those 'features' provide. Exceptions aren't a magic bullet; they just move error handling responsibility elsewhere, and blur the line between fault handling and error handling, which is more dangerous than code that doesn't use exceptions. Everyone agrees that jumping around a function using gotos are bad, but somehow dynamically jumping around the program at runtime to undefined places is all ok.
Compare writing CORBA code in Python and C++. CORBA is fairly transp
If you're talking about memory leakage, then language features do make programs less leaky. Language features can turn root holes from buffer overflows into denial of service attacks, and can often discourage writing the code that produces buffer overflows. Lisp programers don't tend to have buffer overflows, because the language makes it simple to just add it on to a list. C programers do, because the language encourages the use of fixed-width arrays and discourages lists (by not including them in the base language, and making it hard not to leak memory.)
The reason is because C is a low-level procedural language, designed back when systems had 16 K of RAM. You can write C code and not use any built-in arrays by making proper use of libraries that provide arrays (such as CoreFoundation), and thus achieve buffer overflow protection easily. The reason why most C programs don't do that is because the standard library doesn't offer that, as it has an ancient heritage. If people are having so many problems of coding wrong in C, use glib! You won't have any such problems.
To add to that: one of the big differences is that Java is type-safe, while C++ isn't!
You really don't know how to use C++. You can use C++ like C, which makes it not-typesafe. But in pure C++ you have to use dynamic_cast, static_cast, const_cast if you're going to do any kind of non-typesafe functionality, otherwise the compiler forces type-safe. Casting to (MyObject*)foo is inherited from C, and is not supposed to be used in C++.
Ok, type-safety can be more like crutches than training wheels. Take a look at Smalltalk or Objective-C, which don't have multiple inheritance or templates. This is not a limitation in those languages, because the types of objects in those languages don't dictate what methods they implement. In those languages, an object can dynamically re-route messages (method calls) they don't implement to another object that does, or understand (by parsing) the message at run-time to do something appropriate. You can't do that if you force types and thus statically enforce functionality on objects. That's just an example of what you can do without type-safety. The compiler, by enforcing type-safety, can't validate what you're doing, it can only limit your actions. As I said, you have to try programming in different languages, and true to the nature in those languages, before you can understand what removing type-safety can do.
In Smalltalk, every 'type' is a pure object. In C++, every object is designed to behave like a built-in type (like int). In Smalltalk, you don't really need to worry about the types of anything, so long as each object can respond to messages you send to them.
Also, you argue that "Java and C++ don't count as different languages". Yes they do look similar, but they are very, very different in use (for a start Java has memory corruption protection features here, there and everywhere".
Smalltalk, C++, Lisp, and Python are all completely different languages. Java is far more like C++ than it is to any of the other languages I mentioned; I consider it to be a cleaned up C++ more than anything, removing the C from C++ (no pointer arithmetic, well, no pointers even). You can convert a Java program into a C++ program with zero effort just by implementing classes needed, and garbage collection (C++ allows you to implement your own memory management by overloading the new and delete operators. You wouldn't need to implement delete by implementing a garbage-collecting new).
I like smalltalk, I think it's a good language. I also think it is not suitable for very-large-scale programming projects.
Yes it is, and there are many people with incredibly high salaries who use IBM VisualAge Smalltalk that would disagree with you.
It is crammed with keywords, and it contains the notion of Objects and Classes.
But I see that as a good thing - you can concentrate on the mainline code and introduce the student to control flow and so forth, but when you come to the concepts of classes you've got a nice immediate example to point to.
The extra keywords tell the student nothing about object-oriented programming, nor serve as an example of object-oriented programming. A student needs to learn about conditionals, loops, basic algorithm techniques such as bubble-sorts, and computational-complexity. All this really means is that Java's not a great student language (Turing and Pascal are better), not that Java is a bad language. But I use this to serve as an example of language complexity.
As for type-safety, try programming in Python, Smalltalk, and Lisp. Types are irrelevant. In an object-oriented or functional system, you really don't care about the type of anything, just as long as objects (which are supposed to be anonymous black boxes) respond to the messages (have method implementations) you need them to respond to, or that functions transform data the way you need them to. Type-safety is overrated. Strong type-safety is a product of bad C code, where you can cast anything to anything and just start programming with pointer arithmetic. Type-safety should not be the focus of an object-oriented program; messages should be.
Simple, you don't make programs so stupid. Here's what a program does. "OH SHIT! THAT WASN'T SUPPOSED TO HAPPEN! EXCEPTION! Oh shit, there's no exception handler. CORE DUMP!"
The problem comes down to 'that wasn't supposed to happen.' It reminds me of my 2nd year CSC course when my prof said "assume all your input is correct." WTF? They never teach you about error handling in university (not in any curriculum that I've seen anyway).
The problem is that 'errors' aren't talked about much; we just all agree that they're bad and throw an exception (or SIGTERM) when one happens. We're also told to write programs that are correct, and that programs are either correct or not. There's confusion there.
Programs are either faulty or not, in that they either do what they're told or not. A correct program does what it's expected to do.
The problem is when you confuse faults with errors. Faults must not happen. Errors are expected to happen! You can't assume that all your input is correct. You can't just bury your head in the sand and throw an 'i/o error' exception.
You have to keep things simple and design your systems to follow certain rules. In this case, code should do what it was asked to do or not do it. That second option has to be considered as part of the design. You can't design code that will work if everything happens as expected, and will throw some kind of exception (caught by who knows what) if something unexpected happens. If you let everything have a simple chance to succeed or fail, errors can cascade cleanly to some other code that cares to handle it.
For example, say a library is using some other library to write data. Library #2 tells lib #1 that it can't write the data asked. Lib #1 tells the code that calls it that it can't write a PNG file. The user application tells the user that it can't save the document as PNG. If exceptions were used, it would have to be caught. And by which part of this system? What if one part expects another part to catch the exception?
The only thing missing in that example is why the failure occurred. In OOP systems it is easy to communicate between components - communication between 'black boxes' is the whole point in OOP. The way I do it is that if an object is unable to perform a requested action it returns a basic 'no' response, and the reason can be queried from that object later (model objects wouldn't have this ability and they shouldn't - but controller objects would).
Anyway, the point is that 'errors' (which are really just things you didn't plan for but should have) do happen and you have to design your systems for it.
Here's some food for thought, Objective-C vs. Smalltalk. In Smalltalk, every method returns 'self' (this) as a result unless you explicitly return a different object in the code. This allows you to chain messages (method calls) together,
mailbox messages lastObject description.
my Smalltalk's a bit rusty, but mailbox is an object, messages is a method that returns an array object, which responds to the lastObject message. This expression evauluates to the description object for the last email in the mailbox. In Objective-C, you'd write it like this,
[[[mailbox messages] lastObject] description];
Which does pretty much the same thing. There's one difference between Smalltalk and Objective-C, which has been debated for some time. Let's say that the messages array had a count of 0. In both Smalltalk and Objective-C code, you'd expect that lastObject return a nil value. The difference between the two languages is their concept of nil. In Smalltalk, nil an another object that raises a DoesNotUnderstand exception to any message that's sent to it. In Objective-C, nil is treated like a black hole, and sending messages to ni
I think it comes down to a matter of discipline. One of the things that made Unix such a success is KISS. Unix is built around the philo that you should focus on one thing and do that one thing well. Tools in Unix don't re-invent the wheel to get stuff done; they rely on other tools.
Another thing that comes to mind is what Apple's VP of hardware engineering Jon Rubenstein said in an interview. He said that engineers get too creative when they do work, and end up engineering things that do not need engineering - the rote work, as he put it. You have to get engineers to be creative in the non-rote work.
IMO, Java is too complicated and easily gets in the way (I'm not going to touch C++ here). At least with C you can start off with a one-line Hello World program. I've seen first-year CS students trying to understand the many lines of code that constitutes a Java Hello World program (there are so many elements to a typical Java HW example; the class declaration, the static main declaration, the exception handler, System.out, etc. Every token except for "Hello, world!" is gobbldygook to newbies). In the case of C, it can go either way. To a well disciplined programmer, C programs can be extremely elegant. On the other hand, you can end up with some really fug-ugly code. However, a Pascal programmer is more likely to use C in an elegant way because Pascal is simple enough to make a programmer focus on the task, restricting the programmer's freedom to do stupid things.
Although many argue that type-safety is incredibly important, that you can get really weird behaviour if you don't have type-safety, and that it's important that languages restrict programmers by being type-safe. Uh, no. Type-safety is like training wheels. If your program is well structured, 'types' in the program are for the most part irrelevant. What matters is what the code is doing, and knowing what the general flow of the program accomplishes. In a well-structured program with a well-defined execution flow, the data that moves around should always be well defined anyway.
Here's another way to look at it (something an old professor brought up). What useful program has no input and produces no output? There is no such thing. Your job as a programmer is to transform your input sources to your desired output products. And the path to get that done should be as simple as possible. Unfortunately, we've got languages with templates, boxing/unboxing, exceptions, RTTI, etc as our main tools, that often provokes us to design systems that are more complicated than they should be.
Really, it's like an artist trying to make a painting, and going out and buying a self-cleaning, featherweight, self-balancing $1K paintbrush. That's way beyond the point, isn't it? An artist needs to envision their artwork and realize it in their medium of choice. Similarly, a programmer needs to understand the problem they need to solve and then efficiently implement it on their target system (be it a PC or an automated toaster oven). Language features don't make programmers write better programs; discipline does. I can't remember the example perfectly, but it's something like, if you give a team 20 tools to do the job, they'll try and use all 20 tools. If you give a team 4 of those tools that they really need, they'll find a solution too - and a more efficient one.
Anyway, KISS. You need to focus on what execution paths your program takes and what affects those execution paths (and note that exceptions throw a wrench into that. I avoid them). Don't get too creative with the language you're using. The best thing for a programmer to do is to learn how to program non-trivial projects in several different languages (Java and C++ don't count as different languages). And then hopefully more programmers will demand cleaner programming environments that aren't just souped-up C++ clones, and programming will stink less. (Take a look at Smalltalk some time).
The fish is our friend. Or maybe not; see if you find this useful. I got it off the story section of the Casshern site.
As for there, the history which we walk the world where you walk the history which differs completely. The great war continues, as many as 50 years as for the world calls large Asian federal republic and European combination, it had divided into two camps. On end of the long fight, victory it did large Asian federal republic, controlling the east Asian Eurasian continent tract reached the point of. But, those which are obtained with the victory in devastation of human nature, the chemical weapon and the germ weapon, the sequela of the chemical injury and the virus and the radioactivity etc. which the nucleus brings were just the ground which becomes rough. Does the mankind sitting down, just receive loose end?
And oddly enough, consumers are choosing Linux over MacOS. Is everyone stupid, or are there other mitigating factors that you didn't cover in your sermon?
Consumer's aren't choosing Linux, enterprises are choosing Linux for desktops. Mom and Pop aren't formatting their hard drives and installing Linux distros on their 'box' at home. If anything, Microsoft has to worry about the loss of enterprise desktop share, not Apple, who's not in enterprise.
Enterprise takes what's cheap and what works. That's why they buy thousands of identical, feature-less Dell boxes. And that's why they'll install Linux on those boxes instead of Windows XP Pro if Linux does what they need it to do. I mean seriously, why would you install XP in the enterprise? The reasons keep diminishing.
Apple has to make higher priced units that will yeild larger profits due to the price, not because of a markup
Apple's no longer in a position to afford profiting by quantity. The first step is to make the public want Macs. In 1997, the public didn't care. In 2004, finally, Apple is associated with Cool. The public wants Macs.
The thing I find is, whenever I tell someone how much an entry level iMac costs, they're always shocked because it's less than they expected. Step 2 is to make the public decide to buy Macs. That's what the Apple stores and the iPods are for.
but a lot of really bad ones.In the meantime, the Mac's marketshare fell below 2% and has been overtaken by Linux Desktop's share.
That's not Jobs' fault. That's Sculley's, and that's the dispute that caused Steve to leave Apple. Steve and Steve started Apple to make computers For the Rest of Us. Computers that people could use; not room-size boxes hidden away in an industrial building.
Sculley had a vision of using Apple's superior technology to make products with high margins and turn Apple into a billion dollar company. And he did. And he gave up marketshare for that.
Lots of people agree that the real reason of the Mac slow but sure descent into Hell is Job's elitist vision and its results, overpriced hardware, rumor cult(ure) at Apple, etc.
Lots of people are uninformed, but that doesn't make them right. Macs aren't overpriced; they're worth every penny you spend on them, the only problem is that you don't have the choice to spend less for things you don't want because Apple doesn't offer those products (like an iMac without the flat panel display and built-in Bluetooth but in an ATX case).
On the same token, Apple can't charge the same prices that Dell does in order to gain market share; they need to fund their R & D divisions. Dell makes money on volume (quanitity). People buy Macs for quality. Apple has to make higher priced units that will yeild larger profits due to the price, not because of a markup. The reason that Apple can't make money on quantity is Sculley's fault, not Jobs. Apple computers were affordable before Jobs left.
Steve's company brought the first personal computer (that could plug into a TV screen, with colour graphics and sound) to the masses. Also the first consumer floppy drive (tapes were the thing before that). The first computer with a GUI, and the first laser printers (along with Canon). And again, when Jobs came back, he brought the iMac, the iPod, and the entire iLife suite to the masses (iDVD, iMovie, etc). Those things wouldn't exist without Jobs; the PC industry was declared dead with no future until Jobs announced the iMac and the digital hub.
Why do so many people worship this one guy?
He's one of the very few people in the consumer-oriented computer industry that moves it forward. Enterprise computing has their own heros (Oracle and Sun come to mind).
First of all, Mark/Space is not a solution. They do not provide a framework for conduits. Synching with iTunes and iPhoto is nice and all, but what about a Mac application that wants to synch to some Palm app?
The only thing I can think of is that Apple intends to open up iSync so that developers can write their own synching modules (iSync is currently a closed system that only Apple can sync data with). If Apple wants to do this, this is a much better use experience for Mac users, and there's no reason then for Apple to limit it to Palm devices; they could support Win CE devices as well.
As for an Apple based PDA, that's not going to happen. Palm and MS can barely hang on to the PDA market with smart phones and other integrated devices coming into the market; what's Apple going to add that allows them to break into the market? And what about application vendor support?
In the past, Steve said that he wanted to buy Palm. Perhaps Steve's got a plan that we're not aware of. But at this point, we can only dream; being a Mac PDA user now officially sucks.
I went over to a friend's house the other day. He was having problems with his computer and he asked me to look at it, and I realized he had Windows Me and it's like, oh no--that's your first problem.
As a Mac/FreeBSD user, who understands that people have to use Windows, I have a question. Why do people hate Windows Me specifically? As a product, I realize it's stupid to upgrade to (Win98 + different salad dressing), but if it was just that I don't see why people would hate it so much. From people I've met, it sounds like installing Me is the worth thing you can put on your box; people would rather use 98. Is it just that the removal of real mode DOS causes more problems than it solves or something?
And second, Aragorn refused the Ring, Gandalf refused it. Why can't Faramir do it as well?
Did you get to watch the extended DVD?:-/ It really was bad for them to cut out that scene, as it set the stage for Faramir's behaviour in TTT. Otherwise it's just a butchering of the character. Taking that scene into account, the ending where he finally lets the hobbits go and Sam says that "you've have shown your quality" shows us Faramir's character. Really, Faramir didn't desire to have the ring. He was drawn to it as Gandalf ("don't tempt me Frodo!") and Aragorn (end of fellowship) did, and all he really desired was to get it to Gondor; the motivation behind that is in the cut scene.
Again, I am not against Arwen per se, blah blah
Agreeded, her use in the movie is far from perfect, and I really didn't 'get' her bonding with Aragorn while he was far away (turns out they were dream sequences; I really didn't know what was going on). But hey, it's not like Tolkein wrote LOTR in four years. And PJ had to produce, direct, and edit three movies too!
I hated it.:) In the book they only bow to Sam and Frodo! What did Pippin do that was so great?:)
Well, yes, but it's a direct scene (people bow to the short hobbits who have never been regarded as heros, if their existence had been acknowledged at all) not a factual scene:-/ It takes time to set up a sequence to describe 'we only bow to these two hobbits, and we only praise these other two for their valiant service." It's hard to get the point across and not bore the audience. But it's really easy to offend people who know the story well:)
The only Rohan village was the one necessary to the plot.
I think that the village that burned down was a major failing of the movie. A couple houses burning down in a field by crazy aggressive people is normal course during war times. If it felt that they destroyed something more significant (a prosperous town), not only would it have given the audience a better perspective of Rohan, but it definitely would have been more impactful and make the subsequent events (Theoden choosing to do whatever) easier to accept.
Assuming 1 km separation, Edoras is about 5000-10000 kilometers from Minas-Tirith. Does that make any sense?
It's a movie... you have to get the point across and hope that the environment presented fills the gaps so that the audience accepts what they're witnessing as they watch it.
What's a really good exercise, as far as learning what time constraints can do when trying to visually present a story, is to watch the Macross Plus OVA series and then the Macross Plus movie. Both were created by the same team, director/writers. However, one is 45min x 4, and the other is movie length. And the movie length one has extra scenes. With the OVA, you watch each volume one by one. In Japan, they were released several months apart, so each volume is expected to be watched over and over; there's much more detail and depth than is apparent at first. Shockingly, not a single frame of animation is wasted! Every second of the story has something that contributes to the understand of the plot, the characters, or the world they're in.
Then there's the movie. The first 30-40 minutes is pretty much, WTF? And then, WTF? But when it's all over you see what Kawamori-san meant when he said that it's how he expected to present Macross Plus. It's a different representation of the same story, pulled apart and re-assembled by so many constraints. But in this case, it's the same person who chose to do that as the person who created it. And it's not George Lucas we're talking about....
Anyway, I like your response. Your initial post was too short and lacked the depth needed to properly appreciate it;-)
The problem is that MP3 in particular always butchers treble, no matter what the bitrate. It's just what it does (I'm not an audio codec expert, but that's the way MP3 behaves, in the same way that CinePak often looks like pixel-doubling).
320 AAC is quite good and I haven't passed judgment on it yet. But when I regularly listened to AACs at lower bitrate (say 192-256) and put the source CD into the drive, the CD sounded less artificial at times:-/ A large part of it depends on what you're using to listen to stuff; 320 ACC isn't going to help you if you're listening with $50 bargain-bin speakers:P
Slashdot Mirror
Really, software is just a bunch of bytes on your HD. Change those bytes and you've got different software.
Much like cracked games that are actually modified (ah, the good ol' days). The PC gaming industry learned long ago that going against pirates is a losing battle.
I mean, DUH. How hard is it to change software for it to think that some code isn't there? To modify it so that it doesn't execute the 'bad' part of the conditional expression? I've done this for fun with shareware using a low-level debugger at runtime (one that lets you modify registers and see the assembly code as it's given to the CPU).
Hacking software is easier than anything. And once you've done it, you make a patch. I mean really, if they rely on this for counterfeit protection, they're making counterfeiting easier than ever.
duh duh duh duh. It's just like how DVD's CSS was sold to the movie industry as a secure technology. Obviously the developers who created it didn't give a rats ass.
I have started to use fractional clicks. You chumps are triple-clicking, but I get the same work done with 1/3 click!
Actually, the OS 9 Finder (not the X one that is total shit) let you click and a half to navigate volume contents. You'd click and then click and hold on an icon, and then the cursor would turn into a magnifying glass. If you continued to hold (or pushed the space bar to trigger immediately), the icon's window would open (the icon being some sort of container, such as a drive or folder). Within that window (which would pop up centred around the cursor), you could move the magnifying glass to another container and repeat the process until you've gotten to the window you want.
It's called spring-loaded folders.
This isn't necessarily a way to fix your system, but it's some points to check to see what's there.
/Sys/Lib/Extensions /Sys/Lib/StartupItems /Sys/Lib/Frameworks/ /Sys/Lib/PrivateFrameworks /Library
/etc/hostconfig, /etc/rc* . I poke with those files a lot so I have some familiarity with what they're supposed to be like.
/var/log/ can be useful stuff too, if you know the timeframe of when stuff happened (hackers aren't likely to clean up system logs that might have traced some actions unknowingly - by default, sudo commands are logged). Similarly, getting used to how dmesg is supposed to look and what ps -auxww is supposed to provide is important.
/Library's contents (anywhere in it) can affect your system a lot, but most (all?) of those items aren't essential, you should be able to freely remove whatever you want.
:P
/Users) and move things over that you think you need.
You'd want to check these directories for anything you don't recognize are doesn't seem like they belong,
- same goes for
Now keep in mind that existing items can be modified, not just added. It's good to familiarize yourself with a base install. For anything that you don't recognize, check your Receipts directories to see if they were installed with some credibility.
You'd also want to check
You'd also like to examine dot-files and stuff. To make it short, there's a lot of places that shit can go in, but script kiddies aren't that smart and actions may be obvious.
Keep in mind that
To check your system without using it, you can always boot off of a OS 9 volume if your system supports that (it can fit on a CompactFlash card... with my old PowerBook I can at least boot from the PCMCIA slot). I also have 10.1 on another volume that's good for prodding my Panther system with.
NetInfo is a bit of a pickle to familiarize yourself with. Or at least, I haven't familiarized myself with most of the stuff in there yet
Anyway, none of this is a guaranteed way to find or fix problems, but it can reveal what's happened. If your system's been comprimised, your only recourse is to wipe it out. Don't even use your old User accounts, as dotfiles and ~/Library may have comprimised stuff. Keep it around with unknown:unknown ownership (and not in
The reward of becoming really good at a Mario or Zelda game is that of your friends sitting on the couch behind you saying "holy shit, that was awesome."
Um, how about, "holy shit, that was fun." If I wanted a game that let me numerically assess how good I'm at, I'd count my dribbling of a basket ball on the floor for a minute, and then try to beat that record.
Oh, and the Nintendo 64 wasn't the first
My points were more to the tune that Nintendo does their best to bring products to the market that are well rounded and make relevant use of technology. My old Bally had analog controls, but they really weren't that useful. Nintendo created a complete 3D gaming package with the N64, with four controller ports because now they had more than enough power to do four independent on-screen graphics at the same time.
The Playstation had more great games than the N64 had games
I'd contest that, just saying that the N64 had fewer games but with larger punch, which has always been Nintendo's style. I'm not saying that the PSX had bad games, but one certainly didn't trump the other.
You mean Nintendo, the champion of online connectivity?
Also the only one who's done it right with the Nintendo DS? Nintendo has said for a long time that they have their own strategy for online gaming. Who wants a keyboard while you're in the middle of playing a game?
The first one that jumped to optical media?
And optical media is better than solid state? Optical media is only cheaper (more capacity is cheaper).
And who could forget how fast they made a color portable with a backlight.
Which is still more expensive and more costly than the portable they still sell without a backlight, and still has shorter battery life.
Don't forget that they're the first company with a system that did full 3D graphics and analog control with force feedback (with pixel shaders and anti-aliasing to boot), with 4 controller ports. And the company that set the standard for 3D third person games with Mario 64 and Zelda: Ocarina of Time. The first system to offer 1st party wireless control. And did optical storage right with fast load times. Hell, even the Dreamcast has far better load times than the PS2. And the 3DO has significantly better load times and far better audio than the PSX (SF2 for the 3DO lets you start a fight within 30 seconds of turning it on. PSX takes two minutes). Sony can't learn from their mistakes. How useful is two joysticks compared to analog L and R buttons, which started with the Dreamcast?
You can't develop everything; every feature has a trade-off. At least when Nintendo brings something to market, they do it right.
50% of the WRX had broken transmission or turbo
My advice is to never buy a turbo-charged car. I had one (a '90 Supra Turbo), they're glorious when they work and the engines don't give up (well over 100 km/h and they just keep going), but they WILL blow up. Turbos have a finite lifespan. A turbo forces an engine to do something that it doesn't want to do naturally; you're much better off buying a car that has that much power naturally-aspirated. The problem is, when turbos go, they have a tendency to take some of the engine with them.
You may save money bhp/$ in the short term, but the cost will catch up to you
(I'm a bit bitter, but I love my new car).
I think everyone agrees that most x-platform tookits have one glaring weakness - all the platforms share the same user interface. Mozilla supports skinning, which is nice, but it doesn't feel like a Windows application or a Mac application. It feels like an XUL application. NeXT had fantastic x-platform support with OpenStep; it's also how it (and Cocoa) acheive localization. That technique should be able to be used with other toolkits, even if they don't have 'native' support for that technique.
Let's take a look at localization first. Typically, you generate a .strings file for each language. That kinda sucks because if you just did that, all localized versions would share the exact same window and control (widget) dimensions. The following is what Cocoa (OpenStep) does. Each application 'binary' is actually a directory with this kind of layout
Hopefully that's self-explanatory. Basically each platform gets its own version of an executable, and each language gets its own version of the interface (falling back to the basic definition in Resources/ if no version for a specific language is found). Well the next step is obvious. If you want to create a windows specific .nib, you create a MainWindow-windows.nib, which will only be used over MainWindow.nib on the Windows platform. Native controls are used on each platform, regardless if there's a platform-specific nib or not.
It's a shame that Cocoa is no longer x-platform (although the support is still there, it's just that the runtime isn't available on other platforms). But this should be possible with other platforms too; you just need to encapsulate resource loading and load the appropriate resource for each platform and localization.
Inheritance is really only a convenience when implementing systems. It shouldn't be used to decide what objects can respond to what messages, but in C++ you don't have any other tool. Java has interfaces, which allows that. In C++ you'd have to use multiple inheritance, but you can only get away with that pattern if objects subclass from parent classes using the virtual keyword.
Types then aren't what's best for defining what an object does. In non-type based languages you'd simply query if your target object responds to a message if you need to (easy in Python or Objective-C). You can do it in Java, but it's more of a pain and it's a bit rare that you'd need to (since types/interfaces define what objects implement).
The confusion comes when you don't understand how to design a system in a non-type oriented environment. I mean really, if you've only used strong typing systems you can't really comment. In such an environment, the names of methods are the most important. A method called 'setObjects:objectList' or 'objects' are methods that take a sequence object and return a sequence object, respectively. Sequence objects respond to messages such as count, objectAtIndex:number, etc. Well defined and standardized method names are what's important in such a system. In strong typed systems you typically don't bother with proper method naming because it's the type that's important.
Strong typing limits you in ways that don't help. If you've only used languages that enforce it, you really won't see the problem with it. But if you take code written in a non-type enforced language such as Python, objective-c, smalltalk, ruby, etc, that takes advantage of that (or rather, implements code in the freedom provided by dynamic 'typing'), you'd be hard pressed to convert that code into a strong typing system; you'd have to redesign it. My point in saying that is that you lose something by using a strong-typing system.
The only way you can correctly make an object do something that its type doesn't define is to typecast it to another type that does define it, which means using dynamic_cast. RTTI is also the only method for object introspection. Like I said before, if you want to you can define 'interface' classes for multiple-inheritance that you can use to dynamically test, but it ends up failing on a large system because of the virtual base class problem.
If it looks like a duck, sounds like a duck, walks like a duck, it's a duck. It's actually not a duck, but you don't care. It does what you want.
The other way to get dynamic code is with a superclass defines a basic method interface, and a subclass defines a different implementation, which may be what lost you with my comment...
They only contributed to the C++ concept :-/ C++ is a kind of programming in itself, with the goal of being strongly typed, and making all objects act like C's built-in types. The biggest benefit to OOD/OOP is abstraction, with black boxes working with other black boxes. But you don't have black boxes if you know the type of everything! Try taking two C++ libraries with different designs and make them work together. For example, CORBA's C++ system and anything you wrote. It's a royal pain, if not impossible. In the case that it is impossible, the only thing you can really
Yeah, right. One day you graduate to the level of Supreme Programming God, with the power to effortlessly remember the exact types of all the "void *" pointers they left lying around.
Only an idiot would use void* everywhere. C is not a language that lends itself to not being typesafe.
And of course, you don't need type safety when interfacing to other people's code, because you're just so damn intelligent, you instantly understand everything about their code and don't need those 'training wheels'.
In an object oriented system types are meaningless. What matters is what functionality other objects provide. OO systems have foundation classes that have well defined behaviours (lists, strings, dictionaries, etc). They define a common language that every other object can use to communicate with others. As long as you know you're getting a list, you don't care what type it is. You only care about what kind of model object you have. That's the whole point of MVC.
Because lord knows we all understand exactly what the other programmers mean and don't need no steenking type system to communicate what should and shouldn't be legal.
Good systems have good documentation and non-cryptic structure and method names. Calling a function apls24() is not helpful.
I love Slashdot for these kind of broad-brush statments. Which language uses exceptions or RTTI as its 'main tool'
STL requires you to deal with RTTI if you're going to do anything dynamic with it. Python requires exceptions for any error handling. So does Java.
exactly? And who the hell thinks exceptions and templates are more complicated than implementing the same features _without_ exceptions or templates.
With templates you spend more time programming the language than you do programming your system. Templates are a pain in the ass to code properly because you have to handle every case for every kind of object (for example, ~int() is valid in C++). Every time you use a template with a new type (like vector<int>, vector<char>, vector<object*>), the compiler generates code to implement the template class. Every time you want to use the template you need to declare the type (aren't containers generic?). If you want you can typedef that away. Either way you're programming the language and not your program. Have you tried writing an implementation of the STL? I have, and it proves how idiotic templates are (tell me, how do you create a template that constructs pointer objects (new Object()) and stack-based objects (object())?). C++ didn't have templates to begin with. When the language designed added it, someone else started the STL. Then they modified C++ templates as needed so the STL will work, and objects behave exactly like C's built-in types. To quote Alan Kay, "I invented the term object-oriented, and I did not have C++ in mind."
And you only want templates in a strongly-typed environment. A container shouldn't care what kind of object is stored in it, like Java and Python containers. Try using an object oriented language like Smalltalk or Python that doesn't have templates -- they don't need them.
My guess: someone who has never written a large program
You've obviously never used more than a handful of languages, and would probably use lisp like a procedural language. My guess is that you don't know the difference between functional and procedural programming. Someone who has written large systems knows the level of complexity those 'features' provide. Exceptions aren't a magic bullet; they just move error handling responsibility elsewhere, and blur the line between fault handling and error handling, which is more dangerous than code that doesn't use exceptions. Everyone agrees that jumping around a function using gotos are bad, but somehow dynamically jumping around the program at runtime to undefined places is all ok.
Compare writing CORBA code in Python and C++. CORBA is fairly transp
If you're talking about memory leakage, then language features do make programs less leaky. Language features can turn root holes from buffer overflows into denial of service attacks, and can often discourage writing the code that produces buffer overflows. Lisp programers don't tend to have buffer overflows, because the language makes it simple to just add it on to a list. C programers do, because the language encourages the use of fixed-width arrays and discourages lists (by not including them in the base language, and making it hard not to leak memory.)
The reason is because C is a low-level procedural language, designed back when systems had 16 K of RAM. You can write C code and not use any built-in arrays by making proper use of libraries that provide arrays (such as CoreFoundation), and thus achieve buffer overflow protection easily. The reason why most C programs don't do that is because the standard library doesn't offer that, as it has an ancient heritage. If people are having so many problems of coding wrong in C, use glib! You won't have any such problems.
To add to that: one of the big differences is that Java is type-safe, while C++ isn't!
You really don't know how to use C++. You can use C++ like C, which makes it not-typesafe. But in pure C++ you have to use dynamic_cast, static_cast, const_cast if you're going to do any kind of non-typesafe functionality, otherwise the compiler forces type-safe. Casting to (MyObject*)foo is inherited from C, and is not supposed to be used in C++.
Ok, type-safety can be more like crutches than training wheels. Take a look at Smalltalk or Objective-C, which don't have multiple inheritance or templates. This is not a limitation in those languages, because the types of objects in those languages don't dictate what methods they implement. In those languages, an object can dynamically re-route messages (method calls) they don't implement to another object that does, or understand (by parsing) the message at run-time to do something appropriate. You can't do that if you force types and thus statically enforce functionality on objects. That's just an example of what you can do without type-safety. The compiler, by enforcing type-safety, can't validate what you're doing, it can only limit your actions. As I said, you have to try programming in different languages, and true to the nature in those languages, before you can understand what removing type-safety can do.
In Smalltalk, every 'type' is a pure object. In C++, every object is designed to behave like a built-in type (like int). In Smalltalk, you don't really need to worry about the types of anything, so long as each object can respond to messages you send to them.
Smalltalk, C++, Lisp, and Python are all completely different languages. Java is far more like C++ than it is to any of the other languages I mentioned; I consider it to be a cleaned up C++ more than anything, removing the C from C++ (no pointer arithmetic, well, no pointers even). You can convert a Java program into a C++ program with zero effort just by implementing classes needed, and garbage collection (C++ allows you to implement your own memory management by overloading the new and delete operators. You wouldn't need to implement delete by implementing a garbage-collecting new).
Yes it is, and there are many people with incredibly high salaries who use IBM VisualAge Smalltalk that would disagree with you.
The extra keywords tell the student nothing about object-oriented programming, nor serve as an example of object-oriented programming. A student needs to learn about conditionals, loops, basic algorithm techniques such as bubble-sorts, and computational-complexity. All this really means is that Java's not a great student language (Turing and Pascal are better), not that Java is a bad language. But I use this to serve as an example of language complexity.
As for type-safety, try programming in Python, Smalltalk, and Lisp. Types are irrelevant. In an object-oriented or functional system, you really don't care about the type of anything, just as long as objects (which are supposed to be anonymous black boxes) respond to the messages (have method implementations) you need them to respond to, or that functions transform data the way you need them to. Type-safety is overrated. Strong type-safety is a product of bad C code, where you can cast anything to anything and just start programming with pointer arithmetic. Type-safety should not be the focus of an object-oriented program; messages should be.
The idea is that you would put that work into a library, and to use tools that work, rather than re-invent them.
This is easy to say, but what to do about it?
Simple, you don't make programs so stupid. Here's what a program does. "OH SHIT! THAT WASN'T SUPPOSED TO HAPPEN! EXCEPTION! Oh shit, there's no exception handler. CORE DUMP!"
The problem comes down to 'that wasn't supposed to happen.' It reminds me of my 2nd year CSC course when my prof said "assume all your input is correct." WTF? They never teach you about error handling in university (not in any curriculum that I've seen anyway).
The problem is that 'errors' aren't talked about much; we just all agree that they're bad and throw an exception (or SIGTERM) when one happens. We're also told to write programs that are correct, and that programs are either correct or not. There's confusion there.
Programs are either faulty or not, in that they either do what they're told or not. A correct program does what it's expected to do.
The problem is when you confuse faults with errors. Faults must not happen. Errors are expected to happen! You can't assume that all your input is correct. You can't just bury your head in the sand and throw an 'i/o error' exception.
You have to keep things simple and design your systems to follow certain rules. In this case, code should do what it was asked to do or not do it. That second option has to be considered as part of the design. You can't design code that will work if everything happens as expected, and will throw some kind of exception (caught by who knows what) if something unexpected happens. If you let everything have a simple chance to succeed or fail, errors can cascade cleanly to some other code that cares to handle it.
For example, say a library is using some other library to write data. Library #2 tells lib #1 that it can't write the data asked. Lib #1 tells the code that calls it that it can't write a PNG file. The user application tells the user that it can't save the document as PNG. If exceptions were used, it would have to be caught. And by which part of this system? What if one part expects another part to catch the exception?
The only thing missing in that example is why the failure occurred. In OOP systems it is easy to communicate between components - communication between 'black boxes' is the whole point in OOP. The way I do it is that if an object is unable to perform a requested action it returns a basic 'no' response, and the reason can be queried from that object later (model objects wouldn't have this ability and they shouldn't - but controller objects would).
Anyway, the point is that 'errors' (which are really just things you didn't plan for but should have) do happen and you have to design your systems for it.
Here's some food for thought, Objective-C vs. Smalltalk. In Smalltalk, every method returns 'self' (this) as a result unless you explicitly return a different object in the code. This allows you to chain messages (method calls) together,
my Smalltalk's a bit rusty, but mailbox is an object, messages is a method that returns an array object, which responds to the lastObject message. This expression evauluates to the description object for the last email in the mailbox. In Objective-C, you'd write it like this,
Which does pretty much the same thing. There's one difference between Smalltalk and Objective-C, which has been debated for some time. Let's say that the messages array had a count of 0. In both Smalltalk and Objective-C code, you'd expect that lastObject return a nil value. The difference between the two languages is their concept of nil. In Smalltalk, nil an another object that raises a DoesNotUnderstand exception to any message that's sent to it. In Objective-C, nil is treated like a black hole, and sending messages to ni
Uh, I haven't read the salon article.
I think it comes down to a matter of discipline. One of the things that made Unix such a success is KISS. Unix is built around the philo that you should focus on one thing and do that one thing well. Tools in Unix don't re-invent the wheel to get stuff done; they rely on other tools.
Another thing that comes to mind is what Apple's VP of hardware engineering Jon Rubenstein said in an interview. He said that engineers get too creative when they do work, and end up engineering things that do not need engineering - the rote work, as he put it. You have to get engineers to be creative in the non-rote work.
IMO, Java is too complicated and easily gets in the way (I'm not going to touch C++ here). At least with C you can start off with a one-line Hello World program. I've seen first-year CS students trying to understand the many lines of code that constitutes a Java Hello World program (there are so many elements to a typical Java HW example; the class declaration, the static main declaration, the exception handler, System.out, etc. Every token except for "Hello, world!" is gobbldygook to newbies). In the case of C, it can go either way. To a well disciplined programmer, C programs can be extremely elegant. On the other hand, you can end up with some really fug-ugly code. However, a Pascal programmer is more likely to use C in an elegant way because Pascal is simple enough to make a programmer focus on the task, restricting the programmer's freedom to do stupid things.
Although many argue that type-safety is incredibly important, that you can get really weird behaviour if you don't have type-safety, and that it's important that languages restrict programmers by being type-safe. Uh, no. Type-safety is like training wheels. If your program is well structured, 'types' in the program are for the most part irrelevant. What matters is what the code is doing, and knowing what the general flow of the program accomplishes. In a well-structured program with a well-defined execution flow, the data that moves around should always be well defined anyway.
Here's another way to look at it (something an old professor brought up). What useful program has no input and produces no output? There is no such thing. Your job as a programmer is to transform your input sources to your desired output products. And the path to get that done should be as simple as possible. Unfortunately, we've got languages with templates, boxing/unboxing, exceptions, RTTI, etc as our main tools, that often provokes us to design systems that are more complicated than they should be.
Really, it's like an artist trying to make a painting, and going out and buying a self-cleaning, featherweight, self-balancing $1K paintbrush. That's way beyond the point, isn't it? An artist needs to envision their artwork and realize it in their medium of choice. Similarly, a programmer needs to understand the problem they need to solve and then efficiently implement it on their target system (be it a PC or an automated toaster oven). Language features don't make programmers write better programs; discipline does. I can't remember the example perfectly, but it's something like, if you give a team 20 tools to do the job, they'll try and use all 20 tools. If you give a team 4 of those tools that they really need, they'll find a solution too - and a more efficient one.
Anyway, KISS. You need to focus on what execution paths your program takes and what affects those execution paths (and note that exceptions throw a wrench into that. I avoid them). Don't get too creative with the language you're using. The best thing for a programmer to do is to learn how to program non-trivial projects in several different languages (Java and C++ don't count as different languages). And then hopefully more programmers will demand cleaner programming environments that aren't just souped-up C++ clones, and programming will stink less. (Take a look at Smalltalk some time).
The fish is our friend. Or maybe not; see if you find this useful. I got it off the story section of the Casshern site.
Um, yeah.
Consumer's aren't choosing Linux, enterprises are choosing Linux for desktops. Mom and Pop aren't formatting their hard drives and installing Linux distros on their 'box' at home. If anything, Microsoft has to worry about the loss of enterprise desktop share, not Apple, who's not in enterprise.
Enterprise takes what's cheap and what works. That's why they buy thousands of identical, feature-less Dell boxes. And that's why they'll install Linux on those boxes instead of Windows XP Pro if Linux does what they need it to do. I mean seriously, why would you install XP in the enterprise? The reasons keep diminishing.
If you read, I wrote:
Apple's no longer in a position to afford profiting by quantity. The first step is to make the public want Macs. In 1997, the public didn't care. In 2004, finally, Apple is associated with Cool. The public wants Macs.
The thing I find is, whenever I tell someone how much an entry level iMac costs, they're always shocked because it's less than they expected. Step 2 is to make the public decide to buy Macs. That's what the Apple stores and the iPods are for.
but a lot of really bad ones.In the meantime, the Mac's marketshare fell below 2% and has been overtaken by Linux Desktop's share.
That's not Jobs' fault. That's Sculley's, and that's the dispute that caused Steve to leave Apple. Steve and Steve started Apple to make computers For the Rest of Us. Computers that people could use; not room-size boxes hidden away in an industrial building.
Sculley had a vision of using Apple's superior technology to make products with high margins and turn Apple into a billion dollar company. And he did. And he gave up marketshare for that.
Lots of people agree that the real reason of the Mac slow but sure descent into Hell is Job's elitist vision and its results, overpriced hardware, rumor cult(ure) at Apple, etc.
Lots of people are uninformed, but that doesn't make them right. Macs aren't overpriced; they're worth every penny you spend on them, the only problem is that you don't have the choice to spend less for things you don't want because Apple doesn't offer those products (like an iMac without the flat panel display and built-in Bluetooth but in an ATX case).
On the same token, Apple can't charge the same prices that Dell does in order to gain market share; they need to fund their R & D divisions. Dell makes money on volume (quanitity). People buy Macs for quality. Apple has to make higher priced units that will yeild larger profits due to the price, not because of a markup. The reason that Apple can't make money on quantity is Sculley's fault, not Jobs. Apple computers were affordable before Jobs left.
Steve's company brought the first personal computer (that could plug into a TV screen, with colour graphics and sound) to the masses. Also the first consumer floppy drive (tapes were the thing before that). The first computer with a GUI, and the first laser printers (along with Canon). And again, when Jobs came back, he brought the iMac, the iPod, and the entire iLife suite to the masses (iDVD, iMovie, etc). Those things wouldn't exist without Jobs; the PC industry was declared dead with no future until Jobs announced the iMac and the digital hub.
Why do so many people worship this one guy?
He's one of the very few people in the consumer-oriented computer industry that moves it forward. Enterprise computing has their own heros (Oracle and Sun come to mind).
First of all, Mark/Space is not a solution. They do not provide a framework for conduits. Synching with iTunes and iPhoto is nice and all, but what about a Mac application that wants to synch to some Palm app?
The only thing I can think of is that Apple intends to open up iSync so that developers can write their own synching modules (iSync is currently a closed system that only Apple can sync data with). If Apple wants to do this, this is a much better use experience for Mac users, and there's no reason then for Apple to limit it to Palm devices; they could support Win CE devices as well.
As for an Apple based PDA, that's not going to happen. Palm and MS can barely hang on to the PDA market with smart phones and other integrated devices coming into the market; what's Apple going to add that allows them to break into the market? And what about application vendor support?
In the past, Steve said that he wanted to buy Palm. Perhaps Steve's got a plan that we're not aware of. But at this point, we can only dream; being a Mac PDA user now officially sucks.
From the interview:
As a Mac/FreeBSD user, who understands that people have to use Windows, I have a question. Why do people hate Windows Me specifically? As a product, I realize it's stupid to upgrade to (Win98 + different salad dressing), but if it was just that I don't see why people would hate it so much. From people I've met, it sounds like installing Me is the worth thing you can put on your box; people would rather use 98. Is it just that the removal of real mode DOS causes more problems than it solves or something?
And second, Aragorn refused the Ring, Gandalf refused it. Why can't Faramir do it as well?
Did you get to watch the extended DVD? :-/ It really was bad for them to cut out that scene, as it set the stage for Faramir's behaviour in TTT. Otherwise it's just a butchering of the character. Taking that scene into account, the ending where he finally lets the hobbits go and Sam says that "you've have shown your quality" shows us Faramir's character. Really, Faramir didn't desire to have the ring. He was drawn to it as Gandalf ("don't tempt me Frodo!") and Aragorn (end of fellowship) did, and all he really desired was to get it to Gondor; the motivation behind that is in the cut scene.
Again, I am not against Arwen per se, blah blahAgreeded, her use in the movie is far from perfect, and I really didn't 'get' her bonding with Aragorn while he was far away (turns out they were dream sequences; I really didn't know what was going on). But hey, it's not like Tolkein wrote LOTR in four years. And PJ had to produce, direct, and edit three movies too!
I hated it. :) In the book they only bow to Sam and Frodo! What did Pippin do that was so great? :)
Well, yes, but it's a direct scene (people bow to the short hobbits who have never been regarded as heros, if their existence had been acknowledged at all) not a factual scene :-/ It takes time to set up a sequence to describe 'we only bow to these two hobbits, and we only praise these other two for their valiant service." It's hard to get the point across and not bore the audience. But it's really easy to offend people who know the story well :)
The only Rohan village was the one necessary to the plot.
I think that the village that burned down was a major failing of the movie. A couple houses burning down in a field by crazy aggressive people is normal course during war times. If it felt that they destroyed something more significant (a prosperous town), not only would it have given the audience a better perspective of Rohan, but it definitely would have been more impactful and make the subsequent events (Theoden choosing to do whatever) easier to accept.
Assuming 1 km separation, Edoras is about 5000-10000 kilometers from Minas-Tirith. Does that make any sense?
It's a movie... you have to get the point across and hope that the environment presented fills the gaps so that the audience accepts what they're witnessing as they watch it.
What's a really good exercise, as far as learning what time constraints can do when trying to visually present a story, is to watch the Macross Plus OVA series and then the Macross Plus movie. Both were created by the same team, director/writers. However, one is 45min x 4, and the other is movie length. And the movie length one has extra scenes. With the OVA, you watch each volume one by one. In Japan, they were released several months apart, so each volume is expected to be watched over and over; there's much more detail and depth than is apparent at first. Shockingly, not a single frame of animation is wasted! Every second of the story has something that contributes to the understand of the plot, the characters, or the world they're in.
Then there's the movie. The first 30-40 minutes is pretty much, WTF? And then, WTF? But when it's all over you see what Kawamori-san meant when he said that it's how he expected to present Macross Plus. It's a different representation of the same story, pulled apart and re-assembled by so many constraints. But in this case, it's the same person who chose to do that as the person who created it. And it's not George Lucas we're talking about....
Anyway, I like your response. Your initial post was too short and lacked the depth needed to properly appreciate it ;-)
But isnt 320 still enough though?
The problem is that MP3 in particular always butchers treble, no matter what the bitrate. It's just what it does (I'm not an audio codec expert, but that's the way MP3 behaves, in the same way that CinePak often looks like pixel-doubling).
320 AAC is quite good and I haven't passed judgment on it yet. But when I regularly listened to AACs at lower bitrate (say 192-256) and put the source CD into the drive, the CD sounded less artificial at times :-/ A large part of it depends on what you're using to listen to stuff; 320 ACC isn't going to help you if you're listening with $50 bargain-bin speakers :P