Getting Started in Programming & Scripting

[Bibby]

Hi, I'm interested in getting started in the programming world. I've dabbled
in C, C++ and VB6. Which would be the best language to focus my attention to
regarding the following considerations:

Hireability
Portability
Flexibility

The likely candidates seem to be Java, VB.Net, C, C++, C#.

Also, what would be the best scripting language to get started in? Maybe
something that's a subset of an above language? Maybe scripting is a good
way to get started in general?

Thanks,

PA

[Richard Heathfield]

Keith Thompson said:

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags,

It is, at least in some cars. Often this will result in the tripping of a
warning light on your dashboard.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain

[Walter Roberson]

In article <dg**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:

Keith Thompson said:

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags,

It is, at least in some cars. Often this will result in the tripping of a
warning light on your dashboard.

[OT]

Turning off of airbags is recommended in some circumstances, mostly
having to do with having low-mass or fragile people in the front
passenger seat. The airbags come out with a lot of force, and can
themselves be a source of injury (or even death.)

[NB: I am -not- advocating turning off airbags, just indicating that
there are circumstances under which some "reasonable people" might
choose to do so.]
--
Oh, to be a Blobel!

[Steve O'Hara-Smith]

On Thu, 15 Sep 2005 08:47:50 +0000 (UTC)
er*****@nowhere.uk (J French) wrote:

On Thu, 15 Sep 2005 08:16:25 +0100, Chris Hills <ch***@phaedsys.org>
wrote:

I agree that protecting students with a "safe" language makes matters a
lot worse as they rely on the compiler for error checking and safety.

Agreed.
So you drive a car with dodgy brakes, no airbags and no seat belts ?
Absolutely not - but those who learn their road sense on a bicycle
(dodgy brakes, no airbags, no seatbelts and worse) are probably safer
drivers than those who learned it in a Volvo.
There is a lot to be said for strong type checking, it shows up stupid
errors rapidly
Yes but there's a lot to be said for learning the art of
programming with something dangerous like BCPL or C where careless
coding gets rewarded with core dumps and other program crashes.
Gawd, I remember having to write my own call parameter checking
utility

Doing something like that teaches a lot.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

[Default User]

Richard Heathfield wrote:

Keith Thompson said:

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn
off the airbags,

It is, at least in some cars. Often this will result in the tripping
of a warning light on your dashboard.

Really? I don't believe that's the case in the US. In fact, most repair
places will refuse to install switches, as they are concerned about
liability.

Brian

[Walter Roberson]

In article <3o************@individual.net>,
Default User <de***********@yahoo.com> wrote:

Richard Heathfield wrote:

Keith Thompson said:

> I hope that's just an overstretched metaphor. If you're actually
> talking about driving, I don't know if it's even possible to turn
> off the airbags,

It is, at least in some cars.

Really? I don't believe that's the case in the US. In fact, most repair
places will refuse to install switches, as they are concerned about
liability.

[OT]

Really. Here's how to find an official description of the rules.
[I can't just post a link because the final URL contains several
session tokens]

http://www.nhtsa.dot.gov/
-> [Vehicles and Equipment] tab
-> [Air Bags] "Browse Topics"
-> [Questions and Answers on Air Bag On-Off Switches] Frequently Asked Questions
-> [8. Who can get an on-off switch?]
--
Oh, to be a Blobel!

[Default User]

Walter Roberson wrote:

In article <3o************@individual.net>,
Default User <de***********@yahoo.com> wrote:

Richard Heathfield wrote:

Keith Thompson said: I hope that's just an overstretched metaphor. If you're actually
> talking about driving, I don't know if it's even possible to turn
> off the airbags, It is, at least in some cars.

Really? I don't believe that's the case in the US. In fact, most
repair places will refuse to install switches, as they are
concerned about liability.

[OT]

Really. Here's how to find an official description of the rules.

Nothing there contradicts what I said. I didn't say it wasn't possible
to INSTALL a switch, but that they don't come that way. I also said
that many repair shops will refuse to install said switches.

Brian

[Alan Balmer]

On Thu, 15 Sep 2005 08:47:50 +0000 (UTC), er*****@nowhere.uk (J
French) wrote:

I agree that protecting students with a "safe" language makes matters a
lot worse as they rely on the compiler for error checking and safety.

So you drive a car with dodgy brakes, no airbags and no seat belts ?

Airbags and seat belts don't prevent accidents. Inadequate brakes will
definitely cause me to drive more carefully.

I see too many "programmers" who throw code at the compiler and tweak
it until the errors go away. Unfortunately, the compiler can't be
counted on to detect logic errors.
--
Al Balmer
Balmer Consulting
re************************@att.net

[Michael Mair]

Keith Thompson wrote:

Chris Hills <ch***@phaedsys.org> writes:

In article <43*************@news.btopenworld.com>, J French
<er*****@nowhere.uk> writes

On Thu, 15 Sep 2005 08:16:25 +0100, Chris Hills <ch***@phaedsys.org>
wrote:
[...]
I agree that protecting students with a "safe" language makes matters a
lot worse as they rely on the compiler for error checking and safety.

So you drive a car with dodgy brakes, no airbags and no seat belts ?

Not the same thing at all. Also in many cases you turn OFF the airbags
and don't use seat belts. Though you always want working breaks.

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags, and I *always* wear my seatbelt and insist that my
passengers do likewise. I might consider turning off the airbags in a
dire emergence if it made the car go faster, but of course it doesn't.

Getting back to programming, yes, it's often possible to disable
checks for faster performance. Whether it's a good idea is another
matter.

As Walter indirectly mentioned, if you want to transport children below
a certain weight in the front seat, you should turn off the respective
passenger airbag.
And with some vehicles, backing into a parking lot may be easier without
seat-belt -- so, the metaphor is not too overstretched. Keeping the
car in excellent technical condition but knowing when it is better to
neglect some safety gadget sounds not too far from C programming.
The converse metaphor is a completely different thing, of course.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Anonymous 7843]

In article <dg**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:

Chris Hills said:

In article <V6*****************@fe10.lga>, John W. Kennedy
<jw*****@attglobal.net> writes

COBOL 2003 includes OO, and, consequently, references.

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

It's time for the post-increment joke again, if someone would be so kind.

http://www.netfunny.com/rhf/jokes/93q3/coboloop.html

[Mark B]

"Default User" <de***********@yahoo.com> wrote in message
news:3o************@individual.net...

Walter Roberson wrote:

In article <3o************@individual.net>,
Default User <de***********@yahoo.com> wrote:

> Richard Heathfield wrote:

>> Keith Thompson said:

>> > I hope that's just an overstretched metaphor. If you're actually
>> > talking about driving, I don't know if it's even possible to turn
>> > off the airbags,

>> It is, at least in some cars.

> Really? I don't believe that's the case in the US. In fact, most
> repair places will refuse to install switches, as they are
> concerned about liability.

[OT]

Really. Here's how to find an official description of the rules.

Nothing there contradicts what I said.

Sure it did... otherwise, what did you mean by
'I don't believe that's the case in the US' ???
I didn't say it wasn't possible
to INSTALL a switch, but that they don't come that way.
Depending on vehicle make/model... you're still wrong.
FORD F150 comes standard with a passenger side 'deactivation
switch' and I'm certain it's not the only model that comes with it.
There is also a switch in the seat to temporarily disable the bag
when no-one is sitting in the passenger seat. (Quick web search
finds that the F250 also comes standard with the switch:
http://www.automotive.com/2005/43/fo...iews/interior/)
I also said
that many repair shops will refuse to install said switches.

But it's not because of 'liability issues' as you
claimed, they aren't allowed to disable the airbag systems
in any vehicle unless prior approval is received from NHTSA -
nothing however prevents manufacturers from installing the
switches themselves, and as I've pointed out... some do.

That makes you... 0 for 3. Way to go ;)
Had you perused the NHTSA site, you may have seen that
they actually *RECOMMEND* that people in certain
'risk groups' have switches installed to prevent 'air bag deaths'.
http://www.nhtsa.dot.gov/cars/testin...ure/index.html

That being the case, I wouldn't be surprised to see these switches
installed as standard equipment on more vehicles in the future.
Mark
[followups set to /dev/null :P]

[John W. Kennedy]

Chris Hills wrote:

In article <V6*****************@fe10.lga>, John W. Kennedy
<jw*****@attglobal.net> writes

Francis Glassborow wrote:

In article <43***********@zeusedit.com>, Jussi Jumppanen
<ju****@zeusedit.com> writes
Malcolm wrote:
>Pointers, on the other hand, can be grasped in a few days, but
>only if the beginner has the right mindset.
Is it possible to code anything without the concept of pointers?
To the best of my knowledge Cobol has no pointers and Cobol programmers
have no need of the concept (indeed many of them find the idea of a
pointer quite bizarre)

Well, IBM mainframe COBOL has long included some semi-documented pointer
functions intended for use with CICS.

COBOL 2003 includes OO, and, consequently, references.

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

Yes, the feature crept into many compilers long before COBOL 2003 was
finished.
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Doub...ood/index.html

[Steve O'Hara-Smith]

On Thu, 15 Sep 2005 18:42:37 +0000 (UTC)
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

In article <dg**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:

Keith Thompson said:

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags,

It is, at least in some cars. Often this will result in the tripping of a
warning light on your dashboard.

[OT]

Turning off of airbags is recommended in some circumstances, mostly
having to do with having low-mass or fragile people in the front

It is required if you have a rear facing baby seat in the front,
an airbag going off in front of one of those will ram the baby into
the back of the seat with just about certain death as a result. For
this reason the front passenger seat airbag usually has an off switch.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

[Chris Hills]

In article <20****************************@eircom.net>, Steve O'Hara-
Smith <st****@eircom.net> writes

On Thu, 15 Sep 2005 08:47:50 +0000 (UTC)
er*****@nowhere.uk (J French) wrote:

On Thu, 15 Sep 2005 08:16:25 +0100, Chris Hills <ch***@phaedsys.org>
wrote:

>I agree that protecting students with a "safe" language makes matters a
>lot worse as they rely on the compiler for error checking and safety.

Agreed.

So you drive a car with dodgy brakes, no airbags and no seat belts ?

Absolutely not - but those who learn their road sense on a bicycle
(dodgy brakes, no airbags, no seatbelts and worse) are probably safer
drivers than those who learned it in a Volvo.

As some one said to me a long time ago: Motorcyclists make good car
drivers. Because bad motorcyclists don't survive that long.

It is a pity the same is not true in SW Engineering.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
[e-mail]> writes

Chris Hills <ch***@phaedsys.org> writes:

In article <43*************@news.btopenworld.com>, J French
<er*****@nowhere.uk> writes

On Thu, 15 Sep 2005 08:16:25 +0100, Chris Hills <ch***@phaedsys.org>
wrote:[...]I agree that protecting students with a "safe" language makes matters a
lot worse as they rely on the compiler for error checking and safety.

So you drive a car with dodgy brakes, no airbags and no seat belts ?
Not the same thing at all. Also in many cases you turn OFF the airbags
and don't use seat belts. Though you always want working breaks.

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags,

Yes in some cars. In others you have to have them modified. There are
tow good reasons for doing this.
and I *always* wear my seatbelt and insist that my
passengers do likewise.
*Usually* so do I. However there are times when you do not want them.
These are unsuall circumstances

However there is no occasion when you would want dodgy breaks. If you
don't want to slow down you dont push so hard on the peddle

I might consider turning off the airbags in a
dire emergence if it made the car go faster, but of course it doesn't.
They are not turned of to get more speed. There are two other reasons.
One common and one not so common.

Getting back to programming, yes, it's often possible to disable
checks for faster performance. Whether it's a good idea is another
matter.

No the metaphor is the same you are removing "saftey" for a good
reason. In the case of a care Speed was not the reason. In a similar
vein you do not want some "safe" parts fo the language for some specific
reasons of good engineering.

Remember the rules are for the guidance of wise men and the obedience of
idiots. The problem is 90% think they are the 10%.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <dg**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Richard
Heathfield <in*****@invalid.invalid> writes

Keith Thompson said:

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags,

It is, at least in some cars. Often this will result in the tripping of a
warning light on your dashboard.

This is true. Others have to be modified to turn them off.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <dg**********@canopus.cc.umanitoba.ca>, Walter Roberson
<ro******@ibd.nrc-cnrc.gc.ca> writes

In article <dg**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:

Keith Thompson said:

I hope that's just an overstretched metaphor. If you're actually
talking about driving, I don't know if it's even possible to turn off
the airbags,

It is, at least in some cars. Often this will result in the tripping of a
warning light on your dashboard.

[OT]

Turning off of airbags is recommended in some circumstances, mostly
having to do with having low-mass or fragile people in the front
passenger seat. The airbags come out with a lot of force, and can
themselves be a source of injury (or even death.)

[NB: I am -not- advocating turning off airbags, just indicating that
there are circumstances under which some "reasonable people" might
choose to do so.]

Also when carrying a child in the front passenger seat a rear facing
child seat.

The other time is when doing security work. If you have to ram, or are
rammed by another vehicle the air bag gets in the way (and can stun you)
and slows you up by a quite few seconds. This can be fatal to you and
your principal. In this situation you NEED the seat belt and working
breaks.

This is a special situation involving experts. Much like C can have the
air bags take off and seat belts removed.

Rather C does not come with set belts and air bags. The trouble is the
"young drivers" are not told to taught to fit them and like al young
drives try trick driving without. That is why we get bad habits.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[J French]

On Fri, 16 Sep 2005 08:44:19 +0100, Chris Hills <ch***@phaedsys.org>
wrote:

<snip>

Rather C does not come with set belts and air bags. The trouble is the
"young drivers" are not told to taught to fit them and like al young
drives try trick driving without. That is why we get bad habits.

Well put

[Dan]

"John W. Kennedy" <jw*****@attglobal.net> wrote in message
news:np*****************@fe10.lga...

Chris Hills wrote:

In article <V6*****************@fe10.lga>, John W. Kennedy
<jw*****@attglobal.net> writes

To the best of my knowledge Cobol has no pointers and Cobol programmers
have no need of the concept (indeed many of them find the idea of a
pointer quite bizarre)

COBOL 2003 includes OO, and, consequently, references.

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

Yes, the feature crept into many compilers long before COBOL 2003 was
finished.

Is anyone actually using COBOL 2003? My impression was that very little new
development was being done in COBOL these days. Most shops don't want to
pay to upgrade to a new version if all they are doing is maintaining legacy
code.

[Default User]

Mark B wrote:

"Default User" <de***********@yahoo.com> wrote in message
news:3o************@individual.net...

I didn't say it wasn't possible
to INSTALL a switch, but that they don't come that way.

Depending on vehicle make/model... you're still wrong.
FORD F150 comes standard with a passenger side 'deactivation
switch' and I'm certain it's not the only model that comes with it.

Ok.

I also said
that many repair shops will refuse to install said switches.

But it's not because of 'liability issues' as you
claimed, they aren't allowed to disable the airbag systems
in any vehicle unless prior approval is received from NHTSA -
nothing however prevents manufacturers from installing the
switches themselves, and as I've pointed out... some do.

How does that mean that repair shops refuse to install cutout switches?
Many do for liability reasons.

Brian

[Chris Sonnack]

Richard Heathfield writes:

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

It's time for the post-increment joke again, if someone would be so kind.

"Didja hear about the new Object-Oriented version of COBOL?"
"No!"
"It's called POST-INCREMENT-COBOL-BY-ONE."

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

[Walter Roberson]

In article <3p************@individual.net>,
Default User <de***********@yahoo.com> wrote:

[OT]

How does that mean that repair shops refuse to install cutout switches?
Many do for liability reasons.

Depends what you mean by "liability reasons". If a US car repair shop
is not presented with an appropriate letter from NHTSA authorizing the
installation of the airbag cutoff switch, then the shop is disallowed
by law from installing said switch. If the shop goes ahead and installs
the switch anyhow without the proper paperwork, then they are liable
to fines, and possible loss of mechanics license, and possibly
even to lawsuits from distraught relatives alleging that the
unauthorized modification was the -cause- of someone's death
("Sure he was going 80 miles an hour on a wet curve signed for 40 mph --
but he would have survived the 30 foot cliff if his airbag hadn't
been illegally disabled!")

If the proper NHTSA paperwork has been presented, then it just
becomes a standard matter of whether the work was performed
competently, same as any other potential liability that mechanics
face all the time.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[Richard Heathfield]

Chris Sonnack said:

Richard Heathfield writes:

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

It's time for the post-increment joke again, if someone would be so kind.

"Didja hear about the new Object-Oriented version of COBOL?"
"No!"
"It's called POST-INCREMENT-COBOL-BY-ONE."

Thank you very much for giving an old joke a home.

/me passes the collection plate round.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain

[Keith Thompson]

Chris Sonnack <Ch***@Sonnack.com> writes:

Richard Heathfield writes:

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

It's time for the post-increment joke again, if someone would be so kind.

"Didja hear about the new Object-Oriented version of COBOL?"
"No!"
"It's called POST-INCREMENT-COBOL-BY-ONE."

I heard ADD ONE TO COBOL GIVIN COBOL.

Isn't this in the FTJ (Frequently Told Joke) list?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Default User]

Walter Roberson wrote:

In article <3p************@individual.net>,
Default User <de***********@yahoo.com> wrote:

[OT]

How does that mean that repair shops refuse to install cutout
switches? Many do for liability reasons.

Depends what you mean by "liability reasons". If a US car repair shop
is not presented with an appropriate letter from NHTSA authorizing the
installation of the airbag cutoff switch, then the shop is disallowed
by law from installing said switch. If the shop goes ahead and
installs the switch anyhow without the proper paperwork, then they
are liable to fines, and possible loss of mechanics license, and
possibly even to lawsuits from distraught relatives alleging that the
unauthorized modification was the -cause- of someone's death
("Sure he was going 80 miles an hour on a wet curve signed for 40 mph
-- but he would have survived the 30 foot cliff if his airbag hadn't
been illegally disabled!")

If the proper NHTSA paperwork has been presented, then it just
becomes a standard matter of whether the work was performed
competently, same as any other potential liability that mechanics
face all the time.

Do you have legal precedent or law that says that if presented with
said documents the installer cannot be held liable for injuries
resulting from the non-presence of the switch?

I'm not being pedantic. I have read of many shops refusing to install
the switches even with signed releases because they (or their insurers)
feared being sued anyway.

Granted, this was some time ago and the "steps" required to get the
switch permits may have alleviated those worries.

Brian

[John W. Kennedy]

Dan wrote:

"John W. Kennedy" <jw*****@attglobal.net> wrote in message
news:np*****************@fe10.lga...

Chris Hills wrote:

In article <V6*****************@fe10.lga>, John W. Kennedy
<jw*****@attglobal.net> writes
>To the best of my knowledge Cobol has no pointers and Cobol programmers
>have no need of the concept (indeed many of them find the idea of a
>pointer quite bizarre)

COBOL 2003 includes OO, and, consequently, references.

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

Yes, the feature crept into many compilers long before COBOL 2003 was
finished.

Is anyone actually using COBOL 2003? My impression was that very little new
development was being done in COBOL these days. Most shops don't want to
pay to upgrade to a new version if all they are doing is maintaining legacy
code.

I think that depends on the shop -- I was working for a place that was
still using COBOL '68 for development when IBM pulled the plug.

--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
....you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"

[Dave Thompson]

On 12 Sep 2005 15:47:25 -0700, "Rob Thorpe"
<ro***********@antenova.com> wrote:
<snip>

Yes. Several programming languages have no concept of pointer that's
visible to the programmer. For example Lisp, Java and Perl have no
pointers. Perl has references which refer, somehow, to another perl
object - effectively equivalent to a pointer.
And in Java _all_ objects use (aliasing) references. (Classic and I'm
pretty sure standard) BASIC has no pointers. FWIW awk has no pointers,
although arrays (not scalars) are by-reference to functions.

Classic FORTRAN and COBOL have no manipulable pointers; they do have
call-by-reference (formally FORTRAN also allows value-result but
that's not feasible for large data). F90 added pointers that are very
type-strict but still can dangle, plus F90 added and F95 and a TR
incorporated into F03 enhanced a more restricted form that are
memory-safe; I haven't checked on recent COBOL.
Lisp's don't have pointers per se. Each name in a lisp program and
almost everything else is "bound" to a piece of data of some type, and
can be freely rebound. Some of these data types can store sequences of
values. So, altogether there is no need for visible pointers.

(There are naturally tons of pointers in actual implementation, but
they're invisible to the programmer).

Lisp "pointers" are quite visible, although (at least classically)
they refer only to cons cells, so might as well be cell ids. E.g.
; A is bound to list (1 2 3) which is a cell whose left (CAR) is 1
; and right (CDR) is a pointer to a cell with left 2
; and right pointer to cell with left 3 and right NIL.
; This can also be written explicitly (1 . (2 . (3 . NIL)))
(SETQ B (CDR A))
(RPLACA B 9)
; A (or what it is bound to) is now (1 9 3)

Conventionally a lot of Lisp code is pure-functional and never
modifies existing data structures, so aliasing doesn't matter, except
when you compare cells for identity (EQ).

So like it or not I think a basic understanding of pointers
is essential when it comes to programming.

Yes, because it's how real machines work.

Concur.

- David.Thompson1 at worldnet.att.net

[Rob Thorpe]

<Groups clipped a little>
Dave Thompson wrote:

On 12 Sep 2005 15:47:25 -0700, "Rob Thorpe"
<ro***********@antenova.com> wrote:
<snip>

Yes. Several programming languages have no concept of pointer that's
visible to the programmer. For example Lisp, Java and Perl have no
pointers. Perl has references which refer, somehow, to another perl
object - effectively equivalent to a pointer.
And in Java _all_ objects use (aliasing) references. (Classic and I'm
pretty sure standard) BASIC has no pointers. FWIW awk has no pointers,
although arrays (not scalars) are by-reference to functions.

Classic FORTRAN and COBOL have no manipulable pointers; they do have
call-by-reference (formally FORTRAN also allows value-result but
that's not feasible for large data). F90 added pointers that are very
type-strict but still can dangle, plus F90 added and F95 and a TR
incorporated into F03 enhanced a more restricted form that are
memory-safe; I haven't checked on recent COBOL.

Ah, I'd forgotten about Basic, and didn't know about recent versions of
Fortran or Cobol.

Lisp's don't have pointers per se. Each name in a lisp program and
almost everything else is "bound" to a piece of data of some type, and
can be freely rebound. Some of these data types can store sequences of
values. So, altogether there is no need for visible pointers.

(There are naturally tons of pointers in actual implementation, but
they're invisible to the programmer).

Lisp "pointers" are quite visible, although (at least classically)
they refer only to cons cells, so might as well be cell ids. E.g.
; A is bound to list (1 2 3) which is a cell whose left (CAR) is 1
; and right (CDR) is a pointer to a cell with left 2
; and right pointer to cell with left 3 and right NIL.
; This can also be written explicitly (1 . (2 . (3 . NIL)))
(SETQ B (CDR A))
(RPLACA B 9)
; A (or what it is bound to) is now (1 9 3)

No, not quite CAR refers to the first element of a pair, CDR the second
element of that pair. A list is formed by a list of pairs. The data is
stored in the CARs and the link to the next pair being stored in the
CDR. This leads to CAR and CDR being called FIRST and REST.

In the above code if A is (1 2 3):
(setq A '(1 2 3))

(car A) is 1
(cdr A) is the list (2 3) , *not* 2

If I do:
(setq b (cdr A)) b is set to (2 3)
then:
(rplaca b 9) b is set to (9 3) because rplaca is a destructive
operation.

These functions can be thought of as implying pointer operations, but
the concept isn't really necessary. Conceptually CAR and CDR access
the elements of a pair, which the lisp implementation deals with.

They need not be implemented quite as the programmer may expect either.
There have been lisp implementations where pairs & lists are
represented in quite subtle ways.

I think programmers of lower level languages like C are more
comfortable thinking of this as pointer manipulation, which is OK.
Conventionally a lot of Lisp code is pure-functional and never
modifies existing data structures, so aliasing doesn't matter, except
when you compare cells for identity (EQ).

Yep, and use the few modifying operations that exist for efficiency.

[Rotes Sapiens]

On Fri, 16 Sep 2005 11:34:04 -0500, Chris Sonnack <Ch***@Sonnack.com>
wrote:

Richard Heathfield writes:

I recall seeing OO Cobol around 1995 though I don't know if it had
pointers/references then.

It's time for the post-increment joke again, if someone would be so kind.

"Didja hear about the new Object-Oriented version of COBOL?"
"No!"
"It's called POST-INCREMENT-COBOL-BY-ONE."

I think I'll try COmmon Business Upgraded Legacy Language.
Sig:
"The cat was once revered as a god. They have never forgotten this" - Anon

[apg]

Christopher Benson-Manica wrote:

In comp.lang.c J French <er*****@nowhere.uk> wrote:

There is a lot to be said for strong type checking, it shows up stupid
errors rapidly

It catches type errors at compile time (for compiled languages), but
it can also be a hinderance at times. I have taken advantage of the
lax typing of JavaScript many times.

Really what it all comes down to is good programming. It was suggested
that pointers are valuable to circumvent good programming after all you
wouldn't need to bypass type checking if your programming was logically
correct.

To say that if source code compiles without error means the program is
correct is an error in it's self, there are too many reasons why the
program may be bad. It may be logically incorrect as many are, it may
not have checks on bounds or other sources of overrun to name but a few.
Lastly and I come across this one often it just doesn't fulfill the
customers needs and expectations.

There is nothing wrong with using pointers if they are used properly.
Pointers (indexes) are used in assembler frequently. There should be no
need for pointers in a high level language other than an index to a
record or similar requirement. Strong typing I agree is a pain at times
but if you can't express what you are attempting to achieve without
breaking the rules then there is something wrong and it's probably not
the rules.

[apg]

Steve O'Hara-Smith wrote:

On Thu, 15 Sep 2005 08:47:50 +0000 (UTC)
er*****@nowhere.uk (J French) wrote:

On Thu, 15 Sep 2005 08:16:25 +0100, Chris Hills <ch***@phaedsys.org>
wrote:

I agree that protecting students with a "safe" language makes matters a
lot worse as they rely on the compiler for error checking and safety.

Agreed.

So you drive a car with dodgy brakes, no airbags and no seat belts ?

Absolutely not - but those who learn their road sense on a bicycle
(dodgy brakes, no airbags, no seatbelts and worse) are probably safer
drivers than those who learned it in a Volvo.

Maybe...

There is a lot to be said for strong type checking, it shows up stupid
errors rapidly

Yes but there's a lot to be said for learning the art of
programming with something dangerous like BCPL or C where careless
coding gets rewarded with core dumps and other program crashes.

Why stop there, learn with assembler, I did, you've not lived until
you've patched the vtoc in hex or keyed in a bootstrap loader in octal.

Gawd, I remember having to write my own call parameter checking
utility

Doing something like that teaches a lot.

[Walter Roberson]

In article <BF***************@news01.roc.ny>, apg <ap*@NoSpam.alot> wrote:

There is nothing wrong with using pointers if they are used properly.
Pointers (indexes) are used in assembler frequently. There should be no
need for pointers in a high level language other than an index to a
record or similar requirement. Strong typing I agree is a pain at times
but if you can't express what you are attempting to achieve without
breaking the rules then there is something wrong and it's probably not
the rules.
We had a prototype research program that was in a mix of C
(computation section) and IDL (GUI). It went a lot further than
proof of concept, and should have been broken down and rewritten
long long before the point it go to, but you know what they say:
Programming is what happens while you're busy making other plans.

Eventually a decision was taken to generalize some important parts of it,
and modernize it all, and a fresh team was put together. As Java was
The Way Of The Future at the time, the team decided to write the
program in Java as much as possible, dropping into C++ for those
portions that were -measureably- too slow in Java.

You are, I am sure, familiar with the reasons to abandon C and move
to Java: Java is a clean new language design, object oriented,
without those ugly buffer overruns, and without all those pointer
problems C has, and any "well-written" Java program doesn't -need-
anything as gouche as type-punning. And with the IBM JIT compilers,
Java is even faster than C.
Well, about a person-decade of programming effort later, I chatted
with the team leader, and found that they had given up on that
approach, and for their next generation of the project, they were
rewriting everything into as pure C++ as they could, with just a
small graphics library interface for the GUI.

The reason? Because {I was told} Java's "reference" mechanisms in
concert with Java's typing rules, are such that every time they sliced
up a multidimensional array into 1-D vectors for the mathematical
analysis we do, Java insisted on taking a -copy- of the data insted
of just passing along the address of the data. And since the
datasets could be a gigabyte and since the analysis portion might
iterate through ten thousand or more possibilities, all of the
data copying that was going on was just killing their performance.

but if you can't express what you are attempting to achieve without
breaking the rules then there is something wrong and it's probably not
the rules.

On the other hand, as hinted at in my anecdote, a strong typing
system can become a millstone if there are legitimate reasons to
want to logically decompose the types. Even just the layer
change from double[x][y] to double[x*y] can crush you -- a layer change
that is trivial in C but not in a strongly typed system.
--
Goedel's Mail Filter Incompleteness Theorem:
In any sufficiently expressive language, with any fixed set of
email filtering algorithms, there exists at least one spam message
which the algorithms are unable to filter out.

[apg]

Walter Roberson wrote:

In article <BF***************@news01.roc.ny>, apg <ap*@NoSpam.alot> wrote:

There is nothing wrong with using pointers if they are used properly.
Pointers (indexes) are used in assembler frequently. There should be no
need for pointers in a high level language other than an index to a
record or similar requirement. Strong typing I agree is a pain at times
but if you can't express what you are attempting to achieve without
breaking the rules then there is something wrong and it's probably not
the rules.

We had a prototype research program that was in a mix of C
(computation section) and IDL (GUI). It went a lot further than
proof of concept, and should have been broken down and rewritten
long long before the point it go to, but you know what they say:
Programming is what happens while you're busy making other plans.

Eventually a decision was taken to generalize some important parts of it,
and modernize it all, and a fresh team was put together. As Java was
The Way Of The Future at the time, the team decided to write the
program in Java as much as possible, dropping into C++ for those
portions that were -measureably- too slow in Java.

You are, I am sure, familiar with the reasons to abandon C and move
to Java: Java is a clean new language design, object oriented,
without those ugly buffer overruns, and without all those pointer
problems C has, and any "well-written" Java program doesn't -need-
anything as gouche as type-punning. And with the IBM JIT compilers,
Java is even faster than C.
Well, about a person-decade of programming effort later, I chatted
with the team leader, and found that they had given up on that
approach, and for their next generation of the project, they were
rewriting everything into as pure C++ as they could, with just a
small graphics library interface for the GUI.

The reason? Because {I was told} Java's "reference" mechanisms in
concert with Java's typing rules, are such that every time they sliced
up a multidimensional array into 1-D vectors for the mathematical
analysis we do, Java insisted on taking a -copy- of the data insted
of just passing along the address of the data. And since the
datasets could be a gigabyte and since the analysis portion might
iterate through ten thousand or more possibilities, all of the
data copying that was going on was just killing their performance.

but if you can't express what you are attempting to achieve without
breaking the rules then there is something wrong and it's probably not
the rules.

On the other hand, as hinted at in my anecdote, a strong typing
system can become a millstone if there are legitimate reasons to
want to logically decompose the types. Even just the layer
change from double[x][y] to double[x*y] can crush you -- a layer change
that is trivial in C but not in a strongly typed system.

In a strong typed system you should still be able to access your data by
value or reference. Your problem seems to be not dealing with strong
typed items but with the way you are forced to access each item of data.
This is one of the problems I have seen in oop before.

Could it be that more of a problem for people to use oop? rather than
one of the more traditional methodologies. I personally have never been
convinced that oop is the best way to go, however elegant it may be.

Your example appears to be more a shortcoming of the way Java handles
data than that of strongly typed variables. Strong typing limits what
you can do to a variable, you can't assign an ascii value to a strongly
typed integer variable however languages which do not support strong
typing such as Fortran IV will allow this to happen. As pointers in C
are not strongly typed so you could perform the same kind of operation.
Where as pointers in Pascal are strongly typed and so such operations
are not permitted.

I've never understood why some people must have the latest car off the
production line, without too much regard to how it performs and whether
it suits their needs.

[Walter Roberson]

In article <ee****************@news02.roc.ny>, apg <ap*@NoSpam.alot> wrote:

Your example appears to be more a shortcoming of the way Java handles
data than that of strongly typed variables. Strong typing limits what
you can do to a variable, you can't assign an ascii value to a strongly
typed integer variable however languages which do not support strong
typing such as Fortran IV will allow this to happen. As pointers in C
are not strongly typed so you could perform the same kind of operation.
Where as pointers in Pascal are strongly typed and so such operations
are not permitted.

In C, if I have double trouble[1048576][7] then trouble[4][2] has type
double and there is no problem with us working arithmetically with that
single value.

But in C, trouble[4] also has a type -- it is double [7] which is to
say an array of 7 doubles. Hence, if one were using a strongly-typed C,
one would be able to access the doubles in the array "trouble" at most
7 at a time, unless the language were to be enhanced with array
operators (such as in IDL.) This isn't a matter of wanting to store
characters into the space used by the doubles, this is a matter of
the type system.

In any given language, there might not -be- a type system, or there
might be a type system that operates only with the primitive types --
but as soon as you start being able to build aggregate types that are
considered distinct from "just a convenient way to organize primitive
data types", then if you can refer to array sub-sections at all
in the language, those sub-sections have types of their own and
a "strongly typed" system would enforce those types.

Continuing the example, examine trouble[4][9] -- to a strongly typed
system, that's a type error, as trouble[4] is not a type with 10
elements.

For the mathematical analysis we were doing, we often needed to
pass a subsection of a large array. In C as it is now, that's
trivial to do efficiently, as we can make use of the synonym
between the address of an array (&trouble), the address of the
first element of its first dimension (&trouble[0]), and the
address of the first element of the first element of its first
dimension (&trouble[0][0]). C allows all of these to be passed
into a routine that has its corresponding parameter declared
as any of double* or double[] or double[][] . C's type laxity allows
us to access what we know to be a block of consequative memory
in any way that is convenient to us -- but in a strongly typed system,
we would be constrained to only access the memory in the same way
it was declared.
There are languages in which multidimensional arrays have unspecified
internal structure -- allowing the implementation to transparently
move between straight blocks of storage, or vectors of pointers to
vectors of storage, or various sparse representation techniques.
(e.g., Mathematica.) For those languages, one must enforce strong
typing of array subsections (or deny the possibility of those),
or the language must provide a mandatory accessor function along with
the data pointer, or the language must provide a way to allow the current
storage arrangement to be examined.

If one was hoping for efficiency by memcpy()'ing an array area larger
than the fastest-varying dimension, and one cannot force a particular
representation, then only the latter of those three possibilities
(ability to examine the internal representation) offers any hope of
that at all: one cannot get memory-block efficiencies without
escaping from strong typing.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[apg]

Walter Roberson wrote:

In article <ee****************@news02.roc.ny>, apg <ap*@NoSpam.alot> wrote:

Your example appears to be more a shortcoming of the way Java handles
data than that of strongly typed variables. Strong typing limits what
you can do to a variable, you can't assign an ascii value to a strongly
typed integer variable however languages which do not support strong
typing such as Fortran IV will allow this to happen. As pointers in C
are not strongly typed so you could perform the same kind of operation.
Where as pointers in Pascal are strongly typed and so such operations
are not permitted.

In C, if I have double trouble[1048576][7] then trouble[4][2] has type
double and there is no problem with us working arithmetically with that
single value.

But in C, trouble[4] also has a type -- it is double [7] which is to
say an array of 7 doubles. Hence, if one were using a strongly-typed C,
one would be able to access the doubles in the array "trouble" at most
7 at a time, unless the language were to be enhanced with array
operators (such as in IDL.) This isn't a matter of wanting to store
characters into the space used by the doubles, this is a matter of
the type system.

In any given language, there might not -be- a type system, or there
might be a type system that operates only with the primitive types --
but as soon as you start being able to build aggregate types that are
considered distinct from "just a convenient way to organize primitive
data types", then if you can refer to array sub-sections at all
in the language, those sub-sections have types of their own and
a "strongly typed" system would enforce those types.

Continuing the example, examine trouble[4][9] -- to a strongly typed
system, that's a type error, as trouble[4] is not a type with 10
elements.

For the mathematical analysis we were doing, we often needed to
pass a subsection of a large array. In C as it is now, that's
trivial to do efficiently, as we can make use of the synonym
between the address of an array (&trouble), the address of the
first element of its first dimension (&trouble[0]), and the
address of the first element of the first element of its first
dimension (&trouble[0][0]). C allows all of these to be passed
into a routine that has its corresponding parameter declared
as any of double* or double[] or double[][] . C's type laxity allows
us to access what we know to be a block of consequative memory
in any way that is convenient to us -- but in a strongly typed system,
we would be constrained to only access the memory in the same way
it was declared.
There are languages in which multidimensional arrays have unspecified
internal structure -- allowing the implementation to transparently
move between straight blocks of storage, or vectors of pointers to
vectors of storage, or various sparse representation techniques.
(e.g., Mathematica.) For those languages, one must enforce strong
typing of array subsections (or deny the possibility of those),
or the language must provide a mandatory accessor function along with
the data pointer, or the language must provide a way to allow the current
storage arrangement to be examined.

If one was hoping for efficiency by memcpy()'ing an array area larger
than the fastest-varying dimension, and one cannot force a particular
representation, then only the latter of those three possibilities
(ability to examine the internal representation) offers any hope of
that at all: one cannot get memory-block efficiencies without
escaping from strong typing.

First if you were using a strongly typed system and wanted as you state
to pass whole rows of data from you array then you would make the array
an array of records containing an array of double by the number of
elements reading and writing to the master array is no more difficult
and you are able to pass all seven double elements with one reference.
There are many other ways I'm sure you can think of them.

You could better use a different language for array manipulation PL/I
has a whole set of array manipulation methods, I believe that the later
versions of Fortran also support array manipulation. Both of these are
strongly typed languages. I know there are several others but I can't
remember them at the moment. I know in PL/I you could do all you wish
and more with an array.

Why are you copying the array when you only have to reference them, you
can still either write back your changes or write them elsewhere. I
believe that even in Pascal arrays are passed by reference not by
copying them. You don't get much more strongly typed than Pascal.

I agree the way you are doing it will get the job done, it is alright if
you are using it like some kind of programable calculator but not
suitable for production software which will be used by others who may
not understand it's limitations. I wouldn't want similar methods used in
the autopilot of the plane I was a passenger or controlling the local
nuclear power plant. I really wouldn't want similar methods in my OS but
who knows, garbage in BSD.

The only reason for not checking types and bounds is speed but by not
doing so it's like riding fast down hill and not checking that the
breaks work...
--
How many Forth programmers does it take to change a light bulb?

None because they programed it to change it's self.

[Dave Thompson]

On 20 Sep 2005 09:59:16 -0700, "Rob Thorpe"
<ro***********@antenova.com> wrote:

<Groups clipped a little>
And we're actually OT in clc but I don't read c.prog.
Dave Thompson wrote: <snip>

Lisp "pointers" are quite visible, although (at least classically)
they refer only to cons cells, so might as well be cell ids. E.g.
; A is bound to list (1 2 3) which is a cell whose left (CAR) is 1
; and right (CDR) is a pointer to a cell with left 2
; and right pointer to cell with left 3 and right NIL.
; This can also be written explicitly (1 . (2 . (3 . NIL)))
(SETQ B (CDR A))
(RPLACA B 9)
; A (or what it is bound to) is now (1 9 3)

No, not quite CAR refers to the first element of a pair, CDR the second
element of that pair. A list is formed by a list of pairs. The data is
stored in the CARs and the link to the next pair being stored in the
CDR. This leads to CAR and CDR being called FIRST and REST.

That's what I said. Each cell is (at least logically) a pair; the
first cell's left/CAR is the first element and its right/CDR "is"
(points to) the second cell, and so on down the list. (I only gave the
example to length 3, which IMO is enough to make the pattern clear,
though for programmers it might be better to just state the rule.)
In the above code if A is (1 2 3):
(setq A '(1 2 3))

(car A) is 1
(cdr A) is the list (2 3) , *not* 2
(cdr a) is the list (2 3); (car (cdr a)) aka (cadr a) is 2
If I do:
(setq b (cdr A)) b is set to (2 3)
then:
(rplaca b 9) b is set to (9 3) because rplaca is a destructive
operation.
Right. And (cdr a) is still EQ (the same cell as) b, so a is (1 9 3).
Hence, at least as seen by the programmer, these are pointers.
These functions can be thought of as implying pointer operations, but
the concept isn't really necessary. Conceptually CAR and CDR access
the elements of a pair, which the lisp implementation deals with.
CAR and CDR access the halves of a pair a.k.a. cell, but a pair has
identity and is referencable and mutable.
They need not be implemented quite as the programmer may expect either.
There have been lisp implementations where pairs & lists are
represented in quite subtle ways.
True; I should have said 'vanilla' or 'canonical' Lisp. I was trying
to be brief, especially with my (recently worse) off-line delay.
I think programmers of lower level languages like C are more
comfortable thinking of this as pointer manipulation, which is OK.

Conventionally a lot of Lisp code is pure-functional and never
modifies existing data structures, so aliasing doesn't matter, except
when you compare cells for identity (EQ).

Yep, and use the few modifying operations that exist for efficiency.

- David.Thompson1 at worldnet.att.net