Cast your mind way, way back, to the Dark Ages of personal computing. 
Children like me sat at home playing with a Sinclare Spectrum or a 
Commodore 64 - great chunks of grey plastic which load files from audio 
cassette (remember those?), and produce blocky 16-colour graphics. All 
of these machines are powered by low-end 8-bit microprocessors clokced 
at around 1MHz, they have a few KB of RAM, and they each have a ROM 
containing a BASIC interpretter of varying sophistication which also 
doubles as a kind of Disk Operating System. (Not that anybody *has* 
disks yet...)

It is a sobering thought to realise that as children like me sat at 
home, glibly typing in the source code listings from computer magazines 
(remember those?), PostScript had just been released, SQL was 5 years 
old, C was 10 years old, Smalltalk was almost 15 years old, and BASIC 
itself was already 20 years old. The mighty Lisp was over 25 years old 
already. And just a few years later, C++ was invented.

When the C64 was designed, extremely powerful languages such as List, 
Prolog, Smalltalk and even Pascal were already decades old. And yet, the 
C64 came with... BASIC?

Even as Borland released TurboPascal 5.5 for DOS [that's the one with 
the object-oriented extensions which aren't actually object-oriented], 
Eiffel, Erlang and Miranda already existed. (Miranda is the [proprietry] 
language which eventually gave rise to Haskell.) And Haskell 1.0 itself 
was formalised only a year or two after TP 5.5 came out. For MS-DOS. (!)

Have a look at the attached chart. (Excel was less than helpful in 
producing this, BTW.) There are several interesting anomolies:

- C and Prolog appeared at the same time. This doesn't make a lot of 
sense. C is a crude, simplistic low-level bit-twiddling langauge, while 
Prolog is a powerful high-level logic manipulation language. If there 
were computers capable of running Prolog, why did C need to exist?

- Pascal predates C, and yet C fails to incorporate almost any of the 
good ideas from Pascal.

- Smalltalk was doing OOP before home computers were even *invented*, 
and yet it wasn't until 20 _years_ later that commercial products like 
TP 5.5 and Delphi started to take the idea mainstream.

- SQL existed 15 years before high-capacity storage devices appeared. 
(This is worse than it appears. You wouldn't even realise that a 
language like SQL was *necessary* unless databases themselves had 
already existed for some considerable length of time. And after that 
there would obviously be a rash of incompatible proprietry languages 
until people decided to design a standardised one.)

- PostScript was invented 10 years before laser printers existed. (It 
was apparently designed specifically with laser printers in mind, as I 
had always believed.)

- That splodge next to it is C++ and Ada. They were apparently invented 
at the same time. And yet, 10 years later, nobody had heard of C++ yet.

- Haskell was invented back when people were still using green screens 
and MS-DOS. It brings a slight chill to my spine to know that way back 
when I was still coding with AMOS Professional, minds immeasurably 
superior to ours had already constructed the most powerful programming 
language known.

- Perl predates the Internet by half a decade. (WTF?) I can only imagine 
it began life as a Unixy text-munging system in the style of awk, sed, etc.

- JavaScript predates Java. (WTF?!)

- Visual Basic is significantly older than Delphi.

- Ruby, PHP and JavaScript were all around at the same time as Delphi. 
This is puzzling because when Delphi was new, the Internet didn't really 
"exist" yet.

- C# (by which I denote the entire zoo of .NET languages) is the only 
thing in the chart to have been invented this millennium.

Post a reply to this message

Attachments:
Download 'programming languages.png' (26 KB)

Preview of image 'programming languages.png'

> - C and Prolog appeared at the same time. This doesn't make a lot of 
> sense. C is a crude, simplistic low-level bit-twiddling langauge, while 
> Prolog is a powerful high-level logic manipulation language. If there 
> were computers capable of running Prolog, why did C need to exist?

Speed?

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> > - C and Prolog appeared at the same time. This doesn't make a lot of
> > sense. C is a crude, simplistic low-level bit-twiddling langauge, while
> > Prolog is a powerful high-level logic manipulation language. If there
> > were computers capable of running Prolog, why did C need to exist?
>
> Speed?

How'd you imagine writing libraries for said high level logic manipulation
language to interface hardware? Assembler? I'd think C is your best bet there
since it's low level enough to do the bit twiddling to control hardware and high
level enough to not be a PITA.

Just my 2 cents

Post a reply to this message

----- Original Message ----- 
From: "Invisible" <voi### [at] devnull>
Newsgroups: povray.off-topic
Sent: Wednesday, October 21, 2009 8:30 AM
Subject: Programming langauges


> Cast your mind way, way back, to the Dark Ages [...]

Wow... so many thoughts, and the coffee is only beginning to swirl in my 
brain...

Bear in mind that the world wasn't as connected then as it is now. 
Advancement in technology was slower, people used books and published papers 
to share technical ideas, not the Internet. Even now, people use different 
programming languages because, for the most part, programmers are 
provincialists who tend to think the first language they learned is the best 
one.

Pascal was never intended to be efficient on the inside, and was often 
rejected by people working to create real-world software for that reason. 
Wirth invented Pascal specifically as a teaching tool to educate students in 
the concepts of nested, structured programming with a hierarchy of 
visibility of token names. He himself never intended for it to be used in 
the real world. OTOH, Ritchie (and Kernighan, but mostly Ritchie) 
implemented C as a way to take a step back from machine code and assemblers 
to make it easier to port system software across radically different 
hardware architectures.

BASIC was also developed as a teaching tool, but it was also considered the 
best choice by many for popular use (the name itself may have lead that 
charge, based on the power of suggestion). More importantly, BASIC is 
interpreted, so you can ship it without a compiler, linker, or memory for 
large symbol tables. Slap it in a ROM, stick it in your gray box, and start 
selling.

Myself, I was programming a PDP 11 (and a VAX 11/780 shortly thereafter) 
using both C and Pascal at about the same time you were loading your 
cassette tapes. I did have a Vic 20 about then, which I tried to program a 
duplicate of Q*bert on. Good times, that. :D

Post a reply to this message

Captain Jack wrote:

> Wow... so many thoughts, and the coffee is only beginning to swirl in my 
> brain...

Y'aarrr! ;-)

> Bear in mind that the world wasn't as connected then as it is now. 
> Advancement in technology was slower, people used books and published papers 
> to share technical ideas, not the Internet.

Sure. Back then, if you wanted better graphics, you had to wait for the 
next home computer to be released. Today, more powerful graphics cards 
come out almost weekly. (Although we have long since reached the point 
where the graphical quality is as high as anybody needs, and you're only 
arguing about 3D rendering power.)

Look at the C64 with it's 16-colour graphics. 5 years later the A500 has 
12-bit colour and up to 64 colours on-screen at once. Another 5 years 
and the A1200 gives you 24-bit colour and 256 colours at once. That's a 
while to wait. ;-)

> Even now, people use different 
> programming languages because, for the most part, programmers are 
> provincialists who tend to think the first language they learned is the best 
> one.

That must make me rare then. I can program in BASIC [I MEAN OLD SKOOL 
BASIC WITH ALL-CAPS AND LINE NUMBERS INSTEAD OF A TEXT EDITOR], Pascal 
(which is structured), PostScript (which is weird), JavaScript, Java, 
Smalltalk, Eiffel (which are all OOP), Haskell (which is functional), 
SQL (which is relational), and I have a vague grasp of Lisp and Prolog. 
I've also written in machine code. (No, I don't mean assembly. I *mean* 
machine code. I couldn't afford an assembler, so I assembled the program 
by hand with a big book of op-code tables...)

Did I mention POV-Ray SDL in there?

The first langauge I learned was BASIC, and it sux. Even fancy AMOS sux.

[For anybody that doesn't know: AMOS is BASIC with bells on. Sort of 
vaguely like Visual Basic, in that AMOS gives you an IDE and powerful 
multimedia features, but the actual language itself has a billion syntax 
features but still isn't all that powerful. AMOS Professional comes with 
a 2,000-page user guide and has over 800 commands. It arrives on 14 DD 
floppies - most of which are bitmaps, music, sprites and demo programs.]

> Pascal was never intended to be efficient on the inside, and was often 
> rejected by people working to create real-world software for that reason. 
> Wirth invented Pascal specifically as a teaching tool to educate students in 
> the concepts of nested, structured programming with a hierarchy of 
> visibility of token names.

I've heard this before. I never really understood why Pascal couldn't be 
a useful real-world language. (Aside from a few obvious flaws which 
should have been easy to fix.)

> BASIC was also developed as a teaching tool, but it was also considered the 
> best choice by many for popular use (the name itself may have lead that 
> charge, based on the power of suggestion). More importantly, BASIC is 
> interpreted, so you can ship it without a compiler, linker, or memory for 
> large symbol tables. Slap it in a ROM, stick it in your gray box, and start 
> selling.

Lisp isn't too hard to interpret either. (But arguably too hard for 
8-year-olds to program with.) Smalltalk is pretty easy to interpret, and 
easy on the brain too. Prolog would also not be hard to interpret, but 
probably not especially useful for home users.

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4adf12fc$1@news.povray.org...
>
> That must make me rare then. I can program in BASIC [I MEAN OLD SKOOL 
> BASIC WITH ALL-CAPS AND LINE NUMBERS INSTEAD OF A TEXT EDITOR], Pascal 
> (which is structured), PostScript (which is weird), JavaScript, Java, 
> Smalltalk, Eiffel (which are all OOP), Haskell (which is functional), SQL 
> (which is relational), and I have a vague grasp of Lisp and Prolog. I've 
> also written in machine code. (No, I don't mean assembly. I *mean* machine 
> code. I couldn't afford an assembler, so I assembled the program by hand 
> with a big book of op-code tables...)
>
> Did I mention POV-Ray SDL in there?
>
> The first langauge I learned was BASIC, and it sux. Even fancy AMOS sux.

Hmmm... lessee... Coursewriter, Fortran, COBOL, Pascal, Lisp, BASIC 
(Dartmouth, A-BASIC, GWBASIC, VB et cetera on and on), C, C++, C#, Providex, 
BBx, ZPL, Psion AXL, Forth, Prolog, APL (not much), Erlang, x86 Assembler, 
System 36 Assembler--

There's more but that's enough urinating off the port bow. :)

>
> I've heard this before. I never really understood why Pascal couldn't be a 
> useful real-world language. (Aside from a few obvious flaws which should 
> have been easy to fix.)

As originally designed, Pascal didn't support source code modules or 
including files, which made it difficult to write large programs with, and 
made it almost impossible for a team to work on an application. You couldn't 
make libraries to link to later, or use any kind of dynamic linking with it.

It can be (and has been) extended, but then you're getting into a gray area: 
"My language is the best, so I'm going to add in bits of your language to 
prove it." (Not saying that you're saying that, put down the flamethrower, 
please. <g> However, I have heard that statement used in actual 
conversation, in its essence)

Binary, digital computers can only do three things. They do them really 
fast, and can create some amazing things from those three functions, but 
still... when you get right down to it, the language we use doesn't really 
matter. :D

> Lisp isn't too hard to interpret either. (But arguably too hard for 
> 8-year-olds to program with.) Smalltalk is pretty easy to interpret, and 
> easy on the brain too. Prolog would also not be hard to interpret, but 
> probably not especially useful for home users.

What's great for that is Forth... you can fit the rules engine in about 4Kb 
and include the most commonly defined symbols. All the rest of your RAM, 
which doesn't have to be much, is available for code. Like Lisp, though, 
it's a stack oriented language, and I think that confuses a lot of the 
masses.

Post a reply to this message

>> That must make me rare then. I can program in BASIC [I MEAN OLD SKOOL 
>> BASIC WITH ALL-CAPS AND LINE NUMBERS INSTEAD OF A TEXT EDITOR], Pascal 
>> (which is structured), PostScript (which is weird), JavaScript, Java, 
>> Smalltalk, Eiffel (which are all OOP), Haskell (which is functional), SQL 
>> (which is relational), and I have a vague grasp of Lisp and Prolog. I've 
>> also written in machine code. (No, I don't mean assembly. I *mean* machine 
>> code. I couldn't afford an assembler, so I assembled the program by hand 
>> with a big book of op-code tables...)
>>
>> Did I mention POV-Ray SDL in there?
> 
> Hmmm... lessee... Coursewriter, Fortran, COBOL, Pascal, Lisp, BASIC 
> (Dartmouth, A-BASIC, GWBASIC, VB et cetera on and on), C, C++, C#, Providex, 
> BBx, ZPL, Psion AXL, Forth, Prolog, APL (not much), Erlang, x86 Assembler, 
> System 36 Assembler--

I might also throw in Mathematica, TeX, Tcl, MS-DOS scripting, and the 
various other languages which aren't "programming languages" such as 
HTML, CSS, XSLT, AmigaGuide, ARexx, Automake, the lambda calculus...

> There's more but that's enough urinating off the port bow. :)

;-)

>> I've heard this before. I never really understood why Pascal couldn't be a 
>> useful real-world language. (Aside from a few obvious flaws which should 
>> have been easy to fix.)
> 
> As originally designed, Pascal didn't support source code modules or 
> including files, which made it difficult to write large programs with, and 
> made it almost impossible for a team to work on an application. You couldn't 
> make libraries to link to later, or use any kind of dynamic linking with it.

When I first encountered it, Pascal already had modules and sane I/O. (I 
gather that at one time this was not the case.) It still had that silly 
restriction where array sizes had to be known at compile-time for no 
apparent reason...

Anyway, it's irrelevant now. Pascal is a monomorphic language. It would 
get laughed at today.

> What's great for that is Forth... you can fit the rules engine in about 4Kb 
> and include the most commonly defined symbols. All the rest of your RAM, 
> which doesn't have to be much, is available for code. Like Lisp, though, 
> it's a stack oriented language, and I think that confuses a lot of the 
> masses.

Heh, yeah, I can't see that one taking off really...

(You can also interpret Haskell fairly easily, but it probably requires 
too many resouces.)

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4adf1def$1@news.povray.org...
> When I first encountered it, Pascal already had modules and sane I/O. (I 
> gather that at one time this was not the case.) It still had that silly 
> restriction where array sizes had to be known at compile-time for no 
> apparent reason...
>
> Anyway, it's irrelevant now. Pascal is a monomorphic language. It would 
> get laughed at today.

I had a friend who was working on a master's in Comp Sci in oh, about 1982. 
His professor gave him this thesis project:

Write a Pascal compiler.

In Pascal.

I can still hear in my mind the screams coming from late at night from 
friend's apartment. He was NOT a happy camper for those two years. :D

Post a reply to this message

> I had a friend who was working on a master's in Comp Sci in oh, about 1982. 
> His professor gave him this thesis project:
> 
> Write a Pascal compiler.
> 
> In Pascal.
> 
> I can still hear in my mind the screams coming from late at night from 
> friend's apartment. He was NOT a happy camper for those two years. :D

Wee... I should have just grabbed a copy of Borland TurboPascal. It was 
written in TurboPascal! ;-)

I once had a go at writing a Pascal interpretter in BASIC. (Because I 
didn't have access to any computer that actually had a Pascal compiler 
or interpretter.) Of course, not knowing anything about computer science 
[because I was 11], I attempted to construct a program to edit, 
tokenise, parse, type-check and execute the Pascal source code all at 
once. This inevitably resulted in rapid and complete failure.

Today I understand that the correct thing to do would be to build a text 
editor, *then* try to make a compiler/interpretter. And have this thing 
process the souce code in several seperate stages, not all at once.

Basically I was trying to tackle a problem having no idea where to start 
or how to structure it.

I was only 11, after all...

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4adf232d$1@news.povray.org...
> Basically I was trying to tackle a problem having no idea where to start 
> or how to structure it.
>
> I was only 11, after all...

Let me think... 11, for me, would have been 1972-3, which would have been 
the sixth grade... I didn't have access to any kind of computer anywhere 
(that would come about four years later, when my shool got a remote terminal 
attached to an IBM system 34). I *was* into electronics at that point, and a 
rigged a kind of programmable light board out of some scrap wood, parts from 
about a dozen flashlights and some resistors. You could patch jumper wires 
into clips on the board to make little puzzles to solve by flipping numbered 
switches. A couple of years after that, I spent some time building TTL 
circuits, which was really cool, but not as flexible as I would have liked.

But, man oh man, when I did get started programming, I new I'd come home. :D

Post a reply to this message

Invisible schrieb:

> When the C64 was designed, extremely powerful languages such as List, 
> Prolog, Smalltalk and even Pascal were already decades old. And yet, the 
> C64 came with... BASIC?

Sure.

Home computers called for a language with the following features:

- Interpreted (to be able to double-act as a "shell")
- Low memory footprint (to fit in the limited ROM and RAM)
- Shallow learning curve (to give users a false sense of being computer 
experts)

And once Commodore had established BASIC as the de-facto standard for 
home computers, the case was settled anyway.


> Even as Borland released TurboPascal 5.5 for DOS [that's the one with 
> the object-oriented extensions which aren't actually object-oriented], 

 From what I remember, I'd disagree. (Then again, maybe there was a 
difference between TP 5.5 and TP 6.0; I only really used the latter; and 
TP 3.something earlier.)


> - C and Prolog appeared at the same time. This doesn't make a lot of 
> sense. C is a crude, simplistic low-level bit-twiddling langauge, while 
> Prolog is a powerful high-level logic manipulation language. If there 
> were computers capable of running Prolog, why did C need to exist?

Maybe simply /because/ Prolog was such a high-level language, and didn't 
fit all applications? Like, for instance, writing a Unix kernel (which 
is what C was initially invented for)?


> - SQL existed 15 years before high-capacity storage devices appeared. 

This is somewhat unsettling indeed.


> - PostScript was invented 10 years before laser printers existed. (It 
> was apparently designed specifically with laser printers in mind, as I 
> had always believed.)

You're wrong here: The first laser printer dates back to 1969, while 
even the roots of PostScript date no further back than 1976. 
Furthermore, the language was initially targeted at the offset printing 
industry to drive Computer-to-Film imagesetters, and was only later 
adapted to laser printers.


  - Perl predates the Internet by half a decade. (WTF?) I can only imagine
> it began life as a Unixy text-munging system in the style of awk, sed, etc.

You surely mean it predates the /World Wide Web/ by half a decade.

According to Wikipedia, it was indeed developed (at NASA, btw) as a Unix 
tool for report processing.

> - JavaScript predates Java. (WTF?!)

... under the titles "Mocha" and later "LiveScript", yes. The name 
JavaScript wasn't coined until December 1995 - when Java was already 
released to the public (not in 1996, as your chart implies) - probably 
in an attempt to benefit from the Java hype of those days.


> - Visual Basic is significantly older than Delphi.

No surprise here; Delphi was actually Borland's attempt to regain market 
shares, after Microsoft's success with their BASIC dialect and IDE, 
which first introduced (at least to the masses) the concept of a "GUI 
modeller" that allowed to visually edit an application's graphical user 
interface instead of generating it programmatically.


> - Ruby, PHP and JavaScript were all around at the same time as Delphi. 
> This is puzzling because when Delphi was new, the Internet didn't really 
> "exist" yet.

Again, I guess you mean WWW, not internet.

And yes, it did exist already, although in this case Microsoft was just 
appearing on the scene; the first graphical web browser, NCSA Mosaic, 
had been released two years earlier already, and the WWW was already all 
the rage by 1995.

The WWW itself actually dates back to 1991, when it was still text-based.

(As for PHP, it should also be noted that back in 1995, when it was 
first released, it was not much more than a toolset written by the 
author to manage his own personal homepage.)

Post a reply to this message

Invisible schrieb:

> That must make me rare then. I can program in BASIC [I MEAN OLD SKOOL 
> BASIC WITH ALL-CAPS AND LINE NUMBERS INSTEAD OF A TEXT EDITOR], Pascal 
> (which is structured), PostScript (which is weird), JavaScript, Java, 
> Smalltalk, Eiffel (which are all OOP), Haskell (which is functional), 
> SQL (which is relational), and I have a vague grasp of Lisp and Prolog. 
> I've also written in machine code. (No, I don't mean assembly. I *mean* 
> machine code. I couldn't afford an assembler, so I assembled the program 
> by hand with a big book of op-code tables...)

Hum...

BASIC: Yes, first language I learned. On a home computer, of course. 
Locomotive Basic, to be precise. Amstrad CPC 6128.

Pascal: Second serious language I learned. Turbo-Pascal 3.Something back 
then on CP/M machines, later Turbo-Pascal 6.0. My personal favorite 
language in DOS times.

PostScript: Yes, been there. Weiredest (and therefore most interesting) 
language there is out there, if I'm asked (except for /deliberately/ 
obfuscated languages, which aren't half as interesting due to the 
frustration potential involved).

JavaScript, Java, SQL: Yes.

Smalltalk: Seen it; would take some days to get back into it.

Eiffel, Haskell, Lisp, Prolog: No, never seen (well, seen a /bit/ of 
Haskell here of course :-))

Machine code: Yes, I think I did "poke" a few bytes into my Amstrad CPC 
6128; 0xCD was CALL and 0xC9 was RET, if I remember correctly, but it 
has been a while; I preferred assembler anyway (Zilog Z80, 16- and 
32-bit Intel 80x86, Intel 8051).


There are lots of other languages out there though, some of which I've 
done serious work in - like BASIC (Visual Basic for Applications, that 
is), BASIC (good old Siemens mainframe BASIC yet another animal), Unix 
shell scripts, XSLT (kind of an XML query language), and C# - some of 
which I had to learn or toyed around with a bit - like COBOL (yuck!), 
Logo (who hasn't toyed around with /that/? Allegedly you could even do 
other stuff with it than just draw), UnrealScript (gee, first time I saw 
a language natively supporting state machines; and network replication; 
and all that object-oriented, of course), Nice, Tcl/Tk, awk, and maybe 
one or two more - and some of which I had a quick look at, like lua.


> Did I mention POV-Ray SDL in there?

Oh, yeah, now that you mention it... :-)

> Lisp isn't too hard to interpret either. (But arguably too hard for 
> 8-year-olds to program with.) Smalltalk is pretty easy to interpret, and 
> easy on the brain too. Prolog would also not be hard to interpret, but 
> probably not especially useful for home users.

I guess all these languages wouldn't really fit the limited capacities 
of a home computer. Can you, for instance, imagine an object-oriented 
runtime system on something like 32kB RAM and 16kB ROM? Running at 1 
MHz? With automatic garbage collection and all?

Plus, I guess these languages would have lacked syntax for peeks & 
pokes. Can you imagine the home computer boom without peeks & pokes? :-)

Post a reply to this message

Captain Jack schrieb:

> Hmmm... lessee... Coursewriter, Fortran, COBOL, Pascal, Lisp, BASIC 
> (Dartmouth, A-BASIC, GWBASIC, VB et cetera on and on), C, C++, C#, Providex, 

Ah yes, I forgot C/C++ of course...

Post a reply to this message

Invisible schrieb:

> I might also throw in Mathematica, TeX, Tcl, MS-DOS scripting, and the 
> various other languages which aren't "programming languages" such as 
> HTML, CSS, XSLT, AmigaGuide, ARexx, Automake, the lambda calculus...

Well, if XSLT isn't a programming language, then SQL isn't either 
(unless you go for stored procedures, but each manufacturer seems to 
roll their own there).

Post a reply to this message

clipka wrote:
> Invisible schrieb:
> 
>> I might also throw in Mathematica, TeX, Tcl, MS-DOS scripting, and the 
>> various other languages which aren't "programming languages" such as 
>> HTML, CSS, XSLT, AmigaGuide, ARexx, Automake, the lambda calculus...
> 
> Well, if XSLT isn't a programming language, then SQL isn't either 

I could go along with that...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

clipka wrote:

> BASIC: Yes, first language I learned. On a home computer, of course. 
> Locomotive Basic, to be precise. Amstrad CPC 6128.

At one point my dad had an Amstrad machine - I couldn't tell you which 
exact one though...

> PostScript: Yes, been there. Weiredest (and therefore most interesting) 
> language there is out there, if I'm asked (except for /deliberately/ 
> obfuscated languages, which aren't half as interesting due to the 
> frustration potential involved).

It's not *that* weird, just unconventional. (And definitely designed to 
be machine-readable and machine-writable rather than coded by hand!)

> Eiffel, Haskell, Lisp, Prolog: No, never seen (well, seen a /bit/ of 
> Haskell here of course :-))

Eiffel: Object-oriented programming with multiple-inheritance and 
design-by-contract, done right. You know how Pascal is the theoretically 
"perfect" example of a structured language? Eiffel is the same but for 
OOP. (And, like Pascal, it's not very popular and has some gapeing flaws.)

Haskell: Everything [almost] is immutable. Imagine an OO language where 
all your objects lack set-methods. That's Haskell. Now imagine if you 
could have objects which represent functions. (Smalltalk actually does 
this, by the way, with it's [ :foo | ... ] blocks. I think JavaScript 
can do it too.) That's basically Haskell, modulo some weirdness to do 
with lazy evaluation. And friggin' weird syntax, and obscure terminology.

Lisp: Everything is a list [almost]. Prefix syntax, sort of like how 
PostScript is postfix syntax. Other than that (and the "minor detail" 
that you can modify the source code at runtime) it's a plain ordinary 
imperative language. But for some reason, Lispers think it's some 
transcendental wonder-language.

Prolog: You give it facts, and rules for deducing new facts from 
existing facts. It can solve logical equations. (E.g., tell it who's the 
parent of who, and how to trace ancestry, and it can tell you how is 
related to who, and who isn't, and by how many generations, and so on.) 
Has the interesting effect that rules can be applied seemingly 
"backwards" and "sideways" as well as just "forwards" like in normal 
languages.

> Machine code: Yes, I think I did "poke" a few bytes into my Amstrad CPC 
> 6128; 0xCD was CALL and 0xC9 was RET, if I remember correctly, but it 
> has been a while; I preferred assembler anyway (Zilog Z80, 16- and 
> 32-bit Intel 80x86, Intel 8051).

You know you've been using the 6501 too long when you know, off the top 
of your head, that RTS is 96 decimal.

>> Lisp isn't too hard to interpret either. (But arguably too hard for 
>> 8-year-olds to program with.) Smalltalk is pretty easy to interpret, 
>> and easy on the brain too. Prolog would also not be hard to interpret, 
>> but probably not especially useful for home users.
> 
> I guess all these languages wouldn't really fit the limited capacities 
> of a home computer. Can you, for instance, imagine an object-oriented 
> runtime system on something like 32kB RAM and 16kB ROM? Running at 1 
> MHz? With automatic garbage collection and all?

The GC is probably the killer. I rather suspect you could confortably 
fit a Lisp interpretter into a few hundred *bytes*. (But not the 
libraries...)

> Plus, I guess these languages would have lacked syntax for peeks & 
> pokes. Can you imagine the home computer boom without peeks & pokes? :-)

It would be trivial to add this to Smalltalk or Lisp. (In fact, I'm 
fairly sure it's already there.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Even as Borland released TurboPascal 5.5 for DOS [that's the one with 
>> the object-oriented extensions which aren't actually object-oriented], 
> 
>  From what I remember, I'd disagree. (Then again, maybe there was a 
> difference between TP 5.5 and TP 6.0; I only really used the latter; and 
> TP 3.something earlier.)

I never saw TP 6.0.

In TP 5.5, they added an "object" keyword, which allowed you to define 
functions and procedures inside a normal record definition. Other than 
this syntactic change, there is no difference in the language. Most 
especially, the method that gets called depends on the declared type of 
a variable, *not* the type of the object in it! (In other words, static 
binding, not dynamic binding.) It also lacks support for abstract 
classes. But does have inheritance.

So it gives the superficial appearance of OOP, while preventing you 
actually programming in an OO style.

> Maybe simply /because/ Prolog was such a high-level language, and didn't 
> fit all applications? Like, for instance, writing a Unix kernel (which 
> is what C was initially invented for)?

It still mystifies me that C provides no way to say (for example) "this 
thing should be a signed integer with at least 16 bits in it". For a 
language designed for portability, you'd think this would be fairly 
basic, but no...

Also, if they had computers powerful enough to run *Prolog*, why does 
the C preprocessor exist?!

>> - PostScript was invented 10 years before laser printers existed. (It 
>> was apparently designed specifically with laser printers in mind, as I 
>> had always believed.)
> 
> You're wrong here: The first laser printer dates back to 1969, while 
> even the roots of PostScript date no further back than 1976. 
> Furthermore, the language was initially targeted at the offset printing 
> industry to drive Computer-to-Film imagesetters, and was only later 
> adapted to laser printers.

Wikipedia suggests that it was developed specifically for laser 
printing. (I may be wrong on the date that laser printers were 
*invented*, but they did not become common until very, very much later. 
Not unlike C++, apparently...)

>  - Perl predates the Internet by half a decade. (WTF?) I can only imagine
>> it began life as a Unixy text-munging system in the style of awk, sed, 
>> etc.
> 
> You surely mean it predates the /World Wide Web/ by half a decade.

Before the WWW, nobody outside the millitary knew the Internet existed.

In fact, for many years after, also...

> According to Wikipedia, it was indeed developed (at NASA, btw) as a Unix 
> tool for report processing.

Figures.

>> - JavaScript predates Java. (WTF?!)
> 
> ... under the titles "Mocha" and later "LiveScript", yes. The name 
> JavaScript wasn't coined until December 1995 - when Java was already 
> released to the public (not in 1996, as your chart implies) - probably 
> in an attempt to benefit from the Java hype of those days.

What do you mean "probably"? ;-) The language is utterly unrelated to 
Java in any way...

>> - Ruby, PHP and JavaScript were all around at the same time as Delphi. 
>> This is puzzling because when Delphi was new, the Internet didn't 
>> really "exist" yet.
> 
> Again, I guess you mean WWW, not internet.

I mean the Internet becoming known by the general public. ("The 
Internet" can be traced back to a secret classified military project 
which was probably around for *decades* before this, knowing the US 
millitary...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible escreveu:
> - Pascal predates C, and yet C fails to incorporate almost any of the 
> good ideas from Pascal.

It was just a small and obscure academic language back then.  C was 
basically portable assembly for the original Unix.

> - Smalltalk was doing OOP before home computers were even *invented*, 
> and yet it wasn't until 20 _years_ later that commercial products like 
> TP 5.5 and Delphi started to take the idea mainstream.

Smalltalk is actually from about 1977 or something, isn't it?

> - SQL existed 15 years before high-capacity storage devices appeared. 
> (This is worse than it appears. You wouldn't even realise that a 
> language like SQL was *necessary* unless databases themselves had 
> already existed for some considerable length of time. And after that 
> there would obviously be a rash of incompatible proprietry languages 
> until people decided to design a standardised one.)

My uncle said that back then, they created ad-hoc, file-based database 
management systems by themselves.  People were much bolder back then. :)

> - PostScript was invented 10 years before laser printers existed. (It 
> was apparently designed specifically with laser printers in mind, as I 
> had always believed.)

Is it so?

> - Haskell was invented back when people were still using green screens 
> and MS-DOS. It brings a slight chill to my spine to know that way back 
> when I was still coding with AMOS Professional, minds immeasurably 
> superior to ours had already constructed the most powerful programming 
> language known.

Are you talking about Miranda?  Yes, it was the spiritual basis for Haskell.

> - Perl predates the Internet by half a decade. (WTF?) I can only imagine 
> it began life as a Unixy text-munging system in the style of awk, sed, etc.

Yes.  Scripting languages were not devised for the internet.

> - JavaScript predates Java. (WTF?!)

Perhaps would be called oakscript? ;)

> - Visual Basic is significantly older than Delphi.

No, just a few years.

> - Ruby, PHP and JavaScript were all around at the same time as Delphi. 
> This is puzzling because when Delphi was new, the Internet didn't really 
> "exist" yet.

I was browsing the web (at University) in 1994, about same time those 
were starting.

> - C# (by which I denote the entire zoo of .NET languages) is the only 
> thing in the chart to have been invented this millennium.

It's an amalgama of Java and Delphi Pascal.  and some hints of Python as 
of late...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

clipka wrote:
> Invisible schrieb:
> 
>> I might also throw in Mathematica, TeX, Tcl, MS-DOS scripting, and the
>> various other languages which aren't "programming languages" such as
>> HTML, CSS, XSLT, AmigaGuide, ARexx, Automake, the lambda calculus...
> 
> Well, if XSLT isn't a programming language, then SQL isn't either
> (unless you go for stored procedures, but each manufacturer seems to
> roll their own there).

XSLT is definitely turing-complete.

http://www.unidex.com/turing/utm.htm

Post a reply to this message

Nicolas Alvarez wrote:

> XSLT is definitely turing-complete.
> 
> http://www.unidex.com/turing/utm.htm

So is PostScript, but nobody uses that for anything except page 
descriptions.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Aydan wrote:
> "scott" <sco### [at] scottcom> wrote:
>>> - C and Prolog appeared at the same time. This doesn't make a lot of
>>> sense. C is a crude, simplistic low-level bit-twiddling langauge, while
>>> Prolog is a powerful high-level logic manipulation language. If there
>>> were computers capable of running Prolog, why did C need to exist?
>> Speed?
> 
> How'd you imagine writing libraries for said high level logic manipulation
> language to interface hardware? Assembler? I'd think C is your best bet there
> since it's low level enough to do the bit twiddling to control hardware and high
> level enough to not be a PITA.
> 
> Just my 2 cents
> 

Depends on the processor, and your memory limits. Even C didn't do you 
any good if you had to cram stuff in a tiny chunk of memory, and still 
have it work. Nearly everything on Apple IIs was done in assembly.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> C was basically portable assembly for the original Unix.

...and yet, it doesn't make it especially easy to do low-level stuff.

>> - Smalltalk was doing OOP before home computers were even *invented*, 
>> and yet it wasn't until 20 _years_ later that commercial products like 
>> TP 5.5 and Delphi started to take the idea mainstream.
> 
> Smalltalk is actually from about 1977 or something, isn't it?

Yes. Very ancient, as the chart shows.

>> - SQL existed 15 years before high-capacity storage devices appeared. 
> 
> My uncle said that back then, they created ad-hoc, file-based database 
> management systems by themselves.  People were much bolder back then. :)

But what did dthey *store* these files on? Punch cards?!

>> - Haskell was invented back when people were still using green screens 
>> and MS-DOS. It brings a slight chill to my spine to know that way back 
>> when I was still coding with AMOS Professional, minds immeasurably 
>> superior to ours had already constructed the most powerful programming 
>> language known.
> 
> Are you talking about Miranda?  Yes, it was the spiritual basis for 
> Haskell.

Haskell 1.0 is 1990. I guess green-screens is stretching it a litle, but 
lots of people were still using MS-DOS regularly long after that date. 
(And writing stuff in QBASIC and similar.)

Miranda, of course, is even older. (See the chart.)

Post a reply to this message

Orchid XP v8 schrieb:
> Nicolas Alvarez wrote:
> 
>> XSLT is definitely turing-complete.
>>
>> http://www.unidex.com/turing/utm.htm
> 
> So is PostScript, but nobody uses that for anything except page 
> descriptions.

Well, I once wrote a PS program to compute fractals...

In any case, PostScript /is/ a full-fledged programming language, and 
was always intended to be. You /could/ do other stuff with it if you 
really wanted to, and it wouldn't be /too/ difficult once you got into 
it (except for obvious limitations regarding the user interface).

XSLT on the other hand was originally designed as a /query/ language, 
and it is only through extensions to the basic concept that it 
(accidently, not by design) happens to be Turing complete. You really 
have to abuse the language to write generic programs with it, and in- & 
output will be your least problems.

Post a reply to this message

>>> XSLT is definitely turing-complete.
>>
>> So is PostScript, but nobody uses that for anything except page 
>> descriptions.
> 
> Well, I once wrote a PS program to compute fractals...
> 
> In any case, PostScript /is/ a full-fledged programming language, and 
> was always intended to be.

According to Wikipedia, it was always designed to be a page-description 
language.

(I've read that there are in fact GUI systems powered by PS...)

> XSLT on the other hand was originally designed as a /query/ language, 
> and it is only through extensions to the basic concept that it 
> (accidently, not by design) happens to be Turing complete. You really 
> have to abuse the language to write generic programs with it, and in- & 
> output will be your least problems.

SQL was originally designed as a query language too. (Well, technically, 
a data definition and manipulation language, which isn't precisely the 
same thing.) Various people have made it Turing-complete in incompatible 
ways though...

Post a reply to this message

Orchid XP v8 schrieb:

>>> - PostScript was invented 10 years before laser printers existed. (It 
>>> was apparently designed specifically with laser printers in mind, as 
>>> I had always believed.)
>>
>> You're wrong here: The first laser printer dates back to 1969, while 
>> even the roots of PostScript date no further back than 1976. 
>> Furthermore, the language was initially targeted at the offset 
>> printing industry to drive Computer-to-Film imagesetters, and was only 
>> later adapted to laser printers.
> 
> Wikipedia suggests that it was developed specifically for laser 
> printing. (I may be wrong on the date that laser printers were 
> *invented*, but they did not become common until very, very much later. 
> Not unlike C++, apparently...)

Well, /my/ Wikipedia claims otherwise - see 
http://en.wikipedia.org/wiki/PostScript#History:

"Warnock left with Chuck Geschke and founded Adobe Systems in December 
1982. They created a simpler language, similar to InterPress, called 
PostScript, which went on the market in 1984. At about this time they 
were visited by Steve Jobs, who urged them to /adapt PostScript to be 
used as the language for driving laser printers/."

(emphasis added)

Laser printers were originally invented not for quality, but for sheer 
speed (I guess they were the first printers to feature only rotating 
parts, with no linear movement whatsoever, so no acceleration was needed 
when "geared up" for printing), and were found at data centers for quite 
a while.

And, as mentioned, there were other areas of use for PostScript before that.


>>  - Perl predates the Internet by half a decade. (WTF?) I can only imagine
>>> it began life as a Unixy text-munging system in the style of awk, 
>>> sed, etc.
>>
>> You surely mean it predates the /World Wide Web/ by half a decade.
> 
> Before the WWW, nobody outside the millitary knew the Internet existed.

Many university students did, and certainly virtually all informatics 
students. The Internet had long grown beyond its roots in the ARPANET 
into the scientific world, as a tool for file and e-mail transfer as 
well as remote access to other universities' data centers. First 
commercial use of Internet dates back to 1988. Usenet became part of the 
Internet before the WWW era, too. Porn was exchanged via the internet on 
a more-or-less regular basis years before the first HTTP server was set up.


>>> - JavaScript predates Java. (WTF?!)
>>
>> ... under the titles "Mocha" and later "LiveScript", yes. The name 
>> JavaScript wasn't coined until December 1995 - when Java was already 
>> released to the public (not in 1996, as your chart implies) - probably 
>> in an attempt to benefit from the Java hype of those days.
> 
> What do you mean "probably"? ;-) The language is utterly unrelated to 
> Java in any way...

Well, "probably" in the sense of "sounds pretty likely, even though 
nobody can give proof".


> I mean the Internet becoming known by the general public. ("The 
> Internet" can be traced back to a secret classified military project 
> which was probably around for *decades* before this, knowing the US 
> millitary...)

That would have been the ARPANET, with the first data link being 
established in 1969.

However, that's just the root of the /technology/. The first nucleus of 
the actual network that later came to be known as the Internet - the 
NSFNET - was established in 1985 (with a 56 kBit/s backbone - imagine 
that!), linking 6 university computing centers.

Post a reply to this message

Invisible schrieb:

>> In any case, PostScript /is/ a full-fledged programming language, and 
>> was always intended to be.
> 
> According to Wikipedia, it was always designed to be a page-description 
> language.

I'd rather say, a "page-description programming language".

The whole structure of the language indicates that Turing-completeness 
wasn't just something added later - it quite clearly seems to have been 
in there right from the start.

/Conceptually/ it has always been a full-fledged programming language, 
even though the initial /use case/ was of course page description.

Post a reply to this message

Invisible schrieb:
>> My uncle said that back then, they created ad-hoc, file-based database 
>> management systems by themselves.  People were much bolder back then. :)
> 
> But what did dthey *store* these files on? Punch cards?!

Exchangable hard disk drives (around since 1956)? Magnetic tape (used in 
the computing world since the 1950's, after having already seen decades 
of service for analog signal recording)?

You're underestimating the historic arsenal of data storage - and 
possibly overestimating the volume of data processed back then.

AFAIK punchcards and punch tape were used primarily for data input and 
output, not data storage (though of course they could double-feature as 
a backup of the input or output data). Data storage was instead 
typically done on magnetic tapes.

Post a reply to this message

clipka wrote:
> Many university students did, and certainly virtually all informatics 
> students. 

ftp://ftp.rfc-editor.org/in-notes/rfc1.txt

By 1969, there were already open standards processes talking about how to 
improve the internet. Both universities, telephone companies, and computer 
manufacturers knew about it.

Now, you needed a special dedicated computer just to keep up with a 
56kilobit connection, but that doesn't mean anybody didn't know about it.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Invisible escreveu:
>> C was basically portable assembly for the original Unix.
> 
> ...and yet, it doesn't make it especially easy to do low-level stuff.

It doesn't?

>> Smalltalk is actually from about 1977 or something, isn't it?
> 
> Yes. Very ancient, as the chart shows.

Please don't call me ancient. :P

>>> - SQL existed 15 years before high-capacity storage devices appeared. 
>>
>> My uncle said that back then, they created ad-hoc, file-based database 
>> management systems by themselves.  People were much bolder back then. :)
> 
> But what did dthey *store* these files on? Punch cards?!

Magnetic tapes, in the 1970's.  Magnetic tapes, in the form of cassette 
tapes were also available for home use, as MSX and perhaps C64 owners 
may remember.

>> Are you talking about Miranda?  Yes, it was the spiritual basis for 
>> Haskell.
> 
> Haskell 1.0 is 1990. I guess green-screens is stretching it a litle, but 
> lots of people were still using MS-DOS regularly long after that date. 
> (And writing stuff in QBASIC and similar.)
> 
> Miranda, of course, is even older. (See the chart.)

Your concept of old reminds me of childhood.  I was a youth in 1990 so 
it doesn't seem that old to me. :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

>>> C was basically portable assembly for the original Unix.
>>
>> ...and yet, it doesn't make it especially easy to do low-level stuff.
> 
> It doesn't?

I mean, sure, it has support for twiddling bits and stuff. But you'd 
think if you were doing low-level work, you would have a way to 
explicitly say how many bits you want to use. Yet C provides no such 
facility. Every CPU I know of provides an instruction to check for 
sign-overflow, but C ignores overflows by default, and provides no way 
to check for them if you want to. (Besides manually testing the operands 
before doing the operation.)

> Please don't call me ancient. :P

Ancient. :-P

>>>> - SQL existed 15 years before high-capacity storage devices appeared. 
>>>
>>> My uncle said that back then, they created ad-hoc, file-based 
>>> database management systems by themselves.  People were much bolder 
>>> back then. :)
>>
>> But what did dthey *store* these files on? Punch cards?!
> 
> Magnetic tapes, in the 1970's.  Magnetic tapes, in the form of cassette 
> tapes were also available for home use, as MSX and perhaps C64 owners 
> may remember.

The concept of performing a multi-table join where the tables are all 
stored on magnetic tape scares me. o_O

My God, it could take months...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message 
news:4ae0be3d$1@news.povray.org...
> I mean, sure, it has support for twiddling bits and stuff. But you'd think 
> if you were doing low-level work, you would have a way to explicitly say 
> how many bits you want to use. Yet C provides no such facility.

Wouldn't bit fields do what you're describing? As in:

struct PackBits {
    unsigned int field1:2;
    unsigned int field2:1;
    unsigned int field3:4;
    unsigned int field4:1;
}

I can't recall if that's in K&R, but I'm sure it's at least ANSI C.

Post a reply to this message

Captain Jack wrote:
> Wouldn't bit fields do what you're describing?

Only if they're all aligned to byte boundaries, and you know what order the 
fields are in. I.e., yes, but in no way portably. There's no way to portably 
(for example) lay a C structure for an IP datagram header onto the header 
and just use it.

Contrast with (say) Ada, where you can say

type FatTable = packed array[0..1000] of integer 0..4095;

and automatically get instructions that pack and unpack 12-bit entries in 
your array of memory.  (Modulo syntax, mind. :-)

Ada also supports context switching, interrupt handling, defined ways of 
pointing to particular areas of memory (i.e., so you can tell the linker to 
put the machine registers at a particular place), arbitrary ranges for 
integers, for floats, and for decimal numbers. (i.e., you tell Ada what 
range/precision you need, and it picks the best representation, instead of 
trying to find the best representation from amongst the things the compiler 
offers.) It supports prioritized interrupt handling, including blocking 
lower-level interrupts while a higher-level one is running, handling 
priority inversion, and scheduling threads based on the same priorities as 
interrupts. It also supports volatile variables (which might be changed by 
hardware) and atomic operations (where you can guarantee that if you're 
writing a 2-byte integer, you won't get an instruction that stores the value 
using two 1-byte store instructions, which is also important for hardware), 
and "protected" operations that take advantage of hardware instructions for 
blocking multiple threads (i.e., which take advantage of hardware locks).

I don't think C handles *any* of that. About the closest it comes is 
volatile (sort of) and undefined behavior that *often* does what you'd 
expect when using addresses, unless your memory model is too far different 
from C's.


-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4ae0c668$1@news.povray.org...
> Captain Jack wrote:
>> Wouldn't bit fields do what you're describing?
>
> Only if they're all aligned to byte boundaries, and you know what order 
> the fields are in. I.e., yes, but in no way portably. There's no way to 
> portably (for example) lay a C structure for an IP datagram header onto 
> the header and just use it.

That's true... I know the specification calls for packing the bytes as 
tightly as possible, but there's no standard spec for alignment.

I used to use Borland's Turbo C (v2, IIRC) way back when on DOS machines. I 
remember that it had custom pre-processor directives for controlling byte 
and word alignment, but I'm sure those weren't in any way standard.

I also used to make use of its "asm" keyword which would let me insert x86 
assembler code into the middle of my C code, and I'd often use that to 
squeeze some extra bits out of my memory usage. Contrast that with my 
current job, where we use .NET, and I don't even keep track of what I've 
allocated and deallocated, or how much I've used. I seem to have grown fat 
and lazy on the backs of the developers at Redmond. 8D

> I don't think C handles *any* of that. About the closest it comes is 
> volatile (sort of) and undefined behavior that *often* does what you'd 
> expect when using addresses, unless your memory model is too far different 
> from C's.

But that was what's so great about pure C... nothing lets you shoot yourself 
in the foot with confidence the way C does. <g>

Post a reply to this message

Captain Jack wrote:
> That's true... I know the specification calls for packing the bytes as 
> tightly as possible, but there's no standard spec for alignment.

I also believe (but I am too lazy to look it up right now) that it's 
impossible to portably know whether

struct PackBits alpha = {0, 1, 0, 0};
struct PackBits beta = {0, 0, 0, 1};

alpha or beta will yield a larger number when cast to an int. I.e., I don't 
think the standard even says whether the fields are allocated MSB or LSB first.

> I also used to make use of its "asm" keyword which would let me insert x86 
> assembler code into the middle of my C code, and I'd often use that to 
> squeeze some extra bits out of my memory usage.

Yep. When you really need to talk to the machine directly, C falls down. 
That was the point of asking "why is C better?"  It was only better for 
portability compared to the other languages of the time.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New schrieb:

> I also believe (but I am too lazy to look it up right now) that it's 
> impossible to portably know whether
> 
> struct PackBits alpha = {0, 1, 0, 0};
> struct PackBits beta = {0, 0, 0, 1};
> 
> alpha or beta will yield a larger number when cast to an int. I.e., I 
> don't think the standard even says whether the fields are allocated MSB 
> or LSB first.

That's absolutely right: While standard C by now /does/ address the 
problem of detecting the range of values a certain integer type can 
hold, how many bits a "char" has, and even what base, mantissa size and 
exponent size a floating point format uses - still nobody has introduced 
anything that would make it possible to detect endianness at compile time.

Multi-character constants may be a way to detect this with some 
reliability, by testing e.g.

   #if '\xAB\xCD\xEF\xGH' == 0xABCDEFGH
     #define BIG_ENDIAN
   #elif '\xAB\xCD\xEF\xGH' == 0xGHEFCDAB
     #define LITTLE_ENDIAN
   #else
     #define UNKNOWN_ENDIAN
   #end

but the C99 standard does not explicitly specify any byte ordering rules 
of multi-character constants either.

The best you can do is include a runtime self-test routine in the code 
to actively check whether compile-time endianness assumptions were right.

Post a reply to this message

Orchid XP v8 wrote:

> 
> The concept of performing a multi-table join where the tables are all 
> stored on magnetic tape scares me. o_O
> 
> My God, it could take months...
> 

Not at all.  Simply sort the two (or more) files in sequence by the join 
key (one or more fields).  Then it is a matched scan or 'merge join' 
through both.  Variants for Inner, Left, Right and Full Outer joins.

As to sorting large tape files - You already have my reminiscence of 
'Real Sort I' on your blog.  Actually that whole thing was equivalent to 
a join of the account table to the transaction table when both were 
stored as sequential files on multiple volumes of tape.  Multiple months 
of Tran had to be merged and sorted into account sequence.

This was before disk databases and SQL were practical considerations for 
this application.

Back then (circa 1984) the bank that I worked for might have had about 
40 disk drives.  Each the size of a washing machine.  They were IBM 3350 
DASD providing about 300Mb capacity each - so long as you chose an 
efficient block size for the record length.

So that was about 12Gb of disk in total - for a largish bank.  In my 
pocket I now carry a 16Gb memory stick to backup files and sync across 
machines.

Tapes back then held something like 100Mb per reel (IBM 3420 1200 foot 
?) reel.  But there could be thousands of tapes in the library so that 
was hundreds of Gb.

Post a reply to this message

>> The concept of performing a multi-table join where the tables are all 
>> stored on magnetic tape scares me. o_O
>>
>> My God, it could take months...
> 
> Not at all.  Simply sort the two (or more) files in sequence by the join 
> key (one or more fields).  Then it is a matched scan or 'merge join' 
> through both.  Variants for Inner, Left, Right and Full Outer joins.
> 
> As to sorting large tape files - You already have my reminiscence of 
> 'Real Sort I' on your blog.  Actually that whole thing was equivalent to 
> a join of the account table to the transaction table when both were 
> stored as sequential files on multiple volumes of tape.  Multiple months 
> of Tran had to be merged and sorted into account sequence.
> 
> This was before disk databases and SQL were practical considerations for 
> this application.

Indeed - it sounds like back then, doing this kind of stuff was pushing 
hard against the limits of technical feasibility. Like every individual 
operation had to be planned and hand-tuned and assisted by an army of 
technitions. Seems like having an SQL language would be a bit redundant.

...and yet, SQL is apparently that old. Go figure!

> So that was about 12Gb of disk in total - for a largish bank.  In my 
> pocket I now carry a 16Gb memory stick to backup files and sync across 
> machines.

Damn, they make memory sticks that large now??

> Tapes back then held something like 100Mb per reel (IBM 3420 1200 foot 
> ?) reel.  But there could be thousands of tapes in the library so that 
> was hundreds of Gb.

Amusingly, today I work with LTO3 tapes, which hold 400GB each. So... 
only about a thousand times more. (Not, say, several million.) Then 
again, I think those tapes might be slightly bigger physically too!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 10/21/2009 8:30 AM, Invisible wrote:
> - SQL existed 15 years before high-capacity storage devices appeared.
> (This is worse than it appears. You wouldn't even realise that a
> language like SQL was *necessary* unless databases themselves had
> already existed for some considerable length of time. And after that
> there would obviously be a rash of incompatible proprietry languages
> until people decided to design a standardised one.)

Just started learning TSQL, and I have to say that I _HATE_ it. I would 
much rather use a typical object oriented language.

I understand that TSQL is just a wrapper that hides the highly optimized 
operations the server _actually_ performs. But the "spoken sentence 
grammar" type of syntax TSQL uses is highly variable and inconsistent, 
and to me very confusing and frustrating. Bleh.

Mike

Post a reply to this message

SharkD wrote:

> Just started learning TSQL, and I have to say that I _HATE_ it. I would 
> much rather use a typical object oriented language.
> 
> I understand that TSQL is just a wrapper that hides the highly optimized 
> operations the server _actually_ performs. But the "spoken sentence 
> grammar" type of syntax TSQL uses is highly variable and inconsistent, 
> and to me very confusing and frustrating. Bleh.

I've never seen TSQL, but if it's anything like SQL...

...well, look up some COBOL example code sometime. You'll see what I 
mean. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> I've never seen TSQL, but if it's anything like SQL...

  How about making some googling? TSQL is SQL + some extensions.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> The best you can do is include a runtime self-test routine in the code 
> to actively check whether compile-time endianness assumptions were right.

At which point the best approach is probably just to pack and unpack the 
bits yourself. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

On 10/25/2009 7:51 AM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> I've never seen TSQL, but if it's anything like SQL...
>
>    How about making some googling? TSQL is SQL + some extensions.

"Doing" not "making". Please read:

http://grammar.ccc.commnet.edu/grammar/index2.htm

starting with "A, An, The (articles)", and ending with "Zero Articles". 
Make sure not to skip the middle bits, as you'll miss some important 
lessons!

Mike

Post a reply to this message

There's one thing I've always been confused about. Are all compiled 
languages equal in terms of performance? I've frequently read things 
like C++ being a superior performer to Java, but Java of course is a 
runtime language so it's not a fair comparison.

Mike

Post a reply to this message

SharkD wrote:
> There's one thing I've always been confused about. Are all compiled 
> languages equal in terms of performance?

Erm, no.

It depends how you write the program, it depends how good the compiler 
is (there may even be more than one of them), it depends on what the 
program is supposed to be doing in the first place, etc.

(E.g., if you're writing a program that's dominated by network latency, 
it makes little difference to performance which language you use. It 
might affect reliability, security or development cost, but not 
performance.)

In other words, "it depends". Certainly different languages and 
different language tools seem to have their strengths and weaknesses. 
Actually teasing out objective "facts" about such things is less easy.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> On 10/25/2009 7:51 AM, Warp wrote:
> > Orchid XP v8<voi### [at] devnull>  wrote:
> >> I've never seen TSQL, but if it's anything like SQL...
> >
> >    How about making some googling? TSQL is SQL + some extensions.

> "Doing" not "making".

  You "make love", you don't "do love". ;)

-- 
                                                          - Warp

Post a reply to this message

SharkD schrieb:
> There's one thing I've always been confused about. Are all compiled 
> languages equal in terms of performance?

No.

However, it often depends a lot on the compiler and libraries, rather 
than the language itself.

Performance may also vary with the task at hand; a language aimed at 
scientific computations, for instance, may include highly optimized 
libraries for matrix math, but suck at string handling.

Post a reply to this message

clipka wrote:

> Performance may also vary with the task at hand; a language aimed at 
> scientific computations, for instance, may include highly optimized 
> libraries for matrix math, but suck at string handling.

Conversely, I'm told Perl's regex handling is supposed to be quite fast...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 10/25/2009 1:48 PM, clipka wrote:
> However, it often depends a lot on the compiler and libraries, rather
> than the language itself.

Er, yeah! I forgot about POV's 10% performance drop as a result of 
switching from the Visual Studio compiler.

Mike

Post a reply to this message

Orchid XP v8 schrieb:
> clipka wrote:
> 
>> Performance may also vary with the task at hand; a language aimed at 
>> scientific computations, for instance, may include highly optimized 
>> libraries for matrix math, but suck at string handling.
> 
> Conversely, I'm told Perl's regex handling is supposed to be quite fast...

For instance, yes. And I don't expect it to have highly-optimized matrix 
math libraries.

Post a reply to this message

SharkD schrieb:
> On 10/25/2009 1:48 PM, clipka wrote:
>> However, it often depends a lot on the compiler and libraries, rather
>> than the language itself.
> 
> Er, yeah! I forgot about POV's 10% performance drop as a result of 
> switching from the Visual Studio compiler.

A similar performance difference can be observed with POV-Ray on AMD64 
Linux between binaries compiled with the Gnu and Intel compiler suites 
(at least "out of the box"), with Intel in the winning seat.

Post a reply to this message