Live data from Hacker News

Forgotten Language: Jorf could have been Python or Ruby (2005)

ralsina.me

71–74 of 74 posts

Re: Forgotten Language: Jorf could have been Python or Ruby (2005)

#71
post #34

Earlier quoted context omitted.

Coming from a Borland background, MFC was pretty bad when compared with any of its frameworks. However in MFC's defense I think one can blame it on Microsoft's study group. I read somewhere that the Afx prefix came from their original design. A framework close in spirit to OWL, but their study group deemed it to high level. So they made it a thin wrapper over Win16 instead. On my case, the few cases I was forced outs…

I've heard the same thing about the Afx macros and the plan for another more ambitious framework. In my opinion the biggest obstacles for MFC were: * a pretty bad C++ compiler (the first good MS C++ compiler was the one with Visual Studio 2003 as much as i remember) * that the core group were "old school" C guys that either couldn't design a better object oriented system or thought that it would be to hard for the "n…

Just decided to do a bit of archaeology.

The macros in the Windows 3.1 SDK were the strict header mode and message crackers.

https://support.microsoft.com/en-us/kb/83456

It made my life sane every time I had to use C instead of C++, and yet very few people knew about them.

Petzold never mentioned them in his books, I discovered them by chance in another book.

Nice to know that the Afx story might have not been a rumour, since other people heard the same.

My first Visual C++ was v5.0, by then it was already clear that Borland was on they way out as first choice. Sadly.

Re: Forgotten Language: Jorf could have been Python or Ruby (2005)

#72
post #9

Earlier quoted context omitted.

No. Why do you ask?

Things on the front page has way less votes and seems fresher (more quickly replaced) than before. There are multiple stories on the front page right now with less than 10 votes and only one story older than 9 hours.

Some of that may be artifacts of the experiments we've been working on to make it easier for good stories to surface from /newest. If you're interested, see https://news.ycombinator.com/item?id=10376064 and the links there.

Re: Forgotten Language: Jorf could have been Python or Ruby (2005)

#73
post #46

Earlier quoted context omitted.

1) True, I was a casual user of PHP before TheFacebook and remain so. The main point of the counterfactual is about Perl, ie that Perl probably would have retained a bigger part of the dev ecosystem. Though it's also true that a product like HHVM may never have happened. 2) Nice! #TIL

I don't think it's fair to say that Perls lack of retention for any sizable part of the modern web development ecosystem was down to it's performance. Since the days of Apache 1.x Perl has had native C bindings for httpd via mod_perl, which unsurprisingly runs circles around FastCGI and the even slower standard CGI. It's also worth remembering that Ruby didn't really take off as a major force for web development unti…

mod_perl and CGI are no longer recommended for modern perl development. We have Mojolicious, Dancer, Catalyst, Plack, and many other modern frameworks (and libraries). Most of these will run circles around mod_perl, without giving you the horror that is mod_perl's global variables + namespacing hacks and its propensity to segfault.

Re: Forgotten Language: Jorf could have been Python or Ruby (2005)

#74
post #73
post #46

Earlier quoted context omitted.

I don't think it's fair to say that Perls lack of retention for any sizable part of the modern web development ecosystem was down to it's performance. Since the days of Apache 1.x Perl has had native C bindings for httpd via mod_perl, which unsurprisingly runs circles around FastCGI and the even slower standard CGI. It's also worth remembering that Ruby didn't really take off as a major force for web development unti…

mod_perl and CGI are no longer recommended for modern perl development. We have Mojolicious, Dancer, Catalyst, Plack, and many other modern frameworks (and libraries). Most of these will run circles around mod_perl, without giving you the horror that is mod_perl's global variables + namespacing hacks and its propensity to segfault.

I'm aware mod_perl and CGI aren't recommended for modern projects (I spent a good few years as a Perl developer too). The reason I neglected to mention Catalyst et al was because my post was a historical piece and the frameworks you've discussed didn't exist back then.

As an aside, mod_perl's tendency to segfault was easily the single most frustrating thing about Perl development. I've lost count of the number of times I've ran strace against apache processes trying to trace whatever was causing the code to crash. Ugh, glad I don't have to do that any more.

Post reply on HN