5 ms·

I was a big BeOS fan back in the day, but honestly in retrospect I think NeXTStep was a more advance and better thought out system. BeOS went with C++ for GUI p

I was a big BeOS fan back in the day, but honestly in retrospect I think NeXTStep was a more advance and better thought out system. BeOS went with C++ for GUI programming e.g. which is a terrible language to do GUIs in. I wasted about 10 years of my life doing GUI programming in C++, and any C++ solution which didn't totally suck essentially ended up duplicating in a crappy way what had already been figured out in Objective-C. BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore. NeXT also had a more sophisticated display system, based on 2D vector graphics. They had the bundle concept and a lot of other things which I think in sum made it a better system. What I liked about BeOS was the heavy use of the file system attributes, and the translators were you could just drop in a GIF translator and then all you graphics apps could suddenly read GIF images.

nickpsecurity 11y ago
"BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore." I was about to start digging up more on its multithreading due to interesting things I read in architecture documents. Not to mention their multimedia demos. Read lots of positive stuff with interesting tricks like "benaphores." So would you clarify why you think it was a bad design and why nobody will use it any more? And did their concurrency or other design efforts get anything right in your eyes?
- rvense 11y ago
  I programmed for BeOS a little (mostly before I really understood programming, though), and what I remember is just the shear number of threads. Each window (maybe even subregions of windows, don't remember) would spawn two, I think. You'd have to lock to do the simplest things. A lot of rote, manual management of shared mutable state.
  - nickpsecurity 11y ago
    I got you. So it's not tge architecture or how threading worked under hood but the developer experience the API's forced was bad? Right? That could be fixed easily in a knockoff.

nickpsecurity 11y ago

"BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore." I was about to start digging up more on its multithreading due to interesting things I read in architecture documents. Not to mention their multimedia demos. Read lots of positive stuff with interesting tricks like "benaphores." So would you clarify why you think it was a bad design and why nobody will use it any more? And did their concurrency or other design efforts get anything right in your eyes?

rvense 11y ago
I programmed for BeOS a little (mostly before I really understood programming, though), and what I remember is just the shear number of threads. Each window (maybe even subregions of windows, don't remember) would spawn two, I think. You'd have to lock to do the simplest things. A lot of rote, manual management of shared mutable state.
- nickpsecurity 11y ago
  I got you. So it's not tge architecture or how threading worked under hood but the developer experience the API's forced was bad? Right? That could be fixed easily in a knockoff.