headers
Jonathan A Rees | 26 Oct 2003 02:52
Favicon

Re: adoption of E


  Date: Fri, 24 Oct 2003 09:20:42 -0700
  To: e-lang@...
  From: "Mark S. Miller" <markm@...>
  Subject: Re: [e-lang] adoption of E (was: Proposed change to guard
    semantics)

  Everyone, if you're not yet using E, please take a moment and ask
  yourself why not. If you send your reactions either to e-lang or to
  me personally, that would be great, even if it's just to check some
  of the already mentioned reasons.

This question is timely, since I'm just now trying to decide on a
platform for a new project (2 people 3 months).  For us the top reason
not to use E is probably debugging: when something goes wrong, can I
figure out what the problem is, by inspecting the control stack and
lexical environments?  And can I correct the problem (maybe by adding
a method) without losing process state (e.g. TCP connections)?

I know we've discussed this issue but I confess I don't keep up with
the postings to this list and don't know where things stand right now
with E and debugging.  Educate me.

This project has no security requirements, although as always security
is a good thing, and I know you're aiming to make E useful as a
general purpose language.

Macros and familiarity are other desirable features.  Our leading
contenders right now are Common Lisp and jscheme, but E is on the
list.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan A Rees | 26 Oct 2003 02:50
Favicon

Re: adoption of E


  Date: Fri, 24 Oct 2003 09:20:42 -0700
  To: e-lang@...
  From: "Mark S. Miller" <markm@...>
  Subject: Re: [e-lang] adoption of E (was: Proposed change to guard
    semantics)

  Everyone, if you're not yet using E, please take a moment and ask
  yourself why not. If you send your reactions either to e-lang or to
  me personally, that would be great, even if it's just to check some
  of the already mentioned reasons.

This question is timely, since I'm just now trying to decide on a
platform for a new project (2 people 3 months).  For us the top reason
not to use E is probably debugging: when something goes wrong, can I
figure out what the problem is, by inspecting the control stack and
lexical environments?  And can I correct the problem (maybe by adding
a method) without losing process state (e.g. TCP connections)?

I know we've discussed this issue but I confess I don't keep up with
the postings to this list and don't know where things stand right now
with E and debugging.  Educate me.

This project has no security requirements, although as always security
is a good thing, and I know you're aiming to make E useful as a
general purpose language.

Macros and familiarity are other desirable features.  Our leading
contenders right now are Common Lisp and jscheme, but E is on the
list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S. Miller | 26 Oct 2003 05:03

Re: adoption of E

At 05:52 PM 10/25/2003  Saturday, Jonathan A Rees wrote:
>This question is timely, since I'm just now trying to decide on a
>platform for a new project (2 people 3 months).  For us the top reason
>not to use E is probably debugging: when something goes wrong, can I
>figure out what the problem is, by inspecting the control stack and
>lexical environments?

Not yet.

>And can I correct the problem (maybe by adding
>a method) without losing process state (e.g. TCP connections)?

The long answer is, it depends. The short answer is, not yet.

Both of these abilities are planned for, but aren't here yet. They will each 
take a significant amount of work which isn't on anyone's near term 
schedules. Although E was designed with both debugging and live upgrade in 
mind, and I mostly know what I want to do to realize these, currently I can 
only give you bad news.

>Macros and familiarity are other desirable features.  Our leading
>contenders right now are Common Lisp and jscheme, but E is on the
>list.

E does not have macros. The E grammar has productions reserved for a
macro-like syntactic extension scheme I've been thinking about (see the 
"macro" production in e.y), but this is indefinitely postponed. Java and 
Smalltalk do surprisingly well without macros, and I'm inclined to try doing 
likewise for the foreseeable future.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Reich | 26 Oct 2003 15:18
Picon

Re: adoption of E

Mark S. Miller wrote:

>E does not have macros. The E grammar has productions reserved for a
>macro-like syntactic extension scheme I've been thinking about (see the 
>"macro" production in e.y), but this is indefinitely postponed. Java and 
>Smalltalk do surprisingly well without macros, and I'm inclined to try doing 
>likewise for the foreseeable future.
>
I agree that Smalltalk can probably live without macros. But Java 
desperately needs improvement in one way or another. In Java, I have to 
write boilerplate code over and over and over again. I cannot remember 
how often I had to write something like this:

      for (Iterator<File> i = a.getFiles().iterator(); i.hasNext(); ) {
        final File _file = i.next();
        aFiles.put(_file.getName(), _file);
      }

There are basically two concepts that can eliminate this kind of 
repetitive code: macros or higher-order functions with lexical closure. 
Either has been added to Java by various researchers, but none of the 
approaches has been pursued far enough to reach industrial strength. The 
ironic twist here: Java already has a mechanism largely isomorphic to 
higher-order functions with lexical closure: anonymous inner classes. 
But in best Java tradition, they involve so much typing their usage 
would make the above code fragment longer, not shorter.

Getting back to E: E has first-class functions with a short and elegant 
syntax, so most of the boilerplate code can be factored out. I will need 
to gain more experience with actual software development in E to give a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark S. Miller | 26 Oct 2003 16:46

Re: adoption of E

At 06:18 AM 10/26/2003  Sunday, Stefan Reich wrote:
>I agree that Smalltalk can probably live without macros. But Java 
>desperately needs improvement in one way or another. In Java, I have to 
>write boilerplate code over and over and over again. I cannot remember how 
>often I had to write something like this:
>
>     for (Iterator<File> i = a.getFiles().iterator(); i.hasNext(); ) {
>       final File _file = i.next();
>       aFiles.put(_file.getName(), _file);
>     }

I know this is just an example, but in any case, in E:

    for name => _file in a {
        aFiles[name] := _file
    }

(Why is "_file" spelled with an initial underbar?)

>Getting back to E: E has first-class functions with a short and elegant 
>syntax, so most of the boilerplate code can be factored out. I will need to 
>gain more experience with actual software development in E to give a 
>judgement as to whether there is a need for macros.

Exactly. The postponing of macros was based more on our experience with 
Smalltalk than Java. Why do Lisp and Scheme programmers feel a perpetual 
need for macros, while it doesn't hurt to do without in Smalltalk? Mostly, 
simply because Lisp and Scheme programmers spell out the keyword "lambda", 
and so often seek ways to avoid typing it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
marcs | 25 Oct 2003 00:14

Re: Proposed change to guard semantics


> this is a severe restriction. Since the *vast* majority of variable 
accesses,
> even to "var"ed variables, are actually just accessing a location with 
> no side effects or throws possible, this is a shame.

If I understand the proposal correctly (which is doubtful, but one must make 
such assumptions sometimes :-), this is a fine modification to E. However, I 
do wish to disagree with the above statement in case that makes a difference.

My sense of how I've been using "var" versus def since this separation was 
introduced into the language is that the vast bulk of my uses of "var" 
involve a lot of writing and only a little reading. Perhaps this is because 
one of the cases that one thinks of using "var" for I now perform using 
def/bind. Here are 2 common cases I have where I have used vars:

//Situation one: count to get a value that you use once
var count := 0
for each in collection {
    if (meetCriteria(each)) {{ count += 1}
}
//now use the count once to make a decision

//situation 2: set a variable based on context and read many times
var hasProperty := false
if (condition) {hasProperty := true}
//now read the value many times

//Situation 2, as I now do it with def bind
def hasProperty
(Continue reading)

Permalink | Reply | 1 comment |
headers
marcs | 25 Oct 2003 00:30

Re: adoption of E

On Friday 24 October 2003 10:50 am, Marcus Sundman wrote:
> > Everyone, if you're not yet using E, please take a moment and ask yourself
> > why not. If you send your reactions either to e-lang or to me personally,
> > that would be great, even if it's just to check some of the already
> > mentioned reasons.
> 
> I'm not using E because I have the feeling it's impossible to write 
responsive 
> graphical applications using it in its current state. (I haven't tried using 
> swt, but it sure is impossible to write responsive GUIs in native java. In 
UI 
> design there is always the critical 0.1s maximum reaction delay, and when a 
> java GC takes longer than that you are quite screwed.)

You should try E with SWT. All the high-performance heavy-lifting is done in 
the native code, SWT is visibly faster than Swing for both E and Java. I find 
SWT completely acceptable for writing guis, and E's current performance 
weaknesses simply don't come into the equation for most GUI operations. I 
simply haven't had a problem with this.

The one place where E's current performance weakness caused me to adopt a 
different strategy was in generating the outline panel for the eBrowser E 
code development tool. To generate the outline requires chewing through the 
source text in the current textpane, which is sluggish when done in E (though 
actually, since Dean's round of performance optimizations for the jvm a year 
ago, I think even now E is fast enough that one could just do it). The 
solution in this case is to rely on one of E's strengths to compensate for 
its weakness: I spun off the outline computation into a separate vat. This 
was easy to do, delightful actually since I didn't have to worry about 
synchronizing the threads. It worked like a charm.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mark S. Miller | 28 Oct 2003 11:35

Re: Proposed change to guard semantics

At 02:14 PM 10/24/2003  Friday, marcs wrote:
>[...] vast bulk of my uses of "var" 
>involve a lot of writing and only a little reading. [...]
>
>//Situation one: count to get a value that you use once
>var count := 0
>for each in collection {
>    if (meetCriteria(each)) {{ count += 1}
>}
>//now use the count once to make a decision

Good point. And your point probably remains valid despite the following nit: 
The above loop reads count as often as it writes it.

----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM
Permalink | Reply | 0 comments |
headers
Stefan Reich | 28 Oct 2003 12:31
Picon

Re: E as scripting engine

Hi Mark,

thanks a lot for your hints.

My client's planning has changed - they dropped the idea of embedding a 
full-blown scripting language in favor of a more manageable combination 
of JEP (Java Expression Parser) formulas plus plain Java code.

So the urgency of the whole matter isn't there anymore... but having an 
easy-to-use scripting interface for E is an exciting goal anyway, so I 
think I'll give it a go.

This would also enable another nice feature: packaging an E application 
as a standalone jar file (including interpreter and libraries). I 
already wrote a startup class that can be used in such a jar; however, I 
had to save an E script to disk and invoke Rune on it. It would be a lot 
more elegant to execute the script in memory of course :)

Mark S. Miller wrote:

> At 02:02 AM 10/9/2003  Thursday, stefan.reich@... wrote:
> 
>>2. Ease of embedding. How can I embed E? I didn't find a proper embedding
>>API, so I guess I have to dissect Rune.java...
>>
>>What I would _love_ to have is something like this:
>>
>>class EScriptingEngine {
>> void setProperty(String name, Object o);
>> void interpretScript(String script) throws ParseException,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Marcus Sundman | 28 Oct 2003 13:38
Picon
Picon
Favicon

Re: adoption of E

> > I'm not using E because I have the feeling it's impossible to write
> > responsive
> > graphical applications using it in its current state. (I haven't tried
> > using swt, but it sure is impossible to write responsive GUIs in native
> > java. In UI
> > design there is always the critical 0.1s maximum reaction delay, and when
> > a java GC takes longer than that you are quite screwed.)
>
> You should try E with SWT. All the high-performance heavy-lifting is done
> in the native code, SWT is visibly faster than Swing for both E and Java.

I'm not concerned with throughput. It doesn't matter where the "heavy-lifting" 
is done. What concerns me is responsiveness. A GUI program _has_ to be able 
to react to the users' actions within 0.1 seconds.

Clueless developers in general seem to think that throughput matters when it 
comes to UIs. It doesn't. I repeat: throughput does not matter. 
Responsiveness, on the other hand, matters. Look at BeOS. It was "slow" in 
the sense that it had low throughput, but still people perceived it as being 
extremely fast. Why? Because it was _responsive_. And this is just the 
beginning of the story. The "magical" 0.1 seconds is the average limit within 
whitch the brain still comfortably (i.e. without any cognitive load) 
perceives the causal relationship. This is what really matters.

> I find SWT completely acceptable for writing guis, and E's current
> performance weaknesses simply don't come into the equation for most GUI
> operations.

Well, stop-the-world GC is completely out of the question when it comes to 
GUIs. I use the -XX:+UseConcMarkSweepGC switch on Sun's JVM for java programs
(Continue reading)

Permalink | Reply | 2 comments |

Gmane