Earlier quoted context omitted.
Amphibious pitcher debuts in MLB.
What?
Does OO really match the way we think (1997) [pdf]
91–100 of 253 posts
Re: Does OO really match the way we think (1997) [pdf]
#92Re: Does OO really match the way we think (1997) [pdf]
#93I think the big problem with OOP is that it's designed to simulate the real world but has the real world backwards. Real world objects are a composition of parts. The taxonomy of those objects, and its constituent parts, is am artificial construct independent of how those objects are composed. A frog is a frog because it fits some definition that experts agree on. The taxonomy comes afterwards - the composition just…
"In this way, OOP would benefit from composition-first, taxonomy after. An object is a thing because of what it has (and this includes behaviour too), not because of what it is or descended from." A lot of working programmers have figured this out already. Most experienced programmers I know don't use much inheritance.
Plus, my wider point was that in the real world, which is the inspiration for OOP, the taxonomy is artificial and placed onto an object. The taxonomy isn't an inherent part of the object (i.e Dog extends Canidae). The taxonomy is given to an object based on its composition separately i.e a dog is a dog because of some property x, y and z and just so happens that X, y are what makes Canid a Canid and X is what makes a carnivore a carnivore.
Re: Does OO really match the way we think (1997) [pdf]
#94Earlier 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.
Python has had closures exactly the same as Scheme and OCaml since the year 2000. What it lacks is a multiline anonymous function syntax. See PEP 227: https://www.python.org/dev/peps/pep-0227/
From the link you posted: "all uses of the name within the block are treated as references to the current block"
The Python folks call them "late binding closures" and they are frequently discussed as "gotchas".
Essentially lexically scoped variables are captured as references to mutable state. Java did not make this mistake, perhaps because they had Guy Steele (of Scheme fame) on the committee. It is a questionable default that ultimately just destroys ones ability to reason about programs.
Re: Does OO really match the way we think (1997) [pdf]
#95OOP did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example functional has taken prominence in the 90s we'd be in a much better place now.
I have the polar opposite view. I love OOP because it provides a way to elegantly solve so many problems. To take a concrete example, consider the undo-redo mechanism in a text editor. It seems natural to create a list of objects with each object representing the action that can be undone or redone, and a pointer to the most recent action object. Undoing executes the 'undo' method and moves the pointer to the previou…
Re: Does OO really match the way we think (1997) [pdf]
#96Re: Does OO really match the way we think (1997) [pdf]
#97No comment about OO in general, but I think Java/C# is a damn fine language design, avoiding many problems of newer paradigms. Here's an example: 1) Java: starts out with one opaque string type, because that's what OO methodology says. Changes the internals when needed. All clients continue to work forever. 2) Haskell: starts out with strings as exposed linked lists of characters, because functional methodology says…
I'd argue that java strings aren't perfect either, though. You can't seamlessly use the string interface for binary data or char arrays for instance. Also, java has various streaming implementations that all use completely different interfaces so maybe lazy java strings would have been helpful.
Re: Does OO really match the way we think (1997) [pdf]
#98I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.
For example, the amount of articles about programming languages like Rust or Elixir is disproportionate compared to their actual relevance in the industry.
HN has a very strong bias for functional programming.
You almost never hear about Go or Node.js anymore except when there is a major release but these languages are extremely widespread and proven and there is a lot of very interesting stuff happening in these communities that HN seems to ignore.
Re: Does OO really match the way we think (1997) [pdf]
#99I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.