Is there a programming language that is combination of Python andBasic?

[Aaron Brady]

On Apr 19, 3:05 am, "Hendrik van Rooyen" <m... at microcorp.co.za> wrote:
>  "Aaron Brady" <casti..... at gmail.com> wrote:
>
> On Apr 18, 4:44 am, "Hendrik van Rooyen" <m... at microcorp.co.za> wrote:
>
> >> to untangle some spaghetti code. He did not mention if
> >> the spaghetti was actually doing it's job, bug free, which
> >> IMO is the only rational test for the quality of a piece
>
> >I don't use 'rational' in the same way.  Do you mean objective?  Do
> >readability, brevity, simplicity, purity, etc. contribute to quality?
> >Is program quality equivalent (or identical) to code quality?
>
> This paragraph illustrates the problem, I think:
>
> Is there a significant difference between "rational" and "objective"?
> Define "readability, brevity, simplicity, purity, etc" as applied
> to the quality of a programme - it leads, inevitably, to a floundering
> around in a wash of words.

It is an old philosopher's problem, that is, a problem of old
philosophers: do all rational wo/men behave the same given the same
situations, or more specifically, analogously given related
situations?

Rational and objective are related, I think.  An objective test of
code would be a process anyone can follow and derive the same result,
such as how many identifiers it contains.  A rational test involves
some sort of abstraction of humans, such as what the ultimately
rational human likes most, etc.  Objective partial credit on an exam,
for example, must come from a black-and-white rubric with exactly no
room for interpretation.  Rational partial credit could involve
inferences, guesses, and context, esp. acquaintance with the taker.

I agree that many of those traits are matters of degree and multi-
dimensional.  I am looking for an objective metric of code: code X has
traits P, Q, and R.  Period.  It would probably be simpler to start
describing code objectively, rather than trying to square-peg-round-
hole existing words.  However, there may be no objective test of
especially large sizes of code, and may fall to some sort of
interpretation or assessment of the most rational wo/man.

If I disagree with your measuring of a code with objective criteria,
we merely walk through the measurement, and resolve our disagreement
from the criteria upon discovering it.  If I disagree with your
measuring of it with rational criteria, we have to take into account
all sorts of trade-offs, such as long-short term, one-many readers,
different consequences, etc.  I'm speculating a little bit in defining
those words.

I advance that two equifunctional programs (same input-> same output)
can be compared w.r.t. brevity, to take an example, up to isomorphism
of identifier names, control structures, and statement order.  That
is, we can determine how brief code X is, disregarding identifier
names, and statement order where irrelevant.  Control structure
brevity might be something we're trying to measure:

while 1:
  if cond(): break

while not cond():
  ...

Are these equally brief, assuming they accomplish the same thing?  If
we don't have unanimous agreement on the answer to that question, we
must conclude that even brevity is a composite trait and we'll have to
start simpler.  A theory of traits would have to make concrete
predictions about *something*.  If some code has trait P, it will Q.

> However, to stop playing Devil's Advocate, there is such a thing
> as code quality, but it cannot be defined, just like quality in general
> terms cannot be defined - as soon as you try, it turns to dross in
> your hands.  Read Robert Pfirsig's "Zen and the art of motorcycle
> maintenance" for a full explanation of this effect.

Are you saying that quality reduces to how pleasant a particular
reader, or composite of multiple readers, finds the code?

"In the 1960s, programmers gave goto statements an average rating of 6
out of 10, 10 being most pleasing.  In the 70s, that rating dropped to
5 out of 10.  Subroutines were initially disliked, but came to be
favored, advancing from 4/10 in the 60s to 7/10 in the 80s and on.
Possible confounding variables include the increase in processor speed
and thus the increased forgivingness of running time of gosubs; the
prevalence of languages capable of generating subroutine calls; and
the efficiency of the particular calls generated, surveys of which
were not attempted."  --Fabrication

> >> I do not agree with the reasoning that effectively says:
> >> "If it is difficult to comprehend, it must be wrong"
>
> >Wrong no, but impractical, possibly or probably or almost certainly,
> >notwithstanding the subject-dependence of ease of comprehension.
> >Simple code is more future-resilient than that which is difficult to
> >comprehend, even holding the language (version) constant.  It is a
>
> I think that the emphasis on future proofing code is actually overrated.
>
> We try to code as if we are building pyramids, for all time, but the sad
> experience is that only a tiny percentage of application code written has
> a life of longer than about eight years.

Project managers should, I judge, be versed in the trade-offs between
time spent now and time saved later, especially even before a release
date!  That is, for arbitrary unforeseen additional requirement Q, how
much time will it take to add it from path A, vs. from path B?  This
is a sophisticated judgment call, and possibly as much as mostly
guesswork.  I don't know.

> 8<------------------------------
>
> >that of exploration, pioneering, research, and development.  However,
> >even in simplest terms, some structures e.g. recursion, may be
> >difficult to comprehend, but that doesn't mean they would be better
> >more complicated.
>
> This is true - the one does not imply the other, but the subtlety is that
> it cuts either way - not more complicated, and not more simple.

A 'simpler than' relation should be transitive if it's to be
objective.  The simplest recursive solution and the simplest iterative
solution would make a good comparison.  If the 'simplicity of'
predicate is not defined over the entire set of code, I hold it's not
objective.  'X not simpler than Y && Y not simpler than X' should
imply that 'simplicity( X ) == simplicity( Y )'.  However, it needn't
imply that X==Y, and neighboring trait priorities could diverge.

> One
> has to strike a balance, and this is closer to an art than a science.
> That said, however, throwing out the goto ( or even the more intriguing
> comefrom ) is forcing the artist to paint while removing an element from
> his palette - he has to work around the lack.
>
> - Hendrik

I think there could be any amount of beautiful but useless code.  But
we're (uh... for some value of 'we'... heh heh) trying to measure the
utility of a piece, IBNLT including but not limited to its future
value or value elsewhere, that is its /re/usability.

The decision to exclude 'goto' from Pythoneers' tools, or blue from a
some artists' palettes, has unifying effects, such as creating a
"secret club" mentality.  It also may have pedagogical value, such as
making the language easier to learn for many or most.  "Beginners
always abuse blue hues, so we won't include them in our kits."  (I
would have to perform the study that proves it however, or like or
trust the agency that makes the claim, in order to consider it in my
decision to acquire Python as a language.)  Its disadvantages include
a lower ceiling on program efficiency, as well as a shade of brevity.
Other claims about utility, such as clarity and reusability, which are
such, I hold, have yet to be proven.