Considering migrating to Python from Visual Basic 6 for engineering applications

[BartC]

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