Chambers wrote:

> Something that people don't tend to believe: programming is *hard*.  It 
> is *not* a simple matter to sit down with a sheet of requirements, and 
> pound out the class (though having a properly written spec makes it 
> easier).  And, believe it or not, most programmers' jobs could *not* be 
> done by a bunch of monkeys.
> 

I drafted a rather longer reply to this, but thought better of it. I'll 
say only this
programming is *not* hard, but it cane be made hard.

David

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> > I wonder if it would it be possible for POV to expose its core functions
> > in a standard way (eg in a dll for windows), and then you can access
> > them from any programming language you like.
>
> I propose Ook!

Stupid monkey.

(*hands over banana*)

Post a reply to this message

On Sat, 25 Jul 2009 10:48:03 EDT, "clipka" <nomail@nomail> wrote:

>Chambers <Ben### [at] gmailcom_no_underscores> wrote:
>> > I wonder if it would it be possible for POV to expose its core functions
>> > in a standard way (eg in a dll for windows), and then you can access
>> > them from any programming language you like.
>>
>> I propose Ook!
>
>Stupid monkey.
>
>(*hands over banana*)
>
>

Ooo! Big trouble when the librarian gets you :-)
-- 

Regards
     Stephen

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I drafted a rather longer reply to this, but thought better of it. I'll
> say only this
> programming is *not* hard, but it cane be made hard.

As a professional SW developer, I can tell for sure that it depends a lot on the
size (and even more so complexity) of the project, and the operational
parameters to match (memory limits, performance requirements, stuff like that).

If your projects are the size and complexity of a typical POV-Ray scene with
some occasional loops, you're right: That's not hard at all.

If however your project is a POV-Ray animation employing some mechanics
simulation, and you don't have access to a mech sim framework developed by
someone else already, you *might* come to the conclusion that programming can
also be hard all by itself.

And if you were to develop software for a bluetooth handsfree unit to be
integrated into a car, or a modern computer game, you'll certainly find how
hard programming can be.


One problem with OOP support in many mainstream languages is probably this:
They're designed to manage complexity in medium-sized projects (for really
large projects, even those languages may not be good enough); if they do that
well, nobody will complain about the additional overhead they impose, because
it really pays off a lot. However, in very small projects this overhead becomes
more of a burden than a benefit, because the projects don't really have much
complexity in need of being managed.

Mind you, this overhead is imposed not by object-oriented programming as such,
but by the languages. The more formal it is, the more suited it is to manage
complexity. But, of course, that formalism makes it also less suited for
programs you could throw together in a few hours if it weren't for the
formalisms.

I do love Microsoft's C# programming language and IDE: It's really one of the
most powerful environments I have ever used for development, and it's really a
pleasure to use it. I can't think of anything better suited for projects the
size an experienced hobbyist programmer could ever hope to pull off alone.

However, when I develop, say, a small straightforward command line tool I expect
to throw together in a matter of two or three days, C/C++ is actually my
favorite weapon: I can start off with plain old-school C imperative programming
(interspersed with some C++ syntax that has nothing to to with OOP, like line
comments, references, bool data types and the like); if I then happen to
encounter some unexpected complexity, I can throw in a bit of C++ to define
some objects anytime, but keep the program C-style otherwise.

This is the kind of OOP support I'd expect for a POV-Ray SDL: As long as your
project is straightforward, it doesn't bother you with any formalism
whatsoever. But when the task at hand gets complex, that OOP support is right
there for you to use, with all the formalism you need.

Post a reply to this message

Stephen <mcavoysAT@aolDOTcom> wrote:
> >> I propose Ook!
> >
> >Stupid monkey.
> >
> >(*hands over banana*)
> >
> >
>
> Ooo! Big trouble when the librarian gets you :-)

Ook.

Post a reply to this message

On Sat, 25 Jul 2009 12:42:08 EDT, "clipka" <nomail@nomail> wrote:

>Stephen <mcavoysAT@aolDOTcom> wrote:
>> >> I propose Ook!
>> >
>> >Stupid monkey.
>> >
>> >(*hands over banana*)
>> >
>> >
>>
>> Ooo! Big trouble when the librarian gets you :-)
>
>Ook.
>
>
No use trying to soft soap now Oook!
    :)
-- 

Regards
     Stephen

Post a reply to this message

clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
>> I drafted a rather longer reply to this, but thought better of it. I'll
>> say only this
>> programming is *not* hard, but it cane be made hard.
> 
> As a professional SW developer, I can tell for sure that it depends a lot on the
> size (and even more so complexity) of the project, and the operational
> parameters to match (memory limits, performance requirements, stuff like that).
> 
> If your projects are the size and complexity of a typical POV-Ray scene with
> some occasional loops, you're right: That's not hard at all.
> 
> If however your project is a POV-Ray animation employing some mechanics
> simulation, and you don't have access to a mech sim framework developed by
> someone else already, you *might* come to the conclusion that programming can
> also be hard all by itself.
> 
> And if you were to develop software for a bluetooth handsfree unit to be
> integrated into a car, or a modern computer game, you'll certainly find how
> hard programming can be.
> 
> 
> One problem with OOP support in many mainstream languages is probably this:
> They're designed to manage complexity in medium-sized projects (for really
> large projects, even those languages may not be good enough); if they do that
> well, nobody will complain about the additional overhead they impose, because
> it really pays off a lot. However, in very small projects this overhead becomes
> more of a burden than a benefit, because the projects don't really have much
> complexity in need of being managed.
> 
> Mind you, this overhead is imposed not by object-oriented programming as such,
> but by the languages. The more formal it is, the more suited it is to manage
> complexity. But, of course, that formalism makes it also less suited for
> programs you could throw together in a few hours if it weren't for the
> formalisms.
> 
> I do love Microsoft's C# programming language and IDE: It's really one of the
> most powerful environments I have ever used for development, and it's really a
> pleasure to use it. I can't think of anything better suited for projects the
> size an experienced hobbyist programmer could ever hope to pull off alone.
> 
> However, when I develop, say, a small straightforward command line tool I expect
> to throw together in a matter of two or three days, C/C++ is actually my
> favorite weapon: I can start off with plain old-school C imperative programming
> (interspersed with some C++ syntax that has nothing to to with OOP, like line
> comments, references, bool data types and the like); if I then happen to
> encounter some unexpected complexity, I can throw in a bit of C++ to define
> some objects anytime, but keep the program C-style otherwise.
> 
> This is the kind of OOP support I'd expect for a POV-Ray SDL: As long as your
> project is straightforward, it doesn't bother you with any formalism
> whatsoever. But when the task at hand gets complex, that OOP support is right
> there for you to use, with all the formalism you need.
> 
> 
Your points are well taken, I should have said programing is not 
*fundamentally* difficult.
A particular programming task may be difficult because it require a lot 
of time and effort, learning
the idiosyncrasies of all the systems involved and a lot of trial and 
error. A great deal of
experience programming may also be required. But fundamentally, 
programming is not difficult.
But it can be made so.

David

Post a reply to this message

David H. Burns wrote:
> Your points are well taken, I should have said programing is not 
> *fundamentally* difficult.
> A particular programming task may be difficult 

This, to me, sounds like saying "Chess isn't hard, only the opponents are!"

-- 
Chambers

Post a reply to this message

David H. Burns wrote:
> Your points are well taken, I should have said programing is not 
> *fundamentally* difficult.

It is fundamentally difficult. It's as fundamentally difficult as any 
applied mathematics. For sufficiently small problems, you may be able to do 
it in spite of it being fundamentally difficult.

> programming is not difficult.

Then why do you have such a hard time understanding simple things like OO 
programs? :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Chambers wrote:
> David H. Burns wrote:
>> Your points are well taken, I should have said programing is not 
>> *fundamentally* difficult.
>> A particular programming task may be difficult 
> 
> This, to me, sounds like saying "Chess isn't hard, only the opponents are!"
> 
This is a poor analogy. In chess the major difficulty is the opponent, 
but there is no opponent
in programming. But pursuing it anyway, the rules and moves of chess are 
relatively
simple. One can easily learn and use them, however the rules and moves 
*could* be made so
complex that it would be almost impossible to play even against an easy 
opponent.

David

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>> Your points are well taken, I should have said programing is not 
>> *fundamentally* difficult.
> 
> It is fundamentally difficult. 

I disagree strongly!
It's as fundamentally difficult as any
> applied mathematics. 
I disagree here too. I would say that programming is less difficult that 
much
of applied mathematics. And applied mathematics is in general not 
fundamentally difficult.
For sufficiently small problems, you may be able to
> do it in spite of it being fundamentally difficult.

This would seem to contradict the definition of fundamentally difficult.
> 
>> programming is not difficult.
> 
> Then why do you have such a hard time understanding simple things like 
> OO programs? :-)

They do not seem very simple to me, but a number of folk have said they 
are, so I may
have psyched myself into believing they are too hard and complex like 
many students
psyche themselves into believing that, say, chemistry is difficult and 
thus have a hard time with it.
Unfortunately they are encouraged (unconsciously or otherwise) by 
chemists themselves and
even by teachers. To my mind OOP with all its polysyllabic terminology 
is a fad and an obstructive
one -- but it may be that I am wrong and that my attitude has, so far, 
kept me from diving into OOP,
which in reality is relatively easy. :)

David


>

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:

>> programming is not difficult.
> 
> Then why do you have such a hard time understanding simple things like 
> OO programs? :-)
> 
P.S. It may well be that programming itself is easier than understanding 
a written program.
I'm certain that is sometimes (maybe often) true of C programs.

DHB :)

Post a reply to this message

David H. Burns wrote:
>> It is fundamentally difficult. 
> I disagree strongly!

How much do you know about it?

It's fundamentally difficult in that each line of a program does something 
new. If it wasn't new, it would already be finished and you'd just use it.

Building a 51-story office building is marginally harder than building a 
50-story office building.  Building a 51-million LOC program is not 2% 
harder than building a 50-million LOC program, because each of those new 
lines is something brand new, doing something never before done in that 
program, and needs to get plugged in. If it wasn't, it would still be a 
50-million LOC program with handfuls of calls to existing subroutines.

By the way, adding that appropriate handful of calls to existing subroutines 
is the area in which OOP powerful. If you don't understand the benefits of 
OOP, it's because you've never written a program difficult enough to need it.

>> It's as fundamentally difficult as any applied mathematics. 
> I disagree here too. I would say that programming is less difficult that 
> much
> of applied mathematics. 

*All* of programming *is* applied mathematics.

> And applied mathematics is in general not fundamentally difficult.

Sure. That's why they teach it in grade school.

>> Then why do you have such a hard time understanding simple things like 
>> OO programs? :-)
> 
> They do not seem very simple to me,

Yet, oddly enough, hundreds of thousands of professional programmers seem to 
manage it all the time, in spite of you claiming it's not particularly 
difficult.

> but it may be that I am wrong and that my attitude has, so far, 
> kept me from diving into OOP,
> which in reality is relatively easy. :)

Or, maybe, you're just not very good at programming, so anytime you look at 
something big enough to be difficult, you decide it's not really because 
it's difficult or you're incapable, but because everyone else in the whole 
world is lying to you for selfish ends?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

David H. Burns wrote:
> P.S. It may well be that programming itself is easier than understanding 
> a written program.

Funny enough, lumps of glass and metal can understand a written program, but 
we've not been able to get any silicon chips to actually be able to write 
significant programs.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>>> It is fundamentally difficult. 
>> I disagree strongly!
> 
> How much do you know about it?
> 

I have programmed a lot, albeit all small stuff. More complex programs 
are of course more difficult
and OOP may be justified if it makes that more easily. Programming 
should not be restricted
to "professional programmers" anymore than writing a paragraph should be 
restricted to
professional writers!
> 
>> And applied mathematics is in general not fundamentally difficult.
> 
> Sure. That's why they teach it in grade school.

Now you're just being silly! In fact they *do* teach it in grade school. 
Two apples plus
three apples equals five apples.

I think I'm going to cut out. This thread has become to personal.
It was fun though. Thanks to all who participated! :)

David

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>> P.S. It may well be that programming itself is easier than 
>> understanding a written program.
> 
> Funny enough, lumps of glass and metal can understand a written program, 
> but we've not been able to get any silicon chips to actually be able to 
> write significant programs.
> 

I don't see how this comment applies, but at this point, it doesn't matter.
I'm sorry if I hurt some feelings. :)

David

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Your points are well taken, I should have said programing is not
> > *fundamentally* difficult.
>
> It is fundamentally difficult. It's as fundamentally difficult as any
> applied mathematics. For sufficiently small problems, you may be able to do
> it in spite of it being fundamentally difficult.

Ah - here come people who have a precise *definition* of words like
"fundamentally" and "difficult" :P

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > This, to me, sounds like saying "Chess isn't hard, only the opponents are!"
> >
> This is a poor analogy. In chess the major difficulty is the opponent,
> but there is no opponent in programming.

Well, the task to solve with the program is, sort of. And in practice it *is* by
far the major difficulty.

Possibly not though if you're programming only as a small hobby.

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> P.S. It may well be that programming itself is easier than understanding
> a written program.
> I'm certain that is sometimes (maybe often) true of C programs.

It is for certain with programs written in a language you as the reader are not
familiar with.

And yes, programmers tend not to put much effort into making their programs
readable, so it often is the case, too, with programs written in a language you
do know quite well.

Post a reply to this message

clipka wrote:
> Ah - here come people who have a precise *definition* of words like
> "fundamentally" and "difficult" :P

http://en.wikipedia.org/wiki/No_Silver_Bullet

http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf


"""
The essence of a software entity is a construct of interlocking concepts: 
data sets, relationships among data items, algorithms, and invocations of 
functions. This essence is abstract in that such a conceptual construct is 
the same under many different representations. It is nonetheless highly 
precise and richly detailed.

I believe the hard part of building software to be the specification, 
design, and testing of this conceptual construct, not the labor of 
representing it and testing the fidelity of the representation. We still 
make syntax errors, to be sure; but they are fuzz compared with the 
conceptual errors in most systems.
"""

"Fundamental" means basic or essential.
"Difficult" means requiring great physical or mental effort to accomplish or 
comprehend.

So, yeah. If you actually study this stuff, you realize why programming 
(amongst many other fields of endeavor) is fundamentally difficult.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

David H. Burns wrote:
> Programming 
> should not be restricted
> to "professional programmers" anymore than writing a paragraph should be 
> restricted to
> professional writers!

Who said it should?

> Now you're just being silly! In fact they *do* teach it in grade school. 

Math is hard! Let's go shopping! </barbie>

> I think I'm going to cut out. This thread has become to personal.

It just seems to me that someone who has never designed or written a large 
program telling me that "hey, your profession is not really hard, you're 
just hallucinating" is rather insulting.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I have programmed a lot, albeit all small stuff. More complex programs
> are of course more difficult
> and OOP may be justified if it makes that more easily. Programming
> should not be restricted
> to "professional programmers" anymore than writing a paragraph should be
> restricted to
> professional writers!

And guess what - it isn't.

Grab any language you like, get a compiler (or interpreter) and go ahead.

"But," you'll say, "all out there these days has been invaded by OOP and is of
no use for me!"

Here's good news for you: You're wrong.

Fact is that yes, today's mainstream languages virtually *all* come with OOP
support, so they can be applied to large and complex projects.

Fact is also, however, that older languages have not ceased to exist, and there
are even modern compilers and interpreters being developed for them. Some have
introduced dialects with OOP support, but without breaking compatibility.

You love Pascal, but Borland has discontinued its Turbo-Pascal IDE/compiler
series some decade ago, and the old versions can only produce obsolete 16-bit
code? Then maybe you want to have a look at Free Pascal, which even comes with
a clone of the good old Turbo-Pascal IDE. Or just have a look at
http://en.wikipedia.org/wiki/Pascal_(programming_language) to see what else is
currently cooking with that language.

Your favorite language is some other? Just have a look at Wikipedia whether
there's modern compilers or IDEs out there.


Just don't expect professional SW developers from stalling the technological
advancement of *their* weapons of choice just because you don't grok them. That
would be like trying to stop the advent of fountain pens because you as a
hobbyist writer would prefer to stick with the good old dip pen.

Guess what: You can still get dip pens *today* if you really want one. Despite
other "hypes" like ballpoint pens, mechanical typewriters, electrical
typewriters, and nowadays personal computers, first with typewheel printers or
needle dot matrix printers, later with inkjet or laser printers... but well,
who needs them? They have killed the art of writing with dip pens, haven't
they?

The only things from this list that seem to actually have died out are
mechanical typewriters (where electric ones won't do, too often weight or
maintenance is likely to be an issue as well, making pens or pencils the weapon
of choice) and typewheel printers (having been out-evolved by inkjet and laser
printers in terms of quality, and unable to compete with impact dot matrix
printers for carbon copy applications).

Post a reply to this message

clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
>>> This, to me, sounds like saying "Chess isn't hard, only the opponents are!"
>>>
>> This is a poor analogy. In chess the major difficulty is the opponent,
>> but there is no opponent in programming.
> 
> Well, the task to solve with the program is, sort of. And in practice it *is* by
> far the major difficulty.
> 
> Possibly not though if you're programming only as a small hobby.
> 
> 

I'm not sure exactly what you mean. If you mean "The task to accomplish 
with the
program is the major difficulty in practice.", I agree and that would be 
true for
projects large or small, professional or hobby. The difficulty of a 
programming task
is determined by the nature of the task not the difficulty of 
programming per se. But
even an easy programming task can be made difficult by programming tools 
that are
difficult to use.

As I said in another post, I'm about ready to cut out of this thread. I 
don't want to quit
without reiterating what a wonder program Pov-Ray is. My hat's off to 
anybody and everybody
who contributed to making it what it is. I couldn't have done a tiny 
fraction of it -- to tell the truth,
I never would have conceived of it or thought it could be done if I had!

David

Post a reply to this message

Darren New wrote:

> It just seems to me that someone who has never designed or written a 
> large program telling me that "hey, your profession is not really hard, 
> you're just hallucinating" is rather insulting.
> 

If I ever said that, I most certainly apologize. I don't think I ever 
said that the
programming profession was not hard. All professions are hard in my book,
though some are harder than others. Some are fun; others don't seem to be--
but that may depend on the individual. :)

David

Post a reply to this message

clipka wrote:


> You love Pascal...
Did I say I loved Pascal? I once learned it well enough to a fairly long 
(for me)
program in it. I have deliberately refrained from naming my favorite 
language for
fearr of the sneers.

> 
> Your favorite language is some other? Just have a look at Wikipedia whether
> there's modern compilers or IDEs out there.

I have deliberately refrained from naming my favorite language for
fearr of the sneers. But thanks a lot for this suggestion. I will look.
> 
> 

> Guess what: You can still get dip pens *today* if you really want one. 
I know. I wonder if one still get a "Rapideograph" type pen and ink that
would work in it.

Thank, again:)
David

Post a reply to this message

Darren New wrote:

> """
> The essence of a software entity is a construct of interlocking 
> concepts: data sets, relationships among data items, algorithms, and 
> invocations of functions. This essence is abstract in that such a 
> conceptual construct is the same under many different representations. 
> It is nonetheless highly precise and richly detailed.
> 
> I believe the hard part of building software to be the specification, 
> design, and testing of this conceptual construct, not the labor of 
> representing it and testing the fidelity of the representation. We still 
> make syntax errors, to be sure; but they are fuzz compared with the 
> conceptual errors in most systems.
> """
> 
> "Fundamental" means basic or essential.
> "Difficult" means requiring great physical or mental effort to 
> accomplish or comprehend.
> 
> So, yeah. If you actually study this stuff, you realize why programming 
> (amongst many other fields of endeavor) is fundamentally difficult.
> 

I fear my criterion for "difficult" rather subjective, something like: 
If I can do it, it's really
not all that difficult. :)

Of course applying words like "hard" or "difficult" to things like
"programming" or "applied mathematics" is misleading since some things 
included
within these"subjects" may be easy, some hard, some extremely hard.

David :)

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> But
> even an easy programming task can be made difficult by programming tools
> that are
> difficult to use.

No argument here - whether they be useless in general or just unsuited for the
task at hand. There are even programming languages *designed* to be so unsuited
for programming that there exist more compilers than working programs (Brainfuck
for instance, or Ook). But of course one doesn't have to resort to such
constructed examples in order to find particularly painful programming
languages or development tools.

That's why I think it is paramount that POV-Ray's next-generation SDL gets a
custom-tailored language syntax, instead of just integrating a parser and
runtime engine for a popular (or otherwise significant) scripting language as
often proposed.


> As I said in another post, I'm about ready to cut out of this thread.

I guess you're right, we're getting to the point where we're mainly reiterating.
I'll count on you reading that pov4 newsgroup though; have you managed to access
the earlier posts yet? If your newsreader still doesn't give you those, you may
try via the http://news.povray.org web interface to get an overview of what's
been discussed so far.

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > You love Pascal...
> Did I say I loved Pascal? I once learned it well enough to a fairly long
> (for me)
> program in it. I have deliberately refrained from naming my favorite
> language for
> fearr of the sneers.

I just took it as an eyample, having been *my* long-time favorite language
(after BASIC).


> > Guess what: You can still get dip pens *today* if you really want one.
> I know. I wonder if one still get a "Rapideograph" type pen and ink that
> would work in it.

Though Wikipedia states Rotring stopped shipping to the US in 2005, they're
still active on the European market - and yes, they still do manufacture the
"Rapidograph" series of pens:

http://www.rotring.com/en/produkte/technisches_zeichnen/rapidograph.html

;)

Post a reply to this message

clipka wrote:
  I'll count on you reading that pov4 newsgroup though; have you managed 
to access
> the earlier posts yet? If your newsreader still doesn't give you those, you may
> try via the http://news.povray.org web interface to get an overview of what's
> been discussed so far.
> 
> 
I've looked at some of the threads in the POV4 via the web. If I try to 
post from there,
it asks for a password, which I probably entered some months ago and 
have forgotten;
but I'm not quite ready to say anything yet, anyway. TBird must have a 
cutoff date set
somewhere but I've been unable to find it.

David

Post a reply to this message

On 07/26/09 14:26, David H. Burns wrote:
>> You love Pascal...
> Did I say I loved Pascal? I once learned it well enough to a fairly long
> (for me)
> program in it. I have deliberately refrained from naming my favorite
> language for
> fearr of the sneers.

	BASIC? Not my favorite, but I have fond memories of it.

	Can't imagine anything people would be more scared to admit to. LOGO is 
considered more respectable, and too many people like Fortran.


-- 
Free advice is seldom cheap.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Yes, modules occasionally *are* instantiated and referenced; but in typical
> modular projects they're *not*, and instead just resemble code libraries.

  What makes you think that on typical modular projects modules are not
instantiated?

  A string is a module (or can be one in most modular and OO languages), for
example, and obviously you usually instantiate quite many times. Likewise
things like file streams are often modules/objects in such languages.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:

> I just took it as an eyample, having been *my* long-time favorite language
> (after BASIC).

Well, I guess I'll have to admit it BASIC is my favorite language. 
QuickBasic was it's
highest development. Before it was abandoned and replaced by the Visual 
Basics which
are different animals, although in the earlier versions you could 
minimize the interface
development part and still do BASIC programming. That doesn't seem to be 
the case with
the .net versions. I bought the first version years ago and then bought 
a book. The recent posts
on the Microsoft-Arrgh thread reminded me of  the problems with it'a 
installation. Four plus
hours and the creation 50,000 or more new files.I'm not sure that I 
every got to the point where
I could print "hi there". I was able to display an image and VBnet 
seemed to promise good image
  handling capabilities if one could only figure them out. It wouldn't 
install one my new computer a
number of years ago (by that time, it was several versions old). I 
downloaded the free 2008 version a
while back and it was even more obscure to me than the first version. I 
did manage to print "Hi there" to
a textbox and to display an image, but I never figured out how to write 
or import any code. The learning curve
for it would be so steep and long that I had rather do without or find 
something else. The only working
programming tool I have at present, if we discount the Pov-Ray SDL is 
VB4. Or I should say, the only one I
can use with any efficiency. I have a couple of versions of Python which 
I may eventually learn to play
with and "Borland's" free C/C++ compiler that I might use some if I 
could figure out how to do graphics
with it. How I do run on! :)

> Though Wikipedia states Rotring stopped shipping to the US in 2005, they're
> still active on the European market - and yes, they still do manufacture the
> "Rapidograph" series of pens:
> 
> http://www.rotring.com/en/produkte/technisches_zeichnen/rapidograph.html
> 


Thanks. I must use Wikipedia more.

David

Post a reply to this message

Neeum Zawan wrote:

>     BASIC? Not my favorite, but I have fond memories of it.
> 
>     Can't imagine anything people would be more scared to admit to. 

You are right on both counts. BASIC was (and I guess still is) despised 
by the "real programmers"
as not being a *real* programming language.
The fact is (that is to say, "my opinion is") that those who talked that 
way rightly perceived it as a
threat to their elite status and so its development was squelched. The 
VB's are different animals.

Well enough of that. :)

David

Post a reply to this message

David H. Burns wrote:
> that those who talked that way rightly perceived it as a
> threat to their elite status and so its development was squelched. 

And not because of any of the dozens of *actual* reasons that have been 
described over the years.  No, just a conspiracy by the elite to make you, 
David Burns, feel bad that programming is hard. <plonk>

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

David H. Burns wrote:
> Neeum Zawan wrote:
> 
>>     BASIC? Not my favorite, but I have fond memories of it.
>>
>>     Can't imagine anything people would be more scared to admit to. 
> 
> You are right on both counts. BASIC was (and I guess still is) despised 
> by the "real programmers"
> as not being a *real* programming language.
> The fact is (that is to say, "my opinion is") that those who talked that 
> way rightly perceived it as a
> threat to their elite status and so its development was squelched. The 
> VB's are different animals.

It's a completely different beast, for a completely different purpose.

Visual Basic has always been (and always will be) developed to allow 
people to rapidly develop programs that have no memory or speed 
requirements, but only interface ones.  It's great for writing small 
one-off apps, and even larger special purpose apps, but I wouldn't use 
it (or use it exclusively) for something to required significant 
computation.

That's the reason for the complete overhaul from VB6 to VB.Net.  VB6 was 
great as a "basic interpreter", but was hitting a wall in terms of 
usefulness.  VB.Net changed the focus from "basic interpreter" to "rapid 
app development."  People who actually use it for their jobs get more 
done with the new version, so it was probably a good decision on 
Microsoft's part.

-- 
Chambers

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>> that those who talked that way rightly perceived it as a
>> threat to their elite status and so its development was squelched. 
> 
> And not because of any of the dozens of *actual* reasons that have been 
> described over the years.  No, just a conspiracy by the elite to make 
> you, David Burns, feel bad that programming is hard. <plonk>
> 
<plonk>??
No, "conspiracy" is much too strong a word. People of similar interests 
often work toward
similar ends  without "conspiring" together or even knowing one another. 
Real conspiracies
(outside of politics) are probably rather scarce. In any case my brief 
account of my opinion
is false because it is too simplistic. It may, in fact, be that it's 
always wrong to assign motives
or even"*actual* reasons" to account for past events.
There does however seem to be a conspiracy among keyboards to make David 
Burns feel bad
by typing the wrong letter. ;) :)

David

Post a reply to this message

Chambers wrote:
> David H. Burns wrote:
>> Neeum Zawan wrote:
>>
>>>     BASIC? Not my favorite, but I have fond memories of it.
>>>
>>>     Can't imagine anything people would be more scared to admit to. 
>>
>> You are right on both counts. BASIC was (and I guess still is) 
>> despised by the "real programmers"
>> as not being a *real* programming language.
>> The fact is (that is to say, "my opinion is") that those who talked 
>> that way rightly perceived it as a
>> threat to their elite status and so its development was squelched. The 
>> VB's are different animals.
> 
> It's a completely different beast, for a completely different purpose.
> 
> Visual Basic has always been (and always will be) developed to allow 
> people to rapidly develop programs that have no memory or speed 
> requirements, but only interface ones.  It's great for writing small 
> one-off apps, and even larger special purpose apps, but I wouldn't use 
> it (or use it exclusively) for something to required significant 
> computation.
> 
> That's the reason for the complete overhaul from VB6 to VB.Net.  VB6 was 
> great as a "basic interpreter", but was hitting a wall in terms of 
> usefulness.  VB.Net changed the focus from "basic interpreter" to "rapid 
> app development."  People who actually use it for their jobs get more 
> done with the new version, so it was probably a good decision on 
> Microsoft's part.
> 

This makes sense. One can still use the older VB's to write a BASIC 
program, but the
paraphernalia gets in the way.

David

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > Yes, modules occasionally *are* instantiated and referenced; but in typical
> > modular projects they're *not*, and instead just resemble code libraries.
>
>   What makes you think that on typical modular projects modules are not
> instantiated?
>
>   A string is a module (or can be one in most modular and OO languages), for
> example, and obviously you usually instantiate quite many times. Likewise
> things like file streams are often modules/objects in such languages.

Still, in a typical modular project it would be implemented as a library,
providing (A) a classic data structure to hold a string, and (B) classic
routines to operate on them. There may be talk about "instantiating" with
regard to the data structure, but not with regard to the module as a whole,
which might contain additional data structures such as a dedicated heap for the
strings to live in.

Most modular projects use a much too heavyweight concept of a module to
instantiate whole modules for such small stuff as a single string.

And those that do have a lightweight enough concept of a module typically fall
into the full-fledged OOP category anyway.

So no, in typical modular projects, modules are not instantiated. Unless the
system gets so big that it may need to live on multiple machines - in that
case, yes, modules are indeed very frequently instantiated: One instance per
machine.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Still, in a typical modular project it would be implemented as a library,

  I'm not sure if we have the same concept of what "library" means.

  I don't see "module" and "library" being in any way mutually exclusive
concepts. They do not even talk about the same thing. A module is a
programming design/paradigm device. A library is simply a reusable piece
of code (usually residing in its own file or files).

> providing (A) a classic data structure to hold a string, and (B) classic
> routines to operate on them.> There may be talk about "instantiating" with
> regard to the data structure, but not with regard to the module as a whole,
> which might contain additional data structures such as a dedicated heap for the
> strings to live in.

  It sounds to me like you are talking more about syntax than design questions.

  Of course modules can have static data (data which is not tied to an
instance of the module, and thus shared by all the instances) and dynamic
data (data which is stored in each instance and is specific to it, also
called the "state" of the object).

> Most modular projects use a much too heavyweight concept of a module to
> instantiate whole modules for such small stuff as a single string.

  I don't understand how you instantiate a "heavyweight concept of a module".
It sounds to me like you were arguing that if a module contains a thousand
member functions, "instantiating" that module would mean replicating all
those functions for each instance.

  I don't even understand why a modular programming language would even
*support* that, much less want to do it. What use would there be in
replicating a function many times, when the whole idea of a function
as a subroutine is precisely that you *don't* have to replicate the code,
but instead you can call the *same* function/subroutine from different parts
of the code.

  Of course when you instantiate a module, you instantiate an object
containing the dynamic member variables of the module (ie. its state).
After that, whether you just call free functions, giving them the object
as parameter, or member functions through the object, is simply a question
of syntax (and not of implementation), and sometimes of design.

  That is what happens in Modula, C++ and most other modular/OO languages.
Why would any language want to do it differently?

> And those that do have a lightweight enough concept of a module typically fall
> into the full-fledged OOP category anyway.

  Modula doesn't.

> So no, in typical modular projects, modules are not instantiated. Unless the
> system gets so big that it may need to live on multiple machines - in that
> case, yes, modules are indeed very frequently instantiated: One instance per
> machine.

  That's not how I understand modules, nor have I ever heard such a thing.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> There may be talk about "instantiating" with
> regard to the data structure, but not with regard to the module as a whole,
> which might contain additional data structures such as a dedicated heap for the
> strings to live in.

Indeed, this is the generally accepted difference between a class and a 
module, in programming language theory. You only "instantiate" a module (aka 
"package") once, or once per actual type if it's generic.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > I just took it as an eyample, having been *my* long-time favorite language
> > (after BASIC).
>
> Well, I guess I'll have to admit it BASIC is my favorite language.

Not really the most modern of languages (unless you count VB/VBA, but as you say
yourself these are actually totally different beasts), and indeed one of the
most frowned-at languages (VB/VBA included in this case); I guess that's mostly
undeserved, however: The frowns should go to the people who thought it a good
idea to introduce "GOTO" as the second statement after "PRINT", thereby
inviting virtually the whole Home Computer Generation to become hobbyist
spaghetti code producers.

Normally, the first two programs would be:

  10 PRINT "Hello World!"

and

  10 PRINT "Hello World!"
  20 GOTO 10

A few years ago I did some work for an insurance company to port a few old small
SINIX-BASIC programs to VBA (something like two dozen 1000-liners) so they could
get rid of the last legacy machine that could run those programs; some of them
were really well-strucutured, well-commented and well-indented. Others were
really the worst classic spaghetti code I've ever seen in my life, and I was
more than happy that I only had to *port* them, not *fix* anything in them.

It's really a matter of programming style whether a BASIC programmer should be
despised or not. BASIC allows for a broad spectrum there. But then again, ever
since I've seen the C source code of "NetHack", I can tell that at least C
programs - even when not deliberately obfuscated - can be just as messy as any
BASIC code. And at least BASIC is not as cryptic as C.


> QuickBasic was it's highest development.

Just out of curiosity: Did they ever introduce such things as structs (records
in Pascal)? That was the thing that bothered me most about BASIC ever since I
first wanted to store a list of data tuples. Using a separate array for each
"dimension" of the tuple just didn't feel right.


> I was able to display an image and VBnet seemed to promise good image
> handling capabilities if one could only figure them out.

If graphics (or any other non-textual user interaction, for that matter) is what
you want to do, it comes as no surprise to me that you don't like modern
computer languages. The major problem, however, is not an inherent feature of
the languages themselves, but of graphical user interfaces (at least as far as
Windows is concerned; I never got to have a look at X Window or the like),
which follow an *event-driven* paradigm - i.e. *they* want to tell your program
when to do what, which is almost perfectly incompatible with the classic
application-driven paradigm. And although I guess this is exactly what you're
wrongly attributing to OOP, you're not so far off the mark: As a matter of
fact, an object in OOP can be regarded as an event-driven piece of software
(each method call constituding an event), so OOP is a very good paradigm to
model an event-driven application: All you need to do is consider your whole
application an object, too - which I admit is indeed *not* a natural way of
thinking.

(However, while the event-driven paradigm *is* an antithesis to the classic
application-driven paradigm you undoubtedly favor, OOP can be used perfectly
well for both.)

Unfortunately, modern mainstream programming environments indeed don't seem to
come with any framework to support the classic application-driven paradigm,
except for purely textual interfaces ("console application" in Microsoft terms)
or a static sequence of dialogs ("wizards").


> I have a couple of versions of Python which
> I may eventually learn to play
> with and "Borland's" free C/C++ compiler that I might use some if I
> could figure out how to do graphics
> with it. How I do run on! :)

Speaking of Borland, maybe they still come with the good old "graph" library and
the BGI graphics driver format, in which case I'd expect them to include a BGI
to interface to Windows, too.

Same goes for FreePascal. I guess I'll check that out.

C is really not a pretty language, by the way. I'd possibly still program in
Pascal, had it not been for the limitations of the compilers I had at my
disposal (16 bit "real mode" applications only, max array size of 64 kByte)
when I was introduced to C, C++ and Java. (And I'd possibly still program in
BASIC if I hadn't had to learn Pascal at school anyway, and found the language
to feature records ;)).

Post a reply to this message

clipka <nomail@nomail> wrote:
> Not really the most modern of languages (unless you count VB/VBA, but as you say
> yourself these are actually totally different beasts), and indeed one of the
> most frowned-at languages (VB/VBA included in this case); I guess that's mostly
> undeserved

  The original BASIC was such a simplistic scripting language compared to
way more advanced programming languages of the same era (including such
masterpieces as lisp, which was surprisingly advanced and high-level taking
into account it was invented in 1958) that it was basically frowned upon by
everybody from the beginning.

  The original BASIC didn't even have the concept of functions. It had a
very primitive version of them, subroutines (which are like functions which
don't take parameters nor return anything, and without any local scope).
The only thing which differentiated a subroutine call from a goto is that
the subroutine call pushed the caller's address onto a stack, so that a
"return" statement could return there when the subroutine ends. But that's
about it.

  More jarringly, every single variable was global. The concept of local
variables was inexistent, obviously because of the lack of proper functions.

  Goto was an inherent part of the language, and used extensively. This,
naturally, also caused criticism, as liberal use of gotos easily disrupts
the logical flow of code and makes it harder to follow and understand, even
if the obfuscation is not intentional.

  Even if we took goto as barely acceptable, its original implementation was
very ascetic. AFAIK the original BASIC did not support named labels, but
instead every line of code was numbered (by hand by the programmer), and
gotos always jumped to a specified line number. AFAIK the numbering of each
line was mandatory. Naturally this made it quite problematic to insert code
between existing lines. While it was customary to number the lines in
multiples of ten, this only gives the possibility of inserting 9 lines
of code between any existing lines. If you run out of line numbers, you
will have to start renumbering. And good luck trying not to break existing
gotos if you start renumbering. (Some later BASIC text editors supported
automatic renumbering, including all gotos, but naturally no such editors
existed back then, when even having an interactive text editor in the first
place was luxury.)

  Control structures were ascetic and limited, as well as the possibility
of creating things like data containers.

  It's no serious programmer ever bothered with BASIC.

-- 
                                                          - Warp

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> The fact is (that is to say, "my opinion is") that those who talked that
> way rightly perceived it as a
> threat to their elite status and so its development was squelched.

That may have been part of the deal. I guess, however, it was partly justified
by a surge of hobbyist spaghetti-code programmers claiming to know how to
program, but being unaware that software development also includes maintenance
(i.e. bug fixing and later modifications) and teamwork, and that their
spaghetti-code was often very ill-suited to those parts of the job.

I don't think the development was actively squelched. It just slowly died out as
soon as BASIC ceased to be actively pushed by a thriving home computer industry.
That's the primary reason BASIC became so popular in the first place: You got it
for free with every home computer brand in the whole wide world. Not only that:
It even constituted the standard user interface, so without typing a BASIC
command you usually couldn't even start any other software.

For quite a while you didn't get any programming language for free with
IMB-compatible PCs when they replaced home computers as the private man's
computer. (Well, you had batch files, but I guess we agree that they don't
really count.) The reason for this is highly unlikely to have anything to do
with attempts to squelch the language - much to the contrary, Microsoft instead
probably hoped to make money out of it. And in the beginning they did.

I think it was not before DOS 5.0 that Microsoft started to bundle BASIC again
with DOS, possibly in an attempt to revive the dwindling popularity of BASIC;
still it was not as omnipresent as it had been in the home computer era, so it
didn't manage to attract as many new enthusiasts.

Visual Basic, too, might not have gained such popularity, had it not been chosen
as the scripting language for the most popular office package. And who would be
talking about JavaScript, had it not been the first scripting language to be
integrated in a web browser?

(And who would ever have heard of POV-Ray SDL if it wasn't bundled with the
POV-Ray raytracer? ;))


So you see, bundling is a very strong tool for promoting a software language.
I'd say BASIC wasn't quenched, but instead had been hyped before, both
ideologically ("the first language everyone can learn") and financially (dead
giveway with every computer), and has just been allowed to settle to its
"natural" level of importance.

With "natural" level meaning that BASIC is (aside from VB/VBA) not a mainstream
language anymore, but all the while far from dead either - and may even have
what you're looking for. Just had a quick browse though a few Wikipedia pages,
to stumble across this paragraph:

------------
FreeBASIC has a built-in 2D, software graphics library to be QuickBASIC
compatible, which provides the user with simple graphics primitives (such as
rectangles, lines, and circles), blitting, and additional features which
weren't present in QuickBASIC's graphical library. The library itself is not OS
dependent, so code is portable across platforms with the library.
------------
(http://en.wikipedia.org/wiki/FreeBASIC)

(Yes, you *definitely* should spend more time with Wikipedia - she's your friend
;))

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> And not because of any of the dozens of *actual* reasons that have been
> described over the years.  No, just a conspiracy by the elite to make you,
> David Burns, feel bad that programming is hard. <plonk>

Hmm, I think plonking him is a bit too extreme a reaction...

Post a reply to this message

Warp wrote:
>   The original BASIC was such ... that it was basically frowned upon by
> everybody from the beginning.

Welllll... I wouldn't go that far. It was acknowledged as simplified, in 
much the same way that DOS BAT files are simplified or editor macros are 
simplified. It was designed as a beginner's language, so it wasn't really 
frowned upon any more than LOGO or PILOT is frowned upon.

It was only after people tried to turn it into something sophisticated they 
could continue using for large professional programs with multiple 
programmers that it was "frowned upon", methinks.

>   The original BASIC didn't even have the concept of functions.

And many of the languages of the time didn't have recursion even if they had 
functions. :-)

>   Goto was an inherent part of the language, and used extensively. This,
> naturally, also caused criticism, 

Except that BASIC was invented a couple years before structured programming 
was, so this was only a criticism a decade after BASIC was popular. It also 
started out with only what you might call "computed if" statements. I.e., 
the only valid thing after a "then" or "else" was "goto".

>   Even if we took goto as barely acceptable, its original implementation was
> very ascetic. AFAIK the original BASIC did not support named labels, but
> instead every line of code was numbered (by hand by the programmer), and
> gotos always jumped to a specified line number. AFAIK the numbering of each
> line was mandatory.

Yes. BASIC was revolutionary in that it had its own editor built into the 
language, which was pretty nice in the days of punched cards and paper tape.

> Naturally this made it quite problematic to insert code
> between existing lines. While it was customary to number the lines in
> multiples of ten, this only gives the possibility of inserting 9 lines
> of code between any existing lines. If you run out of line numbers, you
> will have to start renumbering.

It also contributed to the spaghetti code, because if you ran out of lines 
and didn't have a automatic renumbering program, you'd put a subroutine 
somewhere, gosub it, and then return. Like patching assembly code. Good 
thing all the variables are global. ;-)  That's why serious people used 
counts of 100 instead of 10. ;-)

>   Control structures were ascetic and limited, as well as the possibility
> of creating things like data containers.
> 
>   It's no serious programmer ever bothered with BASIC.

Not if there was a reasonable choice, and not if you had more than one 
person working on the program. Unless you were just learning how to program.

Actually, I worked with lots of serious programmers that did extensive work 
in BASIC. They were all people I didn't consider very professional, tho, and 
the programs were fairly small compared to what you see for even a simple 
program nowadays.

Except for the ones doing BASIC on the microcomputers, where it was actually 
pretty good, since it was the main supported "high level" language. People 
did some neat stuff in spite of the limitations.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

clipka wrote:
> For quite a while you didn't get any programming language for free with
> IMB-compatible PCs when they replaced home computers as the private man's

I'm pretty sure you still had GWBasic in ROM. Indeed, that was one of the 
reasons people wanted a "real" IBM PC and not just a "compatible" - you 
could build the same hardware, but you couldn't include the GWBasic ROMs, so 
code that called into the ROMs (for things like trigonometric functions etc) 
wouldn't work on a "clone" at first. (Or was it "QuickBasic"?)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On 27-7-2009 18:56, Warp wrote:
> clipka <nomail@nomail> wrote:
>> Not really the most modern of languages (unless you count VB/VBA, but as you say
>> yourself these are actually totally different beasts), and indeed one of the
>> most frowned-at languages (VB/VBA included in this case); I guess that's mostly
>> undeserved
> 
>   The original BASIC was such a simplistic scripting language compared to
> way more advanced programming languages of the same era (including such
> masterpieces as lisp, which was surprisingly advanced and high-level taking
> into account it was invented in 1958) that it was basically frowned upon by
> everybody from the beginning.

As was Pascal, dismissed as 'just an educational language' that was not 
useful for real life projects.

>   The original BASIC didn't even have the concept of functions. It had a
> very primitive version of them, subroutines (which are like functions which
> don't take parameters nor return anything, and without any local scope).
> The only thing which differentiated a subroutine call from a goto is that
> the subroutine call pushed the caller's address onto a stack, so that a
> "return" statement could return there when the subroutine ends. But that's
> about it.
> 
>   More jarringly, every single variable was global. The concept of local
> variables was inexistent, obviously because of the lack of proper functions.
> 
>   Goto was an inherent part of the language, and used extensively. This,
> naturally, also caused criticism, as liberal use of gotos easily disrupts
> the logical flow of code and makes it harder to follow and understand, even
> if the obfuscation is not intentional.

Some historical context: BASIC is from 1964. The famous 'Go To statememt 
considered harmful' dates from 1968. At the time of design goto was 
excepted and even the norm. You can't blame the designers for that. Not 
even with 40+ years hindsight.

>   Even if we took goto as barely acceptable, its original implementation was
> very ascetic. AFAIK the original BASIC did not support named labels, but
> instead every line of code was numbered (by hand by the programmer), and
> gotos always jumped to a specified line number. AFAIK the numbering of each
> line was mandatory. Naturally this made it quite problematic to insert code
> between existing lines. While it was customary to number the lines in
> multiples of ten, this only gives the possibility of inserting 9 lines
> of code between any existing lines. If you run out of line numbers, you
> will have to start renumbering. And good luck trying not to break existing
> gotos if you start renumbering. (Some later BASIC text editors supported
> automatic renumbering, including all gotos, but naturally no such editors
> existed back then, when even having an interactive text editor in the first
> place was luxury.)

Indeed, when I started at uni ('82) I had to use a line editor for my 
programs on the mainframe. At home and elsewhere I had been using full 
screen editors for many years.

>   Control structures were ascetic and limited, as well as the possibility
> of creating things like data containers.

If you look at what the design constraints were you will find that it 
perfectly fitted. As much as everybody would have loved to have more 
expressivity it would not have fitted in the ROM of these days.

>   It's no serious programmer ever bothered with BASIC.

On the contrary, many did. Those that were designing software that had 
to run on cheap general purpose computers like Apple II and the 
Commodore PET series and the like. Many very serious programmers were 
involved in writing BASIC interpreters and compilers. Perhaps the only 
place it was not as much used was in the just starting computer science 
departments of those days. And if they didn't it was more because they 
had no feeling with the real world outside than anything else.

Post a reply to this message

clipka wrote:

> Not really the most modern of languages (unless you count VB/VBA, but as you say
> yourself these are actually totally different beasts), and indeed one of the
> most frowned-at languages (VB/VBA included in this case); I guess that's mostly
> undeserved, however: The frowns should go to the people who thought it a good
> idea to introduce "GOTO" as the second statement after "PRINT", thereby
> inviting virtually the whole Home Computer Generation to become hobbyist
> spaghetti code producers.

Of which I'm one. But to my mind any good computer language should allow 
one to produce
"spaghetti code" (I had forgotten that term) if one wanted to. The 
"GOTO" statement
deserves much of the frowning it gets, but not all.
> 
> Normally, the first two programs would be:
> 

I remember right the first "real program" I ever wrote was a program to 
calculate ozone
concentration on a Commadore Pet. It was the first computer I ever dealt 
with
and after a *very* short time playing with it I was able to write a 
program to replace
the one we had been using on a TI55(?) calculator (the one with the card 
reader --remember
that?) The Pet had a version of Microsoft BASIC in ROM. For years 
afterwards --
until Windows 95--Microsoft was my favorite software company! I had 
never even been
in the room with a computer before and could hardly use an adding 
machine. but I was
able to write a useful program with almost no experience. I don't see 
any good reason
why the basics of *any* high level computer language should not be 
almost that easy to
learn!
> It's really a matter of programming style whether a BASIC programmer should be
> despised or not. BASIC allows for a broad spectrum there. But then again, ever
> since I've seen the C source code of "NetHack", I can tell that at least C
> programs - even when not deliberately obfuscated - can be just as messy as any
> BASIC code. 

Much more so, I am assured. "Document the H* out of your C code!" was 
one of my
teacher's advice.
> 
> 
>> QuickBasic was it's highest development.
> 
> Just out of curiosity: Did they ever introduce such things as structs (records
> in Pascal)? That was the thing that bothered me most about BASIC ever since I
> first wanted to store a list of data tuples. Using a separate array for each
> "dimension" of the tuple just didn't feel right.

Not in QB as I recall. You can do it sort of in VB4, but ir fights you. 
That would
have been one of the next logical steps, along with C-like pointer 
capability and, of
course Windows graphic capability. If I remember right, the QuickBASIC 
and QuickC
IDE's were models of what a good simple IDE should be. Microsoft was 
good in those
days!

>> I was able to display an image and VBnet seemed to promise good image
>> handling capabilities if one could only figure them out.
> 
> If graphics (or any other non-textual user interaction, for that matter) is what
> you want to do, it comes as no surprise to me that you don't like modern
> computer languages. The major problem, however, is not an inherent feature of
> the languages themselves, but of graphical user interfaces (at least as far as
> Windows is concerned; 

Yes access to Windows graphic functions seem unnecessarily complicated and
poorly documented. I can't see any good reason for this.

I never got to have a look at X Window or the like),
> which follow an *event-driven* paradigm - i.e. *they* want to tell your program
> when to do what, which is almost perfectly incompatible with the classic
> application-driven paradigm. And although I guess this is exactly what you're
> wrongly attributing to OOP, you're not so far off the mark: As a matter of
> fact, an object in OOP can be regarded as an event-driven piece of software
> (each method call constituding an event), so OOP is a very good paradigm to
> model an event-driven application: All you need to do is consider your whole
> application an object, too - which I admit is indeed *not* a natural way of
> thinking.
> 
> (However, while the event-driven paradigm *is* an antithesis to the classic
> application-driven paradigm you undoubtedly favor, OOP can be used perfectly
> well for both.)
> 
> Unfortunately, modern mainstream programming environments indeed don't seem to
> come with any framework to support the classic application-driven paradigm,
> except for purely textual interfaces ("console application" in Microsoft terms)
> or a static sequence of dialogs ("wizards").

I don't understand a lot of what you say, but it fascinates me, I may 
have to learn OOP
and more about modern programming just for the fun of it.


> Speaking of Borland, maybe they still come with the good old "graph" library and
> the BGI graphics driver format, in which case I'd expect them to include a BGI
> to interface to Windows, too.

Maybe it does, if so I haven't be able to find it--or recognize it. The 
old "graphic.h" was for DOS and
won't work on XP, anyway, and I think the routines are incompatible with 
modern graphic
cards.
> 

> 
> C is really not a pretty language, by the way. 

No, but it's fascinating, and in my little experience addictive.

David :)

Post a reply to this message

Warp wrote:
> clipka <nomail@nomail> wrote:
>> Not really the most modern of languages (unless you count VB/VBA, but as you say
>> yourself these are actually totally different beasts), and indeed one of the
>> most frowned-at languages (VB/VBA included in this case); I guess that's mostly
>> undeserved
> 
>   The original BASIC was such a simplistic scripting language compared to
> way more advanced programming languages of the same era (including such
> masterpieces as lisp, which was surprisingly advanced and high-level taking
> into account it was invented in 1958) that it was basically frowned upon by
> everybody from the beginning.
> 
>   The original BASIC didn't even have the concept of functions. It had a
> very primitive version of them, subroutines (which are like functions which
> don't take parameters nor return anything, and without any local scope).
> The only thing which differentiated a subroutine call from a goto is that
> the subroutine call pushed the caller's address onto a stack, so that a
> "return" statement could return there when the subroutine ends. But that's
> about it.
> 
>   More jarringly, every single variable was global. The concept of local
> variables was inexistent, obviously because of the lack of proper functions.
> 
>   Goto was an inherent part of the language, and used extensively. This,
> naturally, also caused criticism, as liberal use of gotos easily disrupts
> the logical flow of code and makes it harder to follow and understand, even
> if the obfuscation is not intentional.
> 
>   Even if we took goto as barely acceptable, its original implementation was
> very ascetic. AFAIK the original BASIC did not support named labels, but
> instead every line of code was numbered (by hand by the programmer), and
> gotos always jumped to a specified line number. AFAIK the numbering of each
> line was mandatory. Naturally this made it quite problematic to insert code
> between existing lines. While it was customary to number the lines in
> multiples of ten, this only gives the possibility of inserting 9 lines
> of code between any existing lines. If you run out of line numbers, you
> will have to start renumbering. And good luck trying not to break existing
> gotos if you start renumbering. (Some later BASIC text editors supported
> automatic renumbering, including all gotos, but naturally no such editors
> existed back then, when even having an interactive text editor in the first
> place was luxury.)
> 
>   Control structures were ascetic and limited, as well as the possibility
> of creating things like data containers.
> 
>   It's no serious programmer ever bothered with BASIC.



Clearly, I am no serious programmer. That charge, I accept gladly and 
rejoice in it!
Thanks for the history of BASIC, I didn't know anything about it. As I 
said elsewhere,
my first experience of it was Microsoft Basic and serious programming 
language or not,
it was *very* useful at work and at play! And by it, I learned that even 
I can program,
though perhaps some would hesitate to admit that. :)

David

Post a reply to this message

andrel wrote:
> As was Pascal, dismissed as 'just an educational language' that was not 
> useful for real life projects.

Much of that comes from not having standardized the libraries, by the way. 
Most of the languages from the early 60's lived or died based on how well 
you could interface to the OS without learning the details too hard. If you 
couldn't open a file by name with your language, you were pretty much doomed 
to obscurity. If you couldn't read and write the standard files that the 
"real" programming languages (FORTRAN, COBOL, etc) created (regardless of 
whether you had to open them outside the program), you didn't even get off 
the ground.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message