[HN Gopher] Steve Jobs, NeXTSTEP, and early object-oriented prog...
___________________________________________________________________
Steve Jobs, NeXTSTEP, and early object-oriented programming (2016)
Author : wmlive
Score : 71 points
Date : 2024-11-12 01:06 UTC (1 days ago)
(HTM) web link (computerhistory.org)
(TXT) w3m dump (computerhistory.org)
| Rochus wrote:
| (2016)
| panick21_ wrote:
| This is very narrow history. Basically a history that excludes
| everything that isn't Jobs walk to glory and perfection and
| domination. Ignore many important points, problems, accidents,
| alternatives and so on.
|
| NeXT used 'Display Postscript' a display server that was
| basically a inferior copy of Sun's NeWS system. This was later
| changed because NeXT was to small and Adobe didn't want to
| support Display Postscript anymore. Sun of course killed NeWS
| because they wanted to be a 'standard'. Next didn't care about
| standards. They had less applications then CDE Unix, and far
| lower deployment in the 90s.
|
| Objective C is one of many language that you could use to build
| UI libraries on top of some display system. Objective C wasn't
| the best or inherently better then many others. Objective C
| adoption by Next was kind of a historical accident based on
| office location.
|
| Having something VM based for UI development isn't actually that
| much of an issue, when the hardware manufacture delivers the OS
| with the VM included. And usually it his the hardware manufacture
| that delivers the OS. And VM bases system can be integrated well
| with the core OS, object oriented or not. And that VM are
| inherently to slow is also questionable, specially for UI apps
| that can use C libraries and the Display Server for the most
| performance relevant stuff.
|
| Apple itself had a very nice system for UI development on Dylan
| that was arguable better in many way then the Next system. But
| when Steve Jobs came and they had Next, that wasn't developed
| anymore.
|
| What Jobs showed of in the late 90s wasn't exactly revolutionary
| stuff. But Jobs always presents everything as revolutionary.
|
| IPhone development in 2010 working the same as Next development
| in 1990 is a sign of 'failure', not of success.
| WillAdams wrote:
| What current development environment and language would you
| like to put forward as a successor to/alternative of NeXTstep?
|
| Some notable applications done in it:
|
| - Altsys Virtuoso --- this became Macromedia Freehand
|
| - Lotus Improv --- cloned to become Quantrix Financial Modeler
|
| - Doom notably was developed on NeXTstep and the WAD/level
| editor was never ported (though alternatives were later
| developed)
|
| - Glenn Reid's PasteUp and TouchType --- two of the nicest apps
| for working with documents and type I ever had occasion to use
|
| and a number of ports were done quite quickly and were arguably
| the best ever versions --- WordPerfect for NeXTstep was done in
| six weeks and FrameMaker on the NeXT stands out for an
| interface which I missed when using it on Mac or Windows.
|
| In particular, I'd really like to have a successor
| to/replacement for Touchtype.app (and if that could be grown
| into a replacement for Macromedia Freehand, that would be
| great) --- what tool would allow developing this easily, and
| making press-ready files which perfectly match what is seen on-
| screen?
| wtallis wrote:
| If you're going to bring Sun and NeWS into the conversation,
| you ought to also mention how after NeWS failed, Sun tried
| adopting OpenStep for Solaris.
| ab5tract wrote:
| No offense but this comes off as an equally narrow accounting
| of the historical record.
| KerrAvon wrote:
| I actually used the Apple Dylan environment. IIRC, it required
| 48MB RAM -- yes, M -- to launch, which was extremely an
| extremely large amount at the time -- as in, you probably
| needed to buy more RAM to run it -- and was itself written in
| Macintosh Common Lisp instead of self-hosting. UI development?
| Thing could barely run on a contemporary Mac. Every efficiency
| claim that was made for it was unproven. Maybe it could have
| been great, but it certainly needed at least a couple of years
| more bake time. The NeXT runtime existed and its performance
| characteristics were understood.
|
| Virtual memory was a huge issue for UI development with a
| retained-mode system like DPS; thrashing window contents is
| very not fun if you want a responsive UI. Apple spent years
| optimizing VM for this purpose after the NeXT purchase.
| nullpoint420 wrote:
| I think it's stretching the truth a little to say that Apple
| "had a very nice system for UI development on Dylan." The Dylan
| Eulogy site itself claims they hadn't even finished their
| Interface Builder [1] by the time it was canceled, which NeXT
| already had at the time.
|
| As a side note, Apple Dylan seems incredibly limiting and
| opinionated for no reason. I find it interesting the website
| lamenting its death only shows screenshots [2][3][4] of the
| "advanced" editor, rather than any successful applications made
| using Dylan.
|
| Also, how can I incrementally migrate Dylan into existing
| codebases, which were most likely C, at the time? Does it have
| an FFI? Also, most software engineers mental models at the time
| were imperative, and they expected them to learn the
| intricacies of functional programming and object-oriented at
| the same time?
|
| That's not even to mention the logistics about running it:
|
| > Keeping your source code in a fully version-tracked, object-
| oriented database with full metadata is an idea whose time has
| long since arrived, yet most of us still spend our time editing
| text files. Apple Dylan could export and import code from text
| files, but once you've used an IDE that takes advantage of
| fine-grained object storage of your source, you'll never want
| to go back. [5]
|
| Does this mean I'd need to shape my entire source control
| system around Apple Dylan? How would diffs and collaboration
| work? To use my source control system would I have to "export"
| it to plaintext every time? Text-based AppKit and Obj-C fit
| right into existing source control systems of the day.
|
| Also Obj-C and AppKit was already dogfooded heavily within
| NeXT. The system UI was built using it, as well as all the apps
| that shipped with the system. You can't say that about Dylan
| and MacOS 9.
|
| [1] https://opendylan.org/history/apple-
| dylan/screenshots/misc.h...
|
| [2] https://opendylan.org/history/apple-
| dylan/screenshots/browse...
|
| [3] https://opendylan.org/history/apple-
| dylan/screenshots/dynami...
|
| [4] https://opendylan.org/history/apple-
| dylan/screenshots/index....
|
| [5] https://opendylan.org/history/apple-dylan/eulogy.html
| pjmlp wrote:
| The platform which Dylan was originally designed for, the
| Newton had no C to begin with.
|
| There were two teams fighting for delivering the OS, one
| using Dylan, other using C++, eventually the C++ team won the
| internal politics, even though the Dylan one was relatively
| ahead.
|
| Newton was programmed in NewtonScript, prototype based OOP.
|
| Eventually the SDK allowed for C++ native extensions, and on
| the later version of the OS, before Newton was killed, there
| was already a basic JIT in place.
| chasil wrote:
| Just imagine if NeXT had been based on the Acorn Archimedes
| platform, instead of M68k.
|
| There would be no Java on Android, for sure.
| pjmlp wrote:
| As someone that knows Java since it exists, I fail to see the
| connection.
|
| Additionally, as someone that ported a visualisation
| framework from NeXTSTEP to Windows, the Acorn would never be
| able to run NeXTSTEP.
|
| NeXTSTEP was ridiculously expensive for a reason, in terms of
| hardware capabilities for the time.
| bluedino wrote:
| Mac OS development introduced me to Objective-C. Quirky, but I
| grew to like it. I think it was the first time I 'got' object-
| oriented programming. I had done Windows programming before and
| while it was 'fine', writing Mac OS GUI code was so nice.
| Probably a credit to the frameworks as much as the language,
| though.
|
| What other choice did NeXT have?
|
| C++ was invented about the time NeXT started. Microsoft didn't
| even release MFC until 1992.
|
| C...yikes.
|
| Pascal. Would Steve had went along with that?
| Austin_Conlon wrote:
| Related:
|
| - Oral History of Blaine Garst [PDF]:
| https://archive.computerhistory.org/resources/access/text/20...
|
| - Oral History of Blaine Garst [Video]:
| https://www.youtube.com/watch?v=qtEIq7fe_KQ
|
| - Oral History of Steve Naroff [PDF]:
| https://archive.computerhistory.org/resources/access/text/20...
|
| - Oral History of Steve Naroff [Video]:
| https://www.youtube.com/watch?v=ljx0Zh7eidE
| cxr wrote:
| I highly recommend the Steve Naroff interview. It's 6 hours in
| two parts, but it's worth the investment.
|
| Not listed here, but also available, is the oral history of
| Brad Cox and the later Objective-C paper authored by Naroff,
| Cox, Hsu (the author of the linked blog post) for HOPL IV.
| Someone else will have to dig up the links.
|
| You can also find interviews by other NeXTSteppers on the CHM
| site like Avi Tevanian and others. I think the Naroff one is
| best.
| nextos wrote:
| I always found Objective-C really elegant, due to its
| Smalltalk influence. I once read about Brad Cox explaining
| that the initial prototype was just one or two pages of C
| code to add objects and messaging. It was interesting to
| discover that Erlang had a similar origin story, with a thin
| layer built on top of Prolog [1]. Does a similar description
| of early Objective-C exist? I couldn't find a pointer in the
| videos.
|
| [1] https://www.labouseur.com/courses/erlang/history-of-
| erlang-a....
| Jtsummers wrote:
| https://dl.acm.org/doi/10.1145/3386332 - _The Origins of
| Objective-C at PPI /Stepstone and its Evolution at NeXT_ by
| Brad J. Cox, Steve Naroff, and Hansen Hsu, from HOPL IV
| itslennysfault wrote:
| So, this is why the abomination that is Obj-C is/was used for
| iPhone/Mac apps. I can't overstate how much I hate Obj-C. I'm so
| sooo happy Swift has pretty much entirely taken over.
|
| Side note... I feel similarly about the Java to Kotlin
| transition. Sooo much better. Although, I don't hate Java NEARLY
| as much as Obj-C.
| ramesh31 wrote:
| To each their own. I'm convinced it's just a visceral reaction
| to the square bracket syntax. Obj-C remains my favorite
| language of all time (although I haven't written it in years).
| Having a high level language that allows you to seamlessly drop
| into C felt like magic.
| nullpoint420 wrote:
| I'm using Obj-C for the first time in years for a side
| project. I'm working on making a Wayland backend for cocotron
| on Linux.
|
| It is magical the way I can just use the C libraries with all
| the dynamic goodness Obj-C.
| Longhanks wrote:
| There's even more magic: You can even use/include/write/mix
| and match ObjC with C++, within the same source file - C++
| classes calling ObjC methods, ObjC methods instantiating
| C++ classes, it's all there. No other language comes close
| to this kind of interop with C++ and it is one feature that
| Swift will never be able to match (albeit intentionally).
| tambourine_man wrote:
| https://www.swift.org/documentation/cxx-interop/
| Longhanks wrote:
| Yes, there is interop at the linking level. I was however
| explicitly stating that you can mix and match both ObjC
| and C++ within the same source files and as long as you
| don't violate the language rules of one with what's
| allowed in the other (e.g. giving your ObjC variable the
| name template), then absolutely any features, even
| language-wise, are supported. You can have C++ RAII
| destructors call ObjC methods. You can have C++ classes
| with an NSArray member. You can have a std::vector as a
| property of your ObjC class. You can mix and match
| libdispatch, std::call_once, ObjC blocks and C++ lambdas.
|
| No other language comes close to this incredible source-
| level interop. Here be dragons, but there's also lots of
| opportunity (and fun, from a programming languace theory
| perspective).
| itslennysfault wrote:
| Interesting, I guess that part was missed on me since I only
| really ever used it for iPhone apps and never really had a
| need to use C directly.
|
| Also, you're 100% right. The square brackets are what
| immediately repulsed me and continued to befuddle me even
| after years of experience with it. Also, everything just
| feels "backwards" to me if that makes any sense. Coming from
| Java/C#/JavaScript everything just seemed unintuitive to me
| at all times. Also, I think this was heavily compounded by
| using xCode which (at the time) was incredibly laggy. So, I'd
| mess up the Obj-C syntax and the IDE wouldn't tell me for
| what felt like forever. Often I'd make a change and hit
| "play" before the syntax highlighting caught up and that
| always felt infuriating.
|
| I last used xCode about 4 years ago and it was still an issue
| then (even with swift).
| ramesh31 wrote:
| >"Also, everything just feels "backwards" to me if that
| makes any sense."
|
| Because it is. Obj-C comes from the Smalltalk lineage by
| way of Alan Kay, using message passing [0] versus method
| invocation. It's a subtle difference with huge implications
| to how you design systems. Method invocation won out mostly
| because of Java and C++, but there was a time it wasn't
| clear which was the better OO paradigm.
|
| [0] https://en.m.wikipedia.org/wiki/Message_passing
| bunderbunder wrote:
| Message passing belongs up there with lisp, forth and
| pure functional programming as paradigms that are worth
| learning for "the profound enlightenment experience you
| will have when you finally get it." But I often see that
| my peers in the profession lack the kind of growth
| mentality that enables a person to see past the alienness
| of less algol-y languages.
|
| Quote from "How To Become a Hacker" by Eric S. Raymond:
| http://www.catb.org/esr/faqs/hacker-howto.html
| pjmlp wrote:
| Java is heavily based in Smalltalk and Objective-C, even
| if it has a C++ like syntax for mainstream adoption.
|
| https://cs.gmu.edu/~sean/stuff/java-objc.html
|
| Even Java EE was actually a rebooted Objective-C based
| project done internally at Sun during the OpenSTEP days,
| aka Distributed Objects Everywhere.
| robenkleene wrote:
| I've been an Mac and iOS engineer for over a decade, and
| none of this makes any sense to me. Everything you listed
| (besides the brackets) is worse in Swift than in
| Objective-C (Swift has real problems with live error
| checking in Xcode in particular, due to the additional
| compilation complexity since it's a significantly more
| complicated language).
|
| I've observed some folks have a visceral reaction to having
| to use Xcode, I don't really understand it myself. I can
| understand being annoyed at having to use _a_ specific IDE
| to write iOS and Mac apps, e.g., it 's harder to bring your
| own text editor like you usually can, it's going to make
| your life a lot harder if you try to to avoid using Xcode.
| But comparing Xcode to any IDEs like the JetBrains IDEs
| I've used (mainly the discontinued AppCode), Android Studio
| (also JetBrains under the hood), or other similarly complex
| development environments like Unreal or Unity, I don't see
| any of these as a clear winner. Personally I'd prefer using
| Xcode to any of those. I suspect this comes down to just
| whether you like native Mac apps or not, Xcode is a native
| Mac app and if you like that aesthetic than you'll like
| Xcode. I suspect most of the dislike for Xcode is really
| just folks who dislike the Mac platform (e.g., the UI
| toolkit) overall.
| pjmlp wrote:
| I think it comes from the folks that aren't really into
| Apple culture, rather they buy Apple because of UNIX, or
| want to target iDevices without culture background on the
| ecosystem.
| neverartful wrote:
| The square brackets can be a huge impediment when first
| working on Obj-C (it was to me). I found that after some
| period of time to acclimate they eventually felt 'normal'.
| jwells89 wrote:
| For personal use, the only issue I take with Obj-C is how
| it's considerably less "batteries included" relative to
| Swift.
|
| For collaborative projects on the other hand, it can become a
| handful to maintain if everybody contributing isn't staying
| on top of hygiene with null checks, type checks, etc. Swift
| helps to keep all of that under control.
| cxr wrote:
| Someone really ought to do an alternative "skin" for
| Objective-C. That is, define some reversible transformation
| that can be applied to any Objective-C program that only
| changes the surface-level details but otherwise results in
| mapping the exact same program into the later stages of the
| compiler (and the section of programmers' mental pipeline
| that comes after the part where their eyeballs and sense of
| taste are concerned). It's important that the reversible part
| be adhered to.
|
| It's really kind of a bummer that we don't have well-known
| examples of "skinnable" programming languages already. The
| closest we get are the ones that let you choose your set of
| keywords for different locales in case you don't want to work
| with an English-based PL and those block based languages that
| let you manipulate them as blocks or edit the textual form. I
| firmly believe that PL skinning would really benefit so many
| otherwise worthwhile languages that get short-shrift because
| of negative reactions to the surface-level details. I'm
| referring in particular languages like those in the Pascal
| family. (You could also conceive of e.g. a skin for Golang
| that doesn't have leading caps be the determiner for whether
| a function is public or not. There are lots of applications
| for this, and the variations are a non-issue when you have an
| ecosystem with strong norms about applying a code formatter
| (like gofmt), which can dictate the format of the canonical
| on-disk representation.)
| Aeglaecia wrote:
| surely after 20 years this already exists , someone posted
| a header the other day that makes c syntax python like ,
| macros are enough to accomplish what youre describing? i
| dont perceive it as efficient to force codebase
| contributors to relearn their ingrained language syntax ,
| possibly more efficient for those having newly learned a
| language tho ...
| mpweiher wrote:
| _The Four Stages of Objective-Smalltalk_
|
| https://blog.metaobject.com/2019/12/the-4-stages-of-
| objectiv...
|
| Its first two stages are just that, but it has moved
| beyond, for good reasons.
| wslh wrote:
| I did a few things in Obj-C and I only regretted the memory
| handling stuff. I really liked the performance, reflexibility
| capabilities (reverse engineering classes is almost trivial)
| and smalltalk like style. I will not choose it for any project
| but it gives me the taste that there were more options around
| C/C++
| pjmlp wrote:
| There has been plenty of options back in the day, it was
| guaranteed that C and C++ would take over everything as they
| did during the late 1990's.
|
| Even the Object Pascal to C++ transition at Apple was mostly
| caused by increased UNIX adoption, and Apple programmers
| wanting to offer similar experiences, thus MPW was born.
|
| Same on other platforms, until C and C++ eventually won
| everywhere, at least until several new kids decided to
| challenge them in various fronts.
|
| One that you seldom see nowadays, outside games, is pure GUI
| frameworks using C or C++.
| mentos wrote:
| Did you start with Swift or Objective-C?
|
| I started with Objective-C and loved it but I imagine that
| wouldn't have been the case if I started with Swift.
| bunderbunder wrote:
| Same. I realize that Objective-C is dated by contemporary
| standards. But when I first learned it 20-ish years ago it
| felt like a superpower. I bet it was even more impressive
| when it first appeared another 20 years further back.
|
| I think that one of the tragedies of older programming
| languages is that they survive long enough for people to
| forget the technical - and technological - constraints that
| influenced their design. Swift is great, but there are
| reasons why there weren't any Swift-like languages being
| developed in or around 1984.
|
| Similar feelings about Java. It is definitely not my favorite
| programming language. (I suppose Kotlin isn't either, but
| it's in the top _n_.) But it 's hard for me to actually hate
| it. Java walked so that Kotlin could run.
| incanus77 wrote:
| I'm back in Objective-C now for a large mixed codebase for a
| client and enjoying it. It was my first compiled language
| starting in 2002 so I've got about equal time with only it as I
| do with Swift alongside. And I'm spending more time these days
| in other projects (microcontrollers, mostly) using C so it's a
| breath of fresh air. I'm finding it generally faster than Swift
| in Xcode, which is a bonus.
| neverartful wrote:
| I too am back in Objective-C and being away from it for a
| long while and I'm also enjoying it. For the most part, I
| really like Objective-C. I think it's a very pragmatic
| language. My current project is macOS, but the vast majority
| of my prior work with Xcode and ObjC was with iOS
| development.
| pjmlp wrote:
| Metal is implemented in a mix of Objective-C (CPU) and C++
| (Metal Shaders), Swift only has bindings.
|
| Maybe one it they will rewrite the Objective-C, who knows.
|
| Kotlin transition is a Google thing, outside Android barely
| anyone notices that it exists.
| ahoka wrote:
| "Kotlin transition is a Google thing, outside Android barely
| anyone notices that it exists."
|
| That's not true.
| agumonkey wrote:
| I don't know how realistic is this video but it was interesting
|
| https://www.youtube.com/watch?v=UGhfB-NICzg
|
| A sun vs next rapid development challenge.
| nineteen999 wrote:
| Why do the words "Steve Jobs" and "programming" in the same
| sentence very slightly rub me the wrong way. Probably because one
| thing he wasn't, amongst all the superhuman things attributed to
| him by Apple zealots, is a programmer.
| exe34 wrote:
| Elon Musk doesn't build rockets either - but it's fair to
| associate him with SpaceX progress. We rightly blame the top
| guy when stuff goes pear shaped, and we should be willing to
| let them get some credit when it goes well.
| layer8 wrote:
| > By the 1980s, the problems of cost and complexity in software
| remained unsolved.
|
| We're well into the 2020s and I'd say those problems have pretty
| much remained unsolved. ;)
| aidenn0 wrote:
| Ah, Objective C. The language that combines the famous memory
| safety of C with the blazing-fast performance of Smalltalk.
___________________________________________________________________
(page generated 2024-11-13 23:01 UTC)