What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 23:25, Richard Gaskin wrote:
> I've worked with OS APIs in Pascal, C, and two xTalks, Tookbook's
> OpenTalk scripting language which provides that built-in, and
> CompileIt for HyperTalk.

This is true - they did. However, they come from a time when almost all 
OS APIs were procedural, and quite simple.

(Also, due to the limitations of what one can represent in 'stringy' 
languages - of which LiveCode Script is one - such a facility is 
incredibly fiddly, error prone and difficult to build nice abstractions 
around).

> The one thing I've learned from that is that the language you're using
> isn't all that important, because no matter what you're writing in the
> OS you're talking to expects C:  it uses C data types and structures,
> provides tons of great sample source but all in C, and requires that
> you think like a C programmer, understanding and managing data in ways
> a good xTalk normally insulates from even having to think about - the
> difference between a pointer and a handle isn't interesting to most
> xTalkers, but can be essential in C.

This isn't true. Most of Android's APIs are Java. Most of iOS / Mac's 
APIs are Objective-C. A lot of Windows functionality is provided through 
COM - which is an object-based API. Oh, and in the browser (HTML5) world 
the APIs are JavaScript (another object-based language).

> By the time you become fluent enough in C to understand OS APIs well
> enough to use them, you've already learned enough to write in it as
> well.

This is simply not the case - there's a huge chasm between being able to 
understand C-style APIs and data-structures enough to use them and being 
able to write C (at least to any degree of use / proficiency).

Indeed, given that we are talking about (in many cases) very well 
defined APIs, which have been (ignoring Win32 and MacClassic ;)) very 
well designed - you actually don't need to understand much C to use 
them.

All you need to understand is what the values they take and return are, 
and how they can be appropriately marshalled. Indeed, the goal is that 
LiveCode Builder will do most of the marshalling for you - so as long as 
you have enough of an understanding to read the API definitions and map 
them to LCB forms, you can then use a language which is a great deal 
more familiar to use them (to be fair we still have a fair bit more work 
to do on the marshalling front...).

> Monte's done an amazing job showing off what the externals SDK can do
> for extending LC.  It would be great to see more people jump on board
> with it.

Externals don't really go away with LCB - they just get renamed. All 
that happens is that LCIDLC which is used to simplify the interface 
between Engine and External goes away and is replaced by an LCB file 
containing nothing but foreign handler declarations. Of course, you then 
get the benefit of being able to mix you LCB and C in any way you 
choose.

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps