Live data from Hacker News

Pascal at Apple

blog.fogus.me

91–100 of 145 posts

Re: Pascal at Apple

#91
post #83
post #79

Earlier quoted context omitted.

If you can do Visual Basic-like forms with it... that's the main appeal of Lazarus for me right now - instant native GUI development.

I really think Sun and MS did a big mistake with their VM approaches instead of following what was common on the 90s. So we had to wait 20 years, failure of Moore's law, cache optimization issues, competition from new languages, for them to come up with .NET Native, CoreRT and the initial AOT on Java 9

Calling VM's a mistake is surprising considering that today, a crushing majority of code (JVM, .net and arguably, LLVM) runs on a VM.

In comparison, .net native and Core RT are tiny dots on the radar.

Besides,

- Pascal UCSD Pascal was a VM (p-code)

- A few anti-piracy schemes on the Apple ][ used their own VM to obfuscate their code

- ScummVM was extremely popular to create games

VM's were a thing in the 90s and they are even more of a thing today.

Re: Pascal at Apple

#92
post #49

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 :-)

You can assign a c++ lambda into an object for later use, you just have to be careful about capture by reference and capturing pointer types... But the capture using the copy constructor is handy here, eg. you can copy a shared_ptr and get reference counted captures...

It's funny in this way how c++ lambdas lead to very c++ specific issues and uniquely c++-ish solutions. I think the wackiness of the closure capture mechanism is the best example of this I can think of.

Re: Pascal at Apple

#93
post #10

I joined Apple in 1987, about the time they started ditching Pascal in favor of C. C++ (in the form of CFront) was just starting to be a thing. Apple's Pascal had been extended to the point where there were few true differences between it and C, other than - strings with busted semantics (size being part of the type being a huge mistake, leading to a proliferation of types like Str255, Str32, Str31, Str64, etc). I sh…

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.

Re: Pascal at Apple

#94
post #10

I joined Apple in 1987, about the time they started ditching Pascal in favor of C. C++ (in the form of CFront) was just starting to be a thing. Apple's Pascal had been extended to the point where there were few true differences between it and C, other than - strings with busted semantics (size being part of the type being a huge mistake, leading to a proliferation of types like Str255, Str32, Str31, Str64, etc). I sh…

I hadn't heard of CFront.

https://en.wikipedia.org/wiki/Cfront

Interesting.

Re: Pascal at Apple

#95
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…

>(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 my time, and don't puke out on it (as some people allege they do :), I confess that I prefer the syntax style of the Algol family of languages, such as C, C++, Pascal, D, and Go.

However, the convenience of VB, Delphi, Lazarus and similar drag-and-drop GUI app builder tools is real. Great for quickly prototyping something, and many a time for the final product too.

Re: Pascal at Apple

#96
post #83

Earlier quoted context omitted.

I really think Sun and MS did a big mistake with their VM approaches instead of following what was common on the 90s. So we had to wait 20 years, failure of Moore's law, cache optimization issues, competition from new languages, for them to come up with .NET Native, CoreRT and the initial AOT on Java 9

Calling VM's a mistake is surprising considering that today, a crushing majority of code (JVM, .net and arguably, LLVM) runs on a VM. In comparison, .net native and Core RT are tiny dots on the radar. Besides, - Pascal UCSD Pascal was a VM (p-code) - A few anti-piracy schemes on the Apple ][ used their own VM to obfuscate their code - ScummVM was extremely popular to create games VM's were a thing in the 90s and they…

> Calling VM's a mistake is surprising considering that today, a crushing majority of code (JVM, .net and arguably, LLVM) runs on a VM.

LLVM isn't a VM.

.NET achieved its position, because on Windows many of the APIs became .NET only or C++ COM. Not many people bothered to use alternatives to Microsoft tooling.

JVM achieved its position due to being free, and the huge amount of money and engineering resources that Sun poured into it, which in a way ended up killing the company.

Yet due to the pressure from Fintech customers, Oracle started to look into AOT compilation, with initial support for Linux x64 available on Java 9, other platforms will be supported later. Most commercial JDKs had support for AOT since the early days.

> In comparison, .net native and Core RT are tiny dots on the radar.

Yes, but that is where Microsoft wants to go. There is no pure .NET on UWP, other than via the desktop bridge, the transition technology to port Win32 into UWP.

> - Pascal UCSD Pascal was a VM (p-code)

Quite correct and it ran quite slowly, purely interpreted.

> A few anti-piracy schemes on the Apple ][ used their own VM to obfuscate their code

- ScummVM was extremely popular to create games

The games from Lucasart were hardly something where performance mattered.

> VM's were a thing in the 90s and they are even more of a thing today.

Given Apple's decisions on their programming languages, Go, D, Rust, Pony, Haskell, OCaml, the change of direction on Dart's design, I am not quite sure.

Re: Pascal at Apple

#97
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…

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

Downvotes is the last thing I expected on this comment. I expressed my opinion about what held me back. In what sense does that warrant a downvote?

Re: Pascal at Apple

#98
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…

>It builds fast, tiny, entirely native apps in less than a second, and is an excellent example of how far Pascal went despite falling off the mainstream wagon.

D meets some of your criteria too, at least somewhat small fast, native apps. Build speed is decent (or more) too, and it is designed for that - doesn't have C's repeated overhead of pulling in include files. [1] Haven't tried the GUI toolkits for D though (yet). There are some, like DLangUI, GtkD, etc. Not sure if there are any GUI builders like Delphi, Lazarus, VB, Xojo, etc. have. Also, I think I read that D's language design allows D compilers to be the single-pass kind.

[1] I think this is the video I had blogged about a while ago, in which Bjarne Stroustrup talks about the details of that include files issue:

Video: C++, Rust, D and Go: Panel at LangNext '14

https://jugad2.blogspot.com/2016/08/video-c-rust-d-and-go-pa...

Edited for wording about D compilers.

Re: Pascal at Apple

#99
post #96

Earlier quoted context omitted.

Calling VM's a mistake is surprising considering that today, a crushing majority of code (JVM, .net and arguably, LLVM) runs on a VM. In comparison, .net native and Core RT are tiny dots on the radar. Besides, - Pascal UCSD Pascal was a VM (p-code) - A few anti-piracy schemes on the Apple ][ used their own VM to obfuscate their code - ScummVM was extremely popular to create games VM's were a thing in the 90s and they…

> Calling VM's a mistake is surprising considering that today, a crushing majority of code (JVM, .net and arguably, LLVM) runs on a VM. LLVM isn't a VM. .NET achieved its position, because on Windows many of the APIs became .NET only or C++ COM. Not many people bothered to use alternatives to Microsoft tooling. JVM achieved its position due to being free, and the huge amount of money and engineering resources that Su…

You're setting up a lot of straw men.

Your point, which I was replying to, was that VM's are a mistake, not that they were/are slow, or how some VM's became dominant, or making guesses toward where Microsoft or Oracle want to head.

My response is that 1) VM's are dominant today and 2) for very good reasons.

And because of that, they are not a mistake.

I also speculate they are going to remain dominant for a while because of all their advantages over native approaches, advantages which become even more prominent as hardware keeps pacing up, like it has always done.

Re: Pascal at Apple

#100

I'm reminded of a really great interview with Bill Atkinson where he describes (among many other things) how he initially brought Pascal to Apple and the Apple II. https://youtu.be/6tUWoy1tJkE?t=45m The Pascal bits are from 45:00 to about 50:00. ... My manager at the time said, no, we don't want to do this [Pascal], people are happy with what they got. I overrode him and went to Jobs, and Jobs said "Well, I'm not con…

Interesting at my first job I did a little bit on USCD Pascal on apple.

While I did a little bit of COBOL and Fortran (on digital minicomputers) in high school, USCD Pascal in grade 12 was the thing that really got me off BASIC on my personal computer (at that time, an Apple ][gs).

IIRC, the line my high school computer science teacher used about USCD Pascal without paying at the time (around 1988) was that it was out of copyright or something, but now that I think of it, I'm not so sure that was a legit reason.

Post reply on HN