Walter Bright wrote:
> Don Clugston wrote:
> 
>> Just Pascal, and I never liked it.
>> <rant> It seemed to go out of its way to make pointers difficult to understand. Plus, the first line of code was the "program" statement, which didn't actually do anything, and the last was an almost invisible fullstop. This was supposed to be a good teaching language? </rant>
> 
> 
> I liked Pascal until I tried to write useful programs in it (this was with Pascal implemented according to Wirth's book). It seems I spent all my development time fighting the compiler. The language semantics locked everything up so tight there was no way to get things done.
> 
> Then I read K+R, and it was like the light coming on. The language let me do what I want (casting is the magic ingredient). Despite using early very buggy C compilers, I spent my time working on my algorithms rather than fighting the compiler.
> 
> Pascal vendors noticed the exodus to C, and added a whole boatload of C-like extensions to Pascal to make it a usable. By then, though, it was too late to interest me; I never looked at Pascal again. (The other problem with all those extensions is every vendor did them differently, making Pascal probably the most non-portable language in existence because you *had* to use the extensions.)
> 

Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C


> Pascal basically missed its market window.

Pascal became the de-facto language of choice within teaching establishments; much of the western CS undergraduate courses became oriented toward Pascal. The UCSD p-system became the most advanced software teaching tool in existance. I'd say Pascal hit its "market window" with extreme accuracy. As would most others who were around at the time.

If you want to talk about languages intended for systems-programming, perhaps you should compare to Modula-2 and Modula-3 instead. Now there's a great language that missed its "market window" and/or opportunity.

Interesting to note that D is basically a Modula-3 clone, using C-like syntax instead and adding some more op-overloading. Perhaps D could adopt the more advanced 'import' capabilities from Modula-3 also? Back in the dark ages, they understood such things rather well ... the design in Modula-3 allows one to extend original, imported modules without fear of breaking the code that imports them. What a concept <g>

In fact, here's an NG post from almost 5 years ago: http://www.digitalmars.com/d/archives/94.html

kris wrote:
> Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C

Intended or not, the pascal compiler vendors of the time certainly positioned it as a general purpose programming language, and often it was the only choice on a platform other than Fortran, Basic, or assembler.


> Interesting to note that D is basically a Modula-3 clone, using C-like syntax instead and adding some more op-overloading. Perhaps D could adopt the more advanced 'import' capabilities from Modula-3 also? Back in the dark ages, they understood such things rather well ... the design in Modula-3 allows one to extend original, imported modules without fear of breaking the code that imports them. What a concept <g>
> 
> In fact, here's an NG post from almost 5 years ago: http://www.digitalmars.com/d/archives/94.html

And I still don't know anything about M3 <g>. But being able to extend imports without breaking users can easily be done with some variation on the PIMPL technique or interfaces.

kris wrote:
> Walter Bright wrote:
>> Don Clugston wrote:
>>
>>> Just Pascal, and I never liked it.
>>> <rant> It seemed to go out of its way to make pointers difficult to understand. Plus, the first line of code was the "program" statement, which didn't actually do anything, and the last was an almost invisible fullstop. This was supposed to be a good teaching language? </rant>
>>
>>
>> I liked Pascal until I tried to write useful programs in it (this was with Pascal implemented according to Wirth's book). It seems I spent all my development time fighting the compiler. The language semantics locked everything up so tight there was no way to get things done.
>>
>> Then I read K+R, and it was like the light coming on. The language let me do what I want (casting is the magic ingredient). Despite using early very buggy C compilers, I spent my time working on my algorithms rather than fighting the compiler.
>>
>> Pascal vendors noticed the exodus to C, and added a whole boatload of C-like extensions to Pascal to make it a usable. By then, though, it was too late to interest me; I never looked at Pascal again. (The other problem with all those extensions is every vendor did them differently, making Pascal probably the most non-portable language in existence because you *had* to use the extensions.)
>>
> 
> Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C

Yup.  And for that I think it was well-designed.  The syntax is clear and free of arcane symbology, and irritating enough to use for real work that students are well inclined to move on when they learn a more professional language ;-)  The pointer syntax in Pascal drives me absolutely insane.

> If you want to talk about languages intended for systems-programming, perhaps you should compare to Modula-2 and Modula-3 instead. Now there's a great language that missed its "market window" and/or opportunity.
> 
> Interesting to note that D is basically a Modula-3 clone, using C-like syntax instead and adding some more op-overloading. Perhaps D could adopt the more advanced 'import' capabilities from Modula-3 also? Back in the dark ages, they understood such things rather well ... the design in Modula-3 allows one to extend original, imported modules without fear of breaking the code that imports them. What a concept <g>

Not to derail the topic, but I'm beginning to feel that the current symbol lookup mechanism in conjunction with visibility modifiers does a terrible job at separating interface from implementation.  As D is a module-based language, I firmly believe that I should not want to adopt an C/C++ style include model simply to make my private global symbols actually private.  I'd be interesting to see how Modula handled the minutiae of importing and symbol lookup.


Sean

Walter Bright wrote:
> 
> And I still don't know anything about M3 <g>. But being able to extend imports without breaking users can easily be done with some variation on the PIMPL technique or interfaces.

But PIMPL only works if combined with header files, and it shouldn't be necessary to resort to this just to avoid symbol collisions with implementation-level stuff.  I do think it's a useful tool when complete implementation hiding is necessary for business reasons, but not as a general tool to work around what feels like a language issue.


Sean

Walter Bright wrote:

> And I still don't know anything about M3 <g>. But being able to extend imports without breaking users can easily be done with some variation on the PIMPL technique or interfaces.

I think you may have missed the point there? It's not about interfaces:

D imports an entire module, into the current namespace (or some variation upon that). This means that any additions to the original module have to be aware of the namespace usage of *any* module that imports the original. Otherwise, a namespace collision will occur and the combination will fail to compile. M3 import explicitly from each module instead ~ you can't have such a collision. The value of that is just as solid today as it was in 1989.

One might argue that with D, one should create new modules instead of extending existing ones? That's a fair point until you consider that the module namespace is limited to one file, and the 'friend' aspect is limited to one module (private attributes being visible within the one module). Thus, D suffers this problem in a notable manner.

I forget whether M3 supports importing into a distinct namespace or not --- the "import x.y.z. as foo;" syntax -- but that can alleviate related problems, and would help resolve the current D namespace conflicts that are quite prevalant?

Sean Kelly wrote:

> kris wrote:
>> Walter Bright wrote:
>>> Don Clugston wrote:
>>>
>>>> Just Pascal, and I never liked it.
>>>> <rant> It seemed to go out of its way to make pointers difficult to
>>>> understand. Plus, the first line of code was the "program" statement,
>>>> which didn't actually do anything, and the last was an almost
>>>> invisible fullstop. This was supposed to be a good teaching language?
>>>> </rant>
>>>
>>>
>>> I liked Pascal until I tried to write useful programs in it (this was with Pascal implemented according to Wirth's book). It seems I spent all my development time fighting the compiler. The language semantics locked everything up so tight there was no way to get things done.
>>>
>>> Then I read K+R, and it was like the light coming on. The language let me do what I want (casting is the magic ingredient). Despite using early very buggy C compilers, I spent my time working on my algorithms rather than fighting the compiler.
>>>
>>> Pascal vendors noticed the exodus to C, and added a whole boatload of C-like extensions to Pascal to make it a usable. By then, though, it was too late to interest me; I never looked at Pascal again. (The other problem with all those extensions is every vendor did them differently, making Pascal probably the most non-portable language in existence because you *had* to use the extensions.)
>>>
>> 
>> Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C
> 
> Yup.  And for that I think it was well-designed.  The syntax is clear and free of arcane symbology, and irritating enough to use for real work that students are well inclined to move on when they learn a more professional language ;-)  The pointer syntax in Pascal drives me absolutely insane.
> 
>> If you want to talk about languages intended for systems-programming, perhaps you should compare to Modula-2 and Modula-3 instead. Now there's a great language that missed its "market window" and/or opportunity.
>> 
>> Interesting to note that D is basically a Modula-3 clone, using C-like syntax instead and adding some more op-overloading. Perhaps D could adopt the more advanced 'import' capabilities from Modula-3 also? Back in the dark ages, they understood such things rather well ... the design in Modula-3 allows one to extend original, imported modules without fear of breaking the code that imports them. What a concept <g>
> 
> Not to derail the topic, but I'm beginning to feel that the current symbol lookup mechanism in conjunction with visibility modifiers does a terrible job at separating interface from implementation.  As D is a module-based language, I firmly believe that I should not want to adopt an C/C++ style include model simply to make my private global symbols actually private.  I'd be interesting to see how Modula handled the minutiae of importing and symbol lookup.
> 
> 
> Sean

Well, since a whole lot is broken in this regard already (possibly not so much with modules as with objects though), I think a whole lot should be rethought and preferably in conjunction with other related features such that the functionality is complete, functional, easy and orthogonal (no less :) ).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Sean Kelly skrev:
> kris wrote:
<snip>
>> Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C
> 
> 
> Yup.  And for that I think it was well-designed.  The syntax is clear and free of arcane symbology, and irritating enough to use for real work that students are well inclined to move on when they learn a more professional language ;-)  The pointer syntax in Pascal drives me absolutely insane.
> 
Am I the only one in the world that thinks the pointer syntax in Pascal beats the C and D syntax every time?

I mean how hard can it be:
^foo  == a pointer type, pointing to a foo. foo* works, but * also mul.
foo^  == Whatever the pointer foo points to. *foo works, same argument.
@bar  == The pointer of bar. &bar works to, but why reuse & again?

Pascal pointer logic also reads so well from left to right. Lets say you want to access a struct member of a pointer in C:
foo->bar
or
(*foo).bar
Or in Pascal simply:
foo^.bar
No exceptions, no need to introduce a new operator, and no need to use supeflous paranteses.

Now original Pascal, or even ANSI Pascal is hideous, that I can agree with. But I also think that turning the blind eye on what has been done with Turbo Pascal and Delphi the last two decades is idiotic. Especially since they have been more or less the de facto standard Pascal. And thus what Pascal should be judged by.


// Fredrik

Fredrik Olsson wrote:
> Sean Kelly skrev:
>> kris wrote:
> <snip>
>>> Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C
>>
>>
>> Yup.  And for that I think it was well-designed.  The syntax is clear and free of arcane symbology, and irritating enough to use for real work that students are well inclined to move on when they learn a more professional language ;-)  The pointer syntax in Pascal drives me absolutely insane.
>>
> Am I the only one in the world that thinks the pointer syntax in Pascal beats the C and D syntax every time?
> 
> I mean how hard can it be:
> ^foo  == a pointer type, pointing to a foo. foo* works, but * also mul.
> foo^  == Whatever the pointer foo points to. *foo works, same argument.
> @bar  == The pointer of bar. &bar works to, but why reuse & again?

I think the '@' in place of '&' is quote meaningful, but for the rest... it just didn't seem intuitive to me.  It's been quite a while, but I remember really feeling like I was fighting the language once I got to pointers.

> Now original Pascal, or even ANSI Pascal is hideous, that I can agree with. But I also think that turning the blind eye on what has been done with Turbo Pascal and Delphi the last two decades is idiotic. Especially since they have been more or less the de facto standard Pascal. And thus what Pascal should be judged by.

I was referring to original Pascal.  I've used Delphi quite a bit as well, and while I'm still not crazy about the updated syntax, it's really quite a good system to work with in general.


Sean

kris skrev:
> Just for fun, how many folks here have hands-on experience with any of the following languages?
> 
> Algol
Nope

> Pascal
Hobby projects since 1988, professionally since 1995. I would hardly classify Pascal as a historical language.

> BCPL
nope

> Ada
For a few months in 1999, army stuff.

> Modula
Only Modula-2, back in 1992 on Atari ST, and barely a few hundred lines of code in Objective Modula-2 this year.

> Simula
nope.


Since Pascal fits the bill I think you should also add LISP, FORTRAN, COBOL, and Prolog :).

// Fredrik

Sean Kelly skrev:
> Fredrik Olsson wrote:
> 
>> Sean Kelly skrev:
>>
>>> kris wrote:
>>
>> <snip>
>>
>>>> Eh? We're talking about the language according the Wirth here (as Walter notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal was designed *solely* as an educational tool, for /teaching structured programming/ ... the syntax and design was never intended as a solution for general-purpose systems programming. It's silly to compare it to C
>>>
>>>
>>>
>>> Yup.  And for that I think it was well-designed.  The syntax is clear and free of arcane symbology, and irritating enough to use for real work that students are well inclined to move on when they learn a more professional language ;-)  The pointer syntax in Pascal drives me absolutely insane.
>>>
>> Am I the only one in the world that thinks the pointer syntax in Pascal beats the C and D syntax every time?
>>
>> I mean how hard can it be:
>> ^foo  == a pointer type, pointing to a foo. foo* works, but * also mul.
>> foo^  == Whatever the pointer foo points to. *foo works, same argument.
>> @bar  == The pointer of bar. &bar works to, but why reuse & again?
> 
> 
> I think the '@' in place of '&' is quote meaningful, but for the rest... it just didn't seem intuitive to me.  It's been quite a while, but I remember really feeling like I was fighting the language once I got to pointers.
> 
>> Now original Pascal, or even ANSI Pascal is hideous, that I can agree with. But I also think that turning the blind eye on what has been done with Turbo Pascal and Delphi the last two decades is idiotic. Especially since they have been more or less the de facto standard Pascal. And thus what Pascal should be judged by.
> 
> 
> I was referring to original Pascal.  I've used Delphi quite a bit as well, and while I'm still not crazy about the updated syntax, it's really quite a good system to work with in general.
> 
> 
> Sean

My _only_ gripe with Pascal is case insanity! Unfortunately the more I write in anything else, the more I fail see an excuse :).
foo := Foo.Create();
Should be legal, but as is (and far too late to fix) we are stuck with ugly and stupid prefixes like:
foo := TFoo.Create();
Every class in VCL being named T... is stupidity.

But that aside, Delphi and Pascal makes it easy to be productive, write less, and more bug free code to solve the same problem as in other languages.
Yet again I must point out that D really should have sets and ranges! ;)

// Fredrik