Subject: Programming Paradigms Cont.

From: Shlomi Fish <[email-masked]>
Date: Sat, 2 Mar 2002 17:38:38 +0200 (IST)

I am in the final stages of reading the main body of "Design Patterns",
which is the book that set forth the "Patterns" Programming Paradigm. The
book was recommended to me by several people. One of them was Omer Zak
with which I discussed it in a private conversation. The other was a
fellow Technion student who claimed the book provided a very positive
revelation to him, and also said it can provide answer for many
parallelization and synchronization problems.

So, with great expectation I bought the CD-ROM version of the book, which
contained the book in HTML format. That, and the fact that it occupied
only a few tens of megabytes made reading the book a very good
experience convenience-wise. However, right now I have an ambivalent
feeling toward the book. AFAICT, a large part of the book was dedicated to
try to convince me that it was actually possible to do OOP in C++[1],
rather than to explain why the patterns were useful.

I believe I would have enjoyed it more, had it used Perl or Python or
some other OO dynamically-typed langauge as the language for its
code. But, with C++, I'm having difficulty separating between patterns
that are actually useful to patterns that help overcome C++
idiosyncrecies.

The purpose of such paradigms is to help produce code that is more
modular, more maintainable, more reusable, scales better to larger codebases,
etc. Whether the existing paradigms today (Structured Prog., OOP, Patterns
Prog., FP, "my own" Meta-Data Database Access, Lazy Evaluation,
Dynamic-Typing/Strong-Typing, Lexical Scoping, Exception Throwing, GC,
etc) help that is questionable. While most modern programmers have endorsed the
Structured Programming Paradigm[2], OOP is still a bit controversial. Even
Paul Graham who is a doubtless a fabolous programming seems to criticize
it:

http://www.paulgraham.com/noop.html

My personal view on OOP is that it is useful, when and if it cannot be
replaced by simpler or more elementary means. Writing a derived class to
serve as a callback and thinking that's what makes OOP great is redundant
because the same can be accomplished with a pointer or a reference to a
function. Likewise, GC and dynamic typing can eliminate most of the
horrible (IMHO) C++ tricks with much more elegance and peace of mind.

Perhaps it would be worthwhile to declare a tree of the paradigms that I
mentioned, or order them in some way to determine what is the preferable
way of doing things. (i.e: to which paradigm to refer first, assuming it
is available). This can form a highly useful meta-paradigm of programming.

However, then we may have to create a dictionary of programming,
explaining each algorithmic task that needs to be accomplished, and how to
accomplish it nicely in any programming language in the world. This
naturally, can easily fill mass-storage data racks with useless
information.

Part of the problem with paradigms is that people fail to see them as
guidelines, and see them as a way of life. There were times where I found
OOP useful, however, I did not feel very willing to convert Freecell
Solver to C++ when Markus Oberhumer (of PySol fame) suggested it. While
FCS is not entirely anti-OO in nature, I believe that switching to C++
would give me little advantage over ANSI C. Thus, the fact that some OOP
code would be simpler to implement in C++, was not applicable to the
particular needs of Freecell Solver.

People wrote much more complex things in ANSI C, than Freecell Solver.
Would you go to the GCC, GIMP, Gtk+, Linux Kernel, etc. guys and try to
convince them to switch to C++? Some of these things are actually
cutting-edge super-modular code, despite the fact that they were not
written in C++.

Omer Mussaev once commented to me that Object-Oriented Programming was a
state of mind. That's after I asked how it is possible to do OOP in
Fortran. But OOP is exactly that: a state of mind. You can use it
sometimes, or you can decide to not use it for somethings. But it's not a
panacea for writing better code. Nothing is short of becoming experienced
enough _and_ putting enough effort into the codebase to make it so.

Regards,

	Shlomi Fish

[1] - I have placed the following self-quote in my homepage's humour
collection:

"IMO, C++ supports Object-Oriented Programming roughly as much as COBOL
supports Functional Programming."

Let's not start it into a "C++ pro and against" flamewar, because that's
not the purpose of this article.

[2] - Structured Programming does not imply a complete elimination of
goto statements. I find that using gotos sometimes help keep a C program
(and to slightly less extent a Perl Program) more tidy. Too bad Java does
not have goto's for some reason. (such as hubris?)

---

There is no IGLU Cabal! They set out to write the "IGLU Cabal Paradigm" of
which aimed to be the ultimate programming paradigm ever created or ever
to be created. Then they became frustrated that some programming newbies
who fully read "The IGLU Cabal Paradigm Bible" still produced very bad
code.

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Oleg Goldshmidt <[email-masked]>
Date: 02 Mar 2002 19:01:38 -0500

Shlomi Fish <[email-masked]> writes:

> However, right now I have an ambivalent feeling toward the book.
> ["Design Patters" - OG]

You are not alone. My ambivalence towards it is mostly due to the
impression that it goes a long way towards overengineering code
without discussing tradeoffs. On the other hand, I think it does
enhance one's understanding and programming culture (just don't make a
cult out of it).

> AFAICT, a large part of the book was dedicated to try to convince me
> that it was actually possible to do OOP in C++[1], rather than to
> explain why the patterns were useful.

I didn't get that impression.

> that are actually useful to patterns that help overcome C++

Give the authors some credit: they use smalltalk, too...

> ...OOP is still a bit controversial. Even Paul Graham who is a
> doubtless a fabolous programming seems to criticize it:
> 

Well, he does come from functional programming, which should be taken
into account. In particular, he is a great proponent of bottom-up
approach to programming. Using a gross generalization (and freely
admitting as much), I'd say that at least one key technique of OOP,
namely inheritance, strongly favors top-down approach. If you will, it
is better suited to building carefully planned cathedrals than to
creating a bazaar of tools. Graham is fond of tools (while not being
an open-source programmer). On the other hand, there is nothing
inherently wrong with planning a top-down structure. Both bottom-up
and top-down approaches are feasible, have their advantages and
disadvatages, can win or lose in different environments and/or areas
of project parameter space.

Incidentally, Christopher Alexander, the architect who is supposed to
have influenced the whole "design patterns" approach to software,
advocated "piecemeal growth" in favor to strict advance planning. By
the way, I read Alexander's "Pattern Language" book touted as "the"
revelation for software designers, and was not particularly impressed.

http://www.amazon.com/exec/obidos/ASIN/0195019199/qid=1015087621/sr=1-1/ref=sr_1_1/103-3502687-8795856

if you are curious. Amazon inform me that customers who bought this
book also favour Richard Gabriel. The connection is clearer if you go
to Gabriel's "Patterns of Software":

http://www.amazon.com/exec/obidos/ASIN/0195121236/qid=1015087860/sr=1-1/ref=sr_1_1/103-3502687-8795856

Incidentally, the "Design Patterns" book is probably responsible for 
association that many people have between "software patterns" and OOP.
This is too narrow. Gabriel himself is a Lisp programmer, first and
foremost, and Alexander's concept of "piecemeal growth" was likely
appealing to a lisper (see comment on Graham above).

> My personal view on OOP is that it is useful, when and if it cannot
> be replaced by simpler or more elementary means.

It's just a paradigm, and a particular associated bag of tricks. Just
another one.

> Likewise, GC and dynamic typing can eliminate most of the

Don't forget that much of C++ ugliness comes from the requirement that
it should be C-compatible.

> Perhaps it would be worthwhile to declare a tree of the paradigms
> that I mentioned, or order them in some way to determine what is the
> preferable way of doing things. (i.e: to which paradigm to refer
> first, assuming it is available). This can form a highly useful
> meta-paradigm of programming.

It wouldn't be worthwhile. The meta-paradigm to keep in mind is
TIMTOWTSAC (There Is More Than One Way To Skin A Cat - before any
animal-rights activist flames me: it's just an expression, and I am an
open cat-lover).

> guidelines, and see them as a way of life. 

Is it a problem with paradigms, or rather with people? 

> despite the fact that they were not written in C++.

Or thanks to it. Remember Graham's "Beating the Averages"?

> state of mind. 

So is FP, or any other paradigm.

> That's after I asked how it is possible to do OOP in
> Fortran. 

The answer was, "yes", IIRC ;-)

> You can use it sometimes, or you can decide to not use it for
> somethings.

Right. It's just another bag of tricks (or just another paradigm, if
you like big words).

> "IMO, C++ supports Object-Oriented Programming roughly as much as
> COBOL supports Functional Programming."

Let me add about 4 agorot to your collection: Here is a couple of
quotes I used in some of my signatures in emails sent from my office
address (disclosure: I am coding [NB: note tense!] in C++ mostly these
days):

Object-oriented programming is an exceptionally bad idea which could
only have originated in California.
 
    - Edsger Dijkstra 

I think that object orientedness is almost as much of a hoax as
Artificial Intelligence.

    - Alex Stepanov

In case anyone here (not everyone is a C++ programmer, hopefully)
doesn't know, Stepanov is the author of (the original) STL - a major
piece of C++ as we know it, and a non-OO one (the paradigm used is
"generic programming"). In an interview reproduced at

  http://www.stlport.org/resources/StepanovUSA.html

he has some rather unflattering things to say about OOP, going as far
as calling Java an example of MOP (Money Oriented Programming). IMHO,
he traps himself in the same (well, maybe opposite) corner as those
who argue that everything should be object-oriented. It's just as
wrong to say that nothing should.

> [2] - Structured Programming does not imply a complete elimination
> of goto statements. I find that using gotos sometimes help keep a C
> program (and to slightly less extent a Perl Program) more tidy. Too
> bad Java does not have goto's for some reason. (such as hubris?)

Was it Knuth who wrote a response to Dijkstra's famous paper and
titled it "Goto Considered Harmful Considered Harmful"? 

I personally do use goto in my code, finding it the cleanest and the
most appropriate solution (though never the only one possible) in a
limited number of cases (patterns, if you will).

You can write elegant code without any classes or inheritance, you can
write elegant object-oriented code, you can use functional or generic
or structured or data-driven programming beautifully or horribly. Use
what fits the purpose, keep an open mind, and don't invent unnecessary
absolutes (this last statement is intended to be self-contradictory).

-- 
Oleg Goldshmidt | [email-masked] 
If it aint't broken it hasn't got enough features yet.

---

From: Adi Stav <[email-masked]>
Date: Sat, 2 Mar 2002 21:55:21 +0200

> limited number of cases (patterns, if you will).

Really? In C++? What are they?

I find myself mostly using goto in C only to get around the lack of
on-stack object destructors.

---

From: Omer Zak <[email-masked]>
Date: Sat, 2 Mar 2002 20:51:33 +0200 (IST)

> that are actually useful to patterns that help overcome C++

As I see them, patterns are very abstract.  To explain abstract concepts,
one needs concrete examples.  In the case of patterns, they need to be
made concrete using a programming language.  Then, the reader has to
abstract the patterns from the programming langauge's idiosyncrasies.  It
probably is the reason why the book uses both C++ and SmallTalk.  Just
as it is easier to teach an abstract concept using two different
concrete examples.  Exactly what examples to use is a more-or-less
arbitrary choice.  But the examples had better be understood by the likely
audience of the book.

The patterns detailed in the book are usually patterns of interactions
between few entities, so the Object Oriented paradigm is appropriate for
expressing them.  So the best language, for writing examples in, is the
best known OO language - C++.

An example of patterns, which are not OO based, can be seen in SICP.  The
book contrasts functional programming (without side effects) against
assignment based programming (with side effects).  Those patterns cannot
be illustrated by means of C++, so SCHEME was used to illustrate them. 

Taking analogy from architecture.  One first studies the problem
statement, and decides whether it had better be solved by a design, which
is similar to house, to bridge, or a car.  Once the basic design
(programming paradigm?) has been decided upon, one goes into more details. 
There are several ways to design a house, according to the requirements
from it.  For each design (a design pattern), there are possible ways to
implement it (different computer languages or combinations of languages; 
different algorithms;  etc.). 

                                             --- Omer
There is no IGLU Cabal.  Its concept, design and implementation transcend
every paradigm, pattern or implementation known to today's mankind.
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html

---

From: Shlomi Fish <[email-masked]>
Date: Sat, 2 Mar 2002 21:05:47 +0200 (IST)

> titled it "Goto Considered Harmful Considered Harmful"?

I believe it was subtitled that way, if at all. The article itself is
titled "Structured Programming using Goto Statements".

> limited number of cases (patterns, if you will).

Me too, and I believe that was Knuth' opinion too (note that I did not
read the article yet, even though I'd like to, because it's only available
in print). I don't use goto for everthing, but sometimes it's a life-saver
in C. In Perl I have other tools (like closures or exceptions) which are
more SP and FP sound, so I don't use goto as often, but I'm not
religiously against it even in Perl.

I have seen very bad GW-BASIC code written using gotoes all over the
place. It was written by a Mechanical Engineer and was not a pretty site
(and my room-mate had no choice but to understand it somehow). I could not
make heads nor tails of it.

When I first learned programming, I learned GW-Basic from the "Makhseveth"
booklets (if anybody can still remember them). Now, the booklets were very
good in the sense that despite the fact they taught GW-Basic they taught
the readers to think in SP concepts: loops, conditionals, subroutines,
etc. So the transition to C, where goto is frowned upon when used in
most cases, was quite natural.[1]

What did frustrate me about the booklets (and it was partially my fault)
was that I eventually reached the state where my solution deviated from
the book's solution a lot. Despite the fact that I was sure my solution
was fine, I had the feeling that I did something wrong. But naturally,
There's more than one way to do it<tm> - even in GW-Basic!

Regards,

	Shlomi Fish

> absolutes (this last statement is intended to be self-contradictory).

[1] - When I studied C/C++ the thing I had the hardest time understanding
was pointers (naturally). However, on one of my Hugey Siyur trips the
Arms-Escort who worked as a programmer in the IDF explained to me what
they were all about (a physical location of the variable in memory), and
since then it was relatively straightforward for me to grok them.

> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

---

From: Shlomi Fish <[email-masked]>
Date: Sat, 2 Mar 2002 23:21:52 +0200 (IST)

> best known OO language - C++.

I disagree that the best language to teach about those Patterns is C++
just because it the best known OOPish programming language. (that's the
same mistake the Technion makes when thinking that C/C++ is good for
teachning everything). I would have enjoyed the book much more if they
devoted a chapter at the beginning to teach (say) Python (or Smalltalk -
whatever), and then illustrated everything using it.

That may have made the book less popular, but it certainly would have made
it easier to read.

> be illustrated by means of C++, so SCHEME was used to illustrate them.

C++ is Turing Universal so theoretically they can be illustrated using it.
It would just be a horrid-looking code and bad-style to write them that
way. Abelson & Sussman did not make the mistake of choosing a popular
programming language for their book. They chose a language, and gradually
taught it throughout the book. They assumed one may not be familiar with
Scheme (or even with programming in general) when he is going to read the
book.

Naturally, the techniques (patterns, whatever) presented in the book can
be implemented in other languages, but not with the same elegance and
simplicity as in Scheme. I believe most of the examples there can be
translated 1->1 to Perl, but where (cons myitem (myfunc ....)) is common
place in Scheme recursion, you hardly ever see ($myitem, &myfunc()). in
Perl, as most people will prefer to abstract the resursion as a loop. So,
it is possible, but it's bad style.

Likewise, I believe the Gang of Four could have come up with a better
language to illustrate the patterns they presented. I, on my part, had a
hard time telling whether they were supposed to overcome C++'s problems or
not.

> different algorithms;  etc.).

I think that an house, a bridge, a car is analogous to a programming
language, but that's just a fight about semantics in which we try to make
the connection between two topics that are not precisely analogous. (it
reminds me of The Unified Modelling Language User's Guide where they are
obsessed with this analogy[1])

Continuing with a different analogy presented in Patterns: they say most
books follow some pattern like a Romantic Novel, or a detective story etc.
However, being a writer as well as a programmer, that's not how I see my
stories forming. Obviously, most of the things I came up until now were
humouros, but "Comedy" is not an accurate description of it. When I write
a story, I'm looking for a very cool (and hopefully innovative) Gimmick
that will put the story together. Later I come up with each scene one at a
time (not necessarily at the order in which they are presented in the
story - ;-)).

If I use this analogy for programming, then instead of thinking of the
program's Grand-Unified-Pattern, I'm trying to look at the code's gimmick
(i.e: a Freecell Solver, an FCFS RWlock, etc), then I fill the important
details, and then I write the rest of the code. When I need to add new
features, I refactor the code or re-write portions of it from scratch.

So, OK, remembering a lot of Patterns may help a bit in building a solid
codebase, but I'm usually not concerned that much with the nitty-gritty
details of every algorithm. Maybe I don't mind temporarily having ugly
code in limited places, because I don't mind refactoring it eventually if
it becomes too ugly.

Regards,

	Shlomi Fish

> WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html

[1] - The UML UG was another book which I forced myself into reading till
the end, and felt a bit disappointed from.

---

From: Omer Zak <[email-masked]>
Date: Sun, 3 Mar 2002 02:22:03 +0200 (IST)

> On Sat, 2 Mar 2002, Omer Zak wrote:

[... snipped ...]

> That may have made the book less popular, but it certainly would have made

No, it would have made the book an horrible waste of time.
Why force someone to learn an obscure programming language, which he
probably doesn't have installed on his PC (to try toy examples
illustrating the concepts being discussed) - just to be able to comprehend
the book - if the book's ideas can be represented in a well-known
programming language.  The reader wants to learn about the subject at
hand, rather than waste more than the minimum required time on extraneous
learning.

This is like writing a story about sex, love and food in French, and
prefixing it with a short tutorial for English speakers to quickly
understand enough French to be able to follow the story.  While French is
a better language than English for sexy text, English is better-known, and
does accomplish the task of getting this organ up and that organ wet.

                                             --- Omer
There is no IGLU Cabal.  In order to start a Cabal, you must learn
Political Science, gain an experience running a dictatorship without
getting assassinated for 3 consecutive years, and win an election in
(another) democratic country.  Reading biographies of leaders and books
about management does not count!
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html

---

From: Eran Tromer <[email-masked]>
Date: Sun, 03 Mar 2002 03:11:20 +0200

Omer Zak wrote:
 > illustrating the concepts being discussed) - just to be able to
 > comprehend the book - if the book's ideas can be represented in a
 > well-known programming language.  The reader wants to learn about the
 > subject at hand, rather than waste more than the minimum required time
 > on extraneous learning.

Is it polite to criticize D. E. Knuth in public?
("The Art of Computer Programming" vol.1, pp. 124-163 in 3rd edition)

   Regards,
     Eran Tromer

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 07:27:45 +0200 (IST)

> does accomplish the task of getting this organ up and that organ wet.

I disagree with the analogy. Learning a new human language is by far more
time consuming than learning a new programming language. I know about 7 or
8 programming languages, but only have a thorough grasp of two human ones.
FuM, it may have been a good idea for the book to present its ideas in
some kind of OO pseudo-code. That way, no one's happy.

People who are serious about understanding the Old Testament should
probably learn Hebrew. Yes, it will take a longer time than to read it in
their native tongues, but it would be worthwhile. Likewise, learning a new
programming language (which fills a much smaller part of your brain, and
is altogether faster), to learn a paradigm or a set of patterns that gives
way to it, is not a bad idea.

As someone who occasionaly read or referred to the Bible in its various
English versions, I can say, that it many times loses most of its edge.
Someone I knew suggested translating the Bible into Hebrew, but the
problem it would have lost most of its edge. Naturally (Bible,Hebrew) ->
(Shakespeare's Writings, English) -> (Greek Philosophy, Greek) -> ...

I agree that learning a new human language only to read one singular text
is usually a worse idea than reading the translation (in case you only
wish to enjoy the work). However, someone who wishes to seriously study
it, should usually go the distance.

Regards,

	Shlomi Fish

There is no IGLU Cabal! The statement "There is an IGLU Cabal" only makes
sense in Hebrew, or in Swahili.

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 07:30:19 +0200 (IST)

> ("The Art of Computer Programming" vol.1, pp. 124-163 in 3rd edition)

Donald Knuth is not God. Omer is entitled to his opinion, regardless of
what Knuth said. I may wish to agree with either Omer or Knuth as I do not
consider Omer as essentially inferior or superior to Knuth.

Regards,

	Shlomi Fish

There is no IGLU Cabal! Don Knuth said so, and what Knuth said is The
Truth<tm>.

(this is a very lousy TINIC sequel)

---

From: Eran Tromer <[email-masked]>
Date: Sun, 03 Mar 2002 08:46:38 +0200

> consider Omer as essentially inferior or superior to Knuth.

Darn! I guess I'll have to dismantle the shrine then!

Since you missed the irony, let me be more explicit. I agree with Omer's 
criticism, and point out that it applies to Knuth's AoCP, whose 
readability is severely hampered by the use of the "MIX" assembly language.

Moreover, I wonder why you think Knuth *said* anything about it 
explicitly (he did, not but in the reference I gave). Had you looked it 
up, I suspect that upon seeing the content of the aforementioned pages 
you would see the wisdom of Omer's words.

   Regards,
     Eran Tromer

---

From: Adi Stav <[email-masked]>
Date: Sun, 3 Mar 2002 11:18:11 +0200

> consider Omer as essentially inferior or superior to Knuth.

Or alternatively: Donald Knuth /is/ God. What is possible for him to
implement is not possible for us, mere mortals, as Omer Zak stated.

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 10:24:34 +0200 (IST)

> implement is not possible for us, mere mortals, as Omer Zak stated.

I don't see myself as necessarily inferior to Donald Knuth. True, TeX
would have taken me a long time to write, perhaps longer than Knuth. But,
I could have written it, if I wanted to.

Note that I probably would not design TeX as it is now, but rather try to
come up with a typesetting formatting language, which I will find
desirable. But since TeX, LaTeX, and DocBook are already present, I'd
rather use them, instead of having to re-invent a very complex, and hard
to implement wheel. I prefer to take on projects which were not yet
implemented yet.

Donald Knuth is a simple human being. I consider it a bad thing<tm> to
think or treat people as "God"'s. Some people have achieved wonderful
and ingenius things, but I think I am also capable of achieving them.

Regards,

	Shlomi Fish

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 10:36:28 +0200

> Really? In C++? What are they?

Most often, in C, for cleaning up in case of error before returning
status to the caller in one place, e.g. if I have dynamic memory
allocation. The pattern I often use in a function is as folows: I
initialize to NULL every pointer I need to malloc memory for, then
make my malloc and other calls, and regardless of which of them fails
I goto to the end of function (reached also in case of success) where
I free all the memory before returning. This relieves me of the
necessity to micromanage which memory has already been allocated
and which hasn't when handling possible errors from various operations.

-- 
Oleg Goldshmidt | [email-masked] 
Only wimps use tape backup: real men just upload their important 
stuff on ftp, and let the rest of the world mirror it. [L. Torvalds]

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 10:38:37 +0200

> Is it polite to criticize D. E. Knuth in public?

Yes, if it is done politely. ;-)

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 10:41:57 +0200 (IST)

> readability is severely hampered by the use of the "MIX" assembly language.

How far is he going in using the MIX assembly language? I would have used
Pseudo-code if I were him, or a high-level language such as Perl. When you
teach people about algorithms, you should try to make sure they spend as
little time as possible trying to grok the implementation details, and
rather see the simplicity and elegance (or lack thereof) of the algorithm.
Usually one can think of an abstraction without the implementation
details.

When I think in terms of Assembler, I don't imagine the digital circuits
below on a regular basis. And when I think of logical circuits, I don't
imagine the transistors. And so forth.

I once claimed that when studying OOP, one should not present objects as
abstract ADTs, but rather should give some implementation details.
Obviously, when I think of an object, I don't think of the hash behind it
or the offsets stuff. But it is important to know how things work
internally, sooner or later.

Sometimes the underlying level adds little to the understanding of the
level above it. But it is important for students to understand that
there's nothing magical about Perl, or the computer's assembler, or a NAND
gate, or LC, or whatever, and they can all be implemented with more basic
concepts. Or alternatively, can be implemented on top of other Turing
universal layers.

Obviously, I'll have a hard time implementing a compiler for a C-like
language. But I understand the concepts and how it works. Good
understanding of Assembler concepts (pointers, the stack, etc) can make
you a much better C programmer. I know Freecell Solver was initially
designed improperly, due to lack of experience in working with pointers,
on my part.

> you would see the wisdom of Omer's words.

That you should use the most common programming language for everything?
Like I said earlier, I think it's pretty lame to teach Algorithms, or
Compiler Theory, or to generate VRML pages with C. Why not teach Perl
(/Python/Ruby, yeh yeh) and save the students a hearth of future
frustration. Just because you decided to teach C as the introducery
programming language (possibly a bad choice, but let's skip it), does not
mean it would be perfect for everything else the students will have to do.

I know teaching a distinct programming language for every task will scare
away the students or the readers. I'm also a bit frustrated that there's
seems to be an inflation of new languages recently (which I am partly
responsible), and many languages compete for performing the same task.

But my question is: why is it unthinkable to teach a course about
Functional Programming in C, while teaching Compiler theory with it makes
sense? Or alternatively, can a book about Patterns that uses C++, can
actually teach about Patterns, rather than try to emphasize how to
overcome its OO idionsincrecies?

It's a trade-off, but that's life.

Regards,

	Shlomi Fish

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 10:44:25 +0200 (IST)

> and which hasn't when handling possible errors from various operations.

Excellent idea (or pattern) Oleg! I have used it to some extent to
indicate that a variable is no longer used. But this is actually GC on
ice.

Should be a life saver for Freecell Solver, if and when I decide to make
it malloc-safe.

Regards,

	Shlomi Fish

There is no IGLU Cabal! It was set to NULL after one of its members failed
to allocate.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 10:43:48 +0200

> you would see the wisdom of Omer's words.

http://www-cs-faculty.stanford.edu/~knuth/mmix.html

---

From: mulix <[email-masked]>
Date: Sun, 3 Mar 2002 10:45:39 +0200

> and which hasn't when handling possible errors from various

this works for memory, but fails for other types of resources, since
it tends to lead to this kind of code (which i have seen. really.)

int r1;
int r2; 
int has_r1 = 0; 
int has_r2 = 0; 
...
if ((r1 = acquire_r1()) != BAD_RESOURCE)
   has_r1 = 1; 

if ((r2 = acquire_r2()) != BAS_RESOURCE)
   has_r2 = 1;
...
goto done;
...
done:
if (has_r1)
   release_resource(r1); 

if (has_r2)
   release_resource(r2); 

return something. 

compare with the (nicer|faster|not quite as safe for memory):

int r1; 
int r2; 
...
if ((r1 = acquire_r1()) == BAD_RESOURCE)
   goto out_done; 

if ((r2 = acquire_r2()) == BAD_RESOURCE)
   goto release_r1; 
...
/* no need for goto done here, we just fall through gracefully */ 
release_r2:
   release_resource(r2); 

release_r1:
   release_resource(r1); 

out_done:
   return retval; 

-- 
The ill-formed Orange		
Fails to satisfy the eye:       http://vipe.technion.ac.il/~mulix/ 
Segmentation fault.		http://syscalltrack.sf.net/

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 10:57:42 +0200 (IST)

> http://www-cs-faculty.stanford.edu/~knuth/mmix.html

I guess Knuth is slightly crazy. If you want to learn about the different
layer one encounter when working on a modern OS, then the best book would
probably "Computation Strucutres" or something similar. I do not think a
book about Algorithms should show how they can be implemented in Assembly.

It is obvious they can be, but Pseudocode or Perl or whatever is usually a
better choice.

But who is John Galt? If Kunth is fond of this idea, I'm not going to try
to convince him otherwise. (it's useless trying to convince him)

Regards,

	Shlomi Fish

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 11:15:41 +0200

My "pattern" goes roughly like (don't hold me responsible for details):

err_t foo(size_t n, size_t m)
{
   err_t rc = ERR_SUCCESS;
   double* x = NULL;
   char*   y = NULL;

   if ((x = malloc(n*sizeof(*x))) == NULL)
        goto CLEANUP;

   if ((rc = bar1(x)) != ERR_SUCCESS)
        goto CLEANUP;

   if ((y = malloc(m*sizeof(*y))) == NULL)
       goto CLEANUP;

   if ((rc = bar2(y)) != ERR_SUCCESS)
       goto CLEANUP;

 CLEANUP:

   free(x);
   free(y);

   return rc;
}

Code written like this does not suffer from memory leaks much, even if
you eventually decide that y should be malloc'ed before calling
bar1().

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 11:23:03 +0200 (IST)

>    if ((rc = bar2(y)) != ERR_SUCCESS)

I believe it should be:

if (x != NULL)
{
	free(x);
}

and likewise for y. Otherwise you may actually free NULL. While this makes
no difference for free (read the man page), it could make one if the
variable was allocated in a more elaborate way.

Regards,

	Shlomi Fish

There is no IGLU Cabal! The process that run the "IGLU Cabal Processing
Utility" crashed due to the fact that it tried to free(NULL), and the
malloc implementation was buggy.

---

From: mulix <[email-masked]>
Date: Sun, 3 Mar 2002 11:46:38 +0200

> >    if ((rc = bar2(y)) != ERR_SUCCESS)

here's the problem i alluded to in my post: what if bar1(x) requires
undoing? (think opening a file, or a network connection). either you
have a flag (has_bar1) and release it based on it, or you have a
memory leak here, or you break up the cleanup phase into steps. 

> >    free(y);

ObRant: please trim the pointless yahoogroups signatures when
replying.  
-- 
The ill-formed Orange		
Fails to satisfy the eye:       http://vipe.technion.ac.il/~mulix/ 
Segmentation fault.		http://syscalltrack.sf.net/

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 11:51:18 +0200

> variable was allocated in a more elaborate way.

In which case allocation and freeing would probably be absracted in
special functions that would do checks. I didn't want to be too
elaborate (normally, I'd have some error handling and reporting
adjacent to gotos as well). As written, free(NULL) should do nothing
and the code is valid.

And I asked not to hold me to details here...

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 12:00:25 +0200

> memory leak here, or you break up the cleanup phase into steps.

I certainly agree that the "pattern" is limited. However, you have
status returned by bar1(), and in many
cases you can write

 CLEANUP:
  
   if (rc == ERR_BAR1) { <do_bar1_error_handling> }
   if (rc == ERR_BAR2) { <do_bar2_error_handling> }

   etc.

Of course, this implies that bar1()'s status is distinguishable from
bar2()'s, not necessarily by rc. E.g. fopen()) returns NULL in case of
failure, so you can delegate fclose() to CLEANUP. Not very different
from malloc/free, actually. And some specific error handling (and
reporting) can be done right before the corresponding goto statement.

I did say the applicability was limited. I still find it useful. The
point is that in cases like that I don't see harm in goto.

---

From: Adi Stav <[email-masked]>
Date: Sun, 3 Mar 2002 15:48:53 +0200

> > implement is not possible for us, mere mortals, as Omer Zak stated.
.
.
> and ingenius things, but I think I am also capable of achieving them.

Uhm, er, I am sure that you could, Shlomi. I am not advocating a 
personality worship (unless it's my own). I was merely pointing out 
an alternate interpretation of what Omer Zak said, one that you 
seemed to ignore; YHBT, I guess, even though that was certainly not 
the intended result :)

---

From: Omer Zak <[email-masked]>
Date: Sun, 3 Mar 2002 13:20:23 +0200 (EET)

On Sun, 3 Mar 2002, Shlomi Fish wrote:
[... mercilessly snipped, sorry ...]

> > >> > well-known programming language.The reader wants to learn about the

Actually, I don't remember having any problems reading TAOCP due to
Knuth's choice to use MIX rather than a conventional programming language
or an actually-implemented assembler.

I think it was because he did not deal with high-level abstractions.  He
provided his readers with concrete examples, and built simple abstractions
upon them.  Learning MIX machine language was not more difficult than
memorizing how to say the numerals from 1 to 50 in French.  It is not
necessary to grasp and integrate abstract concepts.

On the other hand, design patterns are very abstract stuff.  To be able to
understand them, one needs solid grasp of lower-level abstractions (which
are nevertheless much abstract than the concepts with which Knuth dealt in
his books).  Therefore one needs to master the concepts of the langauge/s
used in the book.  Using a familiar language (even in unfamiliar ways) is
better than forcing the reader to cram a new language without having time
to digest and integrate its concepts.

                                             --- Omer
There is no IGLU Cabal.  Its guiding concepts are more abstract than
anything attempted, contemplated, created or destroyed by human minds so
far.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Mar 2002 13:55:11 +0200

> or an actually-implemented assembler.

MIX has been implemented. I have no idea how good (or bad) the
implementations are.

http://www-cs-faculty.stanford.edu/~knuth/taocp.html

> I think it was because he did not deal with high-level abstractions.

he didn't want to lock himself into a particular high-level
programming language. He wanted to show how computers compute. MIX can
probably be considered a low-level pseudocode.

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 16:13:10 +0200 (IST)

I'd like to put this thread a little back on the track. (at least as I see
it). As OmerZ noted the patterns paradigm exist independently of the OOP
paradigm. It was just that in the "Design Patterns" book the authors chose
to demonstrate OO patterns. Now, assuming we agree that Patterns are a
good idea, whether OO or not, let's ask this question: when should we use
OOP and when it is better to avoid it?

Some languages are fanatically OO. From the languages I know, Java comes
to mind. In Perl, OTOH, one can live for quite a long time without writing
or even using objects at all. I'm not saying being inherently OO is a good
or bad, but it's a fact that languages differ on the level in which they
embraced its concepts.

However, I'm not sure that if a language is inherently OO, it will
encourage a better design OO-wise. After all, you can still write
everything as one monolithic class. (to take the extreme case) Moreover,
it is possible to do very good OO programming in languages that are not
too OOPish, such as ANSI C or Scheme.

Most people will agree that writing a non-OO GUI is probably a bad idea.
All the GUI libraries I experienced with (namely Win16/Win32, Perl/Gtk+,
Perl/Tk, C/Qt and Tcl/Tk, and Java AWT) were OO to some extent. I believe
it is obvious that the common GUI model calls for OO, and needs it like
air for breath. Maybe one can think of a completely new GUI model (with
extremely different controls and behaviour) that would be non-OO, but
chances are no-one will use it.[1]

However, in some cases, OO will be a nuisance at best, and a way to
extermely complicate the code at best. One of the Technion anomalies that
bother me the most, is that people think using an inherited class as
a callback is a good idea. (AFAICT, in Java that's the only way to have a
callback).[2] Imagine someone doing it in Perl (which has first order
functions and closures). Not a pretty vision.

This is just a simple example. In many cases forcibly using OO can make an
ugly code much worse. (I don't think instancizability qualifies as OOP,
also it is undoubtedly a very important pattern) Some code by nature is
complicated. Maybe it is possible to modularize it, somehow. Sometimes, it
is better to keep it complicated and relatively monolithic, but try to
make it as un-ugly as possible.

In such cases, I believe, trying to use OO will complicate everything. For
the IGLU mailing lists list:

http://www.iglu.org.il/mailing-lists/ (code is available there)

I succesfully used class inheritance to make my job easier. The code since
has become quite ugly and I should refactor it a bit when I see a need,
but nevertheless, OO has proven to be helpful.

Like I said, Freecell Solver is not particularilty OO, and it gives me
headache to think how to object orient it properly. At the moment I'd
rather keep it as non-OO just to make the code a bit cleaner and more
legible.

But even if I'm going to OO it sometime, I'm not going to convert the code
to C++, because I can achieve everything I need with what ANSI C gives me.
The code at the moment is very much ANSI Cish. There's a large difference
between having files that end with .cpp, and code that is
state-of-the-art Standard C++-wise. And I have better things to do with it
than re-write it using Standard C++.

I do mention Freecell Solver here a lot, but it has been the cause of much
inspiration and insights. Is anybody bothered by it too much?

Whatever. To sum up: OOP is out there. Use it when appropriate, but don't
try to forcibly OO a code. "oo -f" considered harmful.

Regards,

	Shlomi Fish

[1] - YA Joel Spolsky Link:

http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

A very good explanation why your GUI should resemble what users' are
familiar with. (among else)

[2] - Maybe it's just me but I think learning a language in which
functions are first-order objects and can be declared at run-time (your
choice of Scheme, Perl, Python, Ruby, LISP, etc) is a must.

---

From: Omer Zak <[email-masked]>
Date: Sun, 3 Mar 2002 16:43:06 +0200 (EET)

> OOP and when it is better to avoid it?

My point of view:  OO is a pattern (or, if you want, a meta-pattern).  The
Gang of Four patterns are sub-patterns of the OO pattern.  In
architecture, one can see similar nesting of patterns - buildings fit for
humans to live/work in (general), apartment houses adapted to the needs of
specific populations (more specialized patterns).

The OO pattern is a good fit for environments, in which you have
several objects, and want to manipulate them in various ways.  Examples:
- GUI - the various widgets need to be manipulated in various ways.
- CAD systems.
- Operating systems (file is an object, subject to various operations, and
  so is a process).

However, a signal processing application does not fit the OO pattern
(systems for designing signal processors ARE as good for OO as other CAD
systems).  The data needs to flow through several blocks, each of which
performs a certain transformation on the flowing data.  So for such an
application a data flow pattern is better than OO pattern.

A sub-pattern of the data flow pattern is better for integrators of
partial differential equations (aka continuous simulators, like weather
simulators).  Each node receives continuous data streams from its
neighbors, performs its computations, and sends continuous data streams to
its neighbors.  This sub-pattern is different from the above in that each
node (block) processes several data streams simultaneously, and all the
blocks usually have very similar algorithms (differing only in
geographical placement == identity of their neighbors).

Unix filters are usually good candidates for data flow patterns - they
read data from stdin, transform it and write to stdout.  Several Perl
scripts (and more so - sed/awk scripts) are meant for this kind of
application, too.

Besides OO and dataflow patterns, what other meta-patterns are there?
                                             --- Omer
There is no IGLU Cabal.  The meta-meta-meta-pattern, which
accurately describes it, has not been conceived yet.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 22:39:19 +0200 (IST)

> specific populations (more specialized patterns).

I fully agree here.

> - Operating systems (file is an object, subject to various operations, and

Again agreed.

> application a data flow pattern is better than OO pattern.

Actually, I don't think the data flow pattern and the OO pattern
contradict themselves here. You can define a filter as a method, and then
have the sub-class perform a slightly different transformation. (hopefully
non-EEers will understand what I say here) You can then instantize this
class to make the application able to filter several signals on several
threads.

One of the things that I found most lacking in Matlab is good primitives
for good OOP/FP/etc. programming. For instance, I could not find a way to
define a conditional breakpoint except to put the statement inside an if
statement, and have the breakpoint stop there. It's a kludge, but it
works, and I'd appreciate anyone who can enlight on how to have a true
conditional breakpoint.

> scripts (and more so - sed/awk scripts) are meant for this kind of

Actually, SICP covers some data flow patterns. The standard map and then
filter instead of writing it using a monolithic function. I always thought
of maps, filters, sort's, etc. as sort of FPish, but maybe they are
actually data flow ones.

> Besides OO and dataflow patterns, what other meta-patterns are there?

I have a pattern (which I presented and implemented in several places)
which I dub Meta-Data Database Access. I consider it a sub-pattern of a
more general pattern which I call Meta-Data Programming. Now, the concept
of MDP is you write an algorithm that accepts a nested data-structure
containing meta-data. This meta-data then instructs the data how to
process the actual data.

The meta-data itself is not, or at least should not be Turing Complete.
Whatever requires Turing Completeness should be abstracted as functions
which are placed inside a functional database and accessed according to
their name or ID.

Hopefully, one can fully create very different systems this way, while
keeping the program in fully serializable, fully analyzable meta _data_.
(and now, I don't consider a code that is about to be evaled as meta data
proper). But so far what I implemented using it was quite limited, so this
is more of a vision then a working paradigm.

Nevertheless, I believe it can be thought of as a meta-pattern because I
don't think it falls into any other category. It's not exactly OO, nor SP,
nor FP, but rather seems to be independant of these paradigms[1].

But so far the programs produced by this vision run most flawlessly
inside my head, but I really think it may prove useful sometimes.

Regards,

	Shlomi Fish

[1] - or meta-patterns. A rose by any other name would same just as sweet.

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 3 Mar 2002 22:56:02 +0200 (IST)

Data-Derived Programming. Refer to:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3

It is a topic of much debate and discussion, and still there are only
ad-hoc heuristics. In case of languages that are Truly Strongly Typed, it
could be a matter of life and death.

It reminds me a bit of OOP, but they are not exactly the same thing.

Regards,

	Shlomi Fish

---

From: guy keren <[email-masked]>
Date: Sun, 3 Mar 2002 23:08:36 +0200 (EET)

> Besides OO and dataflow patterns, what other meta-patterns are there?

buzz words? 'linear programming'. 'generic programming'. 'genetic
algorithms'. you might consider usage of neural networks as a method of
'programming'. the possibilities are endless ;)

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

---

From: Omer Zak <[email-masked]>
Date: Sun, 3 Mar 2002 23:26:26 +0200 (EET)

> 'programming'. the possibilities are endless ;)

Since the Bloody 2002 Purge, which cleared the Hackers-IL mailing list
from all PHBs, we no longer need to concern ourselves with buzzwords.

But most of the buzzwords above reduce into "heuristic programming".  And
here I'd like to point out the philosophical question - is heuristic
programming a pattern?

On one hand, heuristic methods are valid methods for solving problems.
But then methods are synonymous to meta-patterns.  So what's so innovative
about meta-patterns?

On the other hand, heuristic methods are not guaranteed to Solve the
Problem (TM), but only to suggest a "good enough" solution.  I am not sure
that methods which don't Solve the Problem are entitled to meta-pattern-hood.
                                             --- Omer
There is no IGLU Cabal.  Its remains are at the bottom of an ocean of
yesterday's buzzwords.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: guy keren <[email-masked]>
Date: Sun, 3 Mar 2002 23:29:28 +0200 (EET)

> OOP and when it is better to avoid it?

you should use OOP if you believe in it. any other rules are rather
pointless. if someone is used to structured programming, and finds it hard
to adapt their thinking methodology to OOP - don't tell them OOP is better
for them.

> Some languages are fanatically OO.

some people are fanatics about languages (hint, hint...) ;)

> However, I'm not surethat if a language is inherently OO, it will
> encourage a better design OO-wise.

why are you "not sure"? you know it won't change the mind-set of the
programmer unless that programmer wishes to adapt.

there are people who find that the language helps them thinking in a new
way. i know i didn't use proper OOP before i started working in C++.
and C++ encourages one to inherit - people seem to think that "to oop is
to inherit", which is ofcourse not true. in many cases, you can do good
oop without using inheritance (or with very little use of inheritance).
the kind of 'oop is inheritance' thinking has led some unwarry programmers
into creating gazzilions of unnecesary classes and creatin of spagethy
code. why do you keep implying that 'oop is inheritance'? that's a bad
oops :)

> Most people will agree that writing a non-OO GUI is probably a bad idea.

they agree about it _now_. if you look at GUI programming in the 80s, it
wasn't oop (not talking about smalltalk). it was simple event-driven
structured programming (i.e. a main loop received events, had a grand
'switch' statement, and based on the 'message type', invoked the matching
C callback function).

btw, regarding smalltalk, if you think java is too oopsish, consider
learning smalltalk - everything is an object, including numbers. you want
to do '1+2'? you do [1 add: 2], or something similar, which would invoke
the method 'add:' on the object '1', with a parameter consisting of the
object '2'. someone with real smalltalk memory could fix my broken syntax
here.

> Perl/Tk, C/Qt and Tcl/Tk, and Java AWT) were OO to some extent.

this is because you were born too late ;)  its not good practice to assume
computer programming started when you started programming.

> make it as un-ugly as possible.

and perhaps its just that the code is complicated because you didn't
manage (yet) to find a way to modularize it better. claiming that
'something is complicated by its nature' is the first way into stopping to
think.

> rather keep it as non-OO just to make the code a bit cleaner and more

don't assume that 'doing it oop will make it less clean'. you think that
because you already designed and wrote it the way you did, and you're
thinking of ooping it as a gradual change. however, ooping it means to
throw the current code, and design it from scratch. then possibly using
specific code snippets for the implementation of some methods. just admit
it - you've got oop-phobia because oop is too hyped.

> to C++, because I can achieve everything I need with what ANSI C gives me.

you're showing again how strongly oop and c++ are bound in your head - did
anyone claim that ooping requires switching a programming language?

> than re-write it using Standard C++.

actually, i'm not sure they are better. i think part of why you don't look
into oop, is because you're not writing real large applications, together
with several programmers. oops has its overhead, and thus does not seem
appropriate when the ammount of actual work to do is limited. and no, i
don't count fcs as a large project. i hope you don't count it as such
either.

> inspiration and insights. Is anybody bothered by it too much?

if we'll say "yes", would it change anything? :P~~

> try to forcibly OO a code. "oo -f" considered harmful.

gain, you don't OO a code. you design it as OO in advance - the code then
comes from the design. you're reversing the process badly.

> choice of Scheme, Perl, Python, Ruby, LISP, etc) is a must.

good to know. i don't remember myself declaring functions at runtime - the
most i do is write perl scripts that enerate code (with functions). and i
simply never saw a case where i said "oh, if i use annonymous functions
here, it'll make the code better". i hate anonymousity - a function
must have a name! :)

--
guy

---

From: Shlomi Fish <[email-masked]>
Date: Mon, 4 Mar 2002 10:01:23 +0200 (IST)

> to adapt their thinking methodology to OOP - don't tell them OOP is better

My point was that some cases are more oriented around OOP than others.
Naturally, in many of those cases one can write good code using only
non-OOP or pseudo-OOP techniques. But OOP can make your job much easier.

> some people are fanatics about languages (hint, hint...) ;)

I hope you did not mean I am a language fanatic. Whatever.

> code. why do you keep implying that 'oop is inheritance'? that's a bad

My point was that you can still write very non-OO code in C++, and you can
write very good OO code in ANSI C. The fact that C++ gives you OO
primitives, where in C you'll have to hack something on your own, will not
cause people to:

1. Think in OO concepts.
2. Identify the places where those concepts are appropriate.

One can argue that excessive and redundant inheritance is not too OO (or
simply bad design). Like I said Perl has Objects, but one can survive for
a long time without using them. The reason for that is that Perl is widely
used for scripts and people don't want to have to declare a class just for
writing "Hello, World!" (like you do in Java, for example).

Okay let's have a truce: there's a better chance of getting an OO design
right in an inherently OO programming language than in one that does not
encourage it. But, that's not necessarily a bad thing. I find that
forcibly thinking in objects is sometimes an obstacle.

> 'switch' statement, and based on the 'message type', invoked the matching

I remember those switch statements from the time I maintained a raw WIN16
API program. But then again, the Win16 API is quite OO. But I believe you.
In any case, no one on his right mind will design a non-OO GUI in the
future. There are various models out there, all of them OO to some extent.

My point was that OO has proven to be a life saver AFA GUI Design was
concerned, and that GUI gives way to it.

> object '2'. someone with real smalltalk memory could fix my broken syntax

I'd like to learn SmallTalk. Then there's Ruby which is a hybrid of Perl,
Python and SmallTalk. It's on my "languages to learn" list.

But I could not give ST as an example because I was not very familiar with
it.

> computer programming started when you started programming.

Perhaps I was born too late, or simply started GUI design too late. Or
too early - there are more sensible things out there than the raw Windows
API. C/Gtk+ is a bit awkward to use if you ask me too, but at least it has
more decent geometry managers.

> 'something is complicated by its nature' is the first way into stopping to

IMO, real-life programs sometimes require code that is not too elegant:
lots of if's, while's, for's, inside each other, etc. The code you get
does not make a good impression as a very elegant code. Maybe "ugly" was a
bad word. Let's just call it non-elegant.

> it - you've got oop-phobia because oop is too hyped.

No I don't. Perhaps OOP is too hyped and talking with some people allowed
me to "see the light". However, I am _not_ re-writing Freecell Solver from
scratch. A gradual change to OOPism would be a much better idea,
strategically.

But like I said, the places where I think OO patterns might make sense,
are usually not worth the trouble of using them. If I do find that I
_need_ to use them, I'll convert the code in this specific place. But at
the moment it's not too critical.

"If it's working - don't touch!"

> anyone claim that ooping requires switching a programming language?

Actually, that was exactly my opposite case. If I'll OOPify the code, I'll
use ANSI C OOP.

> don't count fcs as a large project. i hope you don't count it as such

I invested a large amount of time hacking on it;  refactoring and
rewriting parts to fit my needs. But naturally it's only a 13,000 lines
code base, which according to SLOCCount would have taken 3 person years to
develop. ;-)

But it's not a large project by a long shot. Some projects contain
100,000's lines of code.

> if we'll say "yes", would it change anything? :P~~

Hmmppf. I really like to mention Freecell Solver, because it gave me a lot
of insights and contains some very interesting algorithms (at least IMHO).

> comes from the design. you're reversing the process badly.

In some places, I believe that having an OO design will not make it better
over a non-OO design. Sometimes procedural code can be just as modular and
just as easy to maintain as OO one. This of course, widely has to do with
one's general philosophy and his background and experience in programming.

> here, it'll make the code better". i hate anonymousity - a function

If that's how people feel about Lambdas after attending my Scheme Lambda
Calculus lecture, then maybe I'm not a good lecturer.

In Perl the following assigns a lambda to a variable:

my $pyth = sub {
	my ($a,$b) = shift;
	return $a**2+$b**2;
};

As you see it's an anonymous function but it's bound to a variable. Perl
also support global functions (which are not lexically scoped) for
convenience, but they are not absolutely compulsory. Lexical scoping is a
very powerful tool, and it saves a lot of trouble.

I believe it is sometimes better to use lexical scoping, assuming it is
supported, than passing context arguments all over the place. In Perl
callbacks do not require a context, because you can easily have one by
creating a closure.

And naturally, defining lambdas and excuting them is a Turing Complete set
of instructions... ;-)

Regards,

	Shlomi Fish

---

From: Oleg Goldshmidt <[email-masked]>
Date: 04 Mar 2002 13:12:44 +0200

> I think it was because he did not deal with high-level abstractions.

Just stumbled on this quote:

A person who is more than casually interested in computers should be well
schooled in machine language, since it is a fundamental part of a computer.
                -- Donald Knuth

---

From: Shlomi Fish <[email-masked]>
Date: Mon, 4 Mar 2002 13:49:18 +0200 (IST)

> schooled in machine language, since it is a fundamental part of a computer.

Does the nano-code, microcode and Assembler of the MAYBE and
G-Machine architectures count? (refer to the book "Computation
Structures") Naturally, we avoided writing the opcodes and operands
directly and started using a macro-processor. (which was not fascinating,
but was sufficient for our needs)

Machine language - geez. While writing stuff in Assembler makes sense
sometimes (but usually is considered harmful needlessly), I don't think
fully thinking of how those instructions translate to machine language is
necessary. One should be aware that they do, and how the do, but for most
case thinking in the Assembler level is enough.

Regards,

	Shlomi Fish

Knuth is not God! Because of him, programmers started to start writing
their code in Machine language again. This made khexedit a useful
engineering tool, but otherwise caused common Perl scripts to take several
monthes to write.

(I am patenting issuing a TINIC with anything else but the phrase "There
is no IGLU Cabal!". The patent number is kept secret to avoid copyrighting
its text)

---

From: Oleg Goldshmidt <[email-masked]>
Date: 04 Mar 2002 14:33:34 +0200

Just in case it wasn't clear, I merely quoted Knuth without expressing
my own opinions. As long as his reasoning is discussed, at least let's
keep track of what he said on the issue (or what is attributed to
him).

Shlomi Fish <[email-masked]> writes:

> sometimes (but usually is considered harmful needlessly)

While we are counting off things "considered harmful" (Dijkstra,
Knuth) can anyone come up with an example of anything in CS considered
"mostly harmless" (Adams). Other than Earth (which is, as is well
known, a computer), that is. ;-)

> caused common Perl scripts to take several monthes to write.

And years to read... (sorry, could not resist) ;-)

---

From: Nimster <[email-masked]>
Date: Tue, 05 Mar 2002 20:22:10 +0200

----- Original Message -----
From: "Shlomi Fish" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 02, 2002 9:05 PM
Subject: [hackers-il] Knuth Responce to the anti-Goto Fiasco [was Re:
Programming Paradigms Cont.]

> religiously against it even in Perl.

It's a late reply: I haven't had time to go over my emails this week.
However, a related anecdote:
INTERCAL [http://www.tuxedo.org/~esr/intercal/], with its "Designed to be
Turing-complete but as fundamentally unlike any existing language as
possible" philosophy, features COME FROM statements
[http://www.muppetlabs.com/~breadbox/intercal-man/s04.html#4.14] instead of
GOTO. You'd write
COME FROM Label 1:
...
Label 1:
...

which translates to
Label 1:
...
GOTO Label 1
...

-Nimster