On Thursday, 14 November 2013 at 07:24:32 UTC, Paulo Pinto wrote:
>
> Because slices are always references, so you have a double indirection.

Right, that makes sense. Note though that this double indirection is necessary if you're passing a slice into a function that will modify its length, such as one that will append to it. It's more idiomatic to just have the function return a new slice, but that's slightly less inefficient.

On Thursday, 14 November 2013 at 07:24:32 UTC, Paulo Pinto wrote:
>
> Because slices are always references, so you have a double indirection.

Right, that makes sense. Note though that this double indirection is necessary if you're passing a slice into a function that will modify its length, such as one that will append to it. It's more idiomatic to just have the function return a new slice, but that's slightly less efficient.

On Tuesday, 12 November 2013 at 12:19:56 UTC, Paulo Pinto wrote:
> On Tuesday, 12 November 2013 at 11:27:51 UTC, Jonathan M Davis wrote:
>> On Tuesday, November 12, 2013 12:09:23 =?UTF-8?B?Ikx1w61z?=.Marques
>> <luis@luismarques.eu>@puremagic.com wrote:
>>> I think you will be pleased with the argument, given D's
>>> philosophy:
>>> 
>>>     https://yinwang0.wordpress.com/2013/11/09/oop-fp/
>>
>> Yeah. Both OO and functional programming are useful, but trying to use any one
>> paradigm exclusively always ends up contorting things. To make this clean, you
>> really need to be able to mix and match paradigms as appropriate.
>>
>> On a related note, a classic blog post that I quite like on how Java takes OO
>> too far is
>>
>> http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>
> If Java takes OO too far, what to say about Smalltalk and derivatives?

Well, Smalltalk and friends are truly Object oriented, as opposed to C++/Java/D etc which are Class oriented. So it is a little different.

But something I've been wondering for years - is there a solid rebuttal anywhere to Stepanov's criticism of OOP? He takes the extreme position that (class oriented) OOP is useless. Surely that can't be right, but...

It's trivial to find good procedural code. It's trivial to find good generic code. It's trivial to find good functional code.
But finding top-quality OOP code is extremely difficult. Eg, the code in the GoF Design Patterns book is widely criticised.

I just can't escape the feeling that class-based runtime polyphorphism is almost never an ideal solution, and that most of the benefits and success of OOP languages comes from things other than OOP itself. And I think it's because OOP is philosophically nonsense -- in the real world, similarities between things are everywhere, but almost none of them are is-A relationships.

>
>>
>> The balanced approach that C++ and D take is definitely the better one IMHO
>> (and D tends to do it better IMHO, since it better supports functional
>> programming than C++ does, meaning that you end up with fewer FP solutions in
>> C++ even when they'd be appropriate).
>>
>> - Jonathan M Davis
>
>
> The future belongs to multi-paradigm languages, I would say.
>
> What I miss still in languages like D, is the Hindley–Milner type inference,
> algebraic data types and pattern matching.
>
> --
> Paulo

On 2013-11-14 10:37, Don wrote:

> I just can't escape the feeling that class-based runtime polyphorphism
> is almost never an ideal solution, and that most of the benefits and
> success of OOP languages comes from things other than OOP itself. And I
> think it's because OOP is philosophically nonsense -- in the real world,
> similarities between things are everywhere, but almost none of them are
> is-A relationships.

I think the most useful parts of OOP is encapsulation and have the data and methods in the same place.

-- 
/Jacob Carlborg

On Thursday, 14 November 2013 at 10:01:34 UTC, Jacob Carlborg wrote:
> On 2013-11-14 10:37, Don wrote:
>
>> I just can't escape the feeling that class-based runtime polyphorphism
>> is almost never an ideal solution, and that most of the benefits and
>> success of OOP languages comes from things other than OOP itself. And I
>> think it's because OOP is philosophically nonsense -- in the real world,
>> similarities between things are everywhere, but almost none of them are
>> is-A relationships.
>
> I think the most useful parts of OOP is encapsulation and have the data and methods in the same place.

Actually no different than using ADT (Abstract Data Types) popularized by modular languages like Modula-2, with the added benefit of type extension and polymorphism.

Just because OOP has objects in the name, it doesn't need to be real objects, but concepts actually.

The main problem was that OOP productivity was oversold hype, in the same vein as web 2.0, cloud computing, agile and whatever might come next. People need to sell books and certifications.

And that the early OO design approaches focused too much in implementation inheritance instead of interfaces and delegation.

--
Paulo

On 2013-11-14 11:51, Paulo Pinto wrote:

> Actually no different than using ADT (Abstract Data Types) popularized
> by modular languages like Modula-2, with the added benefit of type
> extension and polymorphism.

I had a look at this:

http://en.wikipedia.org/wiki/Abstract_data_type#Example:_implementation_of_the_stack_ADT

I don't see the difference compared to basic imperative programming.

-- 
/Jacob Carlborg

On Thursday, 14 November 2013 at 10:51:31 UTC, Paulo Pinto wrote:
> On Thursday, 14 November 2013 at 10:01:34 UTC, Jacob Carlborg wrote:
>> On 2013-11-14 10:37, Don wrote:
>>
>>> I just can't escape the feeling that class-based runtime polyphorphism
>>> is almost never an ideal solution, and that most of the benefits and
>>> success of OOP languages comes from things other than OOP itself. And I
>>> think it's because OOP is philosophically nonsense -- in the real world,
>>> similarities between things are everywhere, but almost none of them are
>>> is-A relationships.
>>
>> I think the most useful parts of OOP is encapsulation and have the data and methods in the same place.
>
> Actually no different than using ADT (Abstract Data Types) popularized by modular languages like Modula-2, with the added benefit of type extension and polymorphism.
>
> Just because OOP has objects in the name, it doesn't need to be real objects, but concepts actually.
>
> The main problem was that OOP productivity was oversold hype, in the same vein as web 2.0, cloud computing, agile and whatever might come next. People need to sell books and certifications.
>
> And that the early OO design approaches focused too much in implementation inheritance instead of interfaces and delegation.
>
> --
> Paulo

I agree that encapsulation and having logic and data in the same place is a nice feature of OOP. Also, OOP is a tool that helps to create an architecture or an infrastructure like Data-Controller-Components, which is quite useful. However, it happens again and again that a program gets tangled with inter-dependencies. No matter how careful the planning is, as in "this component (class) doesn't need to know anything about XYZ.". Sooner or later there will be a case where this is no longer doable. There are valid solutions like proxies etc. but still it somehow doesn't feel right.

At the moment I'm using a mixture where I use structs and ranges for tasks that can be performed independently, like for example a filter that removes comments from a text file. There is no need to put that behavior into a class. In other words it's a "blind" component, that doesn't need to see anything else but the incoming text. Being "blind", it can be reused out of the box. OOP is still useful for having a central data pool (resources) that can be accessed from anywhere by any component - if needs be - delegating tasks etc.

This said, I sometimes have to implement an initially "blind" component (struct, range) as an internal class to get the references that exist within the class that uses it. This, or pass the data to the component (bah!). Either way, it creates dependencies. I tend to blame myself (bad planning, insufficient understanding of the matter), but I wonder whether it is possible at all to have a reasonably complex program without inter-dependencies of some sort, FP or OOP. Is there, in reality, only a certain amount of really independent components, whereas the bulk of the program is invariably inter-dependent to varying degrees?

On Thursday, 14 November 2013 at 12:23:29 UTC, Jacob Carlborg wrote:
> On 2013-11-14 11:51, Paulo Pinto wrote:
>
>> Actually no different than using ADT (Abstract Data Types) popularized
>> by modular languages like Modula-2, with the added benefit of type
>> extension and polymorphism.
>
> I had a look at this:
>
> http://en.wikipedia.org/wiki/Abstract_data_type#Example:_implementation_of_the_stack_ADT
>
> I don't see the difference compared to basic imperative programming.

But OO is imperative programing at heart.

Picking the stack example you linked to, any ADT type that can provide the stack_T operations can be used on its place.

Hence the added benefit OO offers of separating the ADT concept of a stack, from its concrete implementation. This is the real benefit over plain ADTs.

It has nothing to do with real physical objects, although it was sold like that in the beginning, because it was easier for people to understand it.

--
Paulo

On 11/14/13 1:37 AM, Don wrote:
> I just can't escape the feeling that class-based runtime polyphorphism
> is almost never an ideal solution, and that most of the benefits and
> success of OOP languages comes from things other than OOP itself. And I
> think it's because OOP is philosophically nonsense -- in the real world,
> similarities between things are everywhere, but almost none of them are
> is-A relationships.

Compilers (ours included) are a good example where OOP (with some visitor pizzazz) is a good fit. There are obvious hierarchies (addition is-a expression etc).

Andrei