|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
-----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
|
|