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

111–120 of 145 posts

Re: Pascal at Apple

#111

Post by vram22 »

vram22 wrote: post #106
rpeden wrote: post #31

Earlier quoted context omitted.

I think BGI graphics will still work in DOSBox. I remember having a setup a couple of years ago where I shared a directory between Windows and DOSBox. I'd edit the code in Windows using Sublime Text, and then pop in to DOSBox to build/run it. So although it doesn't quite make BGI graphics based apps run directly on Windows...it's still quick and easy enough to have some fun. I did it specifically to give myself a way…

Turbo Pascal is, or at least until some time ago, was, also available from the Borland/Codegear/Embarcadero (hat tip to often useless or destructive M&A) Museum (along with other historical software from them, like Turbo C and so on). I had downloaded TP and TC from the Museum and tried them out a bit again some time ago, for old times' sake. Worked okay, IIRC, but I may have only used them for CLI work, not for BGI…

Note: I should mention that, like it happens on many sites, the links sometimes do not work, or are broken. Caveat lector.

Re: Pascal at Apple

#112

Post by WalterBright »

vram22 wrote: post #93
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…

>3. A lot of my need for goto statements vanished with nested functions. How does that work? Not immediately obvious to me.

A lot of the goto's were used to use a common sequence of code followed by a return. With nested functions, the nested function contains the common sequence of code, and you just:

    T common() { ...common sequence of code... }
    ...
    return common();
instead of:

    goto Lcommon;
    ...
    Lcommon:
    ... common sequence of code ...
    return result;

Re: Pascal at Apple

#113

Post by WalterBright »

nurettin wrote: post #47
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…

Nested functions are good if you have no alternative. If you use them as lambdas or a means of code folding, (both of which don't exist in older IDEs and compilers) you will have to keep jumping around in code in order to follow the logic. That is a very tiring thing to do, especially if you just switched jobs.

There are always alternatives. The issue is how naughty or nice they are.

Re: Pascal at Apple

#114

Post by vram22 »

WalterBright wrote: post #112
vram22 wrote: post #93

Earlier quoted context omitted.

>3. A lot of my need for goto statements vanished with nested functions. How does that work? Not immediately obvious to me.

A lot of the goto's were used to use a common sequence of code followed by a return. With nested functions, the nested function contains the common sequence of code, and you just: T common() { ...common sequence of code... } ... return common(); instead of: goto Lcommon; ... Lcommon: ... common sequence of code ... return result;

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?

Re: Pascal at Apple

#115

Post by adrianmonk »

rbehrends wrote: post #35
robterrell wrote: post #28

It may seem quaint now, but Apple Pascal was a serious tool. I took AP Computer Science in 1985 and the language taught was UCSD Pascal on the Apple ][+. (In the 80's, C on an Apple ][ was impossible. The only C compiler you could get was for a card that went in the expansion slot that included a Z80 processor.) When I went to college in 1986, Pascal was the primary language used in all entry-level courses at Virgini…

A major issue was that C compilers were actually fairly ill-suited for 8-bit processors with limited memory, limited processing power, and at most a floppy disk (if that) for external storage. Pascal was designed to allow single pass compilation of programs, while the C preprocessor alone was a source of what was immense overhead at that time. On CP/M, Turbo Pascal blew all C compilers out of the water in terms of co…

C was also designed to compile in one pass, hence the need for forward references. The preprocessor was extra overhead, though.

Also, from my recollection, Turbo Pascal was not just faster than C compilers. It was also faster than other Pascal compilers. And pretty much any other computer regardless of language. That was part of its appeal.

Re: Pascal at Apple

#116

Post by vram22 »

rcarmo wrote: post #109
vram22 wrote: post #95

Earlier quoted context omitted.

>(If anyone knows of anything like it for cross-platform desktop apps, let me know, I'd love to try it out) Check out Xojo. HN user SyneRyder sometimes comments about it here, and likens it somewhat to Delphi. Cross-platform too. I'm in early stages of trying it out, so won't comment myself on it. Xojo is a BASIC variant, and IIRC, was called RealBASIC earlier. While I've done some work with BASIC and Visual BASIC in…

I tracked RealBasic for a few years before the rebranding. It's nice, and if I were developing desktop apps professionally I'd probably buy it - but for my kids to try out, it's a little expensive :) But yeah, it delivers.

I get you, but the lowest version of Xojo, without database support (or maybe even that includes just SQLite support), is free, IIRC, for local use on a PC. And anyway one can do plenty of apps without any DB.

Re: Pascal at Apple

#117

Post by bluedino »

rcarmo wrote: post #60

I wrote a fair amount of Pascal in my 680x0 Mac days, both in MPW (the Macintosh Programmer's Workshop) and THINK Pascal. Back then Modula-2 was available on VAXen and "big" machines, but Pascal was almost "portable" across Mac/PC/VAXen and was amazingly fast, so it was pretty fun. I eventually moved to C (also using THINK C - see retrospective link below for a sample of those heady times) and never looked back until…

That's a great link. I used Think C in the late 90's and school on an LC III - I can't imagine using it on 80's Mac hardware.

Re: Pascal at Apple

#118

Post by bluedino »

boznz wrote: post #19
cjensen wrote: post #2

I really miss Pascal; it was a great and safe language for beginners. As it was extended with Objects and Modules, it was great for development. But there are good reasons it was surpassed by C. In early Pascal, you got a pointer by allocating memory; you could not get a pointer to an existing variable. You'd be surprised how often that gets in the way when implementing a data structure. Just try to implement the fol…

Turbo Pascal was taught at most UK college in the 80's I think most electronic engineers and CS guys who went to school around then were exposed to it and you would be surprised how many PC/DOS programs in the 80's were written in it.

Turbo Pascal seemed like the perfect language for writing DOS games in the early 90's. Fast, you didn't need to know low-level things but you could always patch in assembly routines if you needed to.

Re: Pascal at Apple

#119

Post by WalterBright »

vram22 wrote: post #114
WalterBright wrote: post #112

Earlier quoted context omitted.

A lot of the goto's were used to use a common sequence of code followed by a return. With nested functions, the nested function contains the common sequence of code, and you just: T common() { ...common sequence of code... } ... return common(); instead of: goto Lcommon; ... Lcommon: ... common sequence of code ... return result;

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.

Re: Pascal at Apple

#120

Post by rcarmo »

vram22 wrote: post #116
rcarmo wrote: post #109

Earlier quoted context omitted.

I tracked RealBasic for a few years before the rebranding. It's nice, and if I were developing desktop apps professionally I'd probably buy it - but for my kids to try out, it's a little expensive :) But yeah, it delivers.

I get you, but the lowest version of Xojo, without database support (or maybe even that includes just SQLite support), is free, IIRC, for local use on a PC. And anyway one can do plenty of apps without any DB.

I'll check into that. The mandatory registration thing is a turnoff...
Post reply on HN