Hacker News Reader

Comment by exe34 | Hacker News Reader

the thing I'd like to see is for software to expose functional/"rest"-like interfaces. similar with websites and the content/user data.

if you look at what accessibility software achieves by simply looking at the screen/hooking into the OS, now imagine any and all software could be connected like that.

some of this functionality is now provided in individual silos, e.g. an email with an appointment in gmail can go into your Google calendar. a ticket from your train company can be added to Google wallet.

but if you look at a flight booking system and want to compare the total price of a given set of dates for travel, including hotel and other things at different times - you're back to doing it on paper (or use somebody's website where 20% of the flights or hotels you want aren't included).

View on HN

> the thing I'd like to see is for software to expose functional/"rest"-like interfaces. similar with websites and the content/user data.

You mean, COM?

ActiveX is raising its arm through the soil

Office is probably the largest consumer-facing application to use COM today. It's honestly a great technology -- which came from the Cairo project.

> if you look at what accessibility software achieves by simply looking at the screen/hooking into the OS

Unfortunately that's kind of a pipe dream... in the real world, the first organization to flagrantly violate the OS vendor's human interface guidelines is the OS vendor itself, who ships some application with custom-schmustom, owner-drawn widgets that cannot be queried according to the standard OS APIs for querying them for content. So the accessibility software literally has to OCR the screen to determine what's written in the text fields and buttons.

Source: Knew a guy who worked on Dragon NaturallySpeaking, he had some war stories.

> now imagine any and all software could be connected like that.

As other commenters mentioned, there's COM, but that's a hairball to code for and a hairball to configure. The nicest systems that worked that way historically were the Lisp machine and Smalltalk environments, but the closest day-to-day software is probably Emacs. Everything in Emacs really can be connected together through the power of text buffers and Lisp. Objective-C is Smalltalk semantics retrofitted onto C, and originally NEXTSTEP, later macOS, really was a promising environment for this sort of integration... but in recent years Apple has been so focused on "apps" that it's doubtful they can keep supporting that vision.

You would have enjoyed AREXX IPC on the Amiga.

https://en.wikipedia.org/wiki/ARexx

Isn't that the SmallTalk model, but everyone decided to use C++ instead?

Not everyone, IBM OS/2 SOM had support for Smalltalk, C and C++.

Smalltalk was OS/2's .NET, so to speak.

Unfortunately it all died alongside OS/2, followed by IBM's pivot to Java.

Java on the AS/400 is the weirdest thing. The whole platform was designed to be compile once to near assembly and then run cached byte code or whatever. Java is just too late compilation is clunky in comparison imo.

I believe Tribes 2 did something similar just at a higher level

TIMI is compiled at installation time usually, the bytecode format is used only as portable executable format.

While initially Java on AS/400 did take advantage of TIMI, IBM eventually moved away from it, into regular JVM design on now IBM i.

Most likely because IBM z doesn't use TIMI, rather language environments, and they want a more straight design, or due to Java dynamic capabilities using TIMI wasn't the best approach.

On AS/400 (IBM i), only Metal C, and the underlying kernel/firmware, written in a mix of PL.8, Modula-2 and C++, are pure native code.

Reply on news.ycombinator.com