Interview with Brad Cox, the Man Behind Objective-C (2009)
mactech.com
mactech.com
The tools developers use have a big impact on the resulting software and so it's crazy to think where we'd be if Obj-C hadn't been created and hadn't enabled the iPhone etc.
There are plenty of efficient systems languages out there...
IMO these features made it more productive than C++ or Pascal for developing GUI-based applications.
Late binding is deciding at runtime the real implementation of a method to be called, which in C++ is done at via virtual method calls.
What you are describing is actually an example dynamic types and reflection.
In C++'s case, there are plenty of reflection libraries to choose from.
The whole point is moot though, because Swift is the future. It's quite amusing seeing the Objective-C community trying to reconcile their irrational love of the language with the reality that Apple communicated - it's a disadvantage for the platform, keeping developers away with its unusual syntax, lack of safety and overcomplicated paradigms.
A key aspect of Apple's NS* and UI* frameworks are various patterns that rely on dynamic dispatch (via 'id') as well as run-time reflection and discovery, something that is close to impossible in a super-static language like C++, which eschews most of those features.
C++ puts performance above all else, Obj-C values productivity as well.
As someone who likes C/Obj-C but absolutely despises C++ and everything to do with it, I count my blessings that Apple didn't choose the C++ route.
I wonder what all those reflection libraries are about....
> As someone who likes C/Obj-C but absolutely despises C++ and everything to do with it, I count my blessings that Apple didn't choose the C++ route.
I hope you never get to write Mac OS X drivers then...
Libraries exist for everything under the sun for C++. Doesn't mean anything. C++ always prefers static dispatch vs dynamic. It's in every single C++ book/article ever written. C++'s RTTI system is extremely gimped and pahetic, exactly for that reason - it's a "limited, rarely-to-be-used" functionality by design.
In Ojb-C, it's opposite. Asking an object what methods it has at runtime, is a very common pattern. Something at which the seasoned C++ programmer screeches in horror and hides in the corner.
>I hope you never get to write Mac OS X drivers then...
Completely irrelevant. Of course drivers are written in C/C++ (a limited sub-set of C++). How many people write OS X drivers? Are you even listening to yourself? 99% of people do not write drivers, they write user-land applications, and the lingua franca for OSX/IOS is Obj-C.
You fail to prove any points. Try harder next time.
"DD: Could you have used Smalltalk directly or were in an environment where C was the language you had to interoperate with?
BC (18:12): Xerox was busy shooting themselves in the foot at the time. They wouldn't sell it to me, or to anybody. The were into this "We're a research lab and that's a research toy and go away.""
Sadly AT&T was more effective bringing their research into mainstream.
http://archive.wired.com/wired/archive/2.09/superdis_pr.html
The gist is to stop charging for software (including subcomponents like shared libraries and reusable objects) per copy, or by copy-based-licensing.
Instead, charge (tiny amounts) per use. Theoretically, this could cure underinvestment in the creation of certain shared components, or in software quality/reliability. It's somewhat related to the idea from Ted Nelson that hypertext transclusion could also route automatic incremental reuse payments.
Of course, enforcing the metering can be hard. (You need either DRM or cheerful voluntary compliance.) And all the usual issues with micropayments apply. But it's an interesting idea and the currently-vibrant in-app/in-game models resemble it in some respects.
[1] http://www.amazon.com/Superdistribution-Objects-Property-Ele...
I don't think micropayments ever really worked out, but he was obviously putting a lot of energy into figuring out how it could be done and it was interesting to hear him hold forth.
becaue no one ever implements MICROpayments, we always end up with macropayments. Have you seen a program or a game that asks you for 0.5 cents for a hat? or 0.001cents for a bullet?
The closest I could find is world of tanks, where you can buy bullets for 0.006 Euro for the smallest tanks, and 0.06 Euro for the most expensive ones. Hats (camo patterns, inscriptions) still cost ~ 1 euro each tho.
Most games simply milk you $5 and up per "micro"payment.
Link bookmarked!
And there's nothing wrong with that, provided their arguments are sound.
One needn't have been a recording artist to criticize a song, nor a published author to criticize a book, nor a president to criticize whoever's in office.
One reason it isn't a well-known quote may be because it embraces a logical fallacy[0];
It might not "need to be" one, but it will help his criticism be more informed.
A person can have any kind of wild off-base ideas about what artists, authors or presidents do. At least those that have done it have some experience and basis in reality.
Now, you could say this case is not similar since it is "used by millions", but a lot of systems that are universally agreed to be bad are used by millions. Hence why a lot of people in HN are trying to "disrupt" said space (or market).
TL;DR Using what you're given to work with and being content with what you're using are two different things and should not measure the quality of said thing.
PS.- This is not to say I believe Brad Cox is bad or Objective C is bad, I haven't used it ever. Is just the "if you can't do it don't criticize it" mentality I'm not for.
Most people are fine with constructive or subjective criticism, like "I don't like Objective-C because I really like pushing the shift key for my braces". From there you can suggest alternatives, or figure out a way to improve the system.
If you can't put enough effort in to a comment to express your opinions you'd be better off using that time elsewhere.
So, these people don't like the systems and are jumping into the arena? That's great. Someone is adding value. They're no longer just a critic.
In this context I think it was more a reflection on the cheapness of the shot and what it says about the people making the cheap shots. There's a big difference between honest criticism and "your thing sucks, haha!"
I very seriously doubt Apple would care one second about NeXT if that wasn't the case.
The immediate reason Apple bought Next was for Nextstep. Apple had no next-generation OS and desperately needed one. The two viable options were Be and Next, and Next was considerably more mature.
The way enterprise does business, I doubt they would even be in the list if that wasn't the case.
After that, there was Next, which was a massive commercial flop in many incarnations until eventually becoming a vendor of an enterprise web application framework in the form of WebObjects. His biggest success was Pixar, where he essentially did little more than provide money and handle business stuff while John Lasseter ran the actual studio.
Furthermore, the guy making the decisions was Gil Amelio, who probably wasn't looking to hire his successor as CEO. Amelio wasn't some interim appointment while they searched for someone to replace him, he was supposed to be the real CEO. Getting Steve Jobs back was a nice gesture for Apple fans and a nice story for the press but not the driving factor. The driving factor was that the Mac was dead without a new OS. Options other than Be and Next were considered, including Solaris and Windows NT, but Next was the preferred option and there were both business and technical reasons for that.
The tools devloped in Apple research where very advanced and very good, but the all got shutdown because of apples money problems. Then the change happend and we went to new system, most of the old research was never continued.
Honsly while I was programming Objective-C I would often have visions of how the world could have been diffrent if Dylan, instead of Objective-C had become THE Apple language.
I completly agree with you, most of the time, technical quality does not mean success.
I think it's := a little bit => too heavy: with :: <punctuation>; but I like the use-of-hypens in symbols instead_of_underscores as in Lisp and as a common practice in CSS. So many shift keys saved! That should be the standard and who cares if we wouldn't be able to write a-b. a - b is more readable anyway.
Check a large piece of code for a general feeling of the language https://github.com/dylan-lang/http/blob/master/common/http-c...
It's from 1992 so it's got a chance to influence Ruby (1995). If you look at both you'll clearly see many similarities in the general style of the language, despite Ruby making a lighter use of punctuation and that can have a large effect. Open that Dylan code side by side with this Ruby https://github.com/puma/puma/blob/master/lib/puma/server.rb which has more or less the same role in a web server implementation.
The main Dylan repositories have a fair amount of activity so it's a fringe language but not dead https://github.com/dylan-lang
The language can also be used for systems programming and the standard toolchain has native code compilers.
Not something you can currently say about Ruby implementations.
It was developed as a competitor to something like C++, now Java, Objective C, now Swift, ... for application development.
It was not thought as a competitor to PERL, Python, Ruby, Basic, Javascript, TCL, ... or similar languages.
Dylan is in many ways more advanced then Ruby. Optional types, macros, multi method dispatch, conditional restarts, optimized for fast compilation, gneric opject creation with 'make'.
From a feature standpoint, dylan can easly take on any other language that is outthere.
My point really was that I dont think NEXTSTEP that was from then on used, was in all ways a improvment as many people seam to think.