 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
