First impressions

[Felix Holmgren]

I've been checking out Etoile for a while, and today I took some more
time to read a lot of the docs. I thought I'd share some of my initial
reactions and some random thoughts and questions.

I think the Etoile web page definitely communicates that this is
something else than your average GNUstep project. The combination of
some pretty graphics with those fragments of Objective-C code caught
my eye. That said, I've later come to feel that the front page (and
most of the site) is too heavy on prettiness and too light on actual
information. Although I sensed that something interesting was going on
here, I was not sure whether et was more than an attempt to give gs a
decent look and feel, combined with a couple of people working on some
pet projects without any real cohesion.

It wasn't until I read the faq (today) that I really started to get a
more concrete picture of what et is trying to accomplish. In my
opinion the info in the faq could be expanded into several pages and
could easily be made into a "tour of Etoile". It is definitely the
single most informative document I've seen so far (and it's not really
so much of a faq as it is a description of the system. At this point,
these features stand out for me as defining et.

* A hot runtime
* Non-file based object metaphor
* Zooming interface
* Dynamic language support
* Updated gs theming

Secondly, I read (half-skimmed) David's papers on the runtime and got
doubly inspired. Prior to reading those I wasn't really sure what the
Language Kit was all about. Just a hook for various "scripting"
languages? But now, between the faq and the papers, I'm really
starting to get a feeling of et as coherent system. Again, I think
some of the info in the papers should/could be made much more visible
on the web page.

A question: how much of the runtime described in the papers is
actually implemented at this time in et?
I also wonder how much of these ideas are fed into gs and how much is
et specific.

It seems to me that the web page should be 90% geared towards
developers for the time being. Even if someone else came across the
page and liked it, they wouldn't really be able to get very far in
trying to use et, so it seems a waste of resources to go out of your
way to attract them. Not in the long term, of course, but for now.
Attracting active developers is, I suppose, much more important. I
myself would have been (even) more easily hooked if the front page had
a list of features ("flexible, dynamic runtime with support for...",
"updated ui metaphor...", "zooming interface...", "documents not
files..."), with a link for a fuller explanation of each item. Maybe
I'm stating the obvious, and probably your answer is "yes it's on our
todo list", but I think you already have a lot of information and
examples available, and you just have to put them up front.

About the proposed themes: these obviously constitute a pretty big
step in the world of GNUstep themes, but -- I'm sorry -- for the
average non-geek, they are not really close to a cutting-edge, 21st
century feeling. Well, maybe close but... I should add that I don't
think any open source desktop really is. I know many developers simply
scoff at such obsession with cosmetic detail but users don't. And
personally I'm as much a user as a developer and I care a lot about
how my work environment feels. I'm sure you would agree that this has
nothing to do with bloated, candy filled interfaces, but with the
small details that make users feel that the gui inspires them, as
opposed to merely letting them get something done. And again on a
completely personal note, all that purple doesn't really do it for me.
I think etoile is definitely on the right track, but it would be worth
to keep on polishing the proposed themes and getting some external
feedback on them.

Btw: it seemed like you're saying (I read through a couple of
interviews too) that Apple's horizontal menu bar was a downgrade from
OpenStep's vertical one, and yet it seems like you're going for a
horizontal bar yourselves. Am I wrong?

Language Kit: from some of the examples and discussions, I first got
the feeling that it was just about putting some Smalltalk syntax and
block semantics on top of the gs runtime and libraries. There seemed
to be a focus on compile time tricks, that to me looked kind of
contrary to the spirit of Smalltalk. As I said, after reading the two
papers I got a completely different appreciation of the et runtime,
but I'm still pretty unclear about how Language Kit will work for
languages whose libraries are not easily mapped onto gs classes. What
will the benefits be in that case? Why not just create a llvm front
end?

Also, I was wondering if it would be of interest to implement fancier
parsing as part of Language Kit. Maybe parser combinators? Or parsing
expression grammars? Would that seem like something that belongs in
Etoile?


Well I have and will have a lot more questions. I'm really looking
forward to seeing how Etoile develops.

/F

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Felix Holmgren]

Well I also looked a bit at the videos from the hackathon now, and
understand Language Kit better :)

One thing I haven't seen mentioned anywhere in the Etoile docs are
DSL:s. Granted, it's become a big hype, but I think DSL:s should have
a natural place in a modern computing system. I saw David referring to
COKE in one of the papers. Alan Kay' gang at the Viewpoints Research
Institute, which is behind COKE, is also creating some pretty
impressive DSL:s. Check this: www.vpri.org/pdf/tr2007008_steps.pdf
(esp. Apendix E!)

So, yeah: the place of DSL:s in Etoile?

/F

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Nicolas Roard]

On Sat, Jul 25, 2009 at 4:47 AM, Felix Holmgren<felix.holmgren@...> wrote:
> I've been checking out Etoile for a while, and today I took some more
> time to read a lot of the docs. I thought I'd share some of my initial
> reactions and some random thoughts and questions.

thanks, and welcome :)

> I think the Etoile web page definitely communicates that this is
> something else than your average GNUstep project. The combination of
> some pretty graphics with those fragments of Objective-C code caught
> my eye. That said, I've later come to feel that the front page (and
> most of the site) is too heavy on prettiness and too light on actual
> information. Although I sensed that something interesting was going on
> here, I was not sure whether et was more than an attempt to give gs a
> decent look and feel, combined with a couple of people working on some
> pet projects without any real cohesion.
>
> It wasn't until I read the faq (today) that I really started to get a
> more concrete picture of what et is trying to accomplish. In my
> opinion the info in the faq could be expanded into several pages and
> could easily be made into a "tour of Etoile". It is definitely the
> single most informative document I've seen so far (and it's not really
> so much of a faq as it is a description of the system. At this point,
> these features stand out for me as defining et.
>
> * A hot runtime
> * Non-file based object metaphor
> * Zooming interface
> * Dynamic language support
> * Updated gs theming

An "Etoile tour" is a very good idea, yes.

> Secondly, I read (half-skimmed) David's papers on the runtime and got
> doubly inspired. Prior to reading those I wasn't really sure what the
> Language Kit was all about. Just a hook for various "scripting"
> languages? But now, between the faq and the papers, I'm really
> starting to get a feeling of et as coherent system. Again, I think
> some of the info in the papers should/could be made much more visible
> on the web page.
>
> A question: how much of the runtime described in the papers is
> actually implemented at this time in et?
> I also wonder how much of these ideas are fed into gs and how much is
> et specific.
>
> It seems to me that the web page should be 90% geared towards
> developers for the time being. Even if someone else came across the
> page and liked it, they wouldn't really be able to get very far in
> trying to use et, so it seems a waste of resources to go out of your
> way to attract them. Not in the long term, of course, but for now.
> Attracting active developers is, I suppose, much more important. I
> myself would have been (even) more easily hooked if the front page had
> a list of features ("flexible, dynamic runtime with support for...",
> "updated ui metaphor...", "zooming interface...", "documents not
> files..."), with a link for a fuller explanation of each item. Maybe
> I'm stating the obvious, and probably your answer is "yes it's on our
> todo list", but I think you already have a lot of information and
> examples available, and you just have to put them up front.

yes.

> About the proposed themes: these obviously constitute a pretty big
> step in the world of GNUstep themes, but -- I'm sorry -- for the
> average non-geek, they are not really close to a cutting-edge, 21st
> century feeling. Well, maybe close but... I should add that I don't
> think any open source desktop really is. I know many developers simply
> scoff at such obsession with cosmetic detail but users don't. And
> personally I'm as much a user as a developer and I care a lot about
> how my work environment feels. I'm sure you would agree that this has
> nothing to do with bloated, candy filled interfaces, but with the
> small details that make users feel that the gui inspires them, as
> opposed to merely letting them get something done. And again on a
> completely personal note, all that purple doesn't really do it for me.
> I think etoile is definitely on the right track, but it would be worth
> to keep on polishing the proposed themes and getting some external
> feedback on them.

I think we all are very interested in good GUI design and a good UI
theme. Quite a lot of effort/discussion went in the Nesedah theme for
example, but as all design, it's a result of a set of constraints..
that being said I'm not saying what we have is the end of all things
and we shouldn't work on that more -- to the contrary :)
(though maybe that's not the most pressing thing to work on at the moment)

> Btw: it seemed like you're saying (I read through a couple of
> interviews too) that Apple's horizontal menu bar was a downgrade from
> OpenStep's vertical one, and yet it seems like you're going for a
> horizontal bar yourselves. Am I wrong?

Personally, I like both, maybe with a bit of preference for the
OpenStep's ones. But at the end, we decided to use the horizontal menu
bar for a few reasons:
- easier to reach (fitt's law)
- works better for accomodating a status area
- less foreign to people

What I like in the NeXTSTEP vertical menu is that they are accessible
anywhere with a right-click, that it's easy to drag submenus off and
thus rearrange your workspace/workflow easily (as in addition, those
teared-off menus remember their positions between application
restart).

We do provide those functionalities with Etoile's menus, so I think
that's a pretty good compromise all in all (well the tear-off
capability is not well functioning currently, but you get the idea
;-).

> Language Kit: from some of the examples and discussions, I first got
> the feeling that it was just about putting some Smalltalk syntax and
> block semantics on top of the gs runtime and libraries. There seemed
> to be a focus on compile time tricks, that to me looked kind of
> contrary to the spirit of Smalltalk. As I said, after reading the two
> papers I got a completely different appreciation of the et runtime,
> but I'm still pretty unclear about how Language Kit will work for
> languages whose libraries are not easily mapped onto gs classes. What
> will the benefits be in that case? Why not just create a llvm front
> end?

For me the main interest of LK is the Smalltalk implementation,
because as david would say, I'm a Smalltalk fanboy :)
What this give us is a simpler/cleaner language to write applications
with, but more importantly, a lot more dynamicity (one of our goal is
to be able to develop an application fully at runtime, for example),
yet without breaking the link to existing code (objective-c, c, c++),
allowing for great reuse. So basically we can develop apps in an even
better environment than what Objective-C can provide, yet not losing
much in the process.

Having other languages in LK will be added bonus, as long as they can
be mapped nicely to the runtime -- this does tend to limit us to
dynamic languages, yes. But having a JavaScript-looking language for
example will certainly be of some use.

The main benefit of LK is that by using the same runtime as
objective-c, you have a toll-free integration with existing
Objective-C frameworks.

> Also, I was wondering if it would be of interest to implement fancier
> parsing as part of Language Kit. Maybe parser combinators? Or parsing
> expression grammars? Would that seem like something that belongs in
> Etoile?

Yes, probably more belonging in LanguageKit, but yes I think that'd be cool.

> Well I have and will have a lot more questions. I'm really looking
> forward to seeing how Etoile develops.

--
Nicolas Roard
"I love deadlines. I like the whooshing sound
they make as they fly by." -- Douglas Adams

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Nicolas Roard]

On Sat, Jul 25, 2009 at 6:14 AM, Felix Holmgren<felix.holmgren@...> wrote:

> Well I also looked a bit at the videos from the hackathon now, and
> understand Language Kit better :)
>
> One thing I haven't seen mentioned anywhere in the Etoile docs are
> DSL:s. Granted, it's become a big hype, but I think DSL:s should have
> a natural place in a modern computing system. I saw David referring to
> COKE in one of the papers. Alan Kay' gang at the Viewpoints Research
> Institute, which is behind COKE, is also creating some pretty
> impressive DSL:s. Check this: www.vpri.org/pdf/tr2007008_steps.pdf
> (esp. Apendix E!)
>
> So, yeah: the place of DSL:s in Etoile?

Well, for me DSL depends principally on the underlying language's
expressivity, and Smalltalk (and to a certain extent Objective-C) are
great languages from that aspect...

Now we could have easier way to plug your own grammar into LK, maybe.
David is probably the person to ask :)

--
Nicolas Roard
"I love deadlines. I like the whooshing sound
they make as they fly by." -- Douglas Adams

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[David Chisnall]

> Now we could have easier way to plug your own grammar into LK, maybe.
> David is probably the person to ask :)

Current LK front ends are using Lemon for the parser.  This is simple,  
but it's not a particularly modern way of writing a parser.  A port of  
OMeta to LK has been on the 'open projects' page for two years, so if  
anyone feels like writing it then patches are welcome...

LK abstracts the scanner/parser into loadable bundles (currently we  
have one for Smalltalk, one for EScript), so there's nothing stopping  
someone writing a new front end for their DSL, or a new front end  
using something like OMeta that takes both a grammar description and a  
source as input, rather than just the source.

David

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Felix Holmgren]

>>Maybe
>> I'm stating the obvious, and probably your answer is "yes it's on our
>> todo list", but I think you already have a lot of information and
>> examples available, and you just have to put them up front.
>
> yes.
And of course, the stuff in the Documentation/Developer/ dir is great
if it could be prettied up a bit. I should add that I would be happy
to help with this kind of stuff once I've gotten more experience with
Etoile, since I think it's a great way to learn and an easy way to do
something useful.

> I think we all are very interested in good GUI design and a good UI
> theme. Quite a lot of effort/discussion went in the Nesedah theme for
> example, but as all design, it's a result of a set of constraints..

Ah, yes. I had mostly been looking at the Narcissus samples. Could
only find one Nesedah sample. Are there more?

> For me the main interest of LK is the Smalltalk implementation,
> because as david would say, I'm a Smalltalk fanboy :)

It seems like many/most people who might be attracted to Etoile would
be of a Smalltalk mindset. Maybe it would be good to mention the
Smalltalkish characteristics of Etoile on the front page?

>Well, for me DSL depends principally on the underlying language's
>expressivity, and Smalltalk (and to a certain extent Objective-C) are
>great languages from that aspect...

One can distinguish between embedded and "external" DSL:s and both
have pros and cons. Embedded DSL:s are very popular in the Ruby
community, where people churn them out by the dozen. I'm not sure
that's always useful. I was not only thinking of the *possibility* of
using DSL:s in Etoile, but of making it an active part of the system
architecture. A lot of configuration and code that is concerned with a
clearly delimited domain (like sockets or UI, especially if enriched
with constraints) can be made much more expressive with a DSL. This
translates into easier user configurability and maintenance, and
greater usability of API:s etc.

The thing with embedded DSL:s a la Ruby is that they are great when
you don't care much about what's going on and just want to get some
tasks done fast, but as soon as you want to go beyond that it can be
unreasonably hard to understand what's going on. So I think it would
be great to have a common front-end like OMeta (perhaps in conjunction
with a simplified runtime API, although it's already simply). Once
you've learned that, it will be relatively easy to look at a DSL spec
to understand how it works and extend or modify it. I'm trying to read
up on OMeta now and might give it a shot.

/F

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss