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 company* (just like C# is) and, second, because it was 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).
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 *by a company* (just like C# is) and, second, because it was 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