A lot more Mac software seems to be multi processor aware than Windows software. H.264 is dog-slow to encode but the Apple H.264 encoder used by the Quicktime encoder is MP-aware, with this, the speed will nearly double.
Just a developer's aside to your comment. This kind of performance is typically very hard to get. Apple actually makes it surprisingly easy to tap into this kind of performance.
It's not particularly hard as an Apple developer to take advantage of highly optimized and MP-aware code. Apple provides a very cool framework on every mac called "Accelerate.framework" (you can find it in/System/Library/Frameworks). This framework is very easy to use (from a C standpoint) compared to competitors and offers MP-aware, Altivec-Aware code. What's even wilder is that on the intel macs, apple can bind Accelerate.framework in the same way. Using this framework, you can make fast code and reduce migration woes.
Far from being a weird apple invention, Apple basically optimized BLAS and LINPACK very tightly to the Mac OS X platform and then exposed via C-apis. They also built some higher level manipulations (as well as part of CoreImage and CoreAudio, from my understanding) on top of these basis, along with other heavily-optimized-and-profiled utilities.
I look at it the other way - because 90+% of all languages and especially extensions like RonR *are* fads, I'm looking for reasons to believe that it isn't.
RonR is too young to draw such a conclusion at this time. Ruby, however, is old enough now that you can probably be safe in drawing the conclusion that it is a growing phenomena, instead of a diminishing one. People like a language thats easy to deploy like perl but powerful like Lisp or Smalltalk.
All I can offer you is anectodal evidence. The company I'm working for does web consulting, and we can respond with amazing speed to user desires because of RubyOnRails. We know many of the alternatives, and RoR is just plain better for our work. I'm sure someone can come up with a 500,000 line counterexample site where only Java will do, and I'm sure someone will mention a framework in their favorite language (e.g., Seagate Trolls on All Rails Articles).
But, lots of people have great stories about Rails. Given that, it just can't be that bad.:) It's definitely worth playing with for a day or two, especially if you know Ruby.
The difference between most college educations and a trade school education is that in college, you learn the basics of an entire field. English majors learn how to do a lot of things in one degree. Art majors (at good art schools) don't have specific classes like "Low Bandwidth Internet Art." Math majors don't have classes like, "The Math and Engineering of Dams."
Likewise, Computer Science Majors don't have super-specific classes. Instead, they teach you the things that you wouldn't think to learn on your own. Fundamentals that make all your work as a compsci major easier. Having a solid understanding of algorithms, what's slow, what's complex, and why has helped me produce better work many times.
If I were in charge of hiring and I had a developer position open, I probably wouldn't hire someone if their school curriculum consisted of the classes he listed. Tech and code come and go, but fundamentals last forever.
Besides, if you can't learn that stuff as you go, you're not suited to a career in computer science. Only motivated and fast learners need apply!
Init being the grandfather of every Linux process on every Linux system (except in highly specialized applications), it better be simple, clean, fast and efficient. Something with an XML parser violates at least two if not three of those qualifications.
Could you please try a new, non-parroted, non-utterly-debunked argument? Not everyone cares about how linux performs ona 386, and we're going to fall into the MS performance/compatability trap if we don't start abandoning some lower edge machines.
Even then, how much overhead would a proplist parser really add? It's not like we're using a full XML format here. Considering the potential performance benefit of easy parallel booting and a nice dose of consistency, 100k of extra footprint in the init process just doesn't seem that huge a price to pay. Consider the overhead that the current system introduces, running a shell script with common idioms is at least as much of a computational chore.
It's this kind of attitude that's also standing in the way of other innovations like the new FS the GP is talking about. People are so convinced the current way is right for performance/compatibility/congative-load reasons that they can't even ponder the thought of changing things.
What inconsistencies? He doesn't list them in the previous paragraphs, he simply concludes "Hey, Tiger's a little messed up, but it's still better!"
A ton. Howabout click-raises-focus vs. click through? The lunacy of the Finder? Wtf is up with the search on System Preferences? The Dock's UI is getting better, but still has issues. Etc, etc, etc. And this is just the stuff I pulled from a search of the very pro-mac blog DaringFireball.net.
I love MacOS X. I cannot imagine using anything else for desktop work (and I cannot imagine using Windows for anything). But at the end of the day, OS X is still a work in progress. It is [b]not[/b] perfect! As long as we can accept that, we can help Apple build a better OS with our feedback, and that's what we all want.
Technically, I would worry much more about Apple. Dominic Giampaolo is very bright, and well funded. His chances of delivering on a good set of semantics are high because he and Jobs are very sharp, and neither of them is afraid to go where no one has gone before. Our chances of losing technically to Giampaolo and Jobs are high, because we are frankly not well funded, and a lot of us are complacent with semantics that are still pretty much the same as their father's Unix box.
So, in summary, I would say that we are still ahead but losing speed fast.
It's not just the FS. Apple is doing a lot of neat stuff that I'd really like to see moved to Linux, but that Linux as a community seems happy to ignore. My biggest pet peeve is that launchd is not being taken more seriously. Even if people don't follow the XML part of it (which is a really weak argument to oppose it with), the parsing backend is literally modular and could be extended/replaced.
Unfortunately, I don't think Apple is going to have a choice in this matter. When the big media companies have seen TC and its "benefits" on the Wintel Vista boxes, they will demand it on Apple boxes. Since Apple doesn't currently have the *COMPUTER* marketshare to stand up to the MPAA/RIAA, on the COMPUTER (where video content will come), they will be unable to get any of the content that media companies will be comfortable releasing to a Trusted Vista box. Since Apple only has 5% market share, it won't hurt much to leave them out.
This implies that the media companies are unhappy with the current situation in music. I'm not sure this is the case. Legal music sales are skyrocketing, iTunes Music Store is making more and more money, and people seem to be okay with this. While some companies on the fringe are trying other subscription-based deals, by-and-large these companies have no significant penetration. It's not happening overnight, but online legal music sales are becoming more and more common.
The music industry has found a combination that seems to work in iTunes. While it's obviously possible to break the DRM, we have no evidence that it's happening on a wide scale. Most people just burn-rerip for player compatibility, and few people notice the difference in most cases.
But there is NOTHING that the MPAA/RIAA is more afraid of than rampant piracy. They see it as bad now, but potentially MUCH worse when all those computers are connected to home TVs and stereos. The sad reality (for me, especially, as I would certainly get a non-TPMed Apple if it was the only "free" (as in speech) choice) is that it WILL happen sooner or later, because it would be a major stumbling block to Apple's foreseeable future as a media-delivery company.
Just try and remember that unlike geeks and hackers, marketing and management people are very quick to jump on a solution that works and stick with it. Even small variations that cause minute dips or rises in sales can mean huge changes in quarterly reports. The Risk of locking out iTunes is enourmous. Both Apple and the recording industry stand in a position of mostly equal power in this situation.
They have a solution that is working very well right now. If they were to change it, they would almost certainly take a huge hit. Make no mistake, things are not going well for the record industry right now. It's doubtful that they can afford another major paradigm shift, especially when this Napster/Yahoo New Deal has shown that consumers are smart enough to see through the ploy and reject them.
You were saying that we shouldn't use [insert own language preference here] Rails-alike and should instead try Rails first... I was saying that actually, I'd rather just stick with the one in my preferred language, as I'll be able to get going more quick.
People have gone from 0 ruby skill to major Rails contributor or Rails consultant in less than 2 months in some cases. Ruby is a very easy language to learn, and its standard library is designed around the concept of doing what you expect. Considering you'll have to wait a few more months just for Python's frameworks to start approaching something resembling parity and even then, they won't be able to mimic many of Rails' killer features, it's obviously faster just to learn the tool now.
Now I'm not really sure what you're trying to say now. That I should try every new language I see?
No one has infinite time. But here you are contemplating building green-pasture small-to-medium scale webapps and you're passing on Ruby On Rails because, "Meh, I don't know it." This is not the more efficient path. As perl folks would put it, this is False Laziness.
I have looked at Ruby, but to be honest if I was to devote some time to learning a new language I'd probably want to go with something a little less similar to the langauges I am already familiar with.
Ruby bears far more in common with both Lisp and Smalltalk than Python does. While they do share many similarities, the significant differences greatly distance them. Ruby and Python coding styles (and their communities) are worlds apart. Take it from someone who has professional competence in both languages... they are extremely different when you go into a real project.
In fact, I'd probably do as you did and have a look at Lisp. I've been meaning to do that for ages.
Learning Lisp is a good idea. But it will help you realize some of the reasons why Python is irritating. Lisp is all about empowering the software author to make his code as close to his domain as possible. Everything in Lisp is carefully shaped towards this goal. Python is all about constraining the programmer to a "readable subset."
It's not that I balk at learning a new language, but if I've got the choice between:
a) Using something neat
and
b) Using something neat that also requires me to learn a new langauge
How about:
Learning something that is exhibiting all the characteristics of a "Killer App," taking a competitive market by storm in a way that hasn't happened for a long time. PHP and J2EE never really had this kind of momentum and penetration within less than a year. Perl did, but that's because Perl made it so much easier than C that there wasn't really any other choice.
A me-too copycat of such a product in a language you know, which does not have all the capabilities of the language used to write the aforementioned killer app.
I'm sorry if I seem to come on a bit strong through all this, but one of the most important attributes of a programmer, in my humble opinion, in is the willingness and even excitement for learning. There is simply too much to know all in advance, you have to train yourself as you go. I see so many pythonistas who take your attitude, and I've never responded. This has built up and I probably directed too much of that ire at you personally, for which I do apologize. My point is Rails is here, now, and the barrier for entry is learning a very interesting language called Ruby. If it were in Lisp, I'd tell people to get off their assess and learn Lisp. If it were in Haskell, the same would apply.
I worry that Python, with a very promising evolutionary path, might fall into the trap of becoming the next Java. It'd be a great loss to see that happen.
I think his point is that while Ruby is nice and all it doesn't seem to offer that much more than eg Python.
Non-trivial lambdas is a big deal. Python doesn't offer it. Ruby does. I'm not sure why python doesn't offer it, but it doesn't and even with this new "with" stuff, it's not going to.
And while Ruby on Rails is good for hacking together a simple WWW site it may not pay off to learn the language just to solve a one off problem. In that case you'd be better off solving it in a language you know.
Your condescending attitude is noted, and not unexpected. People's derision of web apps on slashdot is about as predictable as hot grits and welcoming overlords, albeit more sophisticated.
It's more of a question of "Why Ruby?". And to be honest, I have heard a lot of good things about Ruby, but very little as far as specifics are concerned.
Rails cannot exist in Python. Both I looked at the work on Subway and realized this. Django has taken some good steps, and it's a good idea for Python, but it is not up to par with Rails. If you want concrete details, here are the biggest selling points for Ruby:
Real lambdas. What python has doesn't count, and I've never heard a good, non-Java-esque explanation for why it doesn't have them. I'm tired of being told that we, the masses of programmers, are not smart enough for feature X.
Better meta-programming facilities. It's entirely possible to create embedded domain specific languages in Ruby. Doing so in Python will only yield Python. Ruby is both about a beautiful result and an easy time writing. Python is all about ease of readability (and we hear this from people in the Python community about 76.7 times a day). Python isn't a bad language, but it's still feature deficit. And no, I'm not bitching about immutable strings.
Besides I'm quite convinced that someone who uses Python is already competent in multiple languages. Personally I know Python, C/C++, Java, Haskell, Lisp, Perl, some extinct languages like Basic, Fortran and Pascal as well as hardware languages like VHDL and Verilog. I know these to different degrees of competence, as a rule I have made at least a couple of bigger projects in each and have gotten a "feel" for the languge.
This is why the other poster's reluctance to learn Ruby troubles me. After you learn 4 or 5 lanuages, it starts to become easy. I learned Io in about a day, because I was familiar with languages using similar concepts (yeah, Self!) If people start preaching Python as the Only Thing You Need To Learn, and continue with this "executable pseudocode" approach to everything, then Python is going to be the next Java. This may be exactly what the community wants, but I see it as a failure and a disappointment.
If Python picked up a few key features from Ruby, I'd be very enamored with it. I know it, and I like a lot of what GVR has to say. I just can't understand the stubborn refusal to give us the real killer features that wouldn't even significantly increase the complexity of the language.
And there's me thinking it's an acknowledgement of the fact that there's more than one verb in the universe. Go figure.
Multi-button mice are great in certain contexts. Drafting, drawing, coding. Very specific cases where, yeap, you have verb overload. Usually, the people who engage in these activities can learn to use the tools.
But in the generic case, mousing around the finder and the web and email, you generally only need the "tap, hold and drag" verbs.
So? Since when has ergonomics been subjective?
Ever since the Great Specialization Of Double-Ought, when the King of the Humans decided that humans would no longer be exactly identical, and would react and endure under different stresses in different ways.
To be fair, those people will have all sorts of problems in Mac OS X, where no two buttons require the same sort of mouse-click.
For example, single-click to go into a folder in system preferences, but double-click to go into a folder in Finder.
Double clicking there hurts nothing. The system deliberately pauses to eat the second click. This confusion is part of the modern expectation for an interface, Apple can't just do away with it. Part of usability is conforming to expectations. When you do exceed expectations, you have to do it gently and obviously.
They'll love learning to click-and-hold to get any context menus, or apple-click (much more intuitive than a second button, if you're an EMACS user...)
I'm always surprised how quickly people catch on to click-and-hold.
X11 applications are the best - click twice on GIMP's toolbox to select a tool, then click twice on the image to use that tool...
Who could forget the all-important X11 usability metric!:P~ Sorry, don't write applications that assume focus-follows-mouse and we'll talk. For the real geeks out there, you can enable focus follows mouse.
Oh, and don't expect alt-tab (apple-tab) to work consistantly -- if the window you want is too similar to the one you're using, it becomes apple-backtick.
Apple-tab switches applications. Just because the windows system is stupid and goes by window doesn't mean you should rely on that. Oh, and since it doesn't conform to your expectation, they did it very obviously with that huge app-switcher. Command-tilde is a power-user function.
See, that's the beauty of Mac OS X. The exact same system, coming with stock Apple hardware, is usable by my sister (moderate computer skill, lots of music and IMing and web surfing), my grandfather (minimal computer skill, requires tools for balancing accounts, needs simple web environment), and me (high degree of skill, requires unix development environment and maximum configurability).
Even more amazingly, this degree of flexibility can be achieved on the same machine! Each user can have their own setup and the computer never lets on that its anything else unless you ask.
It's an OS built around progressive disclosure, and it's a really wonderful thing.
I'm sure that Rails is spiffy 'n all, but I'd rather use a language that I'm already familiar with.
I am so tired of this complaint. Keep up or ship out. If you're going to compete with other languages, you need to know what they can and cannot do. That means you have to learn them. This is not time wasted. This is time invested in your ability as a programmer. You are getting "something done." You are training yourself. At the rate that our industry evolves, if you don't train yourself, you'll become useless or confined to legacy work in no time.
As an example, I devoted about one day a week out of my very limited spare time to learn Lisp. It took me about a month to get to where I could make a real lisp program at this pace, and about two months to feel comfortable. I learned it because I wanted to broaden my horizons as a software engineer, I didn't think I'd get any money.
Turns out, 3 weeks later, there was some Scheme code that needed to be reworked. Since no one knew scheme, they were going to ditch perfectly good, working code. For nearly a month, I got paid to professionally hack and upgrade a product written in a dialect of Scheme, and I probably saved months worth of development, the Scheme code was both very good and very complex (at least, a C++ copy would have been complex).
If I hadn't invested my time, I wouldn't have had such an opportunity, and my development group woul d have had to spend at least twice as long developing a replacement piece of code and testing it.
The fact that I see a python user balking at learning a new language really worries me. I hope that you are not reflecting the Python community, because if that's the case, then Python really is the next Java. Sometimes, Getting Things Done means taking a path that has less immediate returns but better long-term returns. The DRY principle (upon which Django leans heavily) is a perfect example of this.
Its always apeared that its the apple apologists, not Apple, who make the excuse that grandma can use one button more easily.
I think the real reason is design and style. Apple has focused more on how the computer looks than on how easy it is to use.
There is an element of truth to this. Apple's design is one of the key components of their products. Even some of the uglier macs still looked better than most PC offerings (you with the window on the side of your PC, I'm frowning at you).
Apple's site says "Single buttons looks, multi-button charm". This suggests that the one button thing has more to do with *looks* and design, than functionality... The statement from the site, "for the best of both form and function", suggests this is true (single button=pretty, multi-button=functional).
You make it sound like a bad thing, that Apple places a higher priority on form than function. Sometimes, this is the right thing to do. The classic Apple example is the iPod. While it may have very competitive peers, it's still on top because it's competitive and looks good. This may seem stupid and shallow to some people, but I argue that we can't ignore the looks and form factor of our products forever.
From the site, "Stick with single-button simplicity or click with multibutton efficiency." *suggests* that they've known all along that the single button is less efficient. Clicking the "Design" link takes us to a page with the statement "Who has time for intuitive, elegant design when there is so much clicking to do", again suggesting that the primary driving force for the mouse has been form over function.
Of course it is less efficient! Who ever said it wasn't? But it looked better, and made some people feel less intimidated. And on my laptop, I really don't feel the loss except when using XCode.
Raw efficiency is not the only consideration though. For example, it'd be more "efficient" to do away with the mouse and use an elaborate keyboard region system to do image editing. But, the mouse is a nice, easy to use interface that maps well to several kinds of input devices.
It's not just about efficiency. The best products also look good and feel natural. Look at the popularity of a wikipedia. Certainly, a targetted web application with lots of software agents to assist and a core team would be more efficient, but Wikipedias social dynamics and interface encourage so many people to use it that it ends up being a better product despite being less efficient.
lso, the buttons on my mouse are ergonomically placed and fit into my hand perfectly as opposed to a mouse that looks very non-ergonomic and doesn't provide any feedback for my actions. I have no idea what the resolution of this mouse is, but I highly doubt it is as precise as my current mouse.
The hockey puck mice were a nightmare. The current mouse design (which is slightly enlarged in this product, according to the tech specs dimensions) is surprisingly comfortable. I suppose they also can reduce strain by requiring almost no force to actuate the top buttons.
The audio feedback built into Mighty Mouse provides an aural sensation that responds to your movements. A tiny speaker inside Mighty Mouse produces button-clicking and Scroll Ball-rolling sound effects.
Because the Apple fan-boys have been arguing that one button is best for many years, so they have to continue to pretend that one button is somehow better. Even though they have basically caved in on this issue and realised that extra UI hardware might actually make the UI better to use.
Dude. Very few people are saying, "One Button Is Better." The people who are saying the one button mouse has merits are considering grandma and grandpa, who had to practice to learn to double click. No really, they actually did. For them, a single mouse button makes far more sense.
Apple users who care though, can now simply change their perspective, click a checkbox, and progressively disclose new features. Heck, they can do it on their user profile, so that grandma and grandpa can share the same computer with me and still be comfortable.
I think it's a rather elegant migration strategy. I didn't think that a multi-button mouse could have also looked just like a single button mouse.
a) What you're doing.
b) Why you're doing it.
c) How you're doing it.
While I agree with a, and sometimes c (usually in the case of frameworks), I think you should never document how you do something unless the code is complex by its very nature (assembly, code that twonks with hardware settings or obscure memory/os operations, etc...).
If you document how to do something simple, and that simple thing changes, you now have at least doubled your workload. Instead, make your code clear and self-documenting and maintainers will thank you far more.
I have two reasons to say this. The first is every maintainer's nightmare. Bad comments are worse than no comments at all. We naturally give comments a large amount of trust, so if they are wrong, it can take awhile to realize it. Second, comments must be updated along with maintenance. An excessive amount of documentation greatly increases the workload (and thus, the opportunity for a mistake).
Finally, if you every find yourself writing comments inside a method, ask yourself, "Why is this method so long and complicated? Can I make it smaller and self-documenting?" I find that my ideal documentation comes when my code is only on headers. Often, we refactor how things are done without refatoring much of what and when its done.
By only documenting your method signatures (like with Javadoc, Doxygen, rdoc, etc...) you help minimize your work and maximize your documentation's effectiveness. It will also help you to write self-documenting code.
This is, of course, just IMHO. But, I really dislike people who excessively document on the grounds of that literate programming nonsense. To get a concrete idea of the style I'm promoting, please see one of my open source libraries.
Everyone seriously needs to calm down and carefully read what the article is saying.
The development release of OSX86 uses the features already present in the hardware to keep itself from being spread to other machines. Currently, all it does is prevent installs. It does not mean that the completed versions will use the DRM for anything (although it is certain they will expose it).
It is disappointing, yes. But this is not a "Sky-Is-Falling" event. It's not even particularly surprising. We knew that Apple would use this to some extent. If all they use it for is their DVD player and their FairPlay DRM decoding module, then we know exactly who is calling the shots on the use of this kind of DRM (You have three guesses, and here's a hint, it's not Apple).
Just to settle the Oracle v. whatever DB issue: I've paid for an Oracle perpetual license, so it's not an option for me to use anything else.
Not many people have something like this, or the cash for it, or even the need for it! So you're in a unique position.
Since you know Ruby, Rails and Oracle, and you have an ideal testing ground, I strongly encourage you to contribute to the oracle driver. Start by making the guts of the oracle driver meet your expectations.
You can work on exposing other API aspects once you've gone through and made the driver work the way you expect. I'm sure this will help clarify things.
Is this "a lot of work?" That depends. Consider that there is a ton of rails consulting work out there. Being an active developer for the project is worth more than the time investment you'd put into it. Also consider how neat it would be to work with an Oracle-saavy Rails.
My problem with Rails is its poor Oracle support. This may have changed in the couple months since I checked it out, but it doesn't seem likely (to me anyway). The impression I got from the design of the database API is that it's very MySQL-centric and provides little flexibility for databases that do things in other ways.
The Oracle driver has gotten better. That doesn't mean it's as good as the MySQL driver. But there is another driver you might be willing to settle with, the postgres driver. I know it's not oracle, but it addresses a lot of feature deficits that I hear as common arguments against MySQL.
Unless the API itself changes, I don't see how it could adequately support Oracle, and for me, poor support for Oracle is an automatic disqualification.
Well, the API doesn't take advantage of much of anything in terms of the calls. Its the job of the driver writer to make use of the underlying functionality. Since you can extend the drivers, nothing stops you from exposing the functionality you need and using that. You can keep it around as a component and reuse it on your projects without much cost in terms of interoperability.
In fact, I know some folks would cheer you for it. It's always possible to use Ruby and basic SQL to mimic more complex database features at a performance hit to less featureful dbs.
I don't agree that efficiency should not be the foremost goal. What is more critical than your application performing with as little an impact on your system as possible?
Nearly everything. I'd rather use a slow program that was well designed and did its job excellently rather than a poorly designed program that didn't. This is nearly universally true. It's hard to come up with a situation where a better designed and more feature-laden product lost to a crappy product that's primary claim to fame was speed. There is, of course, a performance cutoff, past which the speed becomes a real issue. That cutoff's position varies by domain.
Which would you rather use to code; Emacs or Notepad? Notepad starts, loads, saves and runs much faster than Emacs. But I know who's going to get work done faster, and that's the person using Emacs. By your logic, you're firing up notepad.
And why use Java when you could be using C!? C can do everything java can, and it'll make faster compiled code! So why are you using anything but C?
There's a, you know, rule about optimization. Never do it prematurely. This is one of the most important rules of development. Never complicate your code because you "know" where the bottleneck will be. You almost never will. Your comment suggests you forgot that.
By the way, did you intentionally dodge my question about what GUIs do that webpages don't, or was it an honest omission?
I think you miss my point. A web based app, due to the page-based nature of the model, has to be logically divided into pages. You send off an action, and if you need to do much more than rearrange things on the page, you need to get a new page. This model doesn't work terribly well for most things. In the end, you're going to wind up chaining what is for all intents and purposes a real app into the middle of a page to accomplish what you want to do.
Tell me what a regular application does in on enclosing top level UI element that is any different? Update lists? Drag'n'drop? Sure, media manipulation is the exception, but that's true even in desktop apps.
... When, instead, you have a real application, you are generating the content in the most efficient internal form, rather than trying to turn it into a document model without regard for what that does to your efficiency.
Ahh. Yes. Efficiency. Paramour of the Conservative Engineer. It can be ugly, feature-poor, and bloated, but if its efficient, all is forgiven.
I'm kind of tired of how you keep forgetting I'm talking about The Future and not The Now. What exactly do I need to do to get that through? I am not saying you could make something like Photoshop as a webapp now. I'm saying in 5-10 years, code-on-demand web-based models are going to be far more popular from both a user and developer standpoint. Already, they dominate some fields (No one is going to use an offline map system unless they have to, google maps is too good. No one is going to use a static encyclopedia anymore, online encyclopedias are too good), and they will contonue to grow.
I mean, insults to Swing coming from someone advocating Javascript as the language of the future?
Sun thinks JavaScript is the language of the future, or at least on the right track. Check out Self, Sun's research project into prototype-based languages. Javascript is a powerful language with closures, lambdas, real prototype-based OO, and dynamic dispatch.
While implementations may not all be up to snuff, Javascript as a spec is pretty sharp.
Swing isn't nearly as good as native UI elements, but it still blows your web page crap out of the water.
My "web page crap," eh? I wasn't aware I was solely or even partially responsible for the woes of a low-barrier-to-entry field.
Your implication that I am a "lam0r who wri73s teh webapps" is noticed, but false. I'm a professional C++, Java, Ruby and Lisp developer. Yes, I do get paid to write systems in Scheme and Lisp.
Oh, and no. Swing should not be your poster child. It is deeply flawed. I'd actually rather work with MFC over Swing (and that's saying something!). Swing as an API is clunky and difficult to work with. As a GUI from a user's perspective, it is clunky and limiting. It strongly assumes windows-style multiple menu bar windows. It is notoriously bad at helping developers make custom widgets.
It is usable. It is certainly nothing to be proud of.
Not all applications reduce so cleanly to a set of documents like you seem to think.
Since when do webapps map to clean pages? Need I link to Google Mapsagain to make that point? 5 years ago, I thought something like Google Maps was impossible over the web. But it's here today, and it's surprisingly good for what it is and its limitations. Once you get a few regions into cache, it's actually very snappy.
... Using a facility provided to display text and the occasional image to do things that the native system could do better, is kinda dumb.
Web browsers are utterly superior to most UI frameworks at laying out text and elements. While they may not be as to-the-pixel precise, they are far more adept at styling and layout.
The only toolkit I know that even comes close without resorting to an HTML rendering library is Cocoa.
So it's not immediately obvious that a desktop app can be "better". I'd say Google Mail is far better, in terms of both interface and features, than Microsoft Exchange (minus the calendar). The search is better, the threading is better, the hierarchy system is better, the filters are better.
Right now, web apps have limited use. I am saying that will change. JavaScript is going to continue to grow (or something else will take its place). Eventually, we'll have to make a conscious choice between browser and desktop app, and it won't be an obvious one.
Sure, there are all sorts of neat tricks you can use to make your web app look like it's a real app, but deep down you still have to wait for the real app on the server side to come up with a text file that your browser can turn back into interface element impersonations.
First, part of the point of DOM and Ajax is to ameliorate that. Fast broadband and the scalable architecture of webapps helps handle it further. Give it some time.
Second, do you realize how many people take this UI-as-data approach? KDE and Gnome both use special UI description formats which can be loaded at runtime. Cocoa actually serializes running code. Heck, even Tk UIs reduce to strings (and there are cool libraries that can freeze your GUIs). People are already doing it that way, even over network lines.
If you want cross-platform, try a real language that already does it. Java Swing, Perl/tK, etc, will give you the responsiveness and depth of real applications, but run on any enabled system.
Excuse me for taking so long to respond. Your joke about Java left me in stiches. Implying Java was any good. Comedic gold! Those never get boring! "Swing", "Responsive". Brilliant! Your humor works on so many levels!
Slashdot Mirror
It's not particularly hard as an Apple developer to take advantage of highly optimized and MP-aware code. Apple provides a very cool framework on every mac called "Accelerate.framework" (you can find it in /System/Library/Frameworks). This framework is very easy to use (from a C standpoint) compared to competitors and offers MP-aware, Altivec-Aware code. What's even wilder is that on the intel macs, apple can bind Accelerate.framework in the same way. Using this framework, you can make fast code and reduce migration woes.
Far from being a weird apple invention, Apple basically optimized BLAS and LINPACK very tightly to the Mac OS X platform and then exposed via C-apis. They also built some higher level manipulations (as well as part of CoreImage and CoreAudio, from my understanding) on top of these basis, along with other heavily-optimized-and-profiled utilities.
All I can offer you is anectodal evidence. The company I'm working for does web consulting, and we can respond with amazing speed to user desires because of RubyOnRails. We know many of the alternatives, and RoR is just plain better for our work. I'm sure someone can come up with a 500,000 line counterexample site where only Java will do, and I'm sure someone will mention a framework in their favorite language (e.g., Seagate Trolls on All Rails Articles).
But, lots of people have great stories about Rails. Given that, it just can't be that bad. :) It's definitely worth playing with for a day or two, especially if you know Ruby.
Likewise, Computer Science Majors don't have super-specific classes. Instead, they teach you the things that you wouldn't think to learn on your own. Fundamentals that make all your work as a compsci major easier. Having a solid understanding of algorithms, what's slow, what's complex, and why has helped me produce better work many times.
If I were in charge of hiring and I had a developer position open, I probably wouldn't hire someone if their school curriculum consisted of the classes he listed. Tech and code come and go, but fundamentals last forever.
Besides, if you can't learn that stuff as you go, you're not suited to a career in computer science. Only motivated and fast learners need apply!
Even then, how much overhead would a proplist parser really add? It's not like we're using a full XML format here. Considering the potential performance benefit of easy parallel booting and a nice dose of consistency, 100k of extra footprint in the init process just doesn't seem that huge a price to pay. Consider the overhead that the current system introduces, running a shell script with common idioms is at least as much of a computational chore.
It's this kind of attitude that's also standing in the way of other innovations like the new FS the GP is talking about. People are so convinced the current way is right for performance/compatibility/congative-load reasons that they can't even ponder the thought of changing things.
I love MacOS X. I cannot imagine using anything else for desktop work (and I cannot imagine using Windows for anything). But at the end of the day, OS X is still a work in progress. It is [b]not[/b] perfect! As long as we can accept that, we can help Apple build a better OS with our feedback, and that's what we all want.
The music industry has found a combination that seems to work in iTunes. While it's obviously possible to break the DRM, we have no evidence that it's happening on a wide scale. Most people just burn-rerip for player compatibility, and few people notice the difference in most cases.
Just try and remember that unlike geeks and hackers, marketing and management people are very quick to jump on a solution that works and stick with it. Even small variations that cause minute dips or rises in sales can mean huge changes in quarterly reports. The Risk of locking out iTunes is enourmous. Both Apple and the recording industry stand in a position of mostly equal power in this situation.They have a solution that is working very well right now. If they were to change it, they would almost certainly take a huge hit. Make no mistake, things are not going well for the record industry right now. It's doubtful that they can afford another major paradigm shift, especially when this Napster/Yahoo New Deal has shown that consumers are smart enough to see through the ploy and reject them.
- Learning something that is exhibiting all the characteristics of a "Killer App," taking a competitive market by storm in a way that hasn't happened for a long time. PHP and J2EE never really had this kind of momentum and penetration within less than a year. Perl did, but that's because Perl made it so much easier than C that there wasn't really any other choice.
- A me-too copycat of such a product in a language you know, which does not have all the capabilities of the language used to write the aforementioned killer app.
I'm sorry if I seem to come on a bit strong through all this, but one of the most important attributes of a programmer, in my humble opinion, in is the willingness and even excitement for learning. There is simply too much to know all in advance, you have to train yourself as you go. I see so many pythonistas who take your attitude, and I've never responded. This has built up and I probably directed too much of that ire at you personally, for which I do apologize. My point is Rails is here, now, and the barrier for entry is learning a very interesting language called Ruby. If it were in Lisp, I'd tell people to get off their assess and learn Lisp. If it were in Haskell, the same would apply.I worry that Python, with a very promising evolutionary path, might fall into the trap of becoming the next Java. It'd be a great loss to see that happen.
- Real lambdas. What python has doesn't count, and I've never heard a good, non-Java-esque explanation for why it doesn't have them. I'm tired of being told that we, the masses of programmers, are not smart enough for feature X.
- Better meta-programming facilities. It's entirely possible to create embedded domain specific languages in Ruby. Doing so in Python will only yield Python. Ruby is both about a beautiful result and an easy time writing. Python is all about ease of readability (and we hear this from people in the Python community about 76.7 times a day). Python isn't a bad language, but it's still feature deficit. And no, I'm not bitching about immutable strings.
This is why the other poster's reluctance to learn Ruby troubles me. After you learn 4 or 5 lanuages, it starts to become easy. I learned Io in about a day, because I was familiar with languages using similar concepts (yeah, Self!) If people start preaching Python as the Only Thing You Need To Learn, and continue with this "executable pseudocode" approach to everything, then Python is going to be the next Java. This may be exactly what the community wants, but I see it as a failure and a disappointment.If Python picked up a few key features from Ruby, I'd be very enamored with it. I know it, and I like a lot of what GVR has to say. I just can't understand the stubborn refusal to give us the real killer features that wouldn't even significantly increase the complexity of the language.
But in the generic case, mousing around the finder and the web and email, you generally only need the "tap, hold and drag" verbs.
Ever since the Great Specialization Of Double-Ought, when the King of the Humans decided that humans would no longer be exactly identical, and would react and endure under different stresses in different ways.I don't, but the point is that I could.
See, that's the beauty of Mac OS X. The exact same system, coming with stock Apple hardware, is usable by my sister (moderate computer skill, lots of music and IMing and web surfing), my grandfather (minimal computer skill, requires tools for balancing accounts, needs simple web environment), and me (high degree of skill, requires unix development environment and maximum configurability).
Even more amazingly, this degree of flexibility can be achieved on the same machine! Each user can have their own setup and the computer never lets on that its anything else unless you ask.
It's an OS built around progressive disclosure, and it's a really wonderful thing.
As an example, I devoted about one day a week out of my very limited spare time to learn Lisp. It took me about a month to get to where I could make a real lisp program at this pace, and about two months to feel comfortable. I learned it because I wanted to broaden my horizons as a software engineer, I didn't think I'd get any money.
Turns out, 3 weeks later, there was some Scheme code that needed to be reworked. Since no one knew scheme, they were going to ditch perfectly good, working code. For nearly a month, I got paid to professionally hack and upgrade a product written in a dialect of Scheme, and I probably saved months worth of development, the Scheme code was both very good and very complex (at least, a C++ copy would have been complex).
If I hadn't invested my time, I wouldn't have had such an opportunity, and my development group woul d have had to spend at least twice as long developing a replacement piece of code and testing it.
The fact that I see a python user balking at learning a new language really worries me. I hope that you are not reflecting the Python community, because if that's the case, then Python really is the next Java. Sometimes, Getting Things Done means taking a path that has less immediate returns but better long-term returns. The DRY principle (upon which Django leans heavily) is a perfect example of this.
Raw efficiency is not the only consideration though. For example, it'd be more "efficient" to do away with the mouse and use an elaborate keyboard region system to do image editing. But, the mouse is a nice, easy to use interface that maps well to several kinds of input devices.
It's not just about efficiency. The best products also look good and feel natural. Look at the popularity of a wikipedia. Certainly, a targetted web application with lots of software agents to assist and a core team would be more efficient, but Wikipedias social dynamics and interface encourage so many people to use it that it ends up being a better product despite being less efficient.
And regarding feedback, from Apple's Page:
Rtfa, man.Apple users who care though, can now simply change their perspective, click a checkbox, and progressively disclose new features. Heck, they can do it on their user profile, so that grandma and grandpa can share the same computer with me and still be comfortable.
I think it's a rather elegant migration strategy. I didn't think that a multi-button mouse could have also looked just like a single button mouse.
If you document how to do something simple, and that simple thing changes, you now have at least doubled your workload. Instead, make your code clear and self-documenting and maintainers will thank you far more.
I have two reasons to say this. The first is every maintainer's nightmare. Bad comments are worse than no comments at all. We naturally give comments a large amount of trust, so if they are wrong, it can take awhile to realize it. Second, comments must be updated along with maintenance. An excessive amount of documentation greatly increases the workload (and thus, the opportunity for a mistake).
Finally, if you every find yourself writing comments inside a method, ask yourself, "Why is this method so long and complicated? Can I make it smaller and self-documenting?" I find that my ideal documentation comes when my code is only on headers. Often, we refactor how things are done without refatoring much of what and when its done.
By only documenting your method signatures (like with Javadoc, Doxygen, rdoc, etc...) you help minimize your work and maximize your documentation's effectiveness. It will also help you to write self-documenting code.
This is, of course, just IMHO. But, I really dislike people who excessively document on the grounds of that literate programming nonsense. To get a concrete idea of the style I'm promoting, please see one of my open source libraries.
Everyone seriously needs to calm down and carefully read what the article is saying.
The development release of OSX86 uses the features already present in the hardware to keep itself from being spread to other machines. Currently, all it does is prevent installs. It does not mean that the completed versions will use the DRM for anything (although it is certain they will expose it).
Further, it's not immediately obvious if Mac OS X can really be restrained by this kind of DRM because of tools exploiting certain aspects of Mach-O's binary structure.
It is disappointing, yes. But this is not a "Sky-Is-Falling" event. It's not even particularly surprising. We knew that Apple would use this to some extent. If all they use it for is their DVD player and their FairPlay DRM decoding module, then we know exactly who is calling the shots on the use of this kind of DRM (You have three guesses, and here's a hint, it's not Apple).
Since you know Ruby, Rails and Oracle, and you have an ideal testing ground, I strongly encourage you to contribute to the oracle driver. Start by making the guts of the oracle driver meet your expectations.
You can work on exposing other API aspects once you've gone through and made the driver work the way you expect. I'm sure this will help clarify things.
Is this "a lot of work?" That depends. Consider that there is a ton of rails consulting work out there. Being an active developer for the project is worth more than the time investment you'd put into it. Also consider how neat it would be to work with an Oracle-saavy Rails.
In fact, I know some folks would cheer you for it. It's always possible to use Ruby and basic SQL to mimic more complex database features at a performance hit to less featureful dbs.
Which would you rather use to code; Emacs or Notepad? Notepad starts, loads, saves and runs much faster than Emacs. But I know who's going to get work done faster, and that's the person using Emacs. By your logic, you're firing up notepad.
And why use Java when you could be using C!? C can do everything java can, and it'll make faster compiled code! So why are you using anything but C?
There's a, you know, rule about optimization. Never do it prematurely. This is one of the most important rules of development. Never complicate your code because you "know" where the bottleneck will be. You almost never will. Your comment suggests you forgot that.
By the way, did you intentionally dodge my question about what GUIs do that webpages don't, or was it an honest omission?
I'm kind of tired of how you keep forgetting I'm talking about The Future and not The Now. What exactly do I need to do to get that through? I am not saying you could make something like Photoshop as a webapp now. I'm saying in 5-10 years, code-on-demand web-based models are going to be far more popular from both a user and developer standpoint. Already, they dominate some fields (No one is going to use an offline map system unless they have to, google maps is too good. No one is going to use a static encyclopedia anymore, online encyclopedias are too good), and they will contonue to grow.
While implementations may not all be up to snuff, Javascript as a spec is pretty sharp.
My "web page crap," eh? I wasn't aware I was solely or even partially responsible for the woes of a low-barrier-to-entry field.Your implication that I am a "lam0r who wri73s teh webapps" is noticed, but false. I'm a professional C++, Java, Ruby and Lisp developer. Yes, I do get paid to write systems in Scheme and Lisp.
Oh, and no. Swing should not be your poster child. It is deeply flawed. I'd actually rather work with MFC over Swing (and that's saying something!). Swing as an API is clunky and difficult to work with. As a GUI from a user's perspective, it is clunky and limiting. It strongly assumes windows-style multiple menu bar windows. It is notoriously bad at helping developers make custom widgets.
It is usable. It is certainly nothing to be proud of.
Since when do webapps map to clean pages? Need I link to Google Maps again to make that point? 5 years ago, I thought something like Google Maps was impossible over the web. But it's here today, and it's surprisingly good for what it is and its limitations. Once you get a few regions into cache, it's actually very snappy.The only toolkit I know that even comes close without resorting to an HTML rendering library is Cocoa.
So it's not immediately obvious that a desktop app can be "better". I'd say Google Mail is far better, in terms of both interface and features, than Microsoft Exchange (minus the calendar). The search is better, the threading is better, the hierarchy system is better, the filters are better.
Right now, web apps have limited use. I am saying that will change. JavaScript is going to continue to grow (or something else will take its place). Eventually, we'll have to make a conscious choice between browser and desktop app, and it won't be an obvious one.
First, part of the point of DOM and Ajax is to ameliorate that. Fast broadband and the scalable architecture of webapps helps handle it further. Give it some time. Second, do you realize how many people take this UI-as-data approach? KDE and Gnome both use special UI description formats which can be loaded at runtime. Cocoa actually serializes running code. Heck, even Tk UIs reduce to strings (and there are cool libraries that can freeze your GUIs). People are already doing it that way, even over network lines. Excuse me for taking so long to respond. Your joke about Java left me in stiches. Implying Java was any good. Comedic gold! Those never get boring! "Swing", "Responsive". Brilliant! Your humor works on so many levels!