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

Internals of a Turbo Pascal Compiler

turbopascal.org

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Internals of a Turbo Pascal Compiler

#101

Post by iofj »

VSpike wrote: post #81
jimmcslim wrote: post #25

Earlier quoted context omitted.

I've been working with Delphi for the last 18 months; previously Java and .Net many years before that, but Delphi in the distant, distant past. In my opinion, Delphi needs to just die, and the people/companies that have code bases built on it need to rewrite. There are lots of choices for software development these days, I don't think Delphi stands out for any particular use case in the modern world. But hey, maybe I…

Yeah, Delphi needs to die. I used it for a long time, and it was an excellent product for developing Windows applications when compared to the main alternatives, i.e. Visual C++ with MFC (the horror!) or VB6. It was fast, efficient, easy to use, with a great community, good tooling and the picky type system tended to find a lot of potential bugs at compile time (once you got used to it). Now there are a lot of altern…

How about: Using win32 means your application works without any problem and any third-party dlls or weird installs on anything from win2k to windows10 and winRT (any non-arm version). Making a single .exe that works across all of them isn't very hard. Making one that also works on linux and even android and ios is possible, but isn't nearly as seemless. Needless to say, you won't achieve this with either webapps, C#, java, or any of the other languages.

It's incredibly fast. You know how Go and C++ start with tiny applications ? The app starts up 0.2 seconds after you've finished typing the command. Delphi does that for 150000 lines applications. Your executables are decently sized (2-5 megabytes for large apps, kilobytes for small games and the like. Especially Go and C++ have problems with executable size. Go's hello world is still > 2 megabytes, and large go apps have huge binary sizes (dozens of megabytes), despite not containing spectacular amounts of code. Large C++ binaries, statically linked, are dozens to hundreds of megabytes (and God help you if you turn on debug info. I've known compiling a webserver + database app in C++ that actually failed to compile due to the single binary filling up the disk that had ~18 Gigabytes of free space (the binary, once compiled was 1.8 gigabytes, the rest was intermediate files)).

The number of add-ons, controls, database connectivity, install software, ... available for Delphi defies belief and they're extremely high quality.

It's extremely unlikely to change in backwards incompatible ways. Your code will keep working, and will keep looking and working the way it does now (compared to java or shudder the web, it's heaven)

Of course, there are downsides : manual memory allocation is a bit inconvenient (but very fast), HTTP/JSON communication is tricky. Nobody trusts .exe files anymore (for good reason, of course, but ...). It's unlikely to impress when judged on the last buzzwords.

Re: Internals of a Turbo Pascal Compiler

#102

Post by Roboprog »

nickpsecurity wrote: post #100
pjmlp wrote: post #73

Earlier quoted context omitted.

> What's the market do? Push all effort into C and C++. Results of that are still with us. Not to mention the amount of money spent writing band aids for them., in form of static and memory analysers and more recently CPU instructions (Intel MPX). Which not everyone uses, because either it isn't available on their platform, or they choose not to use them anyway. Just like coders that despite C++ safety improvements o…

Obligatory: https://www.gnu.org/fun/jokes/unix-hoax.html Even a professional and fan of C once admitted that this was great because it could've been true. Ain't that something. ;)

The funny thing is, I have actually come to like Unix, compared to the alternative. But C is NOT an applications programming language - it really is just portable assembler.

So much programming machismo:

* Bounds checking is a little slower, so safeties off!

* Multiprocessing with explicit IPC is slightly slower than thread pools, so safeties off!

* Parameters and explicit return values to functions are a little slower than DATA-DIVISION / instance variable mutation whack-a-mole code, so safeties off!

Re: Internals of a Turbo Pascal Compiler

#103

Post by nickpsecurity »

Roboprog wrote: post #102
nickpsecurity wrote: post #100

Earlier quoted context omitted.

Obligatory: https://www.gnu.org/fun/jokes/unix-hoax.html Even a professional and fan of C once admitted that this was great because it could've been true. Ain't that something. ;)

The funny thing is, I have actually come to like Unix, compared to the alternative. But C is NOT an applications programming language - it really is just portable assembler. So much programming machismo: * Bounds checking is a little slower, so safeties off! * Multiprocessing with explicit IPC is slightly slower than thread pools, so safeties off! * Parameters and explicit return values to functions are a little slow…

It's a portable assembler plus a structure for programs. LLVM IR is a portable assembler. I like your examples of their machismo, though. The machismo concept particularly: "Real programmers don't need all those safety mechanisms! Get out of here kid and take your training wheels with you!"

Funny part is they say this even when alternative languages or libraries implement safety tricks without a performance penalty. Then we see clearly that their resistence isn't technical. ;)

Re: Internals of a Turbo Pascal Compiler

#104

Post by pjmlp »

nickpsecurity wrote: post #99
pjmlp wrote: post #73

Earlier quoted context omitted.

> What's the market do? Push all effort into C and C++. Results of that are still with us. Not to mention the amount of money spent writing band aids for them., in form of static and memory analysers and more recently CPU instructions (Intel MPX). Which not everyone uses, because either it isn't available on their platform, or they choose not to use them anyway. Just like coders that despite C++ safety improvements o…

Yeah the band aids add up. We'd need things such as static analysers anyway for spotting problems, optimizing, etc. However, an extra problem with C/C++ is that the languages are so complex to analyse that people get friggin' PhD's for certifying or formalizing even a subset of them. And the average programmer working against the clock is supposed to make something robust with such a tool? That's ridiculous. " becaus…

Modern C++ can be safe by making use of:

- type safe enums (enum class)

- STL collections instead of plain C like types

- references for out parameters

- RAII

- smart pointers

- values types over heap allocations everywhere

- warnings as errors

The problem is making sure there aren't some guys in the team doing C style coding.

Nowadays C++ is still my language to go when I need to step out of Java and .NET.

The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code.

Effective Modern C++, Tour of C++, Elements of Programming and From Mathematics to Generic Programming are all good books, where safe modern C++ is used.

Re: Internals of a Turbo Pascal Compiler

#105

Post by nickpsecurity »

pjmlp wrote: post #104
nickpsecurity wrote: post #99

Earlier quoted context omitted.

Yeah the band aids add up. We'd need things such as static analysers anyway for spotting problems, optimizing, etc. However, an extra problem with C/C++ is that the languages are so complex to analyse that people get friggin' PhD's for certifying or formalizing even a subset of them. And the average programmer working against the clock is supposed to make something robust with such a tool? That's ridiculous. " becaus…

Modern C++ can be safe by making use of: - type safe enums (enum class) - STL collections instead of plain C like types - references for out parameters - RAII - smart pointers - values types over heap allocations everywhere - warnings as errors The problem is making sure there aren't some guys in the team doing C style coding. Nowadays C++ is still my language to go when I need to step out of Java and .NET. The probl…

"Modern C++ can be safe by making use of:"

Thanks for the summary and references. Will be helpful if another honest language comparison is done of C++ against safe, systems languages. Or C++ developers against others on realistic, example programs.

"The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code."

It makes sense. My solution was a auto-generating that from a better language and wrapping their libraries. That does take some serious tooling support, though.

Re: Internals of a Turbo Pascal Compiler

#106

Post by TD-Linux »

pvg wrote: post #74
TD-Linux wrote: post #66

Earlier quoted context omitted.

That's correct, I even have a version of it for the Z80 Softcard on the Apple II. Even in that day, the license was still only for 1 CPU and you had to mail in a license registration card to be able to use the software (I don't think that sort of EULA is legally enforceable, though)

How did that licensing work? Like any self-respecting 11-year-old, my Apple ][ CP/M copy of Turbo Pascal was pirated.

The book just told you to mail in the registration card with strong language. I don't think it was legally enforceable in any way. There wasn't a license key or anything.
Post reply on HN