Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does OO really match the way we think (1997) [pdf]

leshatton.org

Post reply on HN
Print view View original

241–250 of 253 posts

Re: Does OO really match the way we think (1997) [pdf]

#241

Post by lispm »

kazinator wrote: post #227
willtim wrote: post #68

Earlier quoted context omitted.

There is no language definition or implementation called "LISP". Both Scheme and OCaml lexically capture variables by value, as if they have been passed in as arguments. This is not how it works in e.g. Python.

> There is no language definition or implementation called "LISP". Well, yes there actually is: the Lisp 1 language that MacCarthy and friends developed on the IBM 704, and its immediate follow-ups through Lisp 1.5. Since that, there isn't.

There is a basic rule: all languages carrying Lisp in their name implement much of the core of McCarthy's Lisp:

Emacs Lisp, ISLISP (which is defined by an ISO standard) Standard Lisp, Common Lisp (which has an ANSI Standard), ...

Languages in the wider Lisp family, which are more or less incompatible (Logo, Clojure, Dylan, ...) don't use Lisp in their name.

Re: Does OO really match the way we think (1997) [pdf]

#242

Post by barking »

tome wrote: post #182
barking wrote: post #51

I found this anti-oop video very persuasive. https://youtu.be/QM1iUe6IofM He also had a couple of follow up ones. Basically he blames java for oop's popularity. He maintains that oop's combining of methods and data is actually a fault and not a benefit. That every good oop promises apart from inheritance (which is bad anyway) is more easily achieved in procedural programming. OOP promotes endless meaningless abstract…

I'm sad you've been downvoted. I loved this video.

Thanks! I've always found it unnatural to design solutions in an oop way. And any time I have done it the code always seems a lot harder to debug afterwards. At the same time I kinda always felt that my preference for procedural code reflected badly on my programming skills. To hear someone who is clearly skilled and knowledgeable argue so well in support of the way i like to program was a bit like having a weight lifted off my shoulders.

Re: Does OO really match the way we think (1997) [pdf]

#243

Post by empthought »

kazinator wrote: post #228
empthought wrote: post #152

Earlier quoted context omitted.

The question is if you mutate the variable, create a closure, mutate the variable, create a closure, and so on -- do those closures -- when executed -- each use the value that the variable had at the time the individual closure was created, or do they all use the latest value that the variable had? Scheme (and other academic languages) do the first, Python (and other scripting languages) do the second. But the proble…

No, multiple closures in Scheme will not capture different values of the same, mutated variable. For that to happen, the block has to be re-entered such that a fresh binding is created for those variables. That is not mutation. Scheme's version of the do loop actually performs fresh binding, rather than mutation, so lambdas in the do loop capture the iterations separately. If you mutate a variable with set! , all the…

Thanks, "mutate" was definitely the wrong word in my post. The trouble here is that Python doesn't have syntax to do a binding rather than an assignment.

Re: Does OO really match the way we think (1997) [pdf]

#244

Post by tome »

jcelerier wrote: post #240
icebraining wrote: post #155

Earlier quoted context omitted.

You can do that optimization in FP languages if you have unique types, ie, types that can only have one reference to them. You use the list as if it's immutable, by creating a new list with the new command and the rest of the previous list. But since the compiler can prove that the old list is no longer referenced, it can reuse it and simply make the update in-place.

could you show an actual example where commands are polymorphic types (e.g. they come from a separate DLL) and this optimization actually happens ? (the actual "updating" of the command doesn't need to cross DLL boundaries, eg a DLL both provides a command, instantiates it, and updates it. The command queue is instantiated by another DLL though).

I don't know what icebraining is talking about becaue AFAIK there aren't widely used languages with unique types, except perhaps Rust.

Re: Does OO really match the way we think (1997) [pdf]

#245

Post by slackingoff2017 »

jwdunne wrote: post #239
slackingoff2017 wrote: post #220

Earlier quoted context omitted.

Close, any objects with the same properties and types are compatible. The name of the properties and their types need to match. And this isn't always a good thing. If you have a function dealing with the property 'length' or 'value' for instance, you might as well have no type system because Typescript will allow you to pass in any object with those properties which is almost anything. While the code will still compi…

Given an object with a length property with the type a method expects, is there ever a scenario where the method is incorrect? I'm trying to wrap my head around it: if a method needs only the length property, which is an unsigned int, is there any good reason why it shouldn't accept any object that has that property? It appears at first that this is a good quality: the code is general whilst obviously avoiding any ty…

The type system is still working properly in that it will produce code that compiles and runs. For the developer such a behaviour can be misleading. This is compounded by IDE's with intellisense which will suggest passing random objects with the correct properties into the function.

Re: Does OO really match the way we think (1997) [pdf]

#246

Post by flavio81 »

kazinator wrote: post #227
willtim wrote: post #68

Earlier quoted context omitted.

There is no language definition or implementation called "LISP". Both Scheme and OCaml lexically capture variables by value, as if they have been passed in as arguments. This is not how it works in e.g. Python.

> There is no language definition or implementation called "LISP". Well, yes there actually is: the Lisp 1 language that MacCarthy and friends developed on the IBM 704, and its immediate follow-ups through Lisp 1.5. Since that, there isn't.

yes, there is; Common Lisp and it is an Ansi standard. This is what is commonly understood as "Lisp" (noun) as opposed as when writing "a Lisp" (adjective), in which case it could be Scheme, Racket, Clojure, etc.

Re: Does OO really match the way we think (1997) [pdf]

#247

Post by sds2 »

fiddlerwoaroof wrote: post #198
sds2 wrote: post #135

Earlier quoted context omitted.

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

The performance claim doesn't really matter in a world where we use languages like Python, Ruby, PHP and Javascript for major applications. Also, compared to these languages, Common Lisp seems to generally be faster (and, on most implementation/architecture combinations, supports real parallelism). http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php…

> The performance claim doesn't really matter in a world where we use languages like Python, Ruby, PHP and Javascript for major applications.

Yes, it does. And those languages are all providing negative user/developer experience.

Re: Does OO really match the way we think (1997) [pdf]

#248

Post by sds2 »

flavio81 wrote: post #235
sds2 wrote: post #135

Earlier quoted context omitted.

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

>Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. ?! Lisp under SBCL is as fast as Java under the latest Oracle JVM and for numeric computation is sometimes as fast as Fortran. This means at least 10-20x faster than CPython, Ruby's MRI and others. I routinely read third-party Lisp li…

> Lisp under SBCL is as fast as Java under the latest Oracle JVM and for numeric computation is sometimes as fast as Fortran.

Back it up.

> I routinely read third-party Lisp libraries and they are very readable, no problems with that.

Me too and they're all junk.

Re: Does OO really match the way we think (1997) [pdf]

#249

Post by Tehnix »

maxxxxx wrote: post #121
yen223 wrote: post #119

Earlier quoted context omitted.

Store a list of actions, and represent your state as a sum of said actions. That way, no matter what the action is, "undoing" an action is literally just popping it off the list. actions = [append("The"), append(" quick"), append(" brown"), append(" fox")] state = reduce(actions, some_combiner) // This might give you a string "The quick brown fox" If you pop the last element `append(" fox")` of the actions and rebuil…

Makes sense. But i don't see how this is related to OO vs FP then. Putting all your actions into a list is easy. Replaying is easy. The main problem is caching the state which can become tricky no matter OO or FP.

My arguments was actually just that it had nothing to do with OO at all :)

Caching becomes a lot easier though in a pure functional programming lang though, and in a lazy one happens automatically for a lot of things.

Re: Does OO really match the way we think (1997) [pdf]

#250

Post by Tehnix »

pjmlp wrote: post #117
Tehnix wrote: post #42

Earlier quoted context omitted.

Heh, check out time-travel debugging and be amazed at how simple a much more powerful “undo” can be made when purity is involved (in FP langs, e.g. Elm or Haskell). Seriously though, design wise there was not much you said that was specific to OO. Take for example: - all actions are a data type - the history is a list of actions (in LIFO style for the purpose of simplicity here) - undo pops the list and puts undo in…

Already present in Smalltalk, Lisp and Mesa/Cedar development environments at Xerox PARC, no need for FP advocating for it.

I guess immutability is the actual thing that makes it easy, and arguably Lisp is also an FP lang. m Main point though was the ease of doing it in a pure language, almost trivial.
Post reply on HN