On 21/02/2016 21:52, Jussi Piitulainen wrote:
BartC writes:
But this is not so much to do with VB6, but with a very fundamental
capability that seems missing in modern languages.
All that's missing is a minor convenience that turns out to be mainly
awkward. Not at all fundamental.
It /is/ fundamental because it mimics how humans interact:
"Give me 3 numbers:"
"OK: ten, twenty and twenty-nine."
"Yeah, they'd make a triangle."
The capability of parsing simple input formats is easily composed of
more generally useful components that are available. As demonstrated in
this thread.
Yes, by having a box of parts you first have to figure out how to put
together!
IIRC, the first programming exercise I ever did (in 1976 using Algol
60) involved reading 3 numbers from the teletype and working out if
those could form sides of a triangle.
That was a lousy user interface even then - an inflexible user
interaction without even a possibility of handling errors interactively?
Command line arguments would have been better (if available, that is).
The big deal about that kind of interface was it that it /was/
interactive (compared with batch processing or job control or whatever.
I remember using punched cards; those certainly weren't).
Command line arguments are not interactive. If the name of the program
is Triangle, and someone types:
>Triangle
the probably nothing happens. Or it generates an error message. Or it
appears to hang.
In Python, use the interactive loop instead (or command line arguments,
of course, or input(), and I think it's slightly simpler to use input()
three times than instruct the user about how to separate the three
numbers).
Basics also used to use interactive loops. Separating the numbers I
don't think has ever been a big problem. Obviously you can't type ten,
twenty and thirty as 102030, but will need to use white-space or
punctuation. It doesn't take long to figure out! (And how do you
separate command-line arguments? Have you even thought about it?)
Now, nearly 40 years later, I don't actually know how to do that in
Python! Sure, I can cobble something together, with all sorts of
functions and string operations (and I would need to go and look them
up). But it's not just /there/ already.
It seems you'd need to look them up in Algol 60 and Basic, too. Nothing
wrong with that.
Yes, and it would say use 'readln' or 'input' or whatever. In Python,
I'd get two-inch-thick manual full of library functions and modules I
can use to /implement/ 'readln' or 'input'!
It's *good* to be able to cobble together a simple one-liner that does
what you want with fundamental, reusable components. Or a three-liner if
you *want* something more complex.
But this is advanced stuff for a beginner. (I'm not a beginner and it's
advanced for /me/! Well, more of a nuisance when I want to quickly do X
but first need to figure out Y, some input routine.)
Or a page of code to fake something
that is really AI-complete, if *that's* what you want. But mainly I mean
that the present problem is just trivial, and what do you do with the
Basic command if you have a slightly different input format - does it
scale at all? If there is extra text on the line before the numbers? If
the numbers are separated by commas, or semicolons?
I don't know the details of how Basic does it. But it seems to allow any
reasonable separator, while asking for more input than is provided on
the line sets those extra variables to 0 or "".
If you gave this a Python exercise to a class of students, you'd end
up with 30 different solutions just for the first, easy part of the
exercise!
Well, why would they write code that asks for interactive input at all?
They can simply call their triangle-testing function in the Python
interactive loop and specify the integers as arguments:
def istriangle(*threeintegers):
a,b,c = sorted(threeintegers)
return a*a + b*b == c*c
(That detects right-angled triangles. I think 'return a+b>c' is the
correct test for any triangle. It becomes trivial when you have sort
available, but that's part of the point of the exercise.)
istriangle(3,4,5)
True
istriangle(3,1,4)
False
Yes, this is a good next step, to separate the logic from the job of
acquiring the data (and to learn about with subroutines or functions).
But this way, you're putting off the job of requesting interactive data
from a user. If A is the chap writing the program and using the tools,
he might want B to be the one running the program and entering the data.
B won't be running the interactive loop; he won't even know what
language it's in. (And the OP wants B to run an EXE.)
And then there are all the common data sources and formats (CSV, JSON,
XML, ...) that change the game altogether. All the functions and
expression types used to parse the simple input lines in this thread are
still useful, but what use is that very special Basic input command now?
None whatsoever.
Not at all. Once you've got the hang of reading a line of interactive
input, then the same program can be given redirected input from a file.
And the OP's example was reading from a file anyway.
(Some formats will need more sophisticating parsing; that's advanced
stuff though. Advanced enough in fact that you wouldn't attempt parsing
them; just use a library.)
Reading stuff from an interactive console or terminal, is such an
important part of the history of computing, still being used now, that
you'd think a language would provide simple, ready-to-use methods ways
to do it.
Would it have hurt to have done so? Then it would be easier also to port
existing programs.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
