Perhaps it could be in an Enterprise version then, with a few thousand dollars price to justify the work. 8-)

--

Matthew Jones

"Matthew Jones" wrote:

<< Perhaps it could be in an Enterprise version then, with a few thousand dollars price to justify the work. 8-) >>

I understand your irony. But being an experienced developer, I realize that sptlitting code apart is not actually a very difficult thing. It's not much harder than intersection and conjunction of sets. So, I just wouldn't buy it then. Especially since I don't focus just on Delphi-like solutions. We have to admit that these are niche products today.

ooptimum wrote:

> But being an experienced developer, I realize that sptlitting code apart is not actually a very difficult thing.

Presumably that experience tells you that writing the code to manage multiple projects at the same time and doing a large scale multiple compile and tree evaluation will not be so easy. Like I say, its a nice idea, but the cost in development time would be way higher than the benefits to most customers.


--

Matthew Jones

Matthew, I've already understood your position. But let Tim speak for himself. Maybe it won't seem so difficult for a person who independently develops DBMS systems with compilers and interpreters?

<< In my opinion, EWB is a great product with great potential, but it still has some disadvantages. One of its downsides is the very large size of the resulting code. I have not found anything in your message that says that the new version will somehow change the situation.>>

The large size of the code is just the price for all of the functionality being emitted as JS code, and it isn't any worse/better than any other JS code.  It's just how it is, and changing some basic constructs here and there won't put a dent in the size of the emitted code.  The only thing that really works is identifier compression and dead code elimination, and the new compiler *does* to a little better job in that area, so we'll have to see how that improves the situation for your application(s).

<< I have a few ideas if you don't mind, how this can be compensated at least partially. >>

Thanks for the input.  I don't have time to go into all of this in any detail right now, but here are my notes:

1) Re: comparisons - the point of EWB's JS output is to be as compatible with Object Pascal as possible, so as to make it as easy as possible to port existing code (or as much as can be done).  Also, I'm trying as hard as possible to mask the underlying implementation of any given feature in the language runtime, and this is necessary because sometimes you're running JS underneath, and other times you're not.  This doesn't mean that such an intrinsic isn't possible, just that it won't necessarily be able to reflect JS semantics.

2) Yes, and IIF() function would be useful, for sure.  My top priorities for the compiler are getting sets and interfaces completed first, but this type of intrinsic is fairly easy to implement in the compiler.  I added an intrinsic procedure today, and it takes about 5 minutes for straightforward functions/procedures.

3) I understand how arrays work in JS, and I'm not sure why you keep assuming that I don't know fundamental things about JS...do you think that I've only ever used Object Pascal and that's it ?  I gave an hour-long presentation in Buffalo, NY in February on multi-threading/multi-processing in Python - does that help convince you ?

The reason why they work like in Delphi is because the code is *supposed* to be compatible with Delphi/Object Pascal code as much as possible.

4) Sorry, but you won't be able to access invalid array indexes in EWB's Object Pascal implementation, just like you cannot do in Delphi's Object Pascal implementation (at least not without the risk of an AV, depending upon the memory allocation underlying the array instance).

5) Code-splitting is definitely something that I have planned, as it's necessary for web sites that are a collection of EWB applications, as opposed to a single EWB application.  The key here, though, is that you will have to "build" the entire site at one time in the IDE, so that EWB's JS compression still works correctly across all individual applications.

As for other suggestions, please hold off until EWB 3 is out and you can try the new compiler/runtime, and then we'll discuss what can be done moving forward.  Just keep in mind one thing: my primary goal with EWB's language is to *not* turn it into a "kitchen sink" language like C# or Java.  Rather, I just want to make sure that there is a minimal viable set of language constructs that satisfy most needs (for example, interfaces for aspect-oriented development), and keep it at that.  For example, EWB's new interpreter (and the old one) uses manual memory management, so closures are not really something that works well in such an environment without making it harder for the developer to reason about what the code is doing at any given time, especially with regard to memory management.

Tim Young
Elevate Software
www.elevatesoft.com

<< The problem is that the code is not so small. All my initial message is dedicated to this fact. My unfinished mid-sized project generates code with the total size of 3 Mbytes already. >>

This is *with* compression turned on for the project in the compiler options ?

Tim Young
Elevate Software
www.elevatesoft.com

Congratulations on making so much progress on the EWB ecosystem and sharing your progress with us.

I'm looking forward to the beta or even an alpha at this time or any documentation you have.

The sync keyword sounds like something I need for existing projects.  

Are there any performance improvements on existing objects.  I ask because complicated massive EWB projects can sometimes be a bit sluggish parsing data and placing visual objects on the screen.  Not that EWB is particularly slow, but any improvements will be a godsend.

How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible?

Thanks.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

Congratulations on making so much progress on the EWB ecosystem and sharing your progress with us.

I'm looking forward to the beta or even an alpha at this time or any documentation you have.

The sync keyword sounds like something I need for existing projects.  

Are there any performance improvements on existing objects.  I ask because complicated massive EWB projects can sometimes be a bit sluggish parsing data and placing visual objects on the screen.  Not that EWB is particularly slow, but any improvements will be a godsend.

How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible?

Thanks.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

Erick,

<< The sync keyword sounds like something I need for existing projects. >>

I didn't mention that keyword - are you referring to an older conversation ?

<< Are there any performance improvements on existing objects.  I ask because complicated massive EWB projects can sometimes be a bit sluggish parsing data and placing visual objects on the screen.  Not that EWB is particularly slow, but any improvements will be a godsend. >>

Are you referring to in the IDE, or in the browser ?  The browser JS is primarily a function of the JS engine used by the browser, and there's not much I can do in that respect.  The EWB code is about as efficient as one can get in terms of delaying any DOM object updates, etc. during loading.

<< How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible? >>

Yes, it will be backward-compatible for the client applications and you shouldn't need to do anything other than deal with the changes on the server-side.

Thanks.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

Erick,

<< The sync keyword sounds like something I need for existing projects. >>

>I didn't mention that keyword - are you referring to an older conversation ?

Perhaps.  My apologies.


<< How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible? >>

>Yes, it will be backward-compatible for the client applications and you shouldn't need to do anything other
>than deal with the changes on the server-side.

Thanks.  Looking forward to it.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com