Mark Waddingham wrote:
On 2015-10-12 22:31, Richard Gaskin wrote:
That's an obvious option if we assume there must be only one IDE. And
from the company's perspective that's a useful assumption, at least in
as much as they need to provide at a solid basic toolkit to accompany
the engine.
Well, the engine is pretty useless in isolation without tools to be able
to build apps with it (unless of course you are happy with restricting
yourself to script libraries and using a text editor - which whilst
appropriate for some endeavours, for most purposes it would be extremely
tedious).
Of course, which is why I wrote "they need to provide at a solid basic
toolkit to accompany the engine".
Thumbs up on the team's continued IDE efforts.
Noting I've written is an "or". merely a "yes, and...."
I've been using my own tools within every xTalk IDE I've used, and as
long as frontScripts work and we pass messages as good citizens do,
there's an opportunity to have LESS dependence on a large IDE
framework rather than more. Or if we were to be thorough, a fairly
slender one.
I think you might be confusing 'IDE' with 'IDE Framework' here - they
are two quite distinct things.
Tools can be entirely self-contained and fully interchangeable, even
open at the same time, using nothing more than what the engine has
provided for years.
Really? Are you sure that is true?
So you would have every 'application browser' type tool implement its
own code for monitoring for changes in the user stacks, and for
collecting all the data about the objects in user stacks?
You would have every 'tools palette' type tool implement its own code to
go digging around on disk for all extensions, listing, enumerating and
providing an ability to create them?
You would have every 'documentation palette' type tool implements its
own code to go digging around on disk for the content it needs to
display, and then its own code for processing that content into the form
it wishes to display?
You would have every 'standalone builder palette' type tool implement
its own code for building standalones?
You would have every palette which wants a button on some sort of
'launcher stack' have to understand how every 'independent' launcher
stack needs to be told to add its button?
And assuming you would have that, how do you ensure that all these
components which can be used in a 'fully interchangeable' and in an
entirely 'self-contained' fashion don't actually interfere with each
other to the detriment of the user stacks they are acting upon?
In order for any system to work where you can plug-and-play components
from different sources you need to have a common basis of communication
which provides the basic services all the components need to ensure that
they can be used together in the same environment without conflict.
Also, you need to ensure that said set of basic services is rich enough
that those that wish to write such components don't spend most of their
time re-inventing the wheel and can focus entirely on the purpose of
their component.
Now, I see that you appear to regard the 'engine' with some sort of
magical prowess. Indeed, it does provide a 'standard' interface to a
common set of functionality that is exposed through its object model and
syntax; however, I'd assert that the engine's interface is not at a
high-enough level right now to give you what is needed for what you
dream of in terms of the 'bit that binds all these decentralised built
components together'. Thus any solution which provides the above
'nirvana' in terms of interchangeable tools will end up relying on a
collection of script libraries which everyone's tools rely on and use to
ensure they can all co-exist together - i.e. you end up with precisely
the IDE Framework that I've been talking about.
It is important to remember that 'framework' means precisely that - it
is scaffolding, policy, and ancillary services. A 'framework' is just
there to ensure that everything works together for its particular end
purpose - and good ones interfere as little as possible with the actual
action of the components which sit within them.
Ideally, of course, the 'engine' would provide such an appropriate
high-level interface - a strong API - for tools written by disparate
parties acting together in a single environment to give users complete
choice in their toolkit for creating LiveCode applications...
... Sounds like a good way to approach that (given how much faster it is
to write LiveCode Script than C++) would be to provide the engine with a
standard set of script libraries which present a suitable high-level
interface for building IDE Tools to ensure tool writers (including
ourselves) can easily build tools...
... Which is rather like what we've been working on in the LC8 IDE ;)
Warmest Regards,
Mark.
I refer to the engine with admiration only because we all understand
that it's what runs all scripts, including those in an IDE. I rather
like LiveCode Script, and find it very capable. The existence of any
IDE suggests it's useful for making those sorts of things.
It's possible to invest our time enumerating reasons why people
shouldn't enjoy crafting tools in LiveCode, but to what end?
Any IDE (or IDE "tool" or "framework" or any other subset) is just a
collections of stacks. The one thing we know about LiveCode programmers
is that they know how to program in LiveCode. Many of them are quite
good at it.
I see no harm in encouraging people to just continue doing what they've
been enjoying for decades: making tools to help their work and sharing
them with others.
Indeed, I see no way to stop them. :)
All of the tools I've referred to - Mark Weider's, Bjornke's, Geoff's,
Peter's, and others' - exist. Why not have more? Why not have a
convenient launcher for them?
Why not explore new ways of authoring in LiveCode?
Why not have an IDE for pro devs, another for kids, and other for
educators, and others for just about anything people might want to do?
Maybe even one for weirdos who like to play with exploratory skunkworks
projects. Sometimes useful discoveries come from such explorations.
It's possible to imagine a perfect circle, but in the natural world none
exists. All systems are imperfect, influenced by subtle but pervasive
forces that ultimately alter them from their ideal form. Anything that
seems otherwise lives in the space between design specs and shipping. :)
Even the OSes we love are riddled with kludgey workarounds - not that
we should pursue kludges, but it's no more useful to postpone everything
until a perfect system exists.
Ultimately you and I are describing the same goal, a modular and
lightweight IDE system in which tools are plentiful and interchangeable,
something Ken Ray and others have been advocating since the engine
acquisition in 2003.
And there is one salient aspect: neither of us is describing an IDE that
exists today.
All I'm offering here is encouragement for the things that led to this
thread, an acknowledgement that some folks like the App Browser and
others like the Project Browser and still others like Geoff Canyon's
Navigator and others like their own. And the same goes for object
creation tools, and inspectors, and the rest.
Of course the core dev team should also continue doing what they're
doing too. And over time each can learn from the other.
Play, explore, create, share.
Let a thousand flowers bloom.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
