> ∃ i ∈ S: ∀ x ∈ S, i # x = x # i = x.
> ∀ x ∈ S, ∃ y ∈ S: x # y = y # x = i.

Not that I wish to imply, in any way, that I'm bored or that my 
intellectual capabilities are not being fully utilised by my day job OR 
ANYTHING LIKE THAT... >_>

Post a reply to this message

Am 23.04.2012 11:37, schrieb Invisible:
>>>> There are lots of languages that let you can pass a function as an
>>>> argument.
>>>
>>> Heh. I bet most of them are scripting languages though. :-P
>>
>> Meh. Even good old Turbo Pascal had function pointers.
>
> O RLY?
>
> Because, I was actually *looking* for that feature, and couldn't find
> it. It would have been quite helpful...

Might depend on the version; I know it was there in 6.0, because that's 
the one I used when I invented polymorphism (without the use of the OOP 
language extensions; I didn't have the faintest idea what OOP was all 
about, let alone that I was already using one of its core concepts).

Post a reply to this message

Am 23.04.2012 12:19, schrieb Invisible:
> OK, so "magma" consists of a set S and a binary operator #. The #
> operator takes any two elements of S (including the possibility of two
> copies of the same element), and yields a new element of S (possibly the
> same one you started with).

And here I was thinking that magma consisted of molten minerals...

Post a reply to this message

>>> Meh. Even good old Turbo Pascal had function pointers.
>>
>> O RLY?
>>
>> Because, I was actually *looking* for that feature, and couldn't find
>> it. It would have been quite helpful...
>
> Might depend on the version; I know it was there in 6.0,

I only used 5.5

> because that's
> the one I used when I invented polymorphism (without the use of the OOP
> language extensions; I didn't have the faintest idea what OOP was all
> about, let alone that I was already using one of its core concepts).

Yeah, that's what I was trying to do too. ;-)

I love how 5.5 added "OOP", which consisted of letting you use the 
keyword "class" instead of "record", and letting you write your function 
code inside a class instead of outside it. I spent ages trying to figure 
out what advantage that gives you. And of course... IT DOESN'T. It's no 
different. In particular, IT'S NOT OOP.

It would have /actually/ been OO if it had let you make fields private, 
or if it supported dynamic binding. But noooo... :-P

Post a reply to this message

On 23/04/2012 02:41 PM, clipka wrote:
> Am 23.04.2012 12:19, schrieb Invisible:
>> OK, so "magma" consists of a set S and a binary operator #. The #
>> operator takes any two elements of S (including the possibility of two
>> copies of the same element), and yields a new element of S (possibly the
>> same one you started with).
>
> And here I was thinking that magma consisted of molten minerals...

For extra credit, work out the difference between a semigroup and a 
groupoid. :-P

Post a reply to this message

Am 23.04.2012 12:19, schrieb Invisible:

> A less abstract way to think about it is this: If you have a value like
> x, you can put that inside a "box", which I will denote as [x]. Any
> value can be put in a box; in particular, you can put a /box/ in a box,
> for example [[x]].

I suggest thinking outside the box... (sorry, pun definitely intended).

Call it a wrapper object, and I guess we're fine.

Post a reply to this message

On 23/04/2012 02:50 PM, clipka wrote:
> Am 23.04.2012 12:19, schrieb Invisible:
>
>> A less abstract way to think about it is this: If you have a value like
>> x, you can put that inside a "box", which I will denote as [x]. Any
>> value can be put in a box; in particular, you can put a /box/ in a box,
>> for example [[x]].
>
> I suggest thinking outside the box... (sorry, pun definitely intended).
>
> Call it a wrapper object, and I guess we're fine.

Well, "box" is fewer letters to type. ;-)

You can take the guy out of the Haskell, but you cannot take the Haskell 
out of the guy. o_O

Post a reply to this message

Am 23.04.2012 15:43, schrieb Invisible:

> I love how 5.5 added "OOP", which consisted of letting you use the
> keyword "class" instead of "record", and letting you write your function
> code inside a class instead of outside it. I spent ages trying to figure
> out what advantage that gives you. And of course... IT DOESN'T. It's no
> different. In particular, IT'S NOT OOP.
>
> It would have /actually/ been OO if it had let you make fields private,
> or if it supported dynamic binding. But noooo... :-P

There is no language that "is OOP". OOP is a software design approach; 
An OO language (or OO language feature) is one that helps you implement 
such a design, but nothing more.

Bundling record data and related functions (aka methods) in a single 
thing called "class" does help you write software that makes use of data 
encapsulation (an OOP concept); it doesn't help you with enforcing the 
rules of encapsulation, but it simplifies the syntax by (1) 
automatically passing the ubiquitous "this" pointer, and (2) adding new 
namespaces to avoid naming collisions. As such, it does qualify as an OO 
language feature.

BTW, I'm not sure whether they added any new syntax features to classes 
from 5.5 to 6.0, but AFAIR 6.0 *did* support polymorphism; I think the 
"Turbo Vision" framework made excessive use of it.

Post a reply to this message

>> It would have /actually/ been OO if it had let you make fields private,
>> or if it supported dynamic binding. But noooo... :-P
>
> There is no language that "is OOP". OOP is a software design approach;
> An OO language (or OO language feature) is one that helps you implement
> such a design, but nothing more.

It came out around the time OOP was the latest crazy, and everything 
that wasn't OO was old and obsolete, and OO was the wave of the future. 
So they took the existing language, bolted on a few very superficially 
OO syntax elements, and said "Hey! Look! Our product is OO now! BUY IT!!"

About the only /useful/ thing it actually added was a per-type namespace 
for methods. What's it, really. You could /already/ group code and data 
together using modules, so the mere syntactic ability to write one 
inside the other isn't much of a big deal.

> BTW, I'm not sure whether they added any new syntax features to classes
> from 5.5 to 6.0, but AFAIR 6.0 *did* support polymorphism; I think the
> "Turbo Vision" framework made excessive use of it.

I gather Turbo Pascal eventually went on to become Delphi, which was 
briefly very successful. I believe that really was a full OO system.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> It came out around the time OOP was the latest crazy, and everything 
> that wasn't OO was old and obsolete, and OO was the wave of the future. 
> So they took the existing language, bolted on a few very superficially 
> OO syntax elements, and said "Hey! Look! Our product is OO now! BUY IT!!"

  Criticism of the overhyping of object-oriented programming is nothing new.
A famous paper named "My cat is object-oriented" was published in 1989.
(The title is a jab at the fact that anything that claims to be "object-
oriented" sells better, thus if you are selling your cat...)

> About the only /useful/ thing it actually added was a per-type namespace 
> for methods. What's it, really. You could /already/ group code and data 
> together using modules, so the mere syntactic ability to write one 
> inside the other isn't much of a big deal.

  No, what object-oriented programming added was inheritance and
polymorphism. Modules (complete with member functions, public and
private sections, module instantiation and references) existed before
object-oriented programming. What OOP added was inheritance, dynamic
binding and the ability to handle objects polymorphically.

  There are some applications where OOP fits like a glove (eg. GUI
programming), but in most situations just the modular part of OOP is
more than enough.

-- 
                                                          - Warp

Post a reply to this message