Delphi – why won't it die? (2013) - <AUTHOR> http://stevepeacocke.blogspot.com/2013/05/delphi-why-wont-it-just-die.html <comment><USER3> My employer has a multi-million line codebase in Delphi which is still under active development. I mostly do web development, but every once in a while I go back in to build a feature on the Delphi side of the fence.

The IDE itself is dated and no longer competitive with the best of the modern IDE's. The language and API however is updated and productive. You just need to get over Pascal-style syntax instead of C-style, and you are just as productive in it as if you were using C#.

Why is delphi still hanging on?

1\. It delivers executables that need no dependencies. No VM's, no runtimes, no add-on dll's. Underneath it only needs x86 and win32 (unless you're building for mac, android or iOS, which it also supports). I wouldn't be surprised if our software still ran on windows 2000. Since the code is native, performance is never a problem even with wildly inefficient code.

2\. It lets you build GUI software _really_ quickly. Productivity in delphi for someone used to it matches any "modern" GUI development platform. Sure, the IDE misses a few features that competing IDE's have, but on the plus side it compiles ridiculously fast (a full build of 2 million lines takes less than a minute on a single core).

3\. Delphi is the easiest platform by far to have legacy code on, because the maintenance cost is very low. Delphi's contemporaries (classic VB, MFC) have all gone through major upheavals. Delphi has managed to modernize the API's without breaking legacy code too badly (they even managed to elegantly retrofit unicode into the platform). This is why codebases that are based on Delphi somehow never get ported away from it.

Delphi's competitive with other desktop and mobile development platforms, even at what they're charging for it. What they're charging for it is the problem though. Only people already using delphi buy delphi, and so the perception is maintained that delphi is effectively dead, even when it isn't.

<comment><USER4> The great thing about Object Pascal is that, unlike C or C++, it was designed to compile really fast. Pascal units completely remove the burden of C++ header files. In the end, you are almost as productive as with a dynamic language and you still have compiled code. I haven't seen another language to get even close to the balance achieved by Delphi in this respect.

<comment><USER5> Have you heard of Nimrod? ([http://nimrod-lang.org](http://nimrod-lang.org))

Compile-time wise it is very impressive (the compiler which is self-hosting compiles in under 30 seconds on my computer). It also resembles Delphi and Pascal in some ways and I am personally very productive with it.

<comment><USER6> Even C++ compilers (except gcc) mostly compile themselves in under 30 seconds. How is that impressive ?

Delphi compiles source code almost as fast as it can read it from disk. Megabytes of sourcecode per second on a 486.

<comment><USER7> Which C++ compiler compiles itself in under 30 seconds on a typical desktop? Clang takes at least a minute or two even at -j40...

</comment></comment></comment></comment></comment><comment><USER8> If you want to try Delphi Lazarus with Free Pascal ([http://www.lazarus.freepascal.org/](http://www.lazarus.freepascal.org/)) makes for a pretty close FOSS reimplementation of the same Object Pascal language and the RAD IDE functionality. The IDE is reasonably mature but sadly not fully compatible with Borland Delphi 7, so you can't quite rely on a Delphi tutorial. It is cross-platform. The language combines reference counting and manual memory management, has modules and handling strings in it is pleasant compared to (vanilla) C or even C++ (which it is meant to compete with). Unfortunately, last I checked the Unicode support was imperfect.

One thing I've been wondering about lately is if Free Pascal is a good alternative to C or Go for shipping self-contained static binaries to run on *nix. I haven't tried it yet but the small(ish) static binaries the Free Pascal compiler produces and the lack of libc dependencies in theory make it an attractive option if you want to write something to run on OpenWrt on your router. Has anyone here used FPC for that? How are the MIPS and ARM backends?

<comment><USER9> Adding my 2c to this discussion:

I saw just recently, via SourceForge's email newsletter, that Free Pascal made it to SourceForge Project Of The Month (POTM):

[http://sourceforge.net/blog/april-2014-project-of-the- month-...](http://sourceforge.net/blog/april-2014-project-of-the-month-free- pascal/)

I've used various Delphi versions, a little, for personal projects [1], off on on, and liked it. A pity that the free Turbo Delphi Explorer version was discontinued. (TDE was released and then stopped when Borland was in its CodeGear incarnation some years ago.) As others have said, hope Embarcadero comes out with a low-end free or low cost version of Delphi. (They did have a Delphi XE Starter Edition, not sure if it is still there.) I've also read off and on that Delphi (and other Borland products) were/are big in Germany and other European countries.

[1] [http://jugad2.blogspot.in/2010/08/digital- clock-v10-in-3-lin...](http://jugad2.blogspot.in/2010/08/digital- clock-v10-in-3-lines-of-delphi.html)

<comment><USER9> Re [1] above: Image of the digital clock gone from the post, sorry. But it was just a narrow horizontal window with a text box in it, that showed the current time, updating every second, something like the LED digital clocks you see at railway stations or airports.

</comment></comment></comment><comment><USER10> I wrote DDJ's first review of Delphi back in 1995. Maybe it deserves to die, or not, but I get a kick out of the fact that it is still around and sparking discussion. At the time of release its features were quite innovative, and very accessible to the Turbo Pascal programmers (like me!) who were a big part of Borland's customer base for tools. If I recall correctly a lot of Delphi's DNA ended up in C++ builder, and then a lot of the C++ Builder guys ended up at Microsoft... so Delphi has earned its place in the anthropology of our business.

<comment><USER11> Awesome ... appreciate your perspective. Hang around here and keep us kids in line.

</comment></comment><comment><USER12> Software has got to be one of the most interesting industries, where among genuinely skilled people you can have such shockingly divergent opinions on really quite simple questions.

From the article:

> Being highly productive has seen single Delphi developers produce software > that would otherwise require a team of 5 developers. I've been in a team of > 3 developers that out programmed a corporate wide application by having it > up and running in a few months compared to another team I know of over 30 > Java developers who 18 months later still had not produced their > application.

I believe this to be completely true. At least for boring internal enterprise apps within corporations, the new languages/platforms and especially modern program design paradigms with their multiple tiers & supporting libraries, multiple levels of indirection resulting in 30 level deep call stacks, etc results in productivity perhaps 1/4 of what you could achieve with a product like Delphi.

Now this is just my opinion, and it is shared by many others, but there are even more who would vehemently disagree. Yet this isn't some "eternal mystery" class of a disagreement, _for the type of application that Delphi is appropriate_ (very important), it can be very easily demonstrated if it is or is not more productive for the task at hand - the differences are so stark that the conclusion is undeniable. Yet, if you were to propose Delphi as a development platform, it would in most cases be career suicide.

I would suggest some of the main reasons for this are:

\- as a developer, choosing Delphi is virtually career (skillset) suicide

\- it lacks much of the more modern "cool" language features developers so love to play with

\- (as a result) choosing Delphi as a platform is risky due to the small and shrinking developer base

<comment><USER13> > for the type of application that Delphi is appropriate

What type of application is that, in your opinion? Would you use it for a web- based app? (Many boring corporate apps are now web-based, and not just because the developers want that. The business people often want it too.)

> new languages/platforms and especially modern program design paradigms with > their multiple tiers & supporting libraries, multiple levels of indirection > resulting in 30 level deep call stacks, etc results in productivity perhaps > 1/4 of what you could achieve with a product like Delphi.

Modern _languages_ don't particularly encourage or discourage that style of programming. Let's assume we're comparing Delphi to Ruby and Python as the modern competitors for the high-productivity, just-get-it-done language. Those languages have standard libraries with rather minimalist APIs, so I don't see the bloat there.

Now, it's true that _frameworks_ in those languages, like Django and Rails, and huge and have deep callstacks and lots of indirection.

But those frameworks are big because their problem domain (dynamic web app development) is so big and complex. I challenge anyone to find a framework in any language that 1) is as powerful and flexible as Django or Rails, 2) is sanely coded, and 3) doesn't have deep call stacks or lots of indirection.

Maybe I'm way off base, and you're not talking about web development at all. I went that direction because web development is what I think of when people start talking about boring business apps.

<comment><USER12> I can't comment on the web capabilities of Delphi specifically, I'm thinking your standard boring enterprisey CRUD app with various calculations/business logic/reports, etc....thousands of new apps of these kind are written every year, nowadays typically with a web front end (regardless if that's really necessary, all things considered). For most complex applications, a client based GUI is superior for power users, the portions of the app that need widespread distribution can be implemented with a web interface.

The big difference to me is the automatic binding of data from the database through to the UI, you're "done" the requirements so quickly that the currently standard practices of "improving" things with some design patterns and what not gets skipped. It's not so much that Delphi's language capabilities are superior (other than the binding), I think it's that so much of the currently fashionable bloat is more likely to be skipped.

> Modern languages don't particularly encourage or discourage that style of > programming

I agree...this is not forced on us by modern languages, it is current culture/fashion. There are so many cool geegaws out there today, it would be a shame to not use them such that you can include that experience on your resume (to hell with the additional costs and complexity, let someone else worry about that.)

<comment><USER9> Great comment, and I agree. I'd just add that it's probably more like tens of thousands of "new apps of these kind" that are written every year ...

I'm assuming you meant the last paragraph of your comment in a sarcastic way :)

</comment></comment></comment></comment><comment><USER14> Look what Turbo Pascal/Delphi gave a PC developer in 1995:

* An insanely fast compiler

* Statically linked binaries -- no DLL hell (still important for certain kinds of applications)

* A proper module system, no need for precompiled header nonsense

* A UI framework/designer as easy to use as WinForms, at a time when the alternatives were MFC or Win32

* An easy upgrade path to 32-bit Windows

As long as you were ignorant of the world outside of a PC and Windows, it was nirvana.

<comment><USER15> The lead architect of the VCL went-on to work for Microsoft on .Net and most of the venerable (and still working, if not actively maintained) Winforms API is really reminiscent of the VCL, albeit corrupted by the win32 API leaking through.

Maybe it is rose-tinted glasses, but I remember having a significantly more pleasant experience working wight the VCL (through C++ Builder) than with Winforms.

<comment><USER9> That lead architect was:

[http://en.wikipedia.org/wiki/Anders_Hejlsberg](http://en.wikipedia.org/wiki/Anders_Hejlsberg)

I read that he got $1 million (or more?) for leaving Borland for Microsoft.

He's also worked on:

[http://en.wikipedia.org/wiki/TypeScript](http://en.wikipedia.org/wiki/TypeScript)

, Microsoft's enhanced version of JavaScript, which has been in the news somewhat lately.

<comment><USER16> This is the one thing that I will not forgive MS for. They bought the lead guy from Borland rather than compete against the product. I guess it's all fair in business, but it was a gutless defense of VB - an admission, actually - <USER2> VB wasn't up to the competition.

The summary for me is that Delphi was more productive and way better designed than VB with the performance of C. I never understood why it didn't have a broader following. My guess is that developers enjoyed the challenge of C/C++, call it an aesthetic judgement.

<comment><USER17> Myself as well. I really really liked Borland products. I had an emotional attachment to them. I got Borland C/C++ (3?) as a Christmas present shrink- wrapped one year and I thought it was the best Christmas present ever. Lots of people learned C using K&R's book - I learned C/C++ from reading Borland's manuals.

Long story short, when MS turned the full weight of their organization on Borland and sunk them it opened my eyes to MS's corporate behaviour. That's how I learned that MS always played dirty. It set me out on the road to looking for alternatives to Windows. It's ultimately why I'm writing this in Firefox on Ubuntu.

In ref to the blog post (or whatever it is) I thought Delphi was no more. Just goes to show, here is a link: [http://www.embarcadero.com/products/delphi](http://www.embarcadero.com/products/delphi)

<comment><USER18> WOW. I had no idea.

From 1997: "Borland International and Microsoft have settled a Borland- launched lawsuit that started on May 7, 1997, in Santa Clara County, CA. In the suit Borland alleged that Microsoft had hired 34 Borland employees over the past 30 months in order to steal Borland trade secrets."

Just WOW. 34 employees.

</comment></comment></comment></comment></comment></comment><comment><USER19> Delphi was designed by the same architect that later designed .NEt. Microsoft snatched him from Borland. Borland tools were always great, but this was the era of mighty MS. [http://en.wikipedia.org/wiki/Anders_Hejlsberg](http://en.wikipedia.org/wiki/Anders_Hejlsberg)

<comment><USER15> C++ Builder made C++ on Windows so much more accessible than MS Visual Studio 4 + MFC at the time. Truly a revolutionary platform.

<comment><USER20> It was the real "Visual C++" in terms of RAD productivity. Microsoft's compiler had nothing visual about it.

C++/CX + XAML is maybe the closest it gets nowadays.

</comment></comment></comment><comment><USER21> The compiler was lightning fast, and produced fast code. The IDE was fast. It did a beautiful code/visual synchronization that _still_ hasn't been done better. It had good libraries, and did effective programming the large.

Not cross-platform, didn't have automatic memory management, though, and was never going to be able to compete with the advance of free IDEs.

About a million years ago I wrote the Delphi Container and Algorithm Library (DeCAL). Good times :)

<comment><USER20> This is one reason why I see Go compilation speed as PR.

Anyone of us that had the luck to work with tooling in the Amiga/Atari/PC world back in the day C mostly still only relevant on UNIX, knows there were a few languages with very fast compilers available.

<comment><USER22> Go's compilation speed is more than PR. It's reality when compared against what it is designed to replace. Believe me, there are several people on the Go team who fondly remember the "old" days of Turbo Pascal, for instance. But those tools just aren't around any more for practical purposes.

<comment><USER20> > It's reality when compared against what it is designed to replace.

If you mean C and C++ then yes. Not so when compared with most languages with module systems.

This is why I call it PR, because most Go presentations tend to ignore the world outside C and C++.

</comment></comment></comment></comment><comment><USER23> Delphi was one of the greatest development environment ever created when you just "needed to get shit done".

<comment><USER24> No question.

I used Delphi 5 for a long time. The IDE was as easy as it gets, the sample code on the net was rampant, and it produced single little EXE files I could send to people and they had a full-on Windows application.

The closest thing I've found since then that allows me to do something similar minus the IDE is BlitzMax, but the IDE was what made the process so silky smooth in Delphi, and I miss it.

</comment></comment><comment><USER25> I think Delphi got right the "Visual Programming" paradigm. I am surprised that we don't have something similar on newer environments. Perhaps is that multi-user RDBMS with SQL and/or the Web broke the model. I don't know, but it is an interesting question.

<comment><USER9> Also, Delphi didn't have a completely "Visual Programming" paradigm, if you mean it in the sense of some of those experimental tools that claim that all programming can be done visually/graphically, simply by drawing diagrams, dragging and dropping components onto a window, connecting them visually, etc. The visual part of programming with Delphi and similar tools like Visual Basic, was restricted mainly to designing/creating the UI, iteratively and visually, by dragging and dropping widgets like text boxes, labels, drop-down lists, gauges, graph controls, etc., onto a form (a window), setting those widgets' properties such as font, text foreground and background color, enabled/disabled, tab order, etc. etc. Also, data-aware widgets were useful; they would show the back-end database data represented by each widget, live, at UI design time (not just at run time). E.g. a grid widget could show the rows and fields of a table, live. But the rest of the code (widget event handling, business logic, etc.) still had to written in a text editor by the developer.

<comment><USER26> Not completely "visual programming" as you say, but I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.

<comment><USER9> >I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.

Yes, you're right. I found it so too. I forgot to mention in my parent comment that Delphi also generated the stubs/skeletons for the event-handling procedures. Not only was that a convenience, it helped with learning the tool and Windows GUI programming too.

</comment></comment></comment></comment><comment><USER27> I first touched Delphi as a teenager (I was 14 or 15 at the time), and it was Delphi 6. I had already tried different languages by that time.

I had already programmed in BASIC as a child and it was great, for a kid like me who didn't have Internet access and named text files to .COM and .EXE in the hope they would do something, this was awesome. But I still wanted .EXE files and I then tried Pascal, which gave that to me. I also tried few examples of C, but the code I had access to was in Pascal, and I didn't have the doc or internet, so I kept tweaking.

And then I discovered Visual Basic (in its DOS and Windows) and I was able to do buttons and forms and tigers..

Yet, with Visual Basic, there was always this bloated feeling.. I mean, you had to make an installer for your programs with files like VBRUNXXX.DLL and error messages yelling at you, and depending 16bits or 32bits, VB4 or VB6, so ... it's even fuzzy in my head.

And then I found Delphi 6. The first time I tried it, I thought "Hmm, this is Pascal !". I compiled my first thing, and I automatically looked of parasitic files VB style.. Nope. It was that .EXE..

So I took that .EXE file to another computer and ran it, and it _ran_. It didn't need any other files. I didn't have to make an installer for it with WISE or something. It just worked. I was happy.

When my brother who was in CS and was doing image processing (tumors, edge detection, etc), he did his project in Delphi and I'd hang around, and he'd ask me how to do this or that, since I started programming in it before he did, and it was so easy for him to implement stuff and build the application.

So maybe that's why it lasted so long. Easy enough for a kid to do stuff with it. It needed not a lot of knowledge to make buttons and forms, etc. I just make the layout, then program what each button does, etc.. And it was simple.

I may be a biggot, since I tried Embarcadero but it smelled nasty since it was, at least for me, an utter mess. I prefer Delphi 6. It may be nostalgia, but I don't htink it's _only_ nostalgia.

</comment><comment><USER28> Delphi is a great RAD tool, but it's also slowly dying and has lower and lower market share, 100% of my income come from Delphi contracting at the moment, and I love Delphi, but its not a great choice if you're just starting your programming career and have to choose the language to go with. I've been sticking to Delphi for whole my programming career (3 years professionaly, 10+ years hobby programming, i'm 24 now), but its more and more occuring to me that I have to learn some new tech ASAP if I want to progress further. Delphi has no proper crossplatform support and it's a big minus. Also it has ridiculous price.

<comment><USER29> Was once in a similar situation myself. One path is to identify a future customer pain point that will occur if they continue to use Delphi. You can direct the solution to a language/platform you wish to learn, and work like a dog to develop the new skills and build a great piece of software in this new language.

<comment><USER28> Thats exactly my plan, to learn some basics then further improve skills on minor contracting jobs I get and I feel comfortable to do them in new language. It would probably be C++.

<comment><USER30> If you're looking at C++ already then I'd recommend Qt. I think it's pretty close to the RAD feeling I remember from C++ Builder and by extension I assume Delphi.

Compared to them it's not strong on data components that allow you to connect a DB to a UI, you will have to write SQL and code for that. But it is a joy to use, cross-platform and at least on the desktop it is free to use if you don't mind LGPL and shipping DLLs/so with your app.

<comment><USER31> Don't learn Qt if you want to find clients.

<comment><USER32> Care to elaborate? Assuming C++ and UI development of course.

<comment><USER31> Enterprises are not using Qt.

<comment><USER20> They are in factory control tools and in-car automation systems, for example.

Although the latter are starting to use J2ME systems as well.

At least that is my feeling from job posts here in Germany.

<comment><USER31> The grandparent is a consultant, how many of this niche is hiring consultants? What are his chances of having steady (consulting) work using Qt? Let's be reasonable, he has a better chance learning MFC (not that that's a good idea either).

<comment><USER20> Given how Germany is following USA footsteps of outsourcing and offshoring everything in Fortune 1000, maybe there are some opportunities.

In Germany's case mind you, not sure about other countries.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> In terms of job availability it's been dead a long time. I see a single job posted on craigslist every 6 months in city with 50 daily job postings.

Part of the problem is the kind of corporate windows CRUD apps that Delphi excelled at are better implemented as web apps. Which leaves it relegated to hobby developers and 1 man software vendors.

Even weirder is that in 2002 the Delphi community developed a python 2.7/3 type schism over UI changes and .NET inclusion and a large portion of the community refused to adopt new releases. It's pretty telling when a vendor isn't even able to get many of it's own supporters (many of which are these "Delphi will never die" types) to buy new version of their software in over a decade.

<comment><USER34> The insanely high prices aren't helping either though. Yes yes, they are not 'high' if you are a fortune 1000, however, they are high compared to what everyone is used to now. They didn't step on the train of making for instance a version free if you are an open source dev. Or doing low monthly payments. Or do anything 'cool', like turn up and give a demo on how to implement reactive manifesto complaint software client/server with a few clicks / lines of code. That kind of thing would be relevant and interesting to devs _now_ ; if you can do a dashboard in Mac OS X, Windows, iOS, Android with all the backend & frontend stuff smoothly working together, smoothly tested and smoothly deployed, showing off those 6000 datapoints per second coming into the server and the client and still have a responsive interface companies would listen. But they don't; they just don't 'do' anything people want now besides turning up to the mobile parties way too late.

I kind of wonder how many devs still are working on Delphi and if they are not only just bugfixing...

<comment><USER35> I think Embarcadero is seriously hurting themselves with their bunker mentality.

Their whole "there are only X paying customers left, therefore we need to charge $3000" stinks of someone who is preparing for failure, instead of growth.

It really looks like low self-esteem play of some group that secretly believes the market doesn't want what they have, so they desperately milk their few remaining customers to make next months payroll.

I keep hoping some startup sees the huge arbitrage opportunity that is sitting there. Someone just needs to come along and build a quality GUI around the toolchain - very much like what Xamarin did for Mono - and similarly they need to charge a sane subscription model (free for OS/hobbyist, $99 personal dev, $399 corporate lite, etc).

</comment></comment></comment><comment><USER36> I spent the first years of my non-school life developing things in Delphi, including CGI binaries in the end. I can't say how much I loved the language and the IDE. In fact, XCode is still somehow trying but falling far short of providing the same amenities for developers (maybe on purpose).

Since I rediscovered dynamic languages in the early 2000s and haven't (except for some experiments in C) looked back.

It's funny how you can selectively remember the good aspects of a language and forget how much better life has become since you dumped it. Out of nostalgia I checked out Lazarus and I'm glad it has a somewhat thriving community. However, for me it was clear immediately that the time of Delphi/Pascal has passed for good.

<comment><USER37> Can you describe what things Xcode lacks that you miss from Delphi? I'd be interested in learning more about such features.

<comment><USER38> Smart commenting/uncommenting (depends on indentation in Xcode) Expanding case statement for enums (not implemented) Renaming does not work for commented .h and .m file name No shortcuts are shown in hints (debugger step over/into...)

</comment></comment></comment><comment><USER39> Having supported Delphi applications I had to say:

1) It just works;

2) It works in old machines fairly good enough

3) There is a lot of new components/integrations (SQL,DB2,Oracle,WEB,etc)

4) Good reports system

It isn't sexy but do the job very well for most corporate applications.

<comment><USER40> I remember when it was sexy - in the days of Windows 95-98 - that was the best RAD tool out there.

</comment></comment><comment><USER41> I used delphi extensively in the mid 90's, from the 1.0 release until about 2001. Those were probably some of the most enjoyable and productive times of my life.

IMHO, nothing comes close to the syntactic clarity of object Pascal. This has a ton of knock on effects for long term maintainability.

Plus, the early versions of the Delphi component model were insanely clear and well documented. My first delphi program was a reimplementation of a 6 month long (4 programmer) access database/vb application. I completely reimplemented a 2 man year project in about 24 hours with it using little more than the help docs. After a quick demo at work on Monday, everyone pretty much agreed to kick MS Access/vb to the curb and pick up my code base.

The data aware components were a life saver, and to this day programming in a wide range of languages I am constantly reminded how painful doing things that were simple 20 years ago is. It drives a fundamental distaste into my mouth every time I'm hacking an AJAX app to do basic sorting/filtering of a simple result set. Usually doable with delphi in a matter of a few mouse clicks.

Plus, by the late '90s there were a ton of 3rd party component libraries that nailed just about every GUI interaction an average program might need. The integration of reporting components made generating nice paper printouts a snap too.

So, this is probably why its still being used. Reimplementing a delphi application of a hundred thousand lines is probably a thousand man year project with a "modern" web stack. And so, much like the mainframes running in the data centers of banks/insurance/etc companies, delphi is probably still driving a fair number of business logic applications. I know that some of the applications I wrote in the 90's are still in use at government agencies.

BTW: I used BC builder too, and hated it even though I tend to like C++. The C++ syntax was simply to unwieldy vs pascal.

I have periodically tried out more recent version of delphi or lazurus [http://www.lazarus.freepascal.org/](http://www.lazarus.freepascal.org/) and they don't seem to be nearly as elegant as the early versions. Seems all the effort to make it cross platform (kylix) or match up with the .net component models cluttered up the early clarity of implementation.

</comment><comment><USER42> I look at tools for DOM manipulation right now - and I look at what people dream of doing with the DOM, especially with apps.

Then I think back to what Delphi was doing in early 90s - then I wonder if just some of that magic was available for building apps on the DOM we'd be in a better place.

<comment><USER20> This is why kids these days jump into web development, they aren't aware how good tooling we already had back then.

</comment></comment><comment><USER43> To add my two cents, here's a piece I wrote on why I use Delphi/Object Pascal a few years back

[http://screamingduck.com/Article.php?ArticleID=43&Show=ABCE](http://screamingduck.com/Article.php?ArticleID=43&Show=ABCE)

Now that time has moved on, I no longer use Delphi at all, and rarely use FreePascal. My currently active projects are C, Node.js, and Browser Javascript. For game projects I prefer Haxe. For future large scale projects. I'm eyeing Rust. When the time comes I'll probably be weighing up the relative maturity of Haxe and Rust. They are developing from different directions, Rust being more idealistic and Haxe being more pragmatic, but I think they'll grow aspects of the other over time.

</comment><comment><USER44> I remember the same feeling with VB6/VC6. Sure, with VC6, you could do More Stuff, and theoretically, it would be Better Stuff. But in an afternoon with VB6, I could bang out a good first prototype for SO many projects that in many cases, ended up being "good enough" that we never needed to go back and re-do it "properly" in VC6.

PowerBuilder, though... Man, that can't die fast enough.

<comment><USER34> That's how I sold Delphi; I applied for VC projects and then talked them into a 'fast prototype' in Delphi. They never rewrote and I had happy clients for many years. It worked especially well in companies who where forced into VC by higher management and already did a few (long, painful usually) projects in it; they could now show off something much faster and with more features.

</comment></comment><comment><USER45> Delphi had one of the best and most useful help documentations I've ever used. In my eyes it was a huge winner for Delphi over Visual Studio products, although I never really liked the pascal syntax...

<comment><USER46> Delphi/Pascal and Wolfram mathematica are the two things I point people to when we talk about documentation.

Every single function had a working snippet example. Mathematica had details and applications for each function, while Delphi/BP had a well written explanation of what the function would do and how to use it.

They are the standards that have not been surpassed yet. Or even approached imho.

These days you get an auto generated docstring explaining that xval is "the x value passed to the function".

</comment></comment><comment><USER20> One of the great things about Delphi and its predecessor Object Pascal were, besides what other HNers have mentioned, was AOT compilation, being memory safe and allowing systems programming at the same time.

No need for VMs.

Luckly Go, Rust, D and now .NET Native might make younger generations aware of it.

<comment><USER47> Object Pascal is not the predecessor to Delphi

Delphi is the IDE and compiler, Object Pascal is the language (Free Pascal Compiler and GNU Pascal are two other compilers, both exhibit the same quick and safe compilation).

<comment><USER20> > Object Pascal is not the predecessor to Delphi

Object Pascal was designed at Apple as their extensions to Pascal while using it as system programming language to develop the first versions of Mac OS.

Afterwards, Borland extended Turbo Pascal with Apple's agreement and then Turbo Pascal 5.5 was born.

After the initial versions of Delphi, the Borland marketing team decided it was a bit confusing to have Delphi and Object Pascal as names, and decided to start referring to the language as Delphi as well.

I was a Turbo Pascal user since version 3.0 all the way up to the first versions of Delphi.

<comment><USER47> Yes I'm quite aware of the history but the fact that borland/embarcadero choses to call both delphi doesn't really change what I said though, every where besides the marketing of this IDE clearly considers object pascal [1] as the language (with several implementations/compilers), and delphi [2] as the IDE.

Delphi's own documentation, once you're past the marketing naming on the box, makes it clear that the language is object pascal.

[1] [http://en.wikipedia.org/wiki/Object_Pascal](http://en.wikipedia.org/wiki/Object_Pascal) [2] [http://en.wikipedia.org/wiki/Embarcadero_Delphi](http://en.wikipedia.org/wiki/Embarcadero_Delphi)

<comment><USER20> So it seems I need to post some links to official documentation.

<quote>The Delphi Language Guide describes the _Delphi language_ as it is used in RAD Studio development tools. </quote>

[http://docwiki.embarcadero.com/RADStudio/XE6/en/Delphi_Langu...](http://docwiki.embarcadero.com/RADStudio/XE6/en/Delphi_Language_Guide_Index)

<quote>Delphi is a high-level, compiled, strongly typed language that supports structured and object-oriented design. _Based on Object Pascal_ , </quote>

[http://docwiki.embarcadero.com/RADStudio/XE6/en/Language_Ove...](http://docwiki.embarcadero.com/RADStudio/XE6/en/Language_Overview)

The current language is based on Object Pascal, which is quite different from being Object Pascal, which was quite different back in the Turbo Pascal and early Delphi days.

I don't know Delphi and Turbo Pascal history from Wikipedia, I lived through it, from Turbo Pascal 3.0 up to Delphi version 3.

</comment></comment></comment></comment></comment><comment><USER48> I always gravitated to it because it was a fantastic painless (mostly) wrapper for the beastly win32 API. As a unix programmer, it was great when I "just needed a quick windows GUI" for something.

Delphi has been my secret weapon for more than a decade now.

<comment><USER6> I loved it for that too. It's amazing how much easier most things are in Delphi. Yet everything remains possible. I wrote a windows application firewall in Delphi, and that worked. Man that was a great experience.

</comment></comment><comment><USER49> I always wondered why a devshop I've worked at used Delphi. Now I know. The main code base is handled by one developer.

</comment><comment><USER40> Does anyone... Turbo Vision!!! Oh, the memories! and "Uses BGI"

</comment><comment><USER38> I have been Delphi developer for more that 15 yrs. I had 2 shareware apps, one of which is still selling (very well). But now I work in Objective C. Xcode is much better IDE (Delphi is 32 bit, and crashes often with big projects). I will probably continue to do Delphi, on the side, but iOS and OSX are my main domains of interest. Delphi devs are old, no new fresh blood, no jobs available, no new books are being published. Online material is mainly marketing, no useful blog posts, new frameworks, package managers.. Delphi is great for people that have been using it for ages, but with the current pricing, and no 'community' edition, it will not attract new developers.

<comment><USER50> I agree with most of your sentiments, but no new books and no new frameworks isn't completely true. For example, I just started reading Coding in Delphi ([https://leanpub.com/codingindelphi](https://leanpub.com/codingindelphi)) which describes a few current efforts. Still I'm hesitant to make use of those, because they would further lock me in with Embarcadero; sticking to what's in Delphi 2010 itself at least allows for a relatively smooth transition to Lazarus at some point. I haven't given up on the principles of Delphi yet, but I have on Embarcadero.

</comment></comment><comment><USER51> I completely identify with this poster. I inherited an app written in CA Clipper (a language from 1987) It became FoxPro. I had to learn those ancient technologies. Surprisingly, I really enjoyed it. I loved those old terminal/DOS apps. Around 1999, we made the decision to migrate the entire app to Object Pascal/Delphi/Kylix/InterBase/FireBirdSql. It was an incredible effort. I loathed, yet loved it. What I learned during that year STILL comes back from time to time in my current development projects. Kinda makes me feel old! When I started doing C#, I felt quite at home. Apparently, the guy who did Delphi, got hired at Microsoft.

</comment><comment><USER52> And why should it? It may not be trendy but it's a really quality environment for its use case.

I only wrote it as a hobby as a teenager but compared to trying to write Visual Basic or C or Java on Windows it was a real dream. As a hobbyist the absolute most important thing was seeing my effort actually materialise in front of me and to that end it was amazing. And Pascal is a dream compared to C for slightly-higher-than-C level stuff.

I loved it and I hope it sticks around. I just took another look and it compiles applications for Windows, OS X, Android, and iOS. Maybe I should give it another go some time.

</comment><comment><USER53> Delphi 3 introduced me to programming in my teen years. Somehow that's why I never dived in C I guess. I remember how you only had to dealt with pointers when you used Windows API.

It took years to Microsoft to get the web right (as everyone who used Visual Studio and .NET before MVC could tell you), it's no wonder it was difficult for a company like Borland to transition.

As a PHP developer I wonder why I never tried that "Delphi for PHP".

Coincidentally I interned at Borland France during my marketing years ten years ago and developers were really passionate about Delphi.

</comment><comment><USER54> "With very few exceptions, technologies don't die. In this way they differ from biological species, which in the long-term inevitably do go extinct. Technologies are idea-based, and culture is their memory. They can be resurrected if forgotten, and can be recorded (by increasingly better means) so that they won't be overlooked. Technologies are forever." \- Kevin Kelly [1]

[1] [http://kk.org/thetechnium/2006/02/immortal- techno/](http://kk.org/thetechnium/2006/02/immortal-techno/)

</comment><comment><USER55> I did a contract that involved some Delphi not long ago. I was really surprised to see it still in use. The worst thing, though, was registering to get a trial from Embarcadero who then had an elaborate follow-up process including phone calls from them. And after all that, the code in question wouldn't compile with the new editions of Delphi and I had to track down a copy of Delphi 6.

I was really surprised to discover they still have a C++ compiler product. Does anyone use it?

<comment><USER56> I used C++Builder at a previous job. All their software was C++/VCL, they were completely locked in. Embarcadero tried to keep up with the evolving C++ standard and on paper they were moderately successful, but if you actually tried to program in a modern style, it all fell down. E.g. you'd find an object's destructor was ignored, or even worse, run twice. I think I reported about two dozen compiler or C/C++ library bugs.

</comment></comment><comment><USER57> I loved Delphi back in 1997. Then I moved on to Java, and never looked back. It was wonderful though, and GUIs were so easy. It wasn't my first language, but it was the first language I become truly comfortable and productive in.

My move to Java was partly because I was straddling the Windows and Linux worlds, and Delphi couldn't cross that chasm with me at the time.

</comment><comment><USER58> Why? Because it cannot just die yet! One of my most frequently used Windows app is in Delphi. Total Commander. ;)

</comment><comment><USER59> I feel like Delphi has made a recent exciting comeback to relevance. AppMethod allows development of native compiled apps for OSX, Windows, Android and iOS, all from the same Delphi code base. That's a compelling proposition.

<comment><USER26> Isn't Delphi currently hosted only on Windows? I would love to use a tool like Delphi on OSX to make apps for OSX.

</comment></comment><comment><USER60> I have recently joined a small successful ISV selling and developing a couple of Delphi apps in an industry vertical in which I have significant experience; my prior experience has been C#/.Net for quite a while, and before that Java. I recall buying the Delphi IDE way back in the day; possibly when I was still at university, definitely when Borland was still around!

So some informed observations:

1\. The quality of the IDE is incredibly dire compared to Visual Studio+Resharper or Jetbrains IntelliJ. Perhaps it will be improved if a buy a license for Castalia. That said, I've been using XE3, maybe the more recent versions are better but it seems that Embarcadero have been focusing on getting into the cross-platform mobile game (one which I think Xamarin/Phonegap/Titanium, etc are playing better) rather than increasing the quality of the tools or enhancing the language. XE6 may have some improvements under Embarcadero's "QPS" (Quality/Performance/Stability) project. We haven't upgraded our licenses since the versions since XE3 didn't bring anything for us, but if we want to see Delphi survive then perhaps we should be chucking some money Embarcadero's way!

2\. The language is quite verbose, and I find the need to declare the 'interface' for a class separate to the implementation of the methods quite cute. There's so much ceremony around anonymous methods that it hardly seems worth it some times. Lack of built-in multicast delegates for event handlers.

3\. I recently attended a local symposium put on by the user group. There didn't appear to be much diversity amongst the attendees. I would charge that lack of diversity is not a sign of a healthy software development community. Speaking with one of the organiser's, they mentioned that Embarcadero doesn't introduce new Delphi customers to the user group any more since it is just "grumpy old men".

4\. At this symposium one of the talks was on dependency injection. I was bemused that this was a new idea to the Delphi world. One of the advertisers in the symposium papers was a consultancy whose pitch basically was "so you've been making money from selling a product, but you're getting old and want to retire. Pass the source code and rights over to use and we'll work out an arrangement to continue development whilst maintaining a royalty stream for you".

5\. Packaging of open-source for easy reuse is challenging in Delphi. Unlike managed environments such as .Net or Java, reusing well-known open source components is as simple as adding an assembly or a JAR to your project (yes, I acknowledge that in the past this has had its own challenges, but I think in the .Net world at least Nuget has largely conquered this). The native binaries nature of Delphi has meant there is no such equivalent (that I'm aware of), although I'm considering leveraging Nuget's packaging format and tools for BPLs.

<comment><USER61> Re #1, Castalia is very slow fews years ago I tried, it's the ModelMaker Code Explorer that adds a lot of productivity to the IDE, including refactoring, and so on. Plus GExperts and GNPack.

<comment><USER60> Thanks for those recommendations, I'll check them out.

<comment><USER61> GNPack should be CnPack

</comment></comment></comment></comment><comment><USER62> Everybody else seems to love it, even compared to Java.

I can't help but think of using three days to collect and compile all dependencies for a legacy project.

At that point at least I'd take Java and maven any day.

</comment><comment><USER63> dealing with Delphi as a product more than programming language hurts the Delphi community. I mean Embarcadero should give away some (freebies) to the community. like a free/express Delphi version. I think this will refresh its community and the Delphi empire would rise again.

<comment><USER20> They did, but they were not consequent with them so the developers lost trust.

</comment></comment><comment><USER64> Does anyone know more about PeopleCode and their PeopleSoft tools and IDE and how it compares?

<comment><USER65> PeopleSoft was hostilely acquired by Oracle in 2005, after which, despite Oracle trying to kill it for years (and merge the Peoplesoft product into Fusion), it still exists.

PeopleCode/Tools is more equivalent to ABAP offered by SAP, it's heavily tied to the Peoplesoft environment, and has no real comparison to Delphi.

Amazing that you can still find it around these days, but most PeopleSoft customers have moved to Oracle, SAP or Workday by now.

</comment></comment><comment><USER66> Reminds me of ColdFusion. It should be dead, but it's not.

</comment><comment><USER67> The COBOL of the future?

<comment><USER68> Scott Adams could make the same joke again [http://dilbert.com/strips/comic/1997-11-04/?CmtOrder=DateEnt...](http://dilbert.com/strips/comic/1997-11-04/?CmtOrder=DateEntered&CmtDir=ASC)

<comment><USER69> I dont think so. Java is the new Cobol. [http://c2.com/cgi/wiki?JavaIsTheNewCobol](http://c2.com/cgi/wiki?JavaIsTheNewCobol)

<comment><USER51> I'd say Java 1.2 is the new COBOL. Just like COBOL devs were in serious demand during the "millennium crisis", Java 1.2 devs will be in demand the next time we have some sort of fundamental upheaval. This is due to so many banks/utilities/etc betting the farm on older Java. Judging just by current job postings, Rails 3ish might be entrenched for a short while too.</comment></comment></comment></comment>


How to debug your mind - <AUTHOR> http://www.stevenaitchison.co.uk/blog/2009/08/17/9-ways-to-debug-your-mind/

<comment><USER2> DEFECT12655: Blog poster stretches metaphor beyond the breaking point. Runtime exception.

<comment><USER3> As if that weren't enough, he actually mixed two metaphors: debugging the code and using a computer.

</comment></comment><comment><USER4> The author's mind is beyond debugging, and needs a complete rewrite.

</comment><comment><USER5> Ok, it may not be a perfect, or even a close to perfect parallel, but it does get the point across. I for one am guilty of spending way to much time running around doing stuff instead of stopping and spending time processing what really matters. A mental "defrag" if you will.</comment>


Citra: An Experimental 3DS Emulator - <AUTHOR> http://citra-emu.org/ <comment><USER2> I'd really like to read about their experience with the emulators performance, profiling and how the work with that aspect.

I remember an old emulator for the DS (can't remember the name though!) that got a massive speedup going from 0.9 to 0.9.1 (the numbers might be wrong, but it was a "minor update"). The guy developing it had found some innocent looking code near the critical loop that was actually crawling like a snail and replaced it with some other innocent looking code that worked a lot faster.</comment>


SpaceX Falcon 9 Statement on First Stage Engine Anomaly - <AUTHOR> http://www.spaceref.com/news/viewsr.html?pid=42263

<comment><USER3> Note additionally it's being reported that the secondary payload on this flight, an Orbcomm sat, did not get deployed into the correct orbit because the Falcon upper stage insertion burn failed. No info on whether or not this was a related failure. Info at the moment just seems to be social networks, can't find anything more solid: <https://www.facebook.com/jsrpage/posts/10151048911726680>

<comment><USER4> Bad Astronomy [1] has a comment saying the Orbcomm satellite is a test unit (not the production unit yet) and that a second-choice orbit is possibly where it will be released.

[1] [http://blogs.discovermagazine.com/badastronomy/2012/10/08/sp...](http://blogs.discovermagazine.com/badastronomy/2012/10/08/spacex- falcon-9-lost-an-engine-on-the-way-up-dragon-on-its-way-to-iss/)

<comment><USER3> I read it as that they have already deployed rather than will be. But yes, the comment seems to suggest that the idea of trying to put it into the nominal orbit was abandoned, the speculating being that the 2nd stage had to burn for longer to get the dragon/ISS primary payload as it should be, and so not leaving enough fuel left over for the secondary payload nominal insertion. That sounds plausible, but equally SpaceX haven't said anything so it's all just armchair speculation, which is fun anyway.

</comment></comment></comment><comment><USER5> " I believe F9 is the only rocket flying today that, like a modern airliner, is capable of completing a flight successfully even after losing an engine."

Brilliant! By equating the rocket with an airliner (the statistically safest way to travel), this turns what could be a mark against into a huge mark for.

<comment><USER6> While this is indeed an awesome feature to have, it doesn't by itself mean much. The total reliability of course also depends on the probability that one engine will fail, a rocket that needs all its engines may still be more reliable than one that is capable of of flying with two failed engines, but regularly has to do so.

What makes the airliner seem safe is that it can fly with a failed engine _and_ it very rarely loses an engine.

I guess we will have to wait for some more flights till we have decent statistics on the reliability of the Falcon 9. Of course, I'm hoping that it will turn out to be an awesome rocket!

<comment><USER7> For whatever it may be worth, it seems right now the engine failure rate for Falcon 9 is 1 in 27.

<comment><USER8> Is there a similar rate known for regular jet engines?

<comment><USER7> No idea. I am sure it is astronomically small though.

<comment><USER3> A lot of Western aviation qualifying authorities specify a maximum allowable mean time between failure (MTBF) of 1 per 100000 flight hours. I imagine most rocket engine designs would be more like one per hour! That said, they only have to operate for about ten minutes though before they are disposed of, in the case of expendable launch vehicles.

In Falcon 9's case, and totally from memory and probably incorrect and very approximate, we've had 4 launches, each has had 9 Merlin C engines on the first stage, the first stage burn time is 170s or about 3 minutes. There have been two failures - a non destructive engine shutdown on the previous ISS mission on the pad at T-very_little, and the rather more messy rapid disassembly failure of something near the engine or the engine itself on the most recent launch.

So, for this first stage engine the MTBF (remember this is all a bit silly and inaccurate and just for ballpark comparisons with the airline industry) the MTBF has been:

9(engines/launch) _4(launches)_ 0.05(3 min burns in hours)*0.5(2 failures) = 0.9, i.e. a MTBF of 55 minutes for Merlin 1C lower stage, vs most regulators requiring mtbf > 100000 hours on commercial jet airliner engines.

So there's a bit of a way to go yet!

<comment><USER9> I agree that there is plenty of room for improvement, but you can't launch a rocket with commercial jet engines.

I don't know if it makes sense to normalize for thrust or not, but it seems like thrust should be included somehow.

<comment><USER10> They're not saying, "commercial jet engines are more reliable; therefore we should use them". The issue is that the Merlin 1C engine simply hasn't had enough flights to build up its denominator.

It doesn't make sense to normalize for thrust here. This is just failure rate. There's nothing wrong with having a comparatively high failure rate when the sample size is several orders of magnitude smaller: the statistical significance is just weaker; we acknowledge that and move on.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Doesn't seem to be the whole story, since the video clearly shows a significant amount of debris. A simple shutdown wouldn't produce debris, although the loss of internal pressure on the engine bell could cause it to collapse and possibly disintegrate.

I look forward to seeing a more complete analysis.

<comment><USER12> From what I understand, engine exhaust is too hot for any material to withstand without active cooling, which is done as a side-effect of feeding in the fuel. If you just turn it off, then, it's no longer actively cooled, and will rapidly melt from all the other engines around it still going full bore.

This is just a theory.

<comment><USER13> The engine exhaust is very highly directional, it doesn't just go everywhere. For example, the supporting structures around the engines are exposed to the same level of exhaust as a shut-down engine would be, and they are completely uncooled.

</comment></comment></comment><comment><USER14> Here's the latest statement from SpaceX:

SpaceX CRS-1 Mission Update: October 8, 2012 [http://www.spaceref.com/news/viewpr.html?&pid=38825](http://www.spaceref.com/news/viewpr.html?&pid=38825)

"Approximately one minute and 19 seconds into last night's launch, the Falcon 9 rocket detected an anomaly on one first stage engine. Initial data suggests that one of the rocket's nine Merlin engines, Engine 1, lost pressure suddenly and an engine shutdown command was issued immediately. We know the engine did not explode, because we continued to receive data from it. Our review indicates that the fairing that protects the engine from aerodynamic loads ruptured due to the engine pressure release, and that none of Falcon 9's other eight engines were impacted by this event."

No explosion according to them.

</comment><comment><AUTHOR> More info and a video from The Bad Astronomer (Phil Plait): [http://blogs.discovermagazine.com/badastronomy/2012/10/08/sp...](http://blogs.discovermagazine.com/badastronomy/2012/10/08/spacex- falcon-9-lost-an-engine-on-the-way-up-dragon-on-its-way-to-iss/)

</comment><comment><USER15> "There was no effect on Dragon or the Space Station resupply mission." - <USER2> Musk

Just for those who didn't closely follow the events.

</comment><comment><USER14> I think we'll see an expanded statement later today when they've had time to analyze the data more thoroughly.

<comment><USER16> I would hope that it would be later than later today, and that they would take an appropriate amount of time to analyze all the data...

<comment><USER14> There will be a full investigation however the video clearly shows more than just an engine shutdown. Something else happened and this needs some clarification. There's a lot riding on this mission both politically and financially.

<comment><USER16> Yes, and it is for that reason that I hope they take their time. SpaceX is very much a pioneer in this space, and how they handle each situation will set the benchmark, for better or worse, for those that come after.

I thought the way they handled the launch abort during the last mission was done very professionally. Likewise, I hope they handle this situation in a manner that underscores the complexity of putting things in space, but also instills confidence that they are up to the task. If they have to walk back any early mis-diagnoses, it could tarnish their image more than a delay in releasing the full details.

</comment></comment></comment></comment><comment><USER17> How many engines does it take to cause failure?

<comment><USER18> I believe Falcon 9 has 2 engine out capability.

<comment><USER19> probably not _any_ 2 engines though, right? I'd guess if the two engines on one side fail it can't recover, since it could only proceed with 1/6th capacity through the middle engines. (They have 6, right?)

<comment><USER20> I'm not familiar with the specifics of Falcon9 redundancy. But in theory, losing many engines can be completely recoverable, because all 9 engines share a single fuel tank.

Outside of atmosphere, a rocket's final speed and orbit depend on three factors: the mass of the payload, the mass of the fuel, and the inherent engine design efficiency. Notably, it does not depend on _thrust_. Burning one engine for 9 seconds results in a speed boost equal to burning 9 engines for 1 second.

Even if an engine fails and another one is set to reduced thrust, the fuel is still there, and can be burned by remaining engines.

Of course, this is a huge simplification, and loss of thrust while still in atmosphere or near the ground might be a problem.

<comment><USER21> I think thrust counts to a degree, as you'll lose velocity from gravity drag if the time to orbit is too high. The degenerate case would be if your thrust is less than the weight of your rocket (i.e. not moving).

</comment></comment></comment></comment></comment><comment><USER22> everybody interested in why rocket engines have the amazing ability to turn thrust into fireworks when least expected should read this excellent book on rocket propellant history: <http://library.sciencemadness.org/library/books/ignition.pdf>. to spark your interest, foreword was written by isaac asimov.

<comment><USER23> This thread is pretty cold by now but I wanted to thank you for the link to Ignition — it's a really neat window into some of the chemistry and practice of 20th century rocketry. Reminded me of Max Gergel's "Excuse me sir, would you like to buy a kilo of isopropyl bromide?" [http://library.sciencemadness.org/library/books/gergel_isopr...](http://library.sciencemadness.org/library/books/gergel_isopropyl_bromide.pdf) which, now that I look at the link, is hosted at the same server.</comment></comment>


Show HN - socl.in - <AUTHOR> http://www.socl.in/ Social twist to calendar+todo list - http://www.socl.in/ A few good social features - still in very alpha stage, your comments are welcome. <comment><USER3> You badly need a screencast or image-slideshow on there - show, not tell!

I had to force myself to read through that text-pitch - under normal conditions I'd have closed the tab after the first 1-2 sentences. Partly because it's not well written and partly due to the fancy font that makes it hard to read.

<comment><AUTHOR> Thanks, screencast is almost complete. Thanks for reviewing the text too - <USER2> will try to change it asap..

</comment></comment><comment><USER4> Your description text needs help, particularly the first sentence:

 _Socl is the social calendar and to-do list. Your calendar events will be posted to your social world(only if you wish)_

1\. Socl is not _the_ social calendar, it is _a_ social calendar. I don't know why the "-ial" in _social_ has a strikethrough. 2. You need a space between the end of "world" and the beginning of the parenthesis. 3. _Socl is in its early stage - something like a pre-alpha._ Wait, "something like" pre-alpha? I think you mean "pre-alpha", right? It would be much more succinct and better in every way to simply say, "Socl is in pre-alpha release" or, alternatively, "Socl is pre-alpha."

<comment><USER5> Only the "ia" has the strikethrough. I think it's to show that the product name "Socl" = "Social" - "ia". I agree that it is confusing though.

<comment><AUTHOR> Agreed..changed.

</comment></comment></comment><comment><USER6> Google groups for feedback? Really? You have to make it easier than that.

<comment><AUTHOR> Sure, can you suggest a better way ? will a internal support forum help. Google group was just a quick way as I did not have much time...thanks for review.

<comment><USER6> You can use the uservoice/getsatisfaction widget.

Also, do checkout <http://supportbee.com> (we are working on it right now so only beta signup)

<comment><AUTHOR> Thanks let me check getsatisfaction.

</comment></comment></comment></comment><comment><USER7> What's up with the growing blue thingy (click anywhere)? It causes the form to shift downward, and I don't get the point at all.

Also, "sign-in or signin using..." is awkward. Finally, the drop-shadow and strike-through (soc-ia-l) is a bit much.

</comment><comment><USER8> Just signed up. Neat application. I like the colors.

1\. The font makes things hard to read. Have a clear font.

2\. When I say "Next Wednesday" in the Event Time, it calculates the date for me, which is neat. But when you show the list of events, you show the date and not "Next Wednesday" -- which is the way I remember it.

3\. An option for DD/MM/YYYY date format would help.

4\. If I say "Next Wednesday", you'll assume "At around 12.00PM". I think you should just say "Next Wednesday", and show timing info only if the user has entered it explicitly

</comment><comment><USER9> Just a thought - is there some reason you can't autodetect timezone information with js? (new Date().getTimezoneOffset())

<comment><AUTHOR> Doing it now. Thanks.

</comment></comment><comment><USER10> That's a really tough url/name.

<comment><USER11> Agreed. I like how some companies get around the long name problem. The <http://regionalhelpwanted.com/> sites all have the url <http://[regionalname]helpwanted.com/> and the tag-line "long name... amazing results". Even if it's a longer name, it's memorable if you hear a radio ad.

Of course, everyone wants to be a household name like flickr and all.

<comment><USER12> Hm. socasion, socimark, evencial, daycial, plancial. All open com's. Not awesome, but that just took a moment. Not having a .com is an unnecessary barrier.

</comment></comment></comment><comment><USER13> Please have a way to follow people like on twitter. People want to know where their idols (the kind of people you follow on Twitter) are going to be. Expose your thoughts on twitter; expose your social geo info on socl.in.

<comment><AUTHOR> Very good idea..will introduce soon.

</comment></comment><comment><USER14> Bug: clicked on facebook icon, got this:

"{ "error": { "type": "OAuthException", "message": "Invalid redirect_uri: Given URL is not allowed by the Application configuration." } }"

(Using Opera 11.01)

<comment><AUTHOR> Fixed this, Seems like FB changed a few things on graph API

</comment></comment><comment><USER15> I'm not sure what the value added is. It seems like it's a social calendar yet there's a note saying you don't have to share it if you don't want to so I'm confused.

<comment><AUTHOR> Idea is that you are not forced to share every event. You can mute some personal events. If you notice twitter of facebook timelines, most of the people want to share what they are doing now or in near future. This is where the idea came from.

</comment></comment><comment><AUTHOR> Incorporated most of the comments...Thanks for the review guys.</comment>


Show HN: Cluck – chrome extension that helps you avoid scams on Craigslist - <AUTHOR> http://www.cluckcluck.co <comment><AUTHOR> Hi HN,

I talked to a lot of summer interns last year who said they each ran into dozens of scammers while trying to find temp housing on Craigslist. The premise is pretty simple, you can claim listing as your own and leave reviews on listings. Looking for any feedback you might have.</comment>


Object Oriented Advice: Depend on behavior, not data - <AUTHOR> https://www.brainstobytes.com/depend-on-behavior-not-data/ <comment><AUTHOR> Seeing objects as entities that can answer questions and perform actions is one of the things that helped me wrap my head around OO programming, something that took some effort when I was starting.

If someone is still in the same struggle I found myself in years ago, this might help clarify things.

Thanks</comment>


California DMV: Self-driving cars must have driver behind wheel - <AUTHOR> http://www.mercurynews.com/business/ci_29262037/california-self-driving-cars-must-have-driver-behind <comment><USER2> Its nonsensical to think a human can take over at a moment's notice during a particular maneuver. Its the threat of death/accident that makes me pay attention to every moment of driving. On autopilot I wont have that kind of attention. Its simply a trait of the human attention span.

That being said, every self-driving car needs a manual override because there are plenty of situations that cant be easily explained to a computer. the override could be done with a steering wheel and gas pedal, or just a joy- stick mode on the touchscreen pad.

For instance someone has a big empty lot and they want to move a car from row A to row B. The new spot is exactly 50 feet to the right. I just want to back the car up, and go forward while steering over to the right a bit. Row B has no 'street address' to program into a route-computer. I could click on a map but the map doesnt know where on the grass i want to drive.

Even with lidar, etc. there are grey areas that self-driving algorithms are going to have trouble with. Drop a sheet of tissue in the path of a self- driving car moving at 60MPH. The lidar will see it as a solid object and might decide a very dangerous plan - maximum braking - is the best plan, when going through it is actually the best plan.

<comment><AUTHOR> This already happens today with cruise control - and yes, the driver will have to be paying attention while driving, at least in this version of the rules.

<comment><USER3> Cruise control still requires one to mostly drive, and the only "moment's notice" thing a human would do with cruise control would be stomp the brake.

Regardless of what any rule says, stand-by humans will not be paying attention and ready to drive. Even if reading/sleeping/daydreaming were successfully policed, the human will still be out of touch with how the car responds to controls.

Think of the first time you drive after not having driven for a few months - now imagine being already moving at highway speed.

</comment></comment></comment><comment><USER4> CA DMV's position is basically "let's try it with human backup for 3 years, then re-evaluate". That's reasonable enough.

Tesla may have set the field back. They released their "autopilot" as a beta, didn't provide sensors to enforce driver hands-on-wheel, shipped a system that works well only on freeways but will engage on other roads, and claimed that if it crashes, it's the driver's fault. Everybody else shipping similar capabilities (BMW, Mercedes, Cadillac, etc.) has put more restrictions on them (such as a hands-on-wheel sensor) to avoid over-reliance on the automation. Now Tesla has had to remove some features from their "autopilot".[1]

Google may be able to get approval for their 25MPH max speed mini-car operating without driver hands-on-wheel, on the basis of the slow speed. Google's system is much more advanced, and has a detailed model of what everything else moving around it is doing.

Expecting the human driver to take over if the automation fails will not work. The limits of human monitoring are well known from aircraft automation. It takes seconds to tens of seconds for a pilot to grasp the situation and recover properly if the autopilot disconnects in an upset situation. That's for pilots, who are selected and trained much better than drivers, and who go through elaborate simulator training in which failures are simulated. Watch "Children of the Magenta"[2], where a chief pilot at American Airlines talks to his pilots about this.

[1] [http://www.bizjournals.com/sanjose/news/2015/12/16/tesla- to-...](http://www.bizjournals.com/sanjose/news/2015/12/16/tesla-to-limit- self-driving-functions.html) [2] [https://www.youtube.com/watch?v=pN41LvuSz10](https://www.youtube.com/watch?v=pN41LvuSz10)

<comment><USER5> Planes are more complex than cars. Drivers react to road surprises far faster than 10s, when making a decision to brake or swerve

<comment><USER6> That reaction is not necessarily right, its just reflex which can produce more disastrous results than no reaction at all. Can't trust them much, particularly when I'm not fully aware of the situation around me (and I think one is unlikely to be fully aware of situation when on self-driven cars).

</comment></comment></comment><comment><USER7> > That cautious approach requires that the cars have a steering wheel, and a > licensed driver must be ready to take over if the machine fails.

The article takes the tone that this will drastically limit the technology, but honestly at this point a restriction like this seems completely reasonable.

The cars are _not good enough_ to completely drive themselves in all scenarios. At times, they will decide they can't handle a situation and safely ask a driver to take over. This is becoming more and more rare, but it's definitely still the case. Until the technology is proven to basically never need human intervention, it seems reasonable to require a person who can drive to be present.

<comment><USER8> For cases such as if the car detects a malfunction, this probably won't be a big deal, but for most extreme situations where a human will need to take over, and that can't be fixed by stopping the car, will a human be able to take over in a timely enough manner to solve the issue? We are often talking split second decisions, and it will involve a human who likely wasn't paying any more attention to the road than a passenger.

Imagine a car where the passenger's side is fully set up to drive, and with the push of a single button, the driver can swap all control to the passenger. I'm having a hard time thinking of situations where this is better than just stopping the car.

<comment><USER9> Hmm, that's makes me wonder how driving lessons work in US. In Poland it is a legal requirement that the car used for such purpose has a second set of pedals on passenger side, where instructor sits.

When I took a driving lessons my instructor was perfectly capable of pressing the brake or overtaking the wheel on time when I was about to do something stupid. I don't see why manual override of autonomous car should be harder.

I see however, that this can easily defeat purpose of using autonomous car: if the driver must be fully concentrated all the time, be ready to react, then it is even worse than driving normal car.

<comment><USER10> It works the same way in the US. However, in that case, the instructor is normally paying attention to the road and the student's driving, to grade them if nothing else. Usually, passengers can't be relied on for that level of attention.

</comment></comment></comment></comment><comment><USER11> How will this impact one of the key arguments for self-driving cars: elimination of DUIs?

If a driver is required behind the wheel able to take over at a moment's notice then the self-driving car's purpose is defeated - you cannot do work while the car drives, you can't use the car as a sober ride home from the bar, you can't take a nap on your commute, etc.

This is a legislated death sentence for self-driving cars as we envision them.

<comment><USER12> While I agree that it defeats many of the purposes (including Uber-style services), remember that this legislation is in response to current state of self-driving cars. Once they get better, legislation can become more lax.

<comment><USER11> As a general rule of thumb, legislation never becomes more lax.

<comment><USER12> That's a silly thing to say. Uber and AirBnb were illegal when they launched. You couldn't use your phone on an airplane during takeoff until recently. The original speed limit for cars was "no faster than walking".

With the lobbying power of Google, Tesla, Apple and all the car manufactures? It will change.

</comment></comment></comment></comment><comment><AUTHOR> Even though it doesn't look like it, this is actually great news since this provides a path for Google et al to get out there and build broad customer comfort around the technology.

And frankly I don't ever foresee driverless cars that don't have some form of manual ovveride - there will always be situations that won't make sense to the computer that make perfect sense to me.

==== Edited to add this clarification, as people on HN seem overly ready to pick nits. ====

The larger point is that humans will be humans and will never buy a car that will interfere with their freedom to do what they think is right at that moment.

And if you want a better example - maybe I want to speed to get to the hospital in an emergency. Maybe I want to block another car that's leaving the scene of a crime. You get the idea.

<comment><USER13> > _park in this no parking zone blocking traffic for 30 seconds while I run to > get something._

No? Either park legally or go without. You are literally saying to everyone else "me saving 5 minutes by not having to park is more important than whatever it is you're doing."

<comment><USER3> Actually since the "driver" had not left the car, it would be considered "standing" not "parking", at least by MA law.

<comment><USER5> Only if the "driver" can decide to move out of the way if needed, without the passenger directing it

</comment></comment></comment></comment><comment><USER14> Sounds like a good idea for the first 10 or so years of self-driving cars. Remember, not all self-driving cars will be made by Google or Tesla. Some will even be made by the spaghetti-code-Toyota, the cheating-Volkswagen, or the we- send-updates-over-unencrypted-HTTP-BMW. It's best not to jump head-first (literally?) with this.

And it's not just about the "safety" code of these self-driving cars, either. Many of them probably still won't care too much about hiring top-notch security experts in the first few years, to protect their cars against remote hacking (which could be much easier with self-driving cars if they are connected to the Internet).

</comment><comment><USER15> If I have to be responsible for AI and mechanical errors, I don't want an AI driving my car.

Either I want to read a book or take a nap, completely zoned out, or I want to be alert and paying attention to the road.

Sitting there doing nothing bored and disengaged, not able to read a book, not actively engaged in the activity of driving, and also held responsible by the state for failures is the worst of both worlds.

<comment><USER16> If that AI has, say, one-third the risk of accidents as I would have, then I want it driving my car even if I enjoy it slightly less.

<comment><USER15> It's not the I would enjoy the experience less, it's that the experience of just sitting there would render me an inattentive dullard with very poor response to a mechanical or AI failure. If I'm suppose to be responsible per California State, I need to be paying attention. Just sitting there, inactive, mile after mile, hour after hour doing nothing, maybe for months or even years at a time, I will be woefully unprepared to respond to the emergency.

I actually gave up driving for 16 years then restarted when I last moved. What I found when I restarted was that, while physically I could operate the car, my decision making skills when faced with a problem were non-existent. I could see problems coming my way, but the reflexive decision making was gone. I had to relearn the decision making process.

Designing the system to place responsibility on humans to take over only occasionally will ensure that the system creates catastrophic results when humans are found to be unprepared for the responsibility.

</comment></comment></comment><comment> daniel-cussen Brilliant idea on the DMV's behalf. I'm reminded of Douglas Adam's thought, in Hitchhiker's Guide to the Galaxy, that solving a problem ("Now that it's perfectly air-conditioned,") shouldn't allow the removal of redundancy ("...you won't need to open the windows, ever."). Because the problem won't REALLY be solved in all cases, and if the driver finds he's in an ugly situation where he cannot act, there's no steering wheel to handle the convenient killing machine he's riding. Can you imagine the horror?

<comment><USER17> We can include an emergency bike in the trunk so you can still get where you are going.

<comment> daniel-cussen Bikes have the highest practical value of 100% computer-free objects, so this looks like a reasonable solution.

</comment></comment></comment><comment><USER18> This would be a huge setback if approved simply because once approved, such things are unlikely to change even when the time comes that human drivers will not only be unnecessary, but the most dangerous component in all situations. I understand the state's motives: liability, fear of bad press, keeping traffic cops employed (and thus the biggest avenue for random arrests), etc. but none of them justify limiting the technology simply to serve their rather short- sighted, selfish needs. At the same time, the people that could benefit most from driverless cars like the elderly, disabled, youth, etc. are shit out of luck. And all this without a single accident yet attributed to driverless cars (afaik).

</comment><comment><USER3> This is the exact wrong idea. Frankly, consumer-ready self-driving cars should be _prohibited_ from changing into "manual mode" without a user request. And the _manufacturer_ should be liable for an at-fault accident in auto-drive mode. Until these conditions can be satisfied, self-driving cars are simply not ready for prime time.

The proposed rule will lead to proliferation of shoddy "99%" software designed around an expectation that a human can take over at a moment's notice. But humans don't work that way, so any such exceptional condition will likely result in a crash. The only acceptable failure procedure for a self-driving car is to stop.

<comment><USER19> See my comment above on two situations where coming to a stop is actually more dangerous.

TL;DR: If the car fails while driving on a highway or crossing a busy intersection, stopping will cause a wreck.

<comment><USER3> Sure, coming to a stop is dangerous in those situations if other drivers don't react appropriately. It's not a great idea, but I also don't mean that self- driving cars should be doing such emergency stops regularly. And obviously they should do it only as an extreme last resort, when things like pulling over have failed.

I still think it's more reasonable to stop either of those two places than to suddenly hand control of a car traveling 75mph to a human who hasn't driven in a year or longer.

edit: concrete example: You're biking along. Would you rather A. a car in front of you come to an abrupt stop, or B. a car passing you at twice your speed be controlled by a drowsy driver who doesn't know where the edges of his car are and doesn't have a feel for how the steering wheel reacts ?

<comment><USER19> A fair point. The argument really comes down to this: Is it likely that a malfunction will occur while the auto-car is closely followed by another car?

<comment><USER3> Well, I wouldn't say "likely" comes into it. I'm explicitly describing what happens with a choke_and_die() function if say the software crashes with no recovery, or major sensors are damaged - unpredictable by definition. The "I don't know how to navigate this situation" case would be handled by gracefully pulling over, and should _rarely_ happen because developers would be encouraged to work out the kinks rather than having such a terrible user experience be common.

My point is that giving developers an easy out of forcing a human to take over just encourages sloppy non-robust software. And if there's anything that consumer technology companies are good at creating, it's non-robust software that has no place in a car.

</comment></comment></comment></comment></comment><comment><USER20> Does the requirement need to have a control unit at all times? It would be neat to continue to make it an option but also allow the console to hide the wheel and perhaps replace it with some more fly-by-wire smaller replacement.

<comment><USER21> Maybe not hands on the wheel control but I would at least want it to be a wheel that is ready to go by just grabbing it, same with the brakes. If they collapsed or folded into the dash that could lead to issues where a software glitch doesn't let you take back control and the robot overlords end you.

</comment></comment><comment><USER22> I feel like it could be more unsafe this way. What if a human gets scared, takes control, and overreacts when the car is properly handling the situation? Might cause more accidents.

EDIT: reworded sentence so it actually made sense :P

<comment><USER23> The human who drives a self driving car now should know what he's doing. These cars are prototypes now and whoever takes them to the road should be responsible.

</comment></comment><comment><USER24> When I read the geohot article [1] earlier I was thinking that there was no way what he was working on was legal. Would be curious to have someone with more expertise weigh in though.

Does this make comma.ai [1] or cruise [2] more acceptable in the eyes of the state?

1 - [https://news.ycombinator.com/item?id=10744206](https://news.ycombinator.com/item?id=10744206) 2 - [http://www.getcruise.com/](http://www.getcruise.com/)

<comment><USER4> California rules (summarized):

A manufacturer may conduct testing of autonomous vehicles on public roads in California if:

(a) The manufacturer is conducting the testing.

(b) The vehicle is operated by an autonomous vehicle test driver who is an employee ...

(c) The manufacturer can cover $5M in damages via insurance, bond, etc.

(d) Manufacturer's Testing Permit from DMV.

Current California permit holders:

        Volkswagen Group of America
        Mercedes Benz
        Google
        Delphi Automotive
        Tesla Motors
        Bosch
        Nissan
        Cruise Automation
        BMW
        Honda
        Ford

</comment></comment><comment><USER25> Welp. As a blind person who has been looking forward to self-driving vehicles since the 2004 DARPA grand challenge, this is a not totally unexpected kick in the balls.

</comment><comment><USER26> Most driving is fairly routine, but without strong AI I don't see how a self driving car can handle things like:

There is a car accident on the side of the road, and there is a human cop waving cars one at a time to drive past on the wrong side of the road.

I am part of a funeral procession, or a police escorted parade and I need to drive through red lights in order to stay in the procession. (That at least I know from the start to take manual control - except google wants a car with no wheel, and in a world with lots of such cars people won't know how to drive.)

Or, there is an ambulance behind me sirens wailing and in order to get out of the way I must drive illegally for a moment (through a red light, or on the wrong side of the road).

How about something as simple as driving the car up some ramps so I can service the car. How would you do that without both a steering wheel and experience in how to drive?

I don't see how a self driving car can handle any of those.

<comment><USER27> Self-driving cars should only need to handle 90% of driving tasks. For the rest, a qualified human can and should be required to take over.

<comment><USER26> That leaves humans without enough experience to actually know how to drive. It takes years of driving to get good at it.

If people drove only 1/10 as much as now no one would ever get good at it.

It's called _" The Paradox of Automation"_ and it's a huge problem.

Basically the better the Automation the less often humans do anything, but it means that when humans _do_ have to do something it's much much more critical than usual. Which is exactly the situations the humans have no experience with since they take control so rarely.

Basically some automation is good, but a lot of automation is actually detrimental to safety. For each industry you have to calculate that cutoff point and do no further automation past that point, until you are able to reach 100% perfection.

</comment></comment></comment><comment><USER28> Maybe the cars should be required to pass a CA driver's test? If it's good enough to test a driver, why not a car?

<comment><USER29> This reminds me of the recent discussion about Baidu's expulsion from an image recognition competition. They submitted too frequently, causing their machine learning algorithm to solve specifically for the test, rather than for general purpose image recognition.

In your proposed scenario, knowing the CA driver's test constraints, the engineers could easily (and perhaps even inadvertently) be able to design a driver AI capable of passing the test with flying colors, yet fail horribly once faced with real-world driving.

That's not to say that's actually what would happen, only to say that the test would actually be rather useless to certify a self-driving car.

<comment><USER30> Another win for Test Driven Development!

</comment></comment></comment><comment><USER31> , servant walking 20 paces in front carrying red flag.</comment>


Ptop 1.0: A task manager written using Python - black-perl https://medium.com/@darxtrix/releasing-ptop-1-0-a-task-manager-written-using-python-879f63745034 <comment><AUTHOR> Shouldn't this use the real headline? The "awesome" is editorializing.

<comment> black-perl Fixed, thanks :)</comment></comment>


Dear Firefox, Fucking fix it already - <AUTHOR> https://www.change.org/petitions/mozilla-firefox-fix-bug-475891 <comment><USER2> I'm confused. This petition talks about cross-domain fonts, but it links to [http://bugzil.la/475891](http://bugzil.la/475891) which has nothing to do with cross-domain issues. (It's about using different fonts for different Unicode characters.) Did you mean to link to [http://bugzil.la/604421](http://bugzil.la/604421) instead?

Note that IE also applies same-origin restrictions to web fonts, and in fact this is required by the CSS Fonts standard [1], although this has been a somewhat contentious part of the spec [2]. The Blink team has discussed implementing this part of the spec too; Google's Tab Atkins believes that any new resource linking mechanism added to the web platform should be subject to same-origin restrictions by default [3] because this gives the platform better security characteristics.

The publisher of a web font can enable cross-origin use in all browsers by sending CORS headers [4].

[1] [http://www.w3.org/TR/css-fonts-3/#same-origin- restriction](http://www.w3.org/TR/css-fonts-3/#same-origin-restriction)

[2] [http://lists.w3.org/Archives/Public/www- style/2011Jun/thread...](http://lists.w3.org/Archives/Public/www- style/2011Jun/thread.html#msg476)

[3] [https://groups.google.com/a/chromium.org/d/msg/blink- dev/TT9...](https://groups.google.com/a/chromium.org/d/msg/blink- dev/TT9D5-Zfnzw/UKMHYjVe3scJ)

[4] [https://developer.mozilla.org/en- US/docs/HTTP/Access_control...](https://developer.mozilla.org/en- US/docs/HTTP/Access_control_CORS)

<comment><AUTHOR> Updated, thanks for pointing that out.

"The publisher of a web font can enable cross-origin use in all browsers by sending CORS headers."

I agree they can, but why do we need to add "Access-Control-Allow-Origin" header? What is the security risk? I am not being facetious, I really want to know.

<comment><USER2> So, you fixed the bug number, but what about my other points? Why single out Firefox when IE9+ has the same behavior and that behavior is required by the spec? Why don't you (or your CDN) use CORS? Why do you say this is "breaking the web" when thousands of sites are using cross-domain web fonts just fine in Firefox and IE (for example, any site that uses Google Web Fonts)?

 _Edit: I see you added more to your comment now._

There are a few reasons to require CORS for cross-domain font loads. One is so that you can use fonts that have single-site licenses in a way that satisfies the licensor, by not allowing other sites to use the font too without your authorization. Another is to prevent unintended data leaks where a malicious site can deduce things about a user based on whether that user can load a font from a different site, or based on the contents of that font. This isn't about a known attack, but a class of attack that we know from experience is likely to crop up in the future for any type of cross-origin resource load that we allow.

<comment><AUTHOR> "Why single out Firefox when IE9+ has the same behavior and that behavior is required by the spec?"

I don't expect Microsoft to listen to their customers/users. I used to think Mozilla did but apparently not.

<comment><USER2> Hey, I'm part of Mozilla and I spent a significant part of my day researching this spec, and asking questions and listening to try and find out why your use case wasn't being met. Usually we prefer well-reasoned bug reports or emails as apposed to "Fucking fix it" on the HN front page, but we'll take feedback where we find it. :)

Also note that if you can't convince Microsoft to change this as well, then it doesn't matter too much what Mozilla does (at least for sites that need to support IE).

</comment></comment></comment></comment></comment><comment><USER3> So we (Mozilla) are following the spec, which says what it does as the result of discussion/negotiation over a period of at least 4 years (roughly 2007-2011) involving browser makers and font foundries, both in terms of what browsers were willing to implement (not wanting something DRM-like to protect fonts) but what would lead to more font foundries being willing to license commercial fonts for use on the Web. So following the spec here isn't about blindly honoring some piece of paper; it's about honoring the result of a negotiation process that we participated in. WebKit unilaterally ignored this agreement, though it sounds like Blink may well change to honoring it.

Many (but not all) of us believe that same-origin by default is also the right thing for security, that it should be the default for new types of resource linking on the Web, and that not having same origin restrictions for things like images was a pretty serious mistake that we're still paying the security costs of (for example, with canvas image tainting).

<comment><AUTHOR> @dbaron, I appreciate your insight. Makes sense even though, _at this time_ , I do not fully agree with the spec. I guess time will tell.

</comment></comment><comment><USER4> Google Chrome let's you do something Unsafe that none of the other browsers let you do, and you want the safe browser broken so it does the dangerous thing? This doesn't seem like a good idea to me.

You can use fonts from places that let you use them. But this offers both a minimal copy/hot link protection, so that I can't just steal a font from somewhere, or use someone else's hosted font unless they let me.

I don't think Firefox should "fix" this as it seems to be a good decision for preventing all sorts of bad things.

</comment><comment><USER5> I assume there is not an arbitrary reason for this--does Mozilla consider fonts to be dangerous (security-wise)?

Also, do you want to load the fonts across domains so they can be hosted on CDNs?

Also, this is a terrible, non-descriptive title.

</comment><comment><USER6> this is probably astroturfing by google. Who provides both a site with free fonts and a browser without those restrictions. Plus we know they have use for those random resource requests since they also provide 18.104.22.168 and other similar cdn for js libraries. Also they killed 3+ attempts at disbling referrer from the chromium comunity.

or i am just paranoid.

<comment><USER2> Google Web Fonts uses CORS, so it works cross-origin in Firefox and IE.

<comment><USER6> exactly. did you even read my paranoid theory? :)

all they want is that FF and IE be as permissive as Chrome so they can track everyone via cross-domain font requests. As they already do with DNS and free CDN for js libs.

<comment><USER2> But my point is they can already do this. They don't need IE or Firefox to change anything because _IE and Firefox already support cross-domain fonts._</comment></comment></comment></comment>


McDonald's Happy Meal resists decomposition for six months  - <AUTHOR> http://news.yahoo.com/s/yblog_upshot/20101012/bs_yblog_upshot/mcdonalds-happy-meal-resists-decomposition-for-six-months <comment><USER2> In case you're interested, there are many comments from the last times this was submitted. Here is a selection:

<http://news.ycombinator.com/item?id=1656044>

<http://news.ycombinator.com/item?id=1647759>

<http://news.ycombinator.com/item?id=1256516></comment>