Why extensions?

[Seth Tisue]

(an old rant of mine from November 2008 that's perhaps worth sending out
again, since the devel team has turned over since then, so here it is:)

[...a good thing about extensions is] extensions are separately
compiled, so they can be modified and built upon separately from the
main code base. Even after all of NetLogo becomes open source, it's
still going to be a ridiculous hassle to rebuild the entire application
just because you want to make a modified version of one network
primitive. And if you do build a modified app, then no one can run your
model unless they have your modified app, and the app is huge. That's
really no good. On the other hand if your model only depends on a
modified extension, it's much easier to distribute the modified
extension with your model.

If we need to make access to extensions easier, maybe we should make
that a priority in a future version. In the meantime, I don't think we
should be growing the core language except when it's absolutely clearcut
that something belongs there. I think it remains to be seen what
additional link primitives will qualify for that.

I think the core language is too large already and we should be moving
stuff (e.g. hubnet-*, file-*, plot-*) out of it and into extensions, not
vice versa.

If there are currently downsides to putting stuff in extensions, we
should fix those downsides, rather than let them guide design.

Just because something is an extension doesn't mean it's somehow less
important and it doesn't mean it has to be harder to access (if it's
harder now, that's fixable). Take the file primitives for example. I
think that ought to be in an extension. Does that mean I think file I/O
is somehow unimportant or peripheral? No! Does that mean we should
make the file I/O primitives harder for users to get at? No!

(For example, we could say that some extensions are available by
default, without having to add "extensions [file]" to your model.
Or we could do something with checkboxes.)

Here's what being an extension means to me:

1) It identifies a set of related primitives as a distinct entity. This
helps people understand the language: here are the core primitives,
here are the network primitives, here are the file I/O primitives,
etc. As opposed to "here's a gigantic list of 10,000 primitives
that do everything under the sun" -- we've gone too far in that
direction already.

2) It's compiled separately and can be separately modified and improved
by users.

3) The primitives share a uniform naming scheme: they begin with the
name of the extension, followed by a colon. (So for example when
I say file I/O ought to be an extension, all that really means is
that the primitive names ought to begin with "file:" instead of "file-".)

The main point I want to get across to everybody is that putting a
feature in an extension is NOT about giving that feature second class
status. It's about keeping the core language a reasonable size; it's
about modularity; and it's about having consistent naming conventions
for primitives.

--
Seth Tisue | Northwestern University | http://tisue.net
developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Seth Tisue]

and a P.S from around the same time:

Maybe we don't really need the "extensions" keyword at all. Why not
just have the compiler notice if you use a primitive with a colon in it,
and if you do, have the compiler automatically load that extension...?
That would definitely make using extensions lower threshold!

(I don't recall this idea being suggested before; maybe it never
occurred to us...)

--
Seth Tisue | http://tisue.net

[Seth Tisue]

(and further, on the subject of extensions and naming conventions)

The two concrete decisions we must make whenever we add some primitives
to the language are:

- do we give them a common prefix or not?
- if they have a common prefix, is it followed by a colon or a dash?

That's what all these philosophical debates we're having end up boiling
down to. That's what the users actually see. They needn't necessarily
care whether something is an "extension" or not (currently they must,
but we could fix that) -- but they do need to know what keys to press in
what order to use a primitive...

Currently, all our extensions use the colon, but the core language also
includes the following clusters of primitives that use the dash:

user-*
layout-*
hubnet-*
movie-*
netlogo-*
mouse-*
export-*
output-*

They are extension-like in their common naming, but are not actually
extensions at present. I don't have a good word for them. Call
them "semi-core", I guess.

So, at present we have THREE ways to name primitives. If I'm modeling
and I want to (for example) open a file, I have to think about whether
to write:

open-file (core)
file-open (semi-core)
file:open (extension)

I think this is a threshold problem. I would like to fix it if we can.

I am suggesting that the language we would be better off (lower
threshold, easier to learn and read and write, etc) if we had only two
naming conventions, not three.

I see two ways we could do this. Call them the colon way and the dash
way. I have suggested the colon way several times already; I'm
suggesting the dash way for the first time.

Plan A: Rename all of the semi-core primitives to use a colon.
file-open would become file:open, movie-start would becoming
movie:start, etc.

Plan B: Rename all extensions primitives to use a dash. We'd have
gogo-start, array-item, gis-set-world-envelope, etc.

Some folks were iffy on the colon way. Can you articulate your reasons?
Also, question: do you like the dash way any better?

Even if you have some doubts about the colon way... Question: is the colon
way really worse than what we have now, with the three different naming
conventions...?

All of us who use NetLogo heavily have been using the three-convention
system for years now. That means there's a danger of it seeming natural
to us just because we're used to it. But if you step back and take a
fresh look at it, it isn't natural at all.

[Colin Sheppard]

Great discussion Seth. 

I'd be in favor of retaining the colon but making installation and use of extensions simpler.  While, the concept of a namespace may be foreign to beginners, all it takes is some example code to get even the most hopeless noob over the initial hump of using primitives from an extension.  

I think changing extension namespaces to a dash will risk confusion about what's core and what's not, and even if you make it easier to load extensions, it's important for everyone to eventually understand that they are using something extra that was possibly developed by a third party and therefore could be buggy and less reliable than the core.  

Finally, it would be really useful to develop an extensions distribution server like what is done with most contemporary scripting languages (python, perl, R, ruby, etc...).  When a user attempts to use an extension that is not installed, it'd be wonderful if they could simply check a box in a list of available extensions to have the appropriate jar file automatically downloaded and installed for them to the correct location.  Complete documentation for each extension could be a requirement to being published on the server, providing a strong incentive for developers.

-Colin