Re: [PLUG] Pascal?

[Jason <jason@nocks.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 10 July 2002 16H:37, Fred K Ollinger wrote:
> > But, we're not talking grammer, here. And, even with correct grammer,
> > there is more than one correct way to write something. That's one of the
> > essences of most languages. Some writings require languages that can
> > describe subtle variations and nuances. Poets, for example, would shoot
> > you if you removed words that had similar meanings or removed meanings
> > when words had more than one meaning.
> >
> > Now, programming is almost certainly NOT poetry. But, there certainly are
> > valid differences in similar, but different approaches, techniques,
> > grammars, etc. How would you like it if your toolbox was limited to only
> > one type and size of screwdriver? And, just try to get everyone to agree
> > on which one it should be.
>
> All of this is enforce, I thought, in pascal. There really are less
> choices that are 'right'. This forces people to all code their stuff the
> same way which results in less idioms. One could do well by memorizing the
> most common idioms. I, personally, would like this.
>
> The size of screwdriver would be limited to a few screws, small, medium,
> and large. Instead we have a plethora of screws which lead to a plethora
> of tools one needs to even fix the simplest thing. I don't know why this
> is a Good ThingTM for anyone save for tool companies. Yes, there are
> exceptions, but these exceptions are not the rule. Simple things should be
> really simple and harder things will always be a bit harder. Don't make
> simple things complicated just to make hard things a tiny bit easier.

Having different tools is a good thing. Having different languages is a good 
thing. Being able to express solutions in different ways to meet different 
requirements IMHO is a good thing.

It doesn't seem like 2 is a plethora of functions to me. Actually, I find that 
one of the many benefits of OO is fewer function names that accomplish the 
same thing, sometimes due to overloading, sometimes due to inheritance. So, 
in the example given, rather than printf, vprintf, etc. you replace that with 
cout, or more generally streams. Now, you have one concept to learn that 
applies in many different instances. That way, you don't have to memorize a 
lot of function names that all do similar things.

>
> > Java is generally reguarded as simpler than C++ in some ways. I think
> > that may contribute to why some Java code may be more readable than some
> > C++ code. Again, simpler is almost always more readable.
>
> I think the c-isms that have been taken out makes it easier. Plus it's
> syntax looks more like english. I think that c code can be frightening
> which is why I want to learn it, but I don't think that this is the most
> efficient way to go.
>

This seems a little strange at first glance. You are frightened by something, 
which makes you want to learn it. I guess that's encouraging in a sense. I'd 
recommend learning C more as part of a foundation for continuing on to C++ or 
Java. But, you probably wouldn't need to dwell on it too much upfront if that 
was the approach you decided on. There are some parts of "straight C" that 
you don't absolutely need in C++ (or that have been removed entirely), I just 
think it's good to be familiar with the basics first.

> >
> > I don't think anyone is doing any judging here. Did this become a
> > contest? What does the winner get? A free compiler? Free as in... Just
> > kidding.
>
> Yes! You get a shiny copy of gcc! I can't wait. The grand prize includes
> the source code that Bell once valued (in court) as costing > $50,000, in
> the 80's, I call it gnu utils: binutils, and friends!

Cool, that and a couple of bucks and I can go and buy a cup of tea.

>
> > I'm still NOT saying that you should mix and match programming styles or
> > languages. What I AM saying, is that the existence of a new style or
> > language does not mean that we should completely abondon existing
> > concepts, languages,
>
> I think we agree. I think that was the point that Noah was making as well.
> cout and printf are the same in pascal and objective pascal, can't
> remember what they are, though.

Well, abandoning concepts and languages is a little different than creating a 
new language mechanism that offers much more flexibility (with one keyword) 
than a bunch of function calls previously available.

>
> > Learn about the history and what goes on when you link to "C" libraries.
> > Learn about call stacks, how arguments are passed in function calls, etc.
> > Don't forget about this stuff because it's less important in an OO view
> > of the world. The OO view isn't the only valid view. Sometimes, it's not
> > even the best view for a particular problem at hand.
>
> Here, here.
>
> > > I wasn't sure when I entered this conversation, but I'm starting to be
> > > convinced that if you start in c, you really should end in c.
> >
> > Why?
>
> B/c as you said above, you shouldn't mix and match language concepts. Wrap
> a c-function in a struct if you want oo.

Noooooo.... Sorry, that's not at all what I meant to say. I have one word for 
you: Inheritance. Without inheritance, you are missing out on a great deal of 
the benefits of OO. Then, you've got to virtual functions and abstract base 
classes, and.... Hey, the work has already been done for you. It's called 
C++.

If you really want a language holy war, try to discuss the 
strengths/weaknesses of single vs. multiple inheritance. But, we won't go 
there...

>
> > > Probably too vague to make sense. OK, how about printf vs. cout? I
> > > think that cout should inherit fprint rather than being different. I
> > > heard that there are troubles when they are mixed. I don't know. I
> > > forgot all about printf and only use cout. But they should be the same
> > > syntax, cout should be called printf and do things a bit better.
> >
> > But, you have been given two options here. You can provide a method for
> > your object to return a result suitable for printf, or you can make your
> > object work with streams, or you can make your object work with both - if
> > you need or really want to.
>
> I'd rather have a better printf, only.

You can always write your own:)

>
> > The advantage to the cout approach is that if you make your object work
> > with streams, then you can use it for other streams besides just cout. If
> > you want to just use it with cout, that's fine too. C++ provides you with
> > much more power and flexibility that way. This does require you to know
> > what you are doing. But, once you know what you are doing, its very
> > difficult to give that flexibility up.
>
> I agree. I think I'd miss pointers in java. Also, I did think that it was
> easier to 'start' a program in c++ than it is in java. Maybe that's just
> me. I have been told that there are pointers in java, but they are
> 'hidden'. And no, I don't mean in the c-code that java is probably written
> in.

I believe that you are referring to References and aliasing in Java. This gets 
into "Pass by Value" and "Pass by Reference" and how you think of passing a 
Reference to an object in Java, which is another matter that can be argued 
with little or no resolution.

In short, Java does have a notion of "pointers", but not pointer arithmetic. I 
would say that this is definitely safer for the general programmer.

>
> > And, printf vs. cout is such a minor aspect of C/C++. sprintf, snprintf,
> > vprintf, vsprintf, and vsnprintf are much better examples, just kidding.
>
> Never heard of them, but I get the point.
>
> > > > I'll give an example of C++ evolution: the addition of exceptions and
> > > > templates. Is this not evolution in your book? Again, IMHO, C++ has
> > > > been evolving and is still evolving. Very few c++ compilers have
> > > > caught up with a substantial percentage (> 90%) of the features of
> > > > the language.
> > >
> > > This is where I get mad. Probably similar to where you took exception
> > > (get it?) to 'broken' as a bio major, I don't like to see bio terms
> > > used outside of bio b/c the result is ambiguous, things can be argued
> > > either way, computers are not alive, etc.
> > >
> > > I don't think that c++ 'evolved' from c b/c evolving implies that it
> > > did so itself w/o forethought. Languages are created by humans and they
> > > are planned. Also, evolution rarely means adding lots of new features
> > > that don't mix well w/ the old features, but rather changes of the
> > > older features. c++ did take ideas from other languages. Creatures that
> > > evolve never do so. If they happen to be similar to others then this is
> > > covergent evolution, but it's not directed.
> > >
> > > When c++ was created, it was to add classes to c. I think that this was
> > > supposed to be evolved, but it doesn't look that way to me. Sorry.
> >
> > Well, if you and/or Noah want to learn about the design and evolution of
> > C++, read it from the source. Bjarne Stroustrup has a book out, titled,
> > "The Design and Evolution of C++". If you guys want to understand what he
> > did and why he did it, go ask him, or read his book. And, I'm sure he
> > didn't come up with all of these ideas by himself, but he was certainly
> > one of the primary focal points of all of the activity. But, he probably
> > covers most of this in his book. I haven't read it, but I recommend it to
> > anyone that wants to discuss his design intentions.
>
> I might have skimmed it. Shows how much I remember. The main point that no
> matter what he says, I don't like the word 'evolved' in this context. I
> prefer 'bolted on' :) or 'modified'.

I would suggest 'extended', but I don't think that completely covers it. 
Perhaps 'modified and extended'. How does that sound?

>
> > > > "C" funtion definitions in the middle of a module with a bunch of
> > > > member function definitions. I'm saying that you can CALL a "C"
> > > > function from the middle of a member function definition. In fact,
> > > > many times you HAVE TO for system calls. Unless you want to rewrite
> > > > your entire system library in an OO paradigm. And, I don't recommend
> > > > that.
> > > > No matter how much you abstract it and wrap it, the actual system
> > > > call is usually burried in there somewhere. And that's OK.
> > >
> > > Just like everyone's favorite language is written in c. I understand
> > > that. And c was originally written in assembly.
> >
> > Actually, I believe that the C++ language was actually written in C++.
> > There was a preprocessor to generate the C for compilation. But, Mr.
> > Stroustrup claims that C++ was actually written in C++. I'm sure he would
> > disagree with some of my recommendations about good design concepts, etc.
> > but this little nugget is on a FAQ of his somewhere. I could find it if
> > you were interested.
>
> He probably wrote part of the spec in c, then rewrote that in c++ using
> his c coded c++ compiler, then recompiled it all in c++ w/ the c++
> compiler, then finished the spec in that subset of c++, then rewrote
> everything using all the full methods from the c++ compiler to optimize.
> I'm guessing here.

I'm pulling from his FAQ. Specifically, 
http://www.research.att.com/~bs/bs_faq2.html#bootstrapping

"The first C++ compiler (Cfront) was written in C++. To build that, I first 
used C to write a "C with Classes"-to-C preprocessor. "C with Classes" was a 
C dialect that became the immediate ancestor to C++. That preprocessor 
translated "C with Classes" constructs (such as classes and constructors) 
into C. It was a traditional preprocessor in that it didn't undestand all of 
the language, left most of the type checking for the C compiler to do, and 
translated individual constructs without complete knowledge. I then wrote the 
first version of Cfront in "C with Classes". 

Cfront was a traditional compiler that did complete syntax and semantic 
checking of the C++ source. For that, it had a complete parser, built symbol 
tables, and built a complete internal tree representation of each class, 
function, etc. It also did some source level optimization on its internal 
tree representation of C++ constructs before outputting C. The version that 
generated C, did not rely on C for any type checking. It simply used C as an 
assembler. The resulting code was uncompromisingly fast. For more 
information, see D&E."

>
> > > > To me, OO does not mean "don't create procedures anywhere". IMHO, it
> > > > does mean simplify and group functions with relevant data. If you
> > > > don't have a set of related functions and have no related data that
> > > > you need to keep with that function (different data every time you
> > > > call the function), then you probably don't have a new type of
> > > > object.
> > >
> > > I'll make one anyway. What the hey? :)
> >
> > But WHY? If you just need one function, why not just write one function.
> > I'm not even suggesting to extern "C" the thing.
>
> Cause I'm a novice programmer who had too much oo advocacy. I'm laying off
> the future. This was mostly a joke.
>
> > > Almost everyone agrees, they just can't make up their mind what
> > > 'simpler' means.
> >
> > Yes, there are probably a select few in every group who could argue even
> > the "which is really simpler" argument.
> >
> > However, I think if everyone is looking at two things that accomplish the
> > same goal, most people can achieve a consensus on which one is generally
> > simpler, unless the difference is not material.
> >
> > Usually, when two people are asked to implement the same task, one of
> > them will provide a clearly simpler solution. When the two of them work
> > together, they can frequently come up with a third solution, which is
> > even simpler than the previous two. This is one of the reasons that Pair
> > Programming is a somewhat new and interesting concept.
> >
> > I'm not talking about words such as elegant, better, etc. But, simplicity
> > is usually a criteria that most non-argumentative people can agree on. If
> > you need to, you could switch to # of lines of code as the most basic
> > measurement, but that is typically an unnecessary over-simplification.
> >
> > I find that many people don't necessarily LIKE the simplest solution.
> > They often like some esoteric artifact of a slightly less simple
> > solution. Or, they try to anticipate future requirements which have not
> > been provided yet. Again, provided a specific set of requirements and two
> > solutions that satisfy the requirements, most people can arrive on a
> > consensus of which one is simpler.
>
> Well, that was my point. I saw things in c book done the 'hard way' and it
> was easier to read. Then I saw the simple way and I was blown away by both
> the terseness and the difficulty to read. I think in the end, I'll take
> the terse way, but comment it--this is a black box that does x--just pass
> it these values!
>
> > > > efficient and less code to just call the system library directly.
> > > > And, that's OK! Most of the time, though, you should stick with
> > > > what's provided by QT and not worry about what's underneath.
> > >
> > > I don't know if you were reading the list when I decided to 'roll my
> > > own.' My head still hurts from all that hell.
> >
> > I may or may not have. What exactly were you rolling your own of?
>
> Don't laugh. Please be nice... cp :(

OK, that's fine. I'm not laughing. I actually remember the thread now.

>
> > I don't personally partake in the most literal "roll your own"
> > activities. But, I'm sure I could find someone that could provide
> > something that would alleviate that headache of yours... Just kidding.
> >
> :)
> :
> > Seriously, what project were you working on? I don't recall. If it was
> > specifically a cross-platform GUI C++ library (such as QT), I would
> > personally recommend finding one to contribute to, rather than "start
> > from scratch". There are many GUI libraries out there with various
> > strengths and weaknesses. QT, wxWindows, FLTK, etc.
>
> I really don't wish to make a lib now. I am using qt to make an installer
> and I couldn't find a cp function in QFile (where I would put it). It is
> in QUrl, though. What the hey? But yea, I did find it and I'll replace my
> crappy implementation w/ this code shortly. It will make things easier on
> me.

Easier is generally a good thing. If things seem too difficult, it's usually 
because you just aren't familiar with an easier approach, or you just haven't 
thought of it yet.

>
> > If you've started one already, I wouldn't mind disucssing it, and
> > possibly trying to offer some contributions.
>
> God, you would flip to see the code. It really is a giant headache b/c it
> seems like it should be the easiest thing in the world. Libs are _not_
> working that should work. I have one which uses qt only, but it's butt
> slow. QUrl here I come!
>
> > > You have very convincing points. I'm just sitting on the fence, trying
> > > to take all this in. I never thought that c++ was 'broken' until Noah
> > > brought it up. I think you think of 'broken' in different ways.
> >
> > Well, my problem is more with stating opinions using what look
> > grammatically like statements of fact to me rather than opinions.
> >
> > Specifically,
> > "I have some respect for C.  Very little for C++ (it's just broken! ..."
> > and "C++ was designed to be a temporary solution, and imo, it shows.".
> >
> > Particularly the second statement, the "designed to be a temporary
> > solution" doesn't look like a statement of opinion to me. In fact, the In
> > My Opinion (lacking the Humble of course :) was referring to the "it
> > shows".
>
> I'm glad you jumped in then. Always good to hear alternate opinions...I
> mean facts. :)
>
> > The concept of "broken" had not specifically gotten discussed much yet,
> > so I'm not sure specifically in what way Noah was thinking of C++ as
> > broken.
>
> I thought he meant suboptimal. We all know that c++ works in every
> possible way, sw can be written that's highly maintainable and reliable. I
> don't know anyone who would argue this. Most people would say that

I know some people that would argue this. Nice to hear.

> 'broken' means unmaintainable, unreliable, and really slow to develop in
> b/c of crappy idioms in the language.

I'd say that all of the reasons you've listed are things that CAN be 
accomplished easier in C++ than in C.

I find good C++ code easier to maintain, more reliable, and quicker to develop 
b/c of helpful OOP concepts.

One more time, anybody can write really crappy code in any language. IMHO, 
that includes ObjectPascal, C++, and Java. I know some people that are really 
good at writing crappy code.

I don't have any experience with ObjectPascal, but if you want someone to 
write some crappy code in ObjectPascal, I could give you a few references :)

>
> > > > We're starting to get into good OO design principles a bit. There's
> > > > definitely a lot of room for debate there. And, that goes for no
> > > > matter what language you are using.
> > >
> > > Well, I can see that I'm over my head on this one. I was just spouting
> > > off my opinions. Good to hear another view on this, though. Thanks.
> >
> > I'm glad to hear your opinions. I like open discussions. I'm still not
> > sure I understand some of your opinions on this discussion.
> >
> > I hope I haven't turned you off to C++, Java, or future discussions with
> > me. Again, my main concern was to raise an objection to what looked to me
> > like a couple of inaccurate "statements of fact".
> >
> > I'm also happy to take this offline if anyone prefers that.
>
> One of the best discussions on computer languages I ever had. I'm
> thoroughly enjoying myself mainly b/c of the intelligent remarks, copious
> respect,and the total lack of animosity and bad attitude that usually
> pervades these types of discussions.
>
> Fred
>

I'll take this at face value and say glad to hear it.

Here's hoping that any code we write is as enjoyable and full of "intelligent 
remarks, copious respect, and total lack of animosity and bad attitude".

Cheers,
Jason Nocks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj0szgMACgkQ3CryLfCgqRkFQwCfQKkKMnbdh2lPAjJ/u7F0013P
ltoAnjXKGQob+cWKBEab9bekW5QC8fRd
=uOag
-----END PGP SIGNATURE-----


______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug