www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - =?UTF-8?B?V2hhdOKAmXM=?= Wrong with OOP and FP

reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
I think you will be pleased with the argument, given D's 
philosophy:

     https://yinwang0.wordpress.com/2013/11/09/oop-fp/
Nov 12 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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

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
Nov 12 2013
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
Also, in the spirit of non-technical discussion, pro-D stuff, see 
slide 26: 
http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go
Nov 12 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 12 November 2013 at 11:39:23 UTC, Luís Marques wrote:

 Also, in the spirit of non-technical discussion, pro-D stuff, 
 see slide 26: 
 http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go


Yes, Go has a big PR rolling machine on the web.

Given its spartan set of features and religious decisions, I 
doubt anyone would care, if it wasn't being developed at Google.

On the other hand, more people using strong typed languages with 
GC support as C and C++ replacement, is always positive.

Hopefully D will also have a piece of the pie.

--
Paulo
Nov 12 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
There seem to be a lot of developers who genuinely believe that 
Go increases their productivity, for what it's worth. This thread 
is quite interesting: 
https://groups.google.com/forum/#!topic/golang-nuts/29RsB_nfTYA; 
a developer there finds the productivity benefits from using Go 
sufficient to justify going through the process of converting 
objdump'd c assembly into opcodes written in Plan 9 assembly 
syntax just to use AVX2 instructions (which the Plan 9 assembler 
used by Go doesn't support). Not to mention that they're also 
directly writing assembly themselves, due to the Go compiler's 
lack of intrinsics.

On Tuesday, 12 November 2013 at 12:24:23 UTC, Paulo Pinto wrote:

 On Tuesday, 12 November 2013 at 11:39:23 UTC, Luís Marques 
 wrote:

 Also, in the spirit of non-technical discussion, pro-D stuff, 
 see slide 26: 
 http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go


 Yes, Go has a big PR rolling machine on the web.

 Given its spartan set of features and religious decisions, I 
 doubt anyone would care, if it wasn't being developed at Google.

 On the other hand, more people using strong typed languages 
 with GC support as C and C++ replacement, is always positive.

 Hopefully D will also have a piece of the pie.

 --
 Paulo
Nov 12 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 13 November 2013 at 03:46:17 UTC, logicchains wrote:

 There seem to be a lot of developers who genuinely believe that 
 Go increases their productivity, for what it's worth. This 
 thread is quite interesting: 
 https://groups.google.com/forum/#!topic/golang-nuts/29RsB_nfTYA; 
 a developer there finds the productivity benefits from using Go 
 sufficient to justify going through the process of converting 
 objdump'd c assembly into opcodes written in Plan 9 assembly 
 syntax just to use AVX2 instructions (which the Plan 9 
 assembler used by Go doesn't support). Not to mention that 
 they're also directly writing assembly themselves, due to the 
 Go compiler's lack of intrinsics.

 On Tuesday, 12 November 2013 at 12:24:23 UTC, Paulo Pinto wrote:

 On Tuesday, 12 November 2013 at 11:39:23 UTC, Luís Marques 
 wrote:

 Also, in the spirit of non-technical discussion, pro-D stuff, 
 see slide 26: 
 http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go


 Yes, Go has a big PR rolling machine on the web.

 Given its spartan set of features and religious decisions, I 
 doubt anyone would care, if it wasn't being developed at 
 Google.

 On the other hand, more people using strong typed languages 
 with GC support as C and C++ replacement, is always positive.

 Hopefully D will also have a piece of the pie.

 --
 Paulo





It just shows the kind of distortion field Go developers suffer 
from.
Nov 12 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
To be fair, there is a kind of mental satisfaction that comes 
from being able to hold the language spec in one's head. I've 
used Go about as much as I've used D, and while I understand the 
semantics of Go and its stdlib almost completely, I've probably 
not familiar with even a tenth of the functionality in D (which 
is of course because D has a lot more functionality).


On Wednesday, 13 November 2013 at 07:23:40 UTC, Paulo Pinto wrote:

 It just shows the kind of distortion field Go developers suffer 
 from.
Nov 12 2013
parent reply "Froglegs" <barf barf.com> writes:
  Go is a boring language, kind of like Dart, I guess Google just 
sucks at language design? The do use an awful lot of Java, 
perhaps it has caused irreparable damage
Nov 12 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:

  Go is a boring language, kind of like Dart, I guess Google 
 just sucks at language design? The do use an awful lot of Java, 
 perhaps it has caused irreparable damage


If you were working in an Enterprise (TM) with coworkers who were 
potentially competence-challenged, would you want them having 
access to the power of D's compile time code generation? Would 
you like to read and debug code that randomly intermingled D's 
different function call methods; having to determine whether 
foo.bar represents calling the bar method of foo, calling the 
function bar with foo as an argument, or accessing the field bar 
on object foo?
Nov 13 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:

 Go is a boring language, kind of like Dart, I guess Google 
 just sucks at language design? The do use an awful lot of 
 Java, perhaps it has caused irreparable damage


 If you were working in an Enterprise (TM) with coworkers who 
 were potentially competence-challenged, would you want them 
 having access to the power of D's compile time code generation? 
 Would you like to read and debug code that randomly 
 intermingled D's different function call methods; having to 
 determine whether foo.bar represents calling the bar method of 
 foo, calling the function bar with foo as an argument, or 
 accessing the field bar on object foo?


Speaking from my enterprise seat, there are lots of "potentially 
competence-challenged coworkers" in off-shore projects.

Maybe Google's target audience?

--
Paulo
Nov 13 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 13, 2013 09:51:33 Paulo Pinto wrote:

 On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:

 Go is a boring language, kind of like Dart, I guess Google
 just sucks at language design? The do use an awful lot of
 Java, perhaps it has caused irreparable damage


 
 If you were working in an Enterprise (TM) with coworkers who
 were potentially competence-challenged, would you want them
 having access to the power of D's compile time code generation?
 Would you like to read and debug code that randomly
 intermingled D's different function call methods; having to
 determine whether foo.bar represents calling the bar method of
 foo, calling the function bar with foo as an argument, or
 accessing the field bar on object foo?


 
 Speaking from my enterprise seat, there are lots of "potentially
 competence-challenged coworkers" in off-shore projects.
 
 Maybe Google's target audience?


This conversation definitely seems to be taking a turn for the worse. Go was 
created by folks who believe in its goals and paradigms and believed that they 
could better serve those by creating a new language than by using existing 
ones. As I understand it, it was completely an engineering-driven solution and 
not business-driven at all. Google really had very little to do with its 
creation. It's just that the engineers who created it happened to be working 
at Google. And while we may not like the direction that Go went in, that 
doesn't mean that it's worthless or primarily intended to prevent bad 
programmers from fouling things up. Clearly, it does a good enough job that 
many programmers have taken a liking to it and written good, useful programs 
in it.

Personally, I have no interest in it and think that its designers made some 
very poor choices, but that doesn't mean that we should be making fun of it or 
make fun of Google for being the place where the engineers who created it 
work. The fact that Google let its engineers spend company time on creating a 
new programming langueg says very good things about Google, even if the 
language itself ultimately isn't what we'd like.

- Jonathan M Davis
Nov 13 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M Davis 
wrote:

 On Wednesday, November 13, 2013 09:51:33 Paulo Pinto wrote:

 On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains 
 wrote:

 On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs 
 wrote:

 Go is a boring language, kind of like Dart, I guess Google
 just sucks at language design? The do use an awful lot of
 Java, perhaps it has caused irreparable damage


 
 If you were working in an Enterprise (TM) with coworkers who
 were potentially competence-challenged, would you want them
 having access to the power of D's compile time code 
 generation?
 Would you like to read and debug code that randomly
 intermingled D's different function call methods; having to
 determine whether foo.bar represents calling the bar method 
 of
 foo, calling the function bar with foo as an argument, or
 accessing the field bar on object foo?


 
 Speaking from my enterprise seat, there are lots of 
 "potentially
 competence-challenged coworkers" in off-shore projects.
 
 Maybe Google's target audience?


 This conversation definitely seems to be taking a turn for the 
 worse. Go was
 created by folks who believe in its goals and paradigms and 
 believed that they
 could better serve those by creating a new language than by 
 using existing
 ones. As I understand it, it was completely an 
 engineering-driven solution and
 not business-driven at all. Google really had very little to do 
 with its
 creation. It's just that the engineers who created it happened 
 to be working
 at Google. And while we may not like the direction that Go went 
 in, that
 doesn't mean that it's worthless or primarily intended to 
 prevent bad
 programmers from fouling things up. Clearly, it does a good 
 enough job that
 many programmers have taken a liking to it and written good, 
 useful programs
 in it.

 Personally, I have no interest in it and think that its 
 designers made some
 very poor choices, but that doesn't mean that we should be 
 making fun of it or
 make fun of Google for being the place where the engineers who 
 created it
 work. The fact that Google let its engineers spend company time 
 on creating a
 new programming langueg says very good things about Google, 
 even if the
 language itself ultimately isn't what we'd like.

 - Jonathan M Davis


Point taken. I should have thought better before posting. Just 
got carried away due to some of our project's status.

Sorry about that and my excuses to anyone that felt bad with my 
remark.

Despite my critic, I do see lots of use cases where Go might be 
useful and would happily used it over C, although D would be even 
better. :)

No more replies from me on this thread.

..
Paulo
Nov 13 2013
prev sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M Davis 
wrote:

 Personally, I have no interest in it and think that its 
 designers made some
 very poor choices, but that doesn't mean that we should be 
 making fun of it or
 make fun of Google for being the place where the engineers who 
 created it
 work. The fact that Google let its engineers spend company time 
 on creating a
 new programming langueg says very good things about Google, 
 even if the
 language itself ultimately isn't what we'd like.

 - Jonathan M Davis


For the record, I wasn't making fun of Go when I spoke of its 
readability being a particular virtue. If I was managing a large 
project with programmers of divergent ability then I might well 
pick it for that reason alone. The design choices might seem poor 
from the perspective of someone looking for a language that gives 
them lots of power, but if you look at it from the perspective of 
a language designed to minimise the power of co-workers (and 
anybody else) to write difficult-to-understand code, it's 
designed magnificently.

An example of this is how, in order to avoid ambiguity, both 
automatic dereferencing and the -> operator from C were omitted 
from the language. This means that if pt is a pointer to a 
struct, then I have to write (*pt).X to access field X of that 
struct, as opposed to pt.X in D or pt->X in C, making it 
completely clear to anybody glancing at the code that pt is a 
pointer.
Nov 13 2013
parent reply "eles" <eles eles.com> writes:
On Wednesday, 13 November 2013 at 10:19:34 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M 
 Davis wrote:



 struct, then I have to write (*pt).X to access field X of that


It is in our guidelines too. I almost never write "->".
Nov 13 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:

 On Wednesday, 13 November 2013 at 10:19:34 UTC, logicchains 
 wrote:

 On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M 
 Davis wrote:



 struct, then I have to write (*pt).X to access field X of that


 It is in our guidelines too. I almost never write "->".


Ah, right. I just tested, and turns out Go does actually 
automatically dereference pointers to structs, but not to arrays. 
So if arrp is a pointer to an array, writing arrp[0] is a syntax 
error in Go, and it must be written as (*arrp)[0]. D on the other 
hand, as far as I'm aware (correct me if I'm wrong), would 
automatically dereference the pointer.
Nov 13 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 13 November 2013 at 12:05:51 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:

 On Wednesday, 13 November 2013 at 10:19:34 UTC, logicchains 
 wrote:

 On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M 
 Davis wrote:



 struct, then I have to write (*pt).X to access field X of that


 It is in our guidelines too. I almost never write "->".


 Ah, right. I just tested, and turns out Go does actually 
 automatically dereference pointers to structs, but not to 
 arrays. So if arrp is a pointer to an array, writing arrp[0] is 
 a syntax error in Go, and it must be written as (*arrp)[0]. D 
 on the other hand, as far as I'm aware (correct me if I'm 
 wrong), would automatically dereference the pointer.


nope. a pointer can be indexed like in C. ptr[n] is equivalent to 
*(ptr + n) irrespective of what the target type of the pointer 
is. Fully expanded for T* ptr  : *(cast(T*)( (cast(void*)ptr) + 
(T.sizeof * n) ))
Nov 13 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/13/13 4:05 AM, logicchains wrote:

 On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:

 On Wednesday, 13 November 2013 at 10:19:34 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M Davis wrote:



 struct, then I have to write (*pt).X to access field X of that


 It is in our guidelines too. I almost never write "->".


 Ah, right. I just tested, and turns out Go does actually automatically
 dereference pointers to structs, but not to arrays. So if arrp is a
 pointer to an array, writing arrp[0] is a syntax error in Go, and it
 must be written as (*arrp)[0]. D on the other hand, as far as I'm aware
 (correct me if I'm wrong), would automatically dereference the pointer.


If the purpose was to make it clear dereference is happening (presumably 
to have people understand the efficiency issues associated), I wonder 
why they didn't make memory allocation or indirect calls (both of which 
abound in Go) more visible. Was there some other intent behind (*pt).X?

Andrei
Nov 13 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Wednesday, 13 November 2013 at 16:12:01 UTC, Andrei 
Alexandrescu wrote:

 If the purpose was to make it clear dereference is happening 
 (presumably to have people understand the efficiency issues 
 associated), I wonder why they didn't make memory allocation or 
 indirect calls (both of which abound in Go) more visible. Was 
 there some other intent behind (*pt).X?

 Andrei


Looking through the Go spec, it seems I was confused. A pointer 
to a struct can be used with just pt.X, and a pointer to an array 
*arrp can be used with just arrp[0], but a pointer to a _slice_ 
*slcp can only be used with (*slcp)[0], not slcp[0]. I have no 
idea why this is.
Nov 13 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 14 November 2013 at 02:37:52 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 16:12:01 UTC, Andrei 
 Alexandrescu wrote:

 If the purpose was to make it clear dereference is happening 
 (presumably to have people understand the efficiency issues 
 associated), I wonder why they didn't make memory allocation 
 or indirect calls (both of which abound in Go) more visible. 
 Was there some other intent behind (*pt).X?

 Andrei


 Looking through the Go spec, it seems I was confused. A pointer 
 to a struct can be used with just pt.X, and a pointer to an 
 array *arrp can be used with just arrp[0], but a pointer to a 
 _slice_ *slcp can only be used with (*slcp)[0], not slcp[0]. I 
 have no idea why this is.


Because slices are always references, so you have a double 
indirection.
Nov 13 2013
next sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
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.
Nov 14 2013
prev sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
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.
Nov 14 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 13 November 2013 at 12:05:51 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:

 On Wednesday, 13 November 2013 at 10:19:34 UTC, logicchains 
 wrote:

 On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M 
 Davis wrote:



 struct, then I have to write (*pt).X to access field X of that


 It is in our guidelines too. I almost never write "->".


 Ah, right. I just tested, and turns out Go does actually 
 automatically dereference pointers to structs, but not to 
 arrays. So if arrp is a pointer to an array, writing arrp[0] is 
 a syntax error in Go, and it must be written as (*arrp)[0]. D 
 on the other hand, as far as I'm aware (correct me if I'm 
 wrong), would automatically dereference the pointer.


I don't think so. D would index the pointer (as if it pointer to 
an array of slices).
Nov 13 2013
prev sibling parent "eles" <eles eles.com> writes:
On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:

 On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:



 If you were working in an Enterprise (TM) with coworkers who 
 were potentially competence-challenged, would you want them 
 having access to the power of D's compile time code generation? 
 Would you like to read and debug code that randomly 
 intermingled D's different function call methods; having to 
 determine whether foo.bar represents calling the bar method of 
 foo, calling the function bar with foo as an argument, or 
 accessing the field bar on object foo?


Unfortunately, yes, you did hit a nail here. I don't really like 
this way of "calling" functions. If they were only properties, 
OK, but for general functions...

I dunno if it is implemented, but I recall Walter beign quite 
supportive of accepting that:

foo.bar;

is a function call...

A lot of confusion stems from the fact that properties are seen 
more like functions than variables (in the D community). I feel 
it should be the other way around.

Or, simply, get rid of properties completely until better ideas 
come.
Nov 13 2013
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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?


 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
Nov 12 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 What I miss still in languages like D, is the Hindley–Milner 
 type inference, algebraic data types and pattern matching.


Global type inference is too much complex in D, because of 
Turing-complete templates, OOP, very weak interfaces between 
modules in presence of separate compilation, etc, so it can't be 
done or it will become too much hard/complex/slow to do, so it's 
better to forget about it. Also, even in Haskell it's a good 
practice to write down the type signature of all global functions.

The algebraic data types are handy, and Algebraic should improve 
(and if needed some feature should be added to D to make 
Algebraic better!).

Regarding pattern matching, it introduces a significant 
complexity, but a limited form of it could be a good idea for D, 
with improvements in the switch and introducing an optional 
standard method unapply for structs and classes:
https://d.puremagic.com/issues/show_bug.cgi?id=596

Bye,
bearophile
Nov 12 2013
prev sibling parent reply "Don" <x nospam.com> writes:
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
Nov 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 14 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Nov 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 14 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Nov 14 2013
prev sibling parent "Chris" <wendlec tcd.ie> writes:
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?
Nov 14 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 14 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Luís Marques:


     https://yinwang0.wordpress.com/2013/11/09/oop-fp/



 From the article:


 but you can also write pure functions in C, for example:
 
 int f(int x) {
     int y = 0;
     int z = 0;
     y = 2 * x;
     z = y + 1;
     return z / 3;
 }
 
 You can do the same with assembly language too. Pure functions
 don’t just belong to purely functional languages. You can write
 pure functions in any language, but the important thing is, you
 should be allowed to use side-effects too.


Do you want to inform that author about the purity in D? :-)

Bye,
bearophile
Nov 12 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/12/2013 04:20 AM, bearophile wrote:


 Do you want to inform that author about the purity in D? :-)


The author claims to have done programming language research. So, I 
guess he knows about D. (Come to think of it, people who created the Go 
language supposedly had such research as well but they did not (!) know 
about D. ;) )

I am surprised that the Reddit thread has not mentioned D yet:

 
http://www.reddit.com/r/programming/comments/1qg5x8/whats_wrong_with_oop_and_fp/

Ali
Nov 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ali Çehreli:


 The author claims to have done programming language research. 
 So, I guess he knows about D.


 From what I am seeing in the last years in the good Lambda the 
Ultimate Blog, most people doing programming language research 
know everything about monads and zippers, but ignore D :-)

Bye,
bearophile
Nov 12 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile wrote:

 Ali Çehreli:


 The author claims to have done programming language research. 
 So, I guess he knows about D.


 From what I am seeing in the last years in the good Lambda the 
 Ultimate Blog, most people doing programming language research 
 know everything about monads and zippers, but ignore D :-)

 Bye,
 bearophile


Sometimes I have feeling language researchers live in some 
strange imaginary world and never actually check how their ideas 
work in production code.
Nov 12 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 12 November 2013 at 15:35:48 UTC, Dicebot wrote:

 On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile wrote:

 Ali Çehreli:


 Sometimes I have feeling language researchers live in some 
 strange imaginary world and never actually check how their


Lambda the Ultimate and Javaland.
Nov 12 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 12.11.2013 17:10, schrieb eles:

 On Tuesday, 12 November 2013 at 15:35:48 UTC, Dicebot wrote:

 On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile wrote:

 Ali Çehreli:


 Sometimes I have feeling language researchers live in some strange
 imaginary world and never actually check how their


 Lambda the Ultimate and Javaland.


Well, in defence of Javaland, it is a consequence how easy it is for 
enterprise architects to try out their crazy ideas in Java.

Except for a few years at CERN, I always worked in enterprise land, so
I have seen FactoryFactoryAbstractThingy being done in:

- C based platform which used its own concept of pointers, requiring 
conversions between framework pointers and C pointers

- A Frankenstein framework done in CORBA with a healthy mix of C++ and 
Perl code

- A Perl framework for generating code for control of telecommunication 
networks with a thousands plugins, which affected the way the whole code
generation was done, requiring multiple passes

- A transformation engine done in XML/XSLT (yes really!) with a 
JavaScript API being called from a Java driver application

- A framework done on top of J2EE, as if J2EE wasn't enough

Better stop here. :)

--
Paulo
Nov 12 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 12 November 2013 at 17:59:50 UTC, Paulo Pinto wrote:

 Am 12.11.2013 17:10, schrieb eles:

 On Tuesday, 12 November 2013 at 15:35:48 UTC, Dicebot wrote:

 On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile 
 wrote:

 Ali Çehreli:


 Sometimes I have feeling language researchers live in some 
 strange
 imaginary world and never actually check how their


 Lambda the Ultimate and Javaland.


 Well, in defence of Javaland, it is a consequence how easy it


I hesitated to add Javaland to the list, exactly because of that. 
I believe it was successful because, first, was designed *by a 

like C++ but with increased verbosity (and that means less 
cryptic and easier to follow a diff).

I am not the first to consider that Java's verbosity is a good 
thing for a company. But, I confirm that: in my day-to-day job, 
we use C (and some C++). You would be amazed how much our 
guidelines lead us towards increased verbosity (names, 
annotations/comments, declarations).
Nov 12 2013
parent "JN" <666total wp.pl> writes:
On Wednesday, 13 November 2013 at 02:54:05 UTC, eles wrote:

 On Tuesday, 12 November 2013 at 17:59:50 UTC, Paulo Pinto wrote:

 Am 12.11.2013 17:10, schrieb eles:

 On Tuesday, 12 November 2013 at 15:35:48 UTC, Dicebot wrote:

 On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile 
 wrote:

 Ali Çehreli:


 Sometimes I have feeling language researchers live in some 
 strange
 imaginary world and never actually check how their


 Lambda the Ultimate and Javaland.


 Well, in defence of Javaland, it is a consequence how easy it


 I hesitated to add Javaland to the list, exactly because of 
 that. I believe it was successful because, first, was designed 

 mostly like C++ but with increased verbosity (and that means 
 less cryptic and easier to follow a diff).

 I am not the first to consider that Java's verbosity is a good 
 thing for a company. But, I confirm that: in my day-to-day job, 
 we use C (and some C++). You would be amazed how much our 
 guidelines lead us towards increased verbosity (names, 
 annotations/comments, declarations).


Java is popular because it's a general purpose language and an
alternative to c++ with following advantages:

- much better IDE support
- OOP by default, all libraries and frameworks follow it
- rich standard library, so that everyone uses java.lang.String
and it's over, while C/C++ libs still try to reinvent their own
string classes (which often have completely different
interfaces), XML, HTTP etc. built-in to the language
- easy to learn, easy to write (no .h/.cpp madness, no cryptic
template errors, no 10 ways to initialize a variable)
- good performance, slightly behind C/C++ in most cases, way
ahead of Python/Ruby/etc.
- mature GUI frameworks with great RAD tools

and many more.
Nov 13 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 12 November 2013 at 17:59:50 UTC, Paulo Pinto wrote:

 Am 12.11.2013 17:10, schrieb eles:

 On Tuesday, 12 November 2013 at 15:35:48 UTC, Dicebot wrote:

 On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile 
 wrote:

 Ali Çehreli:









 - C based platform which used its own concept of pointers, 
 requiring conversions between framework pointers and C pointers


Encountered that too. Nobody ever tried to re-factor afterwards. 
We ended up rewriting everything from scratch.
Nov 12 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-12 18:59, Paulo Pinto wrote:


 - A framework done on top of J2EE, as if J2EE wasn't enough


There's always a framework to put on top of another :)

-- 
/Jacob Carlborg
Nov 12 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/12/13 12:35 PM, Dicebot wrote:

 On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile wrote:

 Ali Çehreli:


 The author claims to have done programming language research. So, I
 guess he knows about D.


 From what I am seeing in the last years in the good Lambda the
 Ultimate Blog, most people doing programming language research know
 everything about monads and zippers, but ignore D :-)

 Bye,
 bearophile


 Sometimes I have feeling language researchers live in some strange
 imaginary world and never actually check how their ideas work in
 production code.


It isn't just a feeling :)
Nov 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 It isn't just a feeling :)


Researchers are mostly judged and paid (and career advancements 
are mostly based) on the amount and "impact" of papers written. 
It's uncommon for "how ideas work in production code" to have a 
positive influence on career. To this you have to add the fact 
that if they pay you to study and invent new ideas, and you want 
to have fun inventing them, you will go look where are the cutest 
puzzles to solve (like very complex functional tricks).

This is causing a bad and costly disconnect between practice and 
research in computer science and coding, and this is hurting our 
society. Even researchers in the private sector like at Microsoft 
are plagued with a very low ROI because of that.

To solve this problem there is a growing need to tie the career 
advancements and pay of computer science researchers to the 
solution of practical problems. I love free basic research, but 
here there is a growing problem in need to be solved, for the 
society.

The situation is improving only a little, but this far from 
enough:
http://wattsupwiththat.com/2012/04/17/the-journal-science-free-the-code/

Bye,
bearophile
Nov 12 2013
parent "Froglegs" <barf barf.com> writes:
  bearophile how much do you love haskell
Nov 12 2013
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:

 I think you will be pleased with the argument, given D's 
 philosophy:

     https://yinwang0.wordpress.com/2013/11/09/oop-fp/


Before learning D I was using Groovy as main language. At this 
point I had fullen in love with the three big paradigms 
functional, oop and proceduel. Neither true versions but nether 
the less loved it. When it came to wanting efficiency and 
exploring new ideas I even considered my own language.

Since Groovy I actually dont use much functional but still very 
useful.
This is why I no longer understand reasoning behind any one 
paradigm. A great example of why I hate pure oop is singletons. 
To me they are just a hack for procedural style. One that also 
confuses new developers.

These are just some reasons behind my love for D. And why I 
believe it is an appropriate first language.
Nov 12 2013
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:

 I think you will be pleased with the argument, given D's 
 philosophy:

     https://yinwang0.wordpress.com/2013/11/09/oop-fp/


Yep, 100% agree. We should use both, and think ahead whether to 
take first or the second approach to solve the problem at hand.

Regarding Java rumbling about nouns and verbs... I think in the 
long run it is a better practice to name your class/method in a 
way that helps developers understand what it does. Yes, some 
people write long names, but that most often comes from their 
company/team coding style. Nothing wrong with that really, and it 
is not just Java community that does this... (first that comes to 
mind: thread_stackTop() )
Nov 13 2013
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:

 I think you will be pleased with the argument, given D's 
 philosophy:

     https://yinwang0.wordpress.com/2013/11/09/oop-fp/


“functions are also objects”. Yes, they are. 
http://en.wikipedia.org/wiki/Category_theory
Nov 13 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:

 I think you will be pleased with the argument, given D's 
 philosophy:

     https://yinwang0.wordpress.com/2013/11/09/oop-fp/


The thing I don't like with many such "pure paradigm" languages 
is not actually the fact that they stick to a single approach and 
harm the toolset. It is the fact that they define set of 
abstractions and then try to tie those to existing computer 
hardware. With modern insanely clever optimizing compilers it may 
even work performance-wise but it harms learning curve in least 
pleasant way. If language is built as bottom-up abstraction, it 
is relatively trivial to learn for someone familiar with assembly 
level. Any such language. If it is built top-down from imaginary 
abstraction set, it is always a completely new thing every time 
and you often have no idea what certain concept actually means 
(like, is "function" here really a function or some obscure 
wrapper that emulates it?)

I would favor pure FP languages much more if computers would have 
existed that operated in similar matter on hardware level but it 
does not seem like a real thing to happen ;)
Nov 13 2013