Jason on Thu, 11 Jul 2002 12:27:16 -0400


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Pascal?


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

On Thursday 11 July 2002 02H:26, Fred K Ollinger wrote:
> > 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.
>
> Usually, I would agree, but now I'm thinking no. True, I would want more
> options, but I wouldn't want to maintain a codebase which is a hodgepodge
> of a million languages. We are not at that point yet, but we do have a

Still not clear on why giving developers the option to choose a language means 
that they must create a codebase of a hodgepodge of languages. A given app 
should be developed primarily in one language.

The point is that right now we need to allow *different apps* to be created in 
*different languages*, because most languages are not sufficient for *all 
users*. C++ being a good case in point. Quite widespread in use, but still a 
lot of interest in alternatives. String processing being a particularly weak 
point in comparison to some of the alternatives. Go try to convert all of the 
pearl programmers into solely C++ programmers. Good luck!

> problem in my current job w/ some scripts b/c they are in python and
> nobody knew that language. Python my very well best perl, but it was a

If nobody knows it, then how did it get written? Just another attempt at 
humor, here.

This sounds like a poor decision to let the one guy who knew the language go 
off and do his own thing. Or, the guy learned it to add it to his resume, 
then went and found another job.

The real problem here is a lack of training. If Python is going to be used at 
a company, the developers ought to be trained in Python. People should not 
have to learn everything on the job while working on production code. That's 
not to say that it doesn't happen, but it should definitely happen less 
often.

> hassle to find someone to fix it.
>
> I'm thinking the same should hold true in a language. TIMTOWTDI might be
> good when you are composing a beautiful section of code, but I'd rather
> you did it as closely as how I (and others) would do it. I'll take
> readablilty over elegence on most days.

There are a couple of problems here.

First, defining the "right" way to do something is dependent on what the 
requirements are. People are not robots. Generally speaking, they/we like to 
think, be creative, and expressive. We are good at adapting our approach to 
solve each unique problem. This is along those lines of evolution you were 
talking about. We adapt to our environment. We are not good at sticking to 
hard and fast, constrictive rules.

If you are talking about trying to arrive at the most simple solution for a 
given problem, I agree with you to an extent. The problem is, for almost 
every given set of requirements, there is a simple solution that is unique to 
that set of requirements. The reason we have all of these different 
languages, functions, techniques, etc. is exactly that, to make it easier to 
solve a specific set of requirements.

If we could define all of the simplest solutions for all of the possible sets 
of requirements, then great. We'd be done. Oh, we could go one step further, 
and possibly find the smallest subset that would still result in an 
equivalently simple solution for all of the unique problems.

Then, we would all be able to stop developing software and move onto something 
more fundamentally important to the physical world out there. When do you 
think we'll be finished with creating all of the software that we need in the 
world? Oh, and by the way, because people are generally prone to human nature 
and most software is written for human usage, the requirements will often 
change.

Another problem here is that we don't have the answer to the problem at hand 
until we're done (and in the worst case not even then). If we had already 
come up with the solution, why are we writing new code? This is where reuse 
of objects in OO can help. When you have truly solved the problem, you are 
done. Move on to the next problem. In the process of development (finding the 
solution), keep things simple and try to make the code readable for bug fixes 
and when the requirements change. And, try to reuse objects that you've 
already written.

<snip>
> Right b/c I like arcane things. And I have heard the power of c, but never
> felt it myself. Mostly for me, I feel like I'm in the stone age w/ just
> pain c. I know that's mostly lack of skill, so I'm not discouraged.

I wouldn't say that a lack of familiarity with a large set of functions 
equates to a lack of skill. Experience, however, should help in both areas.

<snip>
> > 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.
>
> And this is different than keeping old, crusty things along-side new
> things.

Well, printf is just one crusty thing that was kept in addition to adding the 
new cout as mentioned. There are plenty of crusty old system calls that do 
not have a direct replacement in C++. That's why I kept mentioning that 
sometimes we need to call those crusty old C functions in C++. And, some 
people like the crusty old C functions. Others like the new fangled C++ way 
of doing things.

I have tried to get familiar with both. I think that they both have their 
place. And, I certainly try to avoid switching back and forth within a 
section of code, within a module, and within an application. I think 
minimizing the switching back and forth and mixture of approaches is a good 
thing. Minimizing is totally different from 'preventing' and 'disallowing'. 
Because, sometimes it's necessary. And, that necessity doesn't just go away. 
When you try to force it out of existence, you just push it arround and make 
some peoples lives unnecessarily difficult.

<snip>
> > 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.
>
> I have heard that pointers are like playing w/ fire. I have had segfaults
> all over the place for some random reasons. Pointers must be going every
> which way, but they look ok to me. I usually get it fixed w/ trial and
> error and all the segfaults go away. I know that if this isn't
> straightened out sometime it'll all come back to bite me, but so far it's
> one segfault bug at a time until I clear it then there are no problems.

First, you have probably been given reasonable advice in this instance. It's 
like being told "Don't play with matches". After a certain amount of 
experience, you start to learn when it's OK to "play with fire" and you start 
to say to yourself, "Fire GOOD!" Except, it's not that the fire is good, it's 
just powerful. Then, you bring on the explosives! Let the fun really begin!

In this analogy, I'll equate pointers with fire and pointer arithmetic with 
explosives.

There are some people who need to play with fire and explosives as part of 
their job description (pyrotechnicians/low-level programmers). There are 
others who may just need to employ the benefits of the use of fire. The 
problem is, the need for fire doesn't just go away. You just put protective 
layers between the user and the fire. Most people have absolutely no need for 
explosives. That's fine for most people, just don't prevent the 
pyrotechnicians from getting their job done.

What does this mean in C++? People should probably generally use references 
(the protective layer) when in doubt. And, most people should strictly avoid 
pointer arithmetic. Only well-trained pyrotechnicians should be allowed to do 
pointer arithmetic. But, they do need to be able to do it. And C++ does have 
the protective layer, called references.

Just because a potentially useful feature is there in a language doesn't mean 
everybody has to try to find instances to use it!

Most developers should avoid playing with fire. But, that doesn't mean that we 
have to outlaw matches!

<snip>
> > 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.
>
> I meant easier b/c
> 1. this should be easy as there are many well-trod idioms

Yes.

> 2. why the hell isn't this a library fuction? I spent at least half an
> hour looking for cp somewhere. They have rename(), but they hey? I almost
> wanted to grab code for rename and try to shoe-horn that into cp.

Yes, there probably should be one that does what you were trying to do. But, 
you can't even get programmers to agree on the one way that a basic function, 
such as cp, ought to work for ALL cases. This is again because even cp is 
different depending on what exactly you are trying to do. Implementing such a 
simple function to accomodate so many different users is surprisingly 
difficult in procedural programming.

I haven't explicitly checked all of these, but most OO C++ libraries (QT, MFC, 
wxWindows, etc.) give you a file object (or equivalent) that either has a 
rename or a copy and delete, or all of these.

> 3. cp is not that complicated, it should be write once function instead of
> a never ending mess that really didn't work right

Well, it does work for those who have a good deal of experience with the the 
underlying system calls. What is needed is better encapsulation of that 
knowledge. This is where OO is supposed to, and IMHO does, help.

> 4. there really should be a library function--I know I said this before

I agree with you here. This is where procedural functions start to run into 
problems. Unfortunately, you'll probably never be able to come up with ONE 
function that will handle the requirements that all of the C programmers 
would be satisfied with. Many would still write their own. I don't think it's 
because they prefer it that way, it's just because you can't get agreement on 
ONE function for everybody.

The best thing would probably be to provide one function that met the needs of 
most users, and let those that knew what they needed write their own. This 
often doesn't happen though. Maybe it's because we spend too much time 
discussing what the *right* function would be.

<snip>
> > 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.
>
> If anyone is still listening, let's see some really crappy ObjectPascal.
> We saw bad c++ a few weeks ago. :)

Well, I would give most PLUGers the benefit of the doubt and recommend that 
you might want to look elsewhere for really crappy code, including 
ObjectPascal of course!

<snip>
> My code has lots of animosity, but I'll make it respect me. :)

Actually, I was referring to the code being enjoyable, etc. for others. But, 
it should certainly be for you as well.

I doubt many others besides the two of us are still reading, so we should 
probably take this offline soon. I agree that this was a good dicussion, 
though.

>
> Fred
>

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

iEYEARECAAYFAj0tsbwACgkQ3CryLfCgqRnRTwCeIDZ2StB3cj99I+8yz9wwA6ej
/ecAn0hFG4vHMeaKTlDdtzRx+HvsRu5R
=slzF
-----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