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