Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pascal at Apple

blog.fogus.me

Post reply on HN
Print view View original

121–130 of 145 posts

Re: Pascal at Apple

#121

Post by [deleted] »

microtherion wrote: post #62
jzelinskie wrote: post #8

I've been reading a lot about Niklaus Wirth recently. I read an interesting piece about Oberon I found in an HN archive[0] that mentions Oberon usage on Macs. I'm very tempted to buy "The School of Niklaus Wirth: The Art of Simplicity" after reading a few things about him. I wish there were more instances of "computing in a vacuum" like at ETH. [0]: https://news.ycombinator.com/item?id=10058486

I studied under Wirth at ETH Zurich in the 1980s, so I got to interact with him personally a number of times. His class on compiler construction was particularly interesting. You could see how a philosophy of simplicity and clarity in syntax and semantics would translate to simple and clear compilers. The downside of this philosophy was that aspects of interacting with a computer that were inherently messy tended to…

[deleted]

Re: Pascal at Apple

#122

Post by kwhitefoot »

bbrik wrote: post #72
WalterBright wrote: post #20

Earlier quoted context omitted.

I liked nested functions in Pascal, and put them in D. They turn out to be surprisingly useful: 1. Properly encapsulating their scope, as opposed to having static functions sit awkwardly somewhere else. 2. Factoring out common code within the function. 3. A lot of my need for goto statements vanished with nested functions. 4. Take the address of a nested function, and it serves as a lambda. 5. No need to create "Cont…

C# has just implemented nested functions.

There is a nice blog post that concisely explains why local functions are better than lambdas: https://asizikov.github.io/2016/04/15/thoughts-on-local-func...

Re: Pascal at Apple

#123

Post by drfuchs »

microtherion wrote: post #62
jzelinskie wrote: post #8

I've been reading a lot about Niklaus Wirth recently. I read an interesting piece about Oberon I found in an HN archive[0] that mentions Oberon usage on Macs. I'm very tempted to buy "The School of Niklaus Wirth: The Art of Simplicity" after reading a few things about him. I wish there were more instances of "computing in a vacuum" like at ETH. [0]: https://news.ycombinator.com/item?id=10058486

I studied under Wirth at ETH Zurich in the 1980s, so I got to interact with him personally a number of times. His class on compiler construction was particularly interesting. You could see how a philosophy of simplicity and clarity in syntax and semantics would translate to simple and clear compilers. The downside of this philosophy was that aspects of interacting with a computer that were inherently messy tended to…

As you indicate, the language described in Jensen and Wirth's 1975 "Pascal User Manual" didn't have a way to open files with a name computed at runtime, nor was there a way to close a file. TeX needed to be able to do these things, as well as to have what C programmers would call a "default" case on a switch statement, which was also missing from standard Pascal. Happily, almost all Pascal compilers had these extensions; unhappily, the syntax was not generally agreed upon.

Other than that, TeX actually used a strict subset of standard Pascal; quoting module #3 in Volume B of Knuth's Computers & Typesetting: "Indeed, a conscious effort has been made here to avoid using several idiosyncratic features of standard PASCAL itself, so that most of the code can be translated mechanically into other high-level languages. For example, the `with' and `new' features are not used, nor are pointer types, set types, or enumerated scalar types; there are no `var' parameters, except in the case of files; there are no tag fields on variant records; there are no assignments real:=integer; no procedures are declared local to other procedures."

As you also say, Pascal had virtually useless string types, but TeX worked around that limitation itself, by managing its own string pool in a single big array of characters, with a second array of pointers to where each string started. A string was identified by its index in the later array. Through careful design and coding, no general garbage collection of strings was necessary, just the ability to forget the most recently-made string.

Re: Pascal at Apple

#124

Post by anthay »

kkylin wrote: post #43
WalterBright wrote: post #20

Earlier quoted context omitted.

I liked nested functions in Pascal, and put them in D. They turn out to be surprisingly useful: 1. Properly encapsulating their scope, as opposed to having static functions sit awkwardly somewhere else. 2. Factoring out common code within the function. 3. A lot of my need for goto statements vanished with nested functions. 4. Take the address of a nested function, and it serves as a lambda. 5. No need to create "Cont…

Off-topic, but nested functions are one of my favorite gcc extensions.

In the past I've sometimes used standard C++ local structs to nest functions. E.g.:

    int f()
    {
        struct local {
            static int nested_func()
            {
                return 123;
            }
        };

        return local::nested_func();
    }

Re: Pascal at Apple

#125

Post by vram22 »

WalterBright wrote: post #119
vram22 wrote: post #114

Earlier quoted context omitted.

Got it now, thanks. But, this (the "return common();") could be done even if the function "common" was not nested within the current function, but defined outside of it, right? So what is the benefit of defining "common" as a nested function? Is it because it then has access to, and can use, variables defined in the outer function?

Yes, you can do it that way. But then you'll need a "context pointer" to pass references to the locals it'll need, and the function will need to be located "someplace else", meaning it is not encapsulated. I've done that for years with C and C++. Nested functions are so much nicer and clearer.

Got it now, thanks. I've used nested functions in Python and they have some good uses. Will check them out in D.

Re: Pascal at Apple

#126

Post by TimJYoung »

jdswain wrote: post #34
jzelinskie wrote: post #8

I've been reading a lot about Niklaus Wirth recently. I read an interesting piece about Oberon I found in an HN archive[0] that mentions Oberon usage on Macs. I'm very tempted to buy "The School of Niklaus Wirth: The Art of Simplicity" after reading a few things about him. I wish there were more instances of "computing in a vacuum" like at ETH. [0]: https://news.ycombinator.com/item?id=10058486

I've got that book, it is interesting to read. I also spent quite a bit of time looking at the Oberon system and that has been very educational. Oberon is quite like Pascal, but in some ways simplified even more. He wrote a complete operating system and user interface in Oberon and it is just amazing how much he achieved with very few lines of code. I'm currently attempting to write a C compiler and the complexity is…

I've written an Object Pascal (the current incarnation that Delphi/FreePascal uses) compiler/transpiler for Object Pascal->JavaScript and yes, it's great language for compiler writers because the language makes the job of the compiler so easy. You have to really go out of your way to make the compilation slow, and there aren't a lot of undefined behaviors or other gotchas that are hard to navigate. Also, I wrote it in Delphi. :-)

Re: Pascal at Apple

#127

Post by sidegrid »

kabdib wrote: post #49
WalterBright wrote: post #20

Earlier quoted context omitted.

I liked nested functions in Pascal, and put them in D. They turn out to be surprisingly useful: 1. Properly encapsulating their scope, as opposed to having static functions sit awkwardly somewhere else. 2. Factoring out common code within the function. 3. A lot of my need for goto statements vanished with nested functions. 4. Take the address of a nested function, and it serves as a lambda. 5. No need to create "Cont…

Good points, all. I think I misliked Pascal's nested procedures because they weren't true lambdas; once the outer procedure returned, the inner procs were no longer callable (just one contiguous stack, right?). Early-on, using C++ lambdas, I found myself making the same mistake in a design for some asynchronous completion stuff. Embarrassing; C++ and Pascal are not JavaScript/Lisp/Scheme/Smalltalk :-)

Misliked?

Re: Pascal at Apple

#128

Post by TimJYoung »

rpeden wrote: post #75
raphinou wrote: post #68

Earlier quoted context omitted.

Lazarus looks interesting, but what holds me back is that the language doesn't seem to have evolved. I enjoy functional languages much more these days, and I prefer not to go back to an old language. I would be happy to be proven wrong on this

The language has evolved, but it still falls squarely in the imperative, OO camp. And besides, you mentioned than you'd prefer to stick with more functional languages. It's hard to prove someone's preference wrong. :) I mostly share your preference, but I make an exception for Pascal. There's just something about it that draws me in, even though I've only used it for fun, and not professionally.

Just curious: do you use an IDE, and if so, which one ?

The thing that drew me in to Object Pascal was getting Delphi back in 1996 (I think it cost $200), and being just amazed at how much I could do out-of-the-box without knowing a thing about Object Pascal. The productivity with IDEs like Delphi/Lazarus is just astounding.

I look at setup instructions for many languages today and just cannot believe what I'm reading. Pages and pages of instructions on putting together a dev environment just to compile a Hello World program. It's just insane to me...

Re: Pascal at Apple

#129

Post by coldtea »

sidegrid wrote: post #127
kabdib wrote: post #49

Earlier quoted context omitted.

Good points, all. I think I misliked Pascal's nested procedures because they weren't true lambdas; once the outer procedure returned, the inner procs were no longer callable (just one contiguous stack, right?). Early-on, using C++ lambdas, I found myself making the same mistake in a design for some asynchronous completion stuff. Embarrassing; C++ and Pascal are not JavaScript/Lisp/Scheme/Smalltalk :-)

Misliked?

Mind blowing factoid: not everybody on the internet is a native english speaker.

Re: Pascal at Apple

#130

Post by jenkstom »

Pascal was one of my favorite languages (in the form of Object Pascal). I made a living from it for decades. But Borland and a long succession of companies killed it through mismanagement. It does still exist in the form of freepascal and lazarus, but I've moved on to c#.

Pascal was great for people who didn't have curly braces in their muscle memory. But I suppose I've gone fully over to the dark side now.

Post reply on HN