× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Hans Boldt
>
> Sure, computer programming in general is hard. And like sculpture
> and brain surgery, requires some level of inate talent. But what the
> heck is wrong with trying to make the task easier? Do you think that
> programming tools have to be hard just for the sake of being hard?

Easier for whom?  Someone who has been using the language for 20 years and
now has to decide which syntax to use and has to stick /free and /end-free
in his code just to use new features of the language?  Or for a new
programmer who doesn't want to take the time to learn the RPG syntax and is
confused by something as fundamental as a MOVE instruction?  And how is it
your choice as the compiler writer to decide who should get preferential
treatment?

See, this is the part I don't get - you seem to think it's your mission in
life to guide our programming habits, and this seems to be the siren song
that some others have bought into: that somehow, by squeezing "bad" opcodes
out of the language, you'll one day lead us non-believers into programming
Nirvana.

I disagree.  It's not your choice to tell me whether I should use a MOVE or
not, especially if I've been using it for 20 years.  Removing the MOVE
instruction does not make programming easier for everyone, and it certainly
adds complexity to the maintenance process.  These are bad things, and you
choose not to see them.  And yet, if your stated purpose is to remove the
MOVE instruction from the language, then have the courage to say so, and
offer decent migration tools to that end.  Simply removing MOVE and letting
us sort it all out is not the way to do it.

I proposed a very simple way of letting us decide how to get there... add
free-form sytntax to fixed mode, and add %MOVE and %MOVEL BIFs - neither one
of these requires any significant addition, especially if you're writing
reusable code the way you preach.  Then, give us a converter that will
convert all old-style opcodes to the equivalent "extended fixed" format.
Let us clean up whatever ugly things we want, and then convert us next to
the true free format.  This is simply the next generation of the CVTRPGSRC
that you should have provided with /free anyway.

This would not be a lot to add, it would make the conversion process tons
easier, and it would at least be a nod in the direction of those of us who
work with the language for a living.  Yes, you'd have to support at least a
form of the MOVE instruction in your brave new RPG, but it would be isolated
and easy to spot, and people could convert it as it makes sense to them...
not you.


> At the risk of sounding like a broken record, consider the Python
> language. Of the programming languages in use today, it's probably
> the easiest to learn and use. That ease of use is one of the biggest
> reasons why some Pythonistas claim that the language offers a 10
> times productivity improvement over others. Thats 10 *times*, not
> just 10 percent. If I can write a fully functional HTTP server in 3
> lines of Python code, I tend to believe that claim. To clarify my
> point here, making programmers lives easier in Python's case
> translates into a (quantifiable) productivity gain.
>
> (You could argue that much of Python's benefits arise from the rich
> class library. On the other hand, the language has allowed for a
> rich and easy to use class library without being overwhelming, like
> the class library of one other particular OO language.)

You just couldn't wait, could you?  Your views are so distorted by this that
I guess we need to address it.  Let's analyze if Python has any use in the
business world, shall we?

Can you write an ERP system in Python in three lines, Hans?  Write an MRP
generation.  Write a finite forward scheduler.  Write any of those things,
and I'll agree with you about Python.  But see, you said it yourself, Python
has a great class library - that is, other people's code.  It's not the
language you rave about, it's the amount of pre-written code you can call.
But if the code ain't there, you can't do it.

To be fair, you should only compare languages based on their base
capabilities, not their class libraries, unless the class libraries happen
to match what you're doing - in which case, you're really not developing
anything new, you're just cloning.  And that's what you're talking about,
Hans - cloning.  Writing yet another version of something somebody else
wrote.  Yep, Python clones well.

But that doesn't work in my world, where I'm building unique, custom
business solutions for each and every client.  In my world, we actually have
to design new architectures and custom solutions, not just reuse existing
code.  I also have to maintain existing code, and somehow figure out how to
make old and new work together.  I don't have the luxury of writing
everything from scratch using someone else's class library.  So maybe that's
why you and I see things differently.  You code in a laboratory, or for a
hobby, with no worry about existing code.  I code for a manufacturing shop
that lives or dies on its software, both existing and new.  Different point
of view, eh?


> Now then, because Python is an interpreted language and RPG is a
> compiled language, RPG can never hope to match Python in usability.
> But still, what's wrong in trying to make the job of the RPG
> programmer easier?

You want to make RPG programming easier, fine.  Just do it fairly and
evenly.  Removing the MOVE instruction is neither.  But then again, I'm
going to do something you neglected to do... I'm going to ask people if they
like the MOVE, and how it affects their planned adoption of free-form RPG.
I'll let you know what I find out.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.