ECS-L Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ECS] Re: If, Then, Else, Etc
Ingo Pakleppa
Thu, 16 Nov 2000 08:26:59 -0800

Peter,

I completely agree with the limitations of the language, but I believe 
there is a reason for it.

First, the language stems from the old DOS version of ECS - and back then, 
the rigid structure was actually an advantage for editing the scripts. You 
weren't expected to ever touch the big config file, but rather use ECS to 
edit events one at a time - the fact that everything was stored in one big 
file was mostly incidental.

Second, remember that this was a *scripting* language rather than a 
programming language. Function calling - which you mention as one of the 
big things that are missing - was not an issue in the DOS version that I 
started with. Today, of course it would be *very* helpful.

And third, I believe that this language has evolved rather than being 
designed from scratch.

Personally, I'd love to see yet something else: freeing ECS from all 
languages at all, and instead having it be a bunch of well-designed COM 
objects or JavaBeans. That would allow you to use any language you like to 
program ECS. I, for one, would like to use C++ (or Java) to program ECS.

Ingo

At 07:25 AM 11/16/2000 -0800, J Peter Young wrote:
>I too am a new user of ECS and I must admit to having a very difficult 
>time learning the language. I am a software engineer with 20 years 
>experience and have written two languages very much like the one used in 
>ECS. My biggest frustrations were:
>
>1. The large config file. I think it is a mistake to recommend people 
>start with the big file. It causes more confusion that it solves.
>2. The "difficult" syntax of the language and a complete lack of 
>documentation on how to use it. Specifically:
>
>The rigid structure of the statements - the formatting and the 4 and only 
>elements each statement has to have limit the functionality and really 
>take a lot of effort to figure out how to achieve even simple constructs. 
>For instance I still don't know how to code
>                 c = b - a
>
>Awkward blocking constructs and very limited function calling. The recent 
>other mail outlines some of the problems with the blocking constructs, 
>beven those are talking about really, really simple programming tasks. And 
>nobody mentioned this like return values or parameters - I know, I know 
>they can all be done with global variables - I mean items. But actually 
>you can't achieve the same functionaly with global variables, only some of it.
>
>
>I pretty sure I understand why it was written this way. The interpreter is 
>simple, it fits the event based nature of the ECS engine and it is was 
>probably easy to extend. But I bet the way it has evolved it is not longer 
>that easy to extend.
>
>For me, the biggest single improvement that could be made to ECS is to 
>replace the existing language with a real language - Java or VB.
>
>But I have to agree with everyone else. Compared to writing all this stuff 
>for myself, using ECS is way, way better. I can change hardware to almost 
>anything on the market and I can get enhancements made by writing a small 
>check. Life is good.
>
>Peter


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.