4 ms·

"First, a few obvious, non-negotiable things any new OO language should have: ..." Well, that's like your opinion, man ...

throwaway4good 6y ago
Personally I would drop the static type system and reinvent Self.
- agumonkey 6y ago
  time to dust it off and sell it as new ?
  - throwaway4good 6y ago
    Yeah - I think the kids are ready for that.
    - agumonkey 6y ago
      rebrand it `selfie`
- protomyth 6y ago
  ...and steal the Soups from NewtonScript on the way.
  - mucholove 6y ago
    What are the soups? Both Google and DuckDuckGo give me no results so an example would be appreciated. (Hope I'm not caught up in a prototype joke :)
    - deleted 6y ago
      [deleted]
    - lionsdan 6y ago
      "Data in Newton is stored in object-oriented databases known as soups." https://en.wikipedia.org/wiki/Apple_Newton#Data_storage https://en.wikipedia.org/wiki/Apple_Newton#Data_storage
    - protomyth 6y ago
      Chapter 11-7 of https://www.newted.org/download/manuals/NewtonProgrammerGuide20.pdf https://www.newted.org/download/manuals/NewtonProgrammerGuid... using the Self influenced language NewtonScript https://www.newted.org/download/manuals/NewtonScriptProgramLanguage.pdf https://www.newted.org/download/manuals/NewtonScriptProgramL...
      - astrange 6y ago
        My impression of systems like soups/OpenDoc/component systems/etc is that they're doomed to failure because they don't respect Conway's law. The app model works because each app has its own development team and teams aren't directly editing other teams' data. They don't have the proper expertise and will break something, because it's not possible to enforce data consistency well enough. (Apple's modern OO database is called CoreData, has a pedigree from WebObjects, and its consistency features are pretty hard to use in practice.)
        protomyth 6y ago
        Soups and OpenDoc have no actual relation. Soups is a object file system and OpenDoc was a component system. CoreData is a poor successor to NeXT's EOF. I so miss EOF. The only connection to editing someone else's data was the ability to add fields to soups for things like Contacts which allowed an easy expansion. Given how many programs on UNIX can alter each other's data, I don't agree with Conway in the context of the file system or soup.
- stitched2gethr 6y ago
  After working in Python and Ruby I don't think I could ever choose a dynamically typed language for a project with more than a few thousand lines. There's just a lot of safety, and documentation, you get cheaply when using static types.
  - fiddlerwoaroof 6y ago
    There’s languages like Python and Ruby and then there’s languages like Smalltalk, Common Lisp, Self or Clojure: if dev-time is runtime, you miss compile-time checks a lot less
  - weatherlight 6y ago
    Ruby has conventions and a big testing culture which helps mitigate a lot of those issues. I also work with Typescript and I see whole classes of bugs that could be avoided if everyone just stuck with conventions and best practices. If you like Ruby and wish it had types, check out Crystal. It's basically Ruby with Go's concurrency model, and it's as fast as Go. {Edit: repetition}
  - cutler 6y ago
    Cue the "Dynamic Languages Fail At N Lines of Code" bikeshedding as if Facebook, AirBnB and Shopify never happened.
brabel 6y ago
That's the problem with language design: too much opinion, too little decision making based on actual data. The author says there should be no Exceptions and there should be multiple inheritance... I mean, these seem like pretty extreme positions to have when talking about an OO language... if I remember correctly, multiple inheritance, in particular, was one of the features the languages from the late 90's had actually stayed clear of as it had been shown by the previous generation of languages that it was a mostly bad idea. I think even inheritance as done in Java is not the best of ideas, and there seems to be evidence extension methods or, similarly, type classes, are better suited to add behaviour to data structures. IMO languages like Kotlin and Swift are much more like what modern OOP languages should be than what the author proposes.
- hedora 6y ago
  If you want your language to be called “Object Oriented”, it needs to support implementation inheritance. (Encapsulation and interfaces predate OO). My personal take is that implementation inheritance is a bad idea, and, by extension, Object Oriented programming is a dead end.
- andrewflnr 6y ago
  The author is explicitly using Kotlin as one of their inspirations, and IMO has a pretty reasonable approach to multiple inheritance (and I suspect they would agree that extension methods are preferred when applicable). What problems does MI cause that aren't fixed by OP's solution to diamond inheritance?
  - thu2111 6y ago
    Kotlin extension methods can't be grouped and abstracted over like traits can. And moreover they are not virtual methods. Virtual methods are useful for all sorts of reasons. In Kotlin extension methods are best used as a nice way to add utility methods to code you don't directly control, and as part of the 'extension lambda' system that lets you make DSLs. The way Kotlin defines language integration features using methods with magic names makes it easy to add a thin layer on top of a Java API that makes it much nicer to use, without needing to fork or patch the actual library itself.
_void 6y ago
Lol, can't ignore the Lebowski reference :) good one! I actually think it is very subjective list :)

throwaway4good 6y ago

Personally I would drop the static type system and reinvent Self.

agumonkey 6y ago
time to dust it off and sell it as new ?
- throwaway4good 6y ago
  Yeah - I think the kids are ready for that.
  - agumonkey 6y ago
    rebrand it `selfie`
protomyth 6y ago
...and steal the Soups from NewtonScript on the way.
- mucholove 6y ago
  What are the soups? Both Google and DuckDuckGo give me no results so an example would be appreciated. (Hope I'm not caught up in a prototype joke :)
  - deleted 6y ago
    [deleted]
  - lionsdan 6y ago
    "Data in Newton is stored in object-oriented databases known as soups." https://en.wikipedia.org/wiki/Apple_Newton#Data_storage https://en.wikipedia.org/wiki/Apple_Newton#Data_storage
  - protomyth 6y ago
    Chapter 11-7 of https://www.newted.org/download/manuals/NewtonProgrammerGuide20.pdf https://www.newted.org/download/manuals/NewtonProgrammerGuid... using the Self influenced language NewtonScript https://www.newted.org/download/manuals/NewtonScriptProgramLanguage.pdf https://www.newted.org/download/manuals/NewtonScriptProgramL...
    - astrange 6y ago
      My impression of systems like soups/OpenDoc/component systems/etc is that they're doomed to failure because they don't respect Conway's law. The app model works because each app has its own development team and teams aren't directly editing other teams' data. They don't have the proper expertise and will break something, because it's not possible to enforce data consistency well enough. (Apple's modern OO database is called CoreData, has a pedigree from WebObjects, and its consistency features are pretty hard to use in practice.)
      - protomyth 6y ago
        Soups and OpenDoc have no actual relation. Soups is a object file system and OpenDoc was a component system. CoreData is a poor successor to NeXT's EOF. I so miss EOF. The only connection to editing someone else's data was the ability to add fields to soups for things like Contacts which allowed an easy expansion. Given how many programs on UNIX can alter each other's data, I don't agree with Conway in the context of the file system or soup.
stitched2gethr 6y ago
After working in Python and Ruby I don't think I could ever choose a dynamically typed language for a project with more than a few thousand lines. There's just a lot of safety, and documentation, you get cheaply when using static types.
- fiddlerwoaroof 6y ago
  There’s languages like Python and Ruby and then there’s languages like Smalltalk, Common Lisp, Self or Clojure: if dev-time is runtime, you miss compile-time checks a lot less
- weatherlight 6y ago
  Ruby has conventions and a big testing culture which helps mitigate a lot of those issues. I also work with Typescript and I see whole classes of bugs that could be avoided if everyone just stuck with conventions and best practices. If you like Ruby and wish it had types, check out Crystal. It's basically Ruby with Go's concurrency model, and it's as fast as Go. {Edit: repetition}
- cutler 6y ago
  Cue the "Dynamic Languages Fail At N Lines of Code" bikeshedding as if Facebook, AirBnB and Shopify never happened.

brabel 6y ago

That's the problem with language design: too much opinion, too little decision making based on actual data. The author says there should be no Exceptions and there should be multiple inheritance... I mean, these seem like pretty extreme positions to have when talking about an OO language... if I remember correctly, multiple inheritance, in particular, was one of the features the languages from the late 90's had actually stayed clear of as it had been shown by the previous generation of languages that it was a mostly bad idea. I think even inheritance as done in Java is not the best of ideas, and there seems to be evidence extension methods or, similarly, type classes, are better suited to add behaviour to data structures. IMO languages like Kotlin and Swift are much more like what modern OOP languages should be than what the author proposes.

hedora 6y ago
If you want your language to be called “Object Oriented”, it needs to support implementation inheritance. (Encapsulation and interfaces predate OO). My personal take is that implementation inheritance is a bad idea, and, by extension, Object Oriented programming is a dead end.
andrewflnr 6y ago
The author is explicitly using Kotlin as one of their inspirations, and IMO has a pretty reasonable approach to multiple inheritance (and I suspect they would agree that extension methods are preferred when applicable). What problems does MI cause that aren't fixed by OP's solution to diamond inheritance?
- thu2111 6y ago
  Kotlin extension methods can't be grouped and abstracted over like traits can. And moreover they are not virtual methods. Virtual methods are useful for all sorts of reasons. In Kotlin extension methods are best used as a nice way to add utility methods to code you don't directly control, and as part of the 'extension lambda' system that lets you make DSLs. The way Kotlin defines language integration features using methods with magic names makes it easy to add a thin layer on top of a Java API that makes it much nicer to use, without needing to fork or patch the actual library itself.

_void 6y ago

Lol, can't ignore the Lebowski reference :) good one! I actually think it is very subjective list :)