Induction: A Polyglot Database Client For Mac OS X • Hacker News Board

Re: Induction: A Polyglot Database Client For Mac OS X

#81

Post by nknight » Tue, Mar 06, 2012, 6:00 AM UTC

sjs wrote: post #69

tikhonj wrote: post #37

Earlier quoted context omitted.

That's just patently untrue: either GTk or Qt would work perfectly. I don't see why the desktop environment would matter--the program doesn't have to (and probably shouldn't) care whether I'm on Gnome or KDE or Unity. Moreover, all the popular environments support both GTk and Qt fairly well, and both are cross-platform, so you would actually be supporting more users than with a Mac OS-only program. Really, fragmenta…

> Moreover, all the popular environments support both GTk and Qt fairly well, and both are cross-platform, so you would actually be supporting more users than with a Mac OS-only program. By that logic Windows should be first since it has the most users. Also, are you sure that the installed base of Gtk+ or Qt (or both) is greater than the installed base of OS X?

Qt works just fine on *nix, Mac, and Windows. GTK+ isn't quite so nicely polished, but is still viable on all three.

Installed base is irrelevant if you include the libraries or statically link. You'll bloat your download a few MB, but it's manageable.

Re: Induction: A Polyglot Database Client For Mac OS X

#82

Post by methoddk » Tue, Mar 06, 2012, 6:07 AM UTC

renownedmedia wrote: post #55

methoddk wrote: post #38

This is freaking awesome and I can't wait to build it.

I'm lazy, where's the binaries? :3

Theres a binary hosted on the github page somewhere.

Re: Induction: A Polyglot Database Client For Mac OS X

#83

Post by Groxx » Tue, Mar 06, 2012, 7:14 AM UTC

ksuther wrote: post #75

Groxx wrote: post #71

Earlier quoted context omitted.

GC is on the way out? I haven't heard that before... have a link?

End of the page here: https://developer.apple.com/library/ios/#releasenotes/Object... Apple highly encourages using ARC over GC for new development.

Well yeah. One is compiler-assisted reference counting and the other is garbage collection. Reference counting is nearly always faster than garbage collecting, and Apple has generally been a bit obsessed on speed, for however much that has gained them or lost them.

Their wording there is suspect though. Interesting - thanks for the link!

Re: Induction: A Polyglot Database Client For Mac OS X

#84

Post by chalst » Tue, Mar 06, 2012, 12:35 PM UTC

Groxx wrote: post #83

ksuther wrote: post #75

Earlier quoted context omitted.

End of the page here: https://developer.apple.com/library/ios/#releasenotes/Object... Apple highly encourages using ARC over GC for new development.

Well yeah. One is compiler-assisted reference counting and the other is garbage collection. Reference counting is nearly always faster than garbage collecting, and Apple has generally been a bit obsessed on speed, for however much that has gained them or lost them. Their wording there is suspect though. Interesting - thanks for the link!

Reference counting is generally quite a bit slower overall than stop-the-world garbage collection.

I guess you meant latency, where reference counting generally has better latency than incremental garbage collection.

Re: Induction: A Polyglot Database Client For Mac OS X

#85

Post by lobster_johnson » Wed, Mar 07, 2012, 8:15 PM UTC

thought_alarm wrote: post #49

Isn't this just reinventing ODBC? Back in the day you could whip together an app like this using Borland's dev tools in literally a matter of minutes, and it worked with any data source configured on your system. And I think there's a YouTube video that has Steve Jobs demoing that same sort of data access using only Interface Builder on NeXTSTEP. What am I missing?

ODBC is fairly complex (both to work against and to implement providers for) and is very much tied to relational databases.

It's also unevenly implemented: On Windows there's native Microsoft-provided ODBC (but in terms of focus it has been superceded by ADO, which superceded OLE DB, which was supposed to be the replacement for ODBC — it's not like Microsoft ever settles on a single technology), and on Unix there's UnixODBC. I don't know about the driver quality; I suspect Windows ODBC drivers are quite good, whereas JDBC has been favoured by the server/enterprise world for a while, and I would not be surprised if UnixODBC drivers were a bit behind the times.

As for the Borland dev tools, they also used their own proprietary data source tech: The BDE (Borland Database Engine), which had an ODBC bridge built in. I remember being quite fed up with the BDE at the time, and eventually started using a set of native ODBC components that someone developed.

Cocoa does have a sort of rich data framework that you refer to: Core Data. Unfortunately it's quite complex, and not really designed to be a common interface to databases, but rather a sort of data abstraction layer where you work with objects and never see any SQL.