View mode: basic / threaded / horizontal-split · Log in · Help
February 15, 2012
Re: Anti-OOP... stupid?
On Tuesday, 14 February 2012 at 22:45:28 UTC, H. S. Teoh wrote:
> On Tue, Feb 14, 2012 at 11:00:43PM +0100, Zero wrote:
>> Hello!
>> 
>> I've recently started to work with D, and I'll start a "bigger"
>> project soon, using it. For a few days I've been thinking 
>> about the
>> approach I'll take here, and since I don't /have/ to use full 
>> OOP in
>> D, I was wondering... how crazy is it to not use full OP 
>> nowadays?
>
> I do that all the time. I guess that makes me crazy. :)
>
>
> [...]
>> What I want to know from you people... is that stupid? To even 
>> think
>> about doing something like this? Basically mixing procedural 
>> and OOP?
>
> D allows you to program in functional style, OOP, procedural 
> style, or
> any combination of them. There is a reason D was designed this 
> way. :)
>
>
>> I know about the dangers, and disadvantages, but if those 
>> don't scare
>> one away, would you consider it bad, if someone did this, on a 
>> larger
>> project?
> [...]
>
> OOP has its own share of dangers and disadvantages. Which, 
> sadly, most
> people don't talk about very much because they don't have the 
> guts to go
> against the current cool trendy bandwagon that everyone's 
> jumping on.
>
> Templates, for one thing, don't fit very well into the OO 
> paradigm (ever
> tried a virtual template function?), even though you *can* use 
> it to
> enhance an OO-based design. And D's templates are one of the 
> best things
> about D, ever.
>
> Of course, many aspects of OO does help with large projects, so 
> it's
> usually a good idea to take advantage of that. But that doesn't 
> mean you
> *have* to use OO, or that it's "bad" to mix in procedural stuff 
> when it
> suits you.
>
> I mean, if you take OO to the extreme, that would require 
> excluding all
> those evil procedural constructs like if statements and for 
> loops, and
> write everything in terms of invoking object methods...  like 
> this
> monstrosity:
>
> class MyClass {
> 	void myMethod() {
> 		IntVariable i;
> 		ForLoopFactory.create(
> 			new IntSetter(i.address(), new Number(0)),
> 			new BooleanCondition(
> 				new LessThanComparator(i.address(),
> 					100)),
> 			new IntAdder(&i, 1),
> 			new IfStatement(
> 				new EqualComparator(i.address(),
> 					new Number(42)),
> 				new FunctionCaller(writeln.address(),
> 					new String("Found it!")),
> 			)
> 		).execute();
> 	}
> }
>
> which is, of course, completely ridiculous.
>
> The bottom line is, use whatever tools work best for what you 
> need to
> do. If OO works well, use it. If procedural code works well, 
> that use
> it. If both works well in different cases, then use a mix of 
> both
> depending on the circumstances.
>
> Trying to shoehorn everything into an object is stupid.
>
>
> T

I agree with the general sentiment to have a large toolbox and 
using the right tool for the job be it functional, OOP, etc.. 
having said that, I have to strongly disagree with both claims 
above.

1. D templates are an enhanced version of C++ templates which are 
a poor design. The problem stems IMO not from issues with OOP but 
rather with the horrible idea of C++-like templates. Other 
languages have *much* better solutions which integrate better.

2. The above horrible example completely misrepresents OOP. The 
"correct" way to truly do control flow in OOP is a-la smalltalk:

class My class {
 void myMethod() {
     ...
     100.times({ ... }); // for-loop
     (myVar > 42).ifTrue({ ... }); // if statement
     (myVar < 100).if({.. code if true ...}, {... code if false 
...});  //  if statement with else clause
     ...
  }
}

etc.. incidentally, Smalltalk uses selectors (Objective-C is 
basically fugly smalltalk..) : (expression) ifTrue: [ ^42 ] 
ifFalse: [ ^24 ] the above returns 42 if true and 24 otherwise.
February 15, 2012
Re: Anti-OOP... stupid?
Many reasons why non-OOP methodology creates problems come from how 
scoping works in a language.  In C, there's one global name-space, so 
declaring functions anywhere can lead to major problems:  unexpected 
dependencies, unclear sequence of execution, aberrant mutations, name-space 
conflicts, etc.

However in D, much like Python, true modules are supported by the 
language.  There is no "global" scope the programmer has access to, only 
the module scope which matches file scope.  This solves the name-space 
problem.

Other than that, make sure your module level functions and values only 
depend on other modules in a predictable fashion, do only a small set of 
mostly self-contained things, and are well documented.

Also remember that module-level variables have thread scope, so by 
default, each thread will have its own copy.

 - Vijay

On Tue, 14 Feb 2012, Zero wrote:

> Hello!
>
> I've recently started to work with D, and I'll start a "bigger" project soon, 
> using it. For a few days I've been thinking about the approach I'll take 
> here, and since I don't /have/ to use full OOP in D, I was wondering... how 
> crazy is it to not use full OP nowadays?
>
> Naturally one would use objects, but since this isn't C#, or Java, not 
> freaking everything has to be an object. The C style kinda feels more natural 
> to me. (I know, I know, C naturally can do some OOP like stuff, etc... but 
> you get the idea, mainly normal functions, some globals, yada, yada.)
>
> What I want to know from you people... is that stupid? To even think about 
> doing something like this? Basically mixing procedural and OOP? I know about 
> the dangers, and disadvantages, but if those don't scare one away, would you 
> consider it bad, if someone did this, on a larger project?
>
> I'm looking forward to your answers.
>
> Zero
>
February 15, 2012
Re: Anti-OOP... stupid?
foobar:

> 1. D templates are an enhanced version of C++ templates which are 
> a poor design. The problem stems IMO not from issues with OOP but 
> rather with the horrible idea of C++-like templates. Other 
> languages have *much* better solutions which integrate better.

C++ is one of the most commonly used languages, probably there are billions of lines of C++ in use, and C++ library code uses templates often, so despite the well known flaws of C++ templates (bloat, bad error messages, etc), they are somehow "good enough", they aren't horrible.

Compared to C++, D templates introduce constraints, a better syntax, and more uniform/sane semantics of details. Bjarne Stroustrup is still trying to invent simplified Concepts to improve C++ templates, to give them "static" types.

Java generics, C# generics, Ada generic programming, C++ templates, ML polymorphism, Haskell type inference with type classes, Haskell template extensions, are designed to satisfy different needs and constraints. All of them are used and useful, none of them are perfect.

Bye,
bearophile
February 15, 2012
Re: Anti-OOP... stupid?
On 02/15/2012 03:30 PM, foobar wrote:
> ...
> 1. D templates are an enhanced version of C++ templates which are a poor
> design. The problem stems IMO not from issues with OOP but rather with
> the horrible idea of C++-like templates. Other languages have *much*
> better solutions which integrate better.
>
> [snip.]

Please elaborate. What kind of construct in a language that supports OO 
solves the same set of problems D templates do and is unequivocally a 
better design?
February 15, 2012
Re: Anti-OOP... stupid?
On Wednesday, 15 February 2012 at 15:35:37 UTC, bearophile wrote:
> foobar:
>
>> 1. D templates are an enhanced version of C++ templates which 
>> are a poor design. The problem stems IMO not from issues with 
>> OOP but rather with the horrible idea of C++-like templates. 
>> Other languages have *much* better solutions which integrate 
>> better.
>
> C++ is one of the most commonly used languages, probably there 
> are billions of lines of C++ in use, and C++ library code uses 
> templates often, so despite the well known flaws of C++ 
> templates (bloat, bad error messages, etc), they are somehow 
> "good enough", they aren't horrible.
>
> Compared to C++, D templates introduce constraints, a better 
> syntax, and more uniform/sane semantics of details. Bjarne 
> Stroustrup is still trying to invent simplified Concepts to 
> improve C++ templates, to give them "static" types.
>
> Java generics, C# generics, Ada generic programming, C++ 
> templates, ML polymorphism, Haskell type inference with type 
> classes, Haskell template extensions, are designed to satisfy 
> different needs and constraints. All of them are used and 
> useful, none of them are perfect.
>
> Bye,
> bearophile

I beg to differ. I was talking about the *design* aspect of 
templates and you seem to agree that it is flawed. the design 
*is* horrible and can be compared to other better designs. The 
fact that it is used in so much software is a completely 
orthogonal matter. Most people use qwerty keyboards (including 
me) but that does not mean it's the superior design. on the 
contrary, it was *intentionally* designed to be flawed for 
historical reasons that are no longer relevant. what is "good 
enough"? it is highly subjective. Is it enough to be commonly 
used by many people? what other criteria would be required to 
classify as good enough and not worth improvement? should we 
never strive to achieve better designs?

I don't know Haskell and won't comment on the above mentioned 
features but regarding generics (e.g in C#) - they have no 
conflicts with OOP and are a good feature.
February 15, 2012
Re: Anti-OOP... stupid?
On Wednesday, 15 February 2012 at 15:35:53 UTC, Timon Gehr wrote:
> On 02/15/2012 03:30 PM, foobar wrote:
>> ...
>> 1. D templates are an enhanced version of C++ templates which 
>> are a poor
>> design. The problem stems IMO not from issues with OOP but 
>> rather with
>> the horrible idea of C++-like templates. Other languages have 
>> *much*
>> better solutions which integrate better.
>>
>> [snip.]
>
> Please elaborate. What kind of construct in a language that 
> supports OO solves the same set of problems D templates do and 
> is unequivocally a better design?

Lisp/scheme macros come to mind :) There are no issues AFAIK 
integrating those with OOP, in fact the OOP features are 
implemented with macros (CLOS).
February 15, 2012
Re: Anti-OOP... stupid?
On 02/15/2012 09:17 PM, foobar wrote:
> On Wednesday, 15 February 2012 at 15:35:53 UTC, Timon Gehr wrote:
>> On 02/15/2012 03:30 PM, foobar wrote:
>>> ...
>>> 1. D templates are an enhanced version of C++ templates which are a poor
>>> design. The problem stems IMO not from issues with OOP but rather with
>>> the horrible idea of C++-like templates. Other languages have *much*
>>> better solutions which integrate better.
>>>
>>> [snip.]
>>
>> Please elaborate. What kind of construct in a language that supports
>> OO solves the same set of problems D templates do and is unequivocally
>> a better design?
>
> Lisp/scheme macros come to mind :)

=D. I actually thought about explicitly excluding those to get a more 
meaningful answer. Using runtime code modification is cheating.

There are certainly ways to dynamically dispatch, expand and execute a 
macro in lisp. If every D program was allowed to include a complete D 
compiler, virtual template functions would work too. Can you point me to 
an implementation in lisp that does this and is actually fast enough to 
be considered for real work?

> There are no issues AFAIK integrating
> those with OOP, in fact the OOP features are implemented with macros
> (CLOS).

You can use templates to implement a multiple-dispatch virtual function 
system just fine. We are not talking about implementing OOP using 
templates, but about using templated virtual methods.

Anyway, I don't see your point yet: You seem to think templates are 
poorly designed because dynamic languages such as lisp are more flexible 
than static languages such as D?
February 15, 2012
Re: Anti-OOP... stupid?
On Wednesday, 15 February 2012 at 20:55:47 UTC, Timon Gehr wrote:
<snip>
>> Lisp/scheme macros come to mind :)
>
> =D. I actually thought about explicitly excluding those to get 
> a more meaningful answer. Using runtime code modification is 
> cheating.
>
> There are certainly ways to dynamically dispatch, expand and 
> execute a macro in lisp. If every D program was allowed to 
> include a complete D compiler, virtual template functions would 
> work too. Can you point me to an implementation in lisp that 
> does this and is actually fast enough to be considered for real 
> work?
>
>> There are no issues AFAIK integrating
>> those with OOP, in fact the OOP features are implemented with 
>> macros
>> (CLOS).
>
> You can use templates to implement a multiple-dispatch virtual 
> function system just fine. We are not talking about 
> implementing OOP using templates, but about using templated 
> virtual methods.
>
> Anyway, I don't see your point yet: You seem to think templates 
> are poorly designed because dynamic languages such as lisp are 
> more flexible than static languages such as D?

I'm no lisp expert and as such Google would be better than me to 
point to specific implementations and such :)

regarding run-time modification of code - as I said, i'm no lisp 
expert but I did hear about lisp AOT compilers so it should be a 
matter of implementation. Another example which I'm more familiar 
with is Nemerle macros which are closely related to Lisp macros 
and follow similar design principles. In fact Nemerle macros are 
separately compiled plugins for the compiler which can manipulate 
the AST directly.

Regarding templated virtual methods - take a look at:
http://nemerle.org/wiki/index.php?title=Design_patterns
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home