News for hackers. Stuff that matters.
Re:Internals of a Turbo Pascal Compiler by luso_brazilian on Friday September 11, 2015 @04:19AM (#10202547)
You will then be pleased to know that C# development team is led by Anders Hejlsberg, the same Anders mentioned in the article that created what went to become Borland Turbo Pascal. IIRC, he also led the development of Borland Delphi and its language, Object Pascal.

He is really a prolific language designer, one of the unsung heroes of that area.

Re:Internals of a Turbo Pascal Compiler by barrkel on Friday September 11, 2015 @04:28AM (#10202589)
Object Pascal was originally an Apple invention (with help from Wirth), and made some strides towards ISO standardisation. However it used a value-based OO model that made vtables optional until you added the first virtual method, permitted object slicing, had no common ancestor for all classes, had an odd syntax for calling constructors (using extra parameters to New), etc.

Delphi introduced a new object model while retaining the old object model for backward compatibility. The language was renamed to Delphi some time later to reflect this; while Object Pascal in practice meant the language that the Borland compilers compiled, its technical and historical meaning is both broader (more compilers) and more limited (a smaller language with different features).

Re:Internals of a Turbo Pascal Compiler by junto on Friday September 11, 2015 @04:32AM (#10202606)
Interestingly I just Googled Borland to see what they do these days: http://www.borland.com/Products

Seems like they made quite a major pivot?

Re:Internals of a Turbo Pascal Compiler by lucifersam on Friday September 11, 2015 @05:24AM (#10202748)
Yes, quite some time back they split the languages and compilers part out and the rump of Borland became an application lifecycle management company, or something like that.

The bit you're probably looking for is at http://www.embarcadero.com/ now. Some of the old people like David Intersimone are still there.

I worked with Delphi for a long time, through versions 3, 5 and 7 (the odd numbers were always better). When .NET came, the whole situation went crazy and never recovered. I can't remember the twists and turns now, but I think they released a .NET only RAD Studio which was awful, then they added the Win32 bits back but Delphi.NET was still awful. Then they dropped .NET and incorporated Remobjects Chrome/Oxygene as Delphi Prism, which was an Object Pascal inspired .NET language. Now they've split again, and Radstudio is all about Firemonkey, a cross-platform UI library. Remobjects are doing their own thing.

Re:Internals of a Turbo Pascal Compiler by jimmcslim on Friday September 11, 2015 @06:30AM (#10202931)
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'm just bitter after RAD Studio crashed on me one too many times...

Re:Internals of a Turbo Pascal Compiler by nickpsecurity on Friday September 11, 2015 @01:22PM (#10204937)
Compared to VC++, it was easier to learn, read, write, make reliable apps, and extend. I could teach anyone a Wirth language. The Go community is learning the benefits of Pascal-style design. People wanting a new Delphi should probably use Go. Just because Delphi stagnated and died off.

Anyone wanting Pascal/Delphi today should use Lazaurus IDE w/ Free Pascal Compiler. Compatible with Delphi where it mattered, aiming for better in other areas, open-source, and cross-platform. Best use case is a C or C++ replacement that's safer, easy to read, and supports computers with little resources. Go's not there yet on runtime side.

Re:Internals of a Turbo Pascal Compiler by amyjess on Friday September 11, 2015 @03:42PM (#10205750)
> People wanting a new Delphi should probably use Go. Just because Delphi stagnated and died off.

Or, for that matter, Nim, which also has a huge amount of Pascal heritage.

Go is a hybrid of Oberon and C (with semantics leaning more towards Oberon and syntax more towards C, but they're both mixed in), and Nim is Modula-3 semantics married to Python syntax (with the best parts of a bunch of other languages thrown in). Both Oberon and Modula-3 are descended from Modula-2, which in turn is descended from Pascal.

Personally, I'm more in the Nim camp, partially because I prefer Modula-3 to Oberon, partially because I prefer Nim's Pythonesque syntax to Go's C/Oberon mashup syntax, and partially because Nim's metaprogramming features are truly beautiful.

Re:Internals of a Turbo Pascal Compiler by nickpsecurity on Saturday September 12, 2015 @12:11AM (#10207189)
Modula-3 semantics married to Python syntax. Now that sounds potentially great. :) Even more so since I've recommended each language. Modula-3 was the second time (since Turbo Pascal) that industry types took Wirth's design ideas, ran with them, and produced an industrial implementation that kicked ass. Was used in SPIN OS w/ type-safe linking where OS and linked code leveraged type system for protection. Python syntax's benefits are well known.

I was a bit concerned about the maturity, compiler complexity, available libraries, and so on about Nim. I figured it might be in alpha quality or something given it's so new. So, I was hesitant to try it. I might give it a go sometime soon reading comments like yours.

Btw, do you have experience with its macro system? Any take-it-to-next-level language needs at least good macros and preferably great ones. Top contenders of my recent research are Racket, Julia, and Red. If Nim is more like Modula3/Python & has good macros, then it might be a credible contender due to mainstream programmers being able to pick it up more easily than really weird languages.

Re:Internals of a Turbo Pascal Compiler by beagle3 on Friday September 11, 2015 @05:02PM (#10206160)
> which in turn is descended from Python.

I think you meant Pascal?

Re:Internals of a Turbo Pascal Compiler by amyjess on Friday September 11, 2015 @05:09PM (#10206199)
Yes, I did. I'll edit it.

(...and edited)

Re:Internals of a Turbo Pascal Compiler by pjmlp on Friday September 11, 2015 @04:09PM (#10205886)
Go might have a few Oberon influences, and it was what made me look at it in first place.

However, even Turbo Pascal was more expressive than Go in terms of language features (not taking the GC into account). Delphi even more so, specially if one takes into consideration the VCL and IDE.

But, it would be nice to see someone come up with a System 3 Gadgets library for Go, or an environment like BlackBox Component Builder.

Re:Internals of a Turbo Pascal Compiler by nickpsecurity on Friday September 11, 2015 @04:47PM (#10206087)
I totally agree. Blackbox is particularly kicking butt in Russia. I recommended Go because it's mainstreamed with all benefits that entails for developers and employers.
Re:Internals of a Turbo Pascal Compiler by Xixi on Friday September 11, 2015 @03:15PM (#10205626)
Most people writing Delphi code in 2015 do it to maintain legacy Windows desktop applications. I don't think you can do that with Go. The most logical replacement would still be C# (or another language running on .net) with WinRT (or more likely WPF: I mean if you are still using Delphi you are probably not using Windows 8/10...).
Re:Internals of a Turbo Pascal Compiler by nickpsecurity on Friday September 11, 2015 @04:57PM (#10206135)
Funny you say that cuz I picked it for future proofing. I specifically wanted it to be the legacy language instead of C++ in case the talent was short many years down the line. That proved out haha. ;)
Re:Internals of a Turbo Pascal Compiler by VSpike on Friday September 11, 2015 @03:50PM (#10205801)
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 alternatives and to be honest, I can't really think of a reason you'd choose it any more - even if you /did/ want to create Windows native apps.

Re:Internals of a Turbo Pascal Compiler by iofj on Saturday September 12, 2015 @11:26AM (#10208328)
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 by lobster_johnson on Friday September 11, 2015 @02:00PM (#10205186)
Don't forget the first pivot: Inprise.

Borland decided that the new shiny thing was "enterprise client/server middleware" — whatever that was. The new Inprise products were oriented towards building distributed client/server database apps using DCOM and the all-too-obviously-dead-on-arrival CORBA.

This was right around the time the web took off, but before the inane "enterprise Java application server" market exploded. Borland had a hard time competing with Java, and they started to neglect the stuff that had made Delphi such a powerful proposition in the first place.

Re:Internals of a Turbo Pascal Compiler by 72deluxe on Friday September 11, 2015 @04:56AM (#10202667)
I used Borland C++ Builder and their version of it in the XP - Windows 7 days, when they released Codegear 7. As far as I knew many of the developers left after they renamed themselves Inprise ("integrating the enterprise" whatever that means), decided to produce odd products that targeted an entirely different audience and after they ditched all the development work on C++ Studio (I think that was what it was called).

I remember them introducing Kylix and the disappointment of it being based on Qt and Wine so slow on my old Linux box. The VCL stagnated too (horrible flicker on XP as I recall, to begin with so hacks to disable theming via the application manifest were needed) and the compiler let you do illegal things in C++ in Codegear's C++ Builder 7 (must dig out an example). The installer for C++ Builder 7 took FOREVER to run and also required you keep all of your setup files in your temp directory for later updates to work (???? insane eh!)

I remember them releasing a paid PHP editor etc. at the time when you could just grab Netbeans and use that for £0.00 - difficult to compete with that!

Re:Internals of a Turbo Pascal Compiler by tonyedgecombe on Friday September 11, 2015 @06:07AM (#10202874)
After that PHP editor I vowed to never by another product from them, it was truly awful.
Re:Internals of a Turbo Pascal Compiler by vidarh on Friday September 11, 2015 @05:52AM (#10202821)
They've been rotating at high speed for the better part of the last two decades. Starting around the time of Philippe Khan's departure.