"Matthew Jones" wrote:

>Where in the Lambda version is the equivalent of this line, for example:

>  if (httpVerb = 'POST') or (httpVerb = 'PUT') then
>    XHR.Request.setRequestHeader('Content-type', 'application/json');

If you would read the code carefully, you would mention that it's a "GET" verb used in DataRequest.getRecord, and these lines are irrelevant there, but relevant in generalized function they were taken from, which handles all the verbs. It was just an excerpt from the library.

> Just that they are not necessary, and not there now,

Most of the language constructions are not necessary. It's enough two simple operators for a language to be a Turing complete, believe it or not.

> so not much point in worrying about them until there are no more higher priority things to be focussed on.

There are a bit too many such things for a project of its age, isn't it? Ah, it's a one-man company, focused on quality, I forgot, sorry.

> Now you are quoting me from a completely different context to put words in my mouth - please don't.

My bad. I realized it too late. I can't edit posts here.

ooptimum wrote:

> Ah, it's a one-man company, focused on quality, I forgot, sorry.

Mr. Young, to be clear, I'm not sarcastic about your company or you personally, not at all, but I am sarcastic about the arguments that I was fed here. I admire your dedication and professional approach, which I felt from your answers on this forum.

ooptimum wrote:

> Ah, it's a one-man company, focused on quality, I forgot, sorry.

In the 1990's, Canada's biggest company was Northern Telecom (Nortel), and I have some blue chip now-worthless shares I can sell you from that lesson I learned about big companies not failing.  Instead, they invent new products and drop existing ones without notice or sometimes might fail dismally.  Or have you ever invested coding time in Java only to have Oracle buy Sun and claim you owe royalties?  Big companies cause more pain than small ones.

My investment here is not in the software price, but in the effort I put into writing solutions that would have no upgrade path.

But Tim is honest and has shared his general game plans for ages.  I don't think there are any big secrets that he trades honest good development work for our reasonable subscription every year.   He's not going to walk away from his loyal paying customers unless we make it impossible to continue.  His plans can change over time and with experience, like his earlier goal of a PHP based environment, but I don't think there were ever any unpleasant surprises that I would say are more typical of larger companies.  

Not to pick on Elevate, but my only concern with almost any small software businesses would be to know that there is a succession plan.  I'd like to know generally that there is a source copy in escrow (legal word for safe recoverable backup) in case of fire or an accident, and that the family or heirs can pass a product along to someone who would maintain it if necessary.

FWIW, it can be as simple as an encrypted file (not zip encryption which is easily broken) stored with a friend or third party, and the password stored with family documents like a will that wouldn't cost anything extra.   Knowing that a plan exists can mollify our worries.

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

ooptimum wrote:

> but I am sarcastic about the arguments that I was fed here.

Sure, just as we can be about your arguments. 8-)

Worth saying perhaps that I wrote a software product 15 years ago that uses DBISAM to serve a 24/7 line of business system that really must be reliable or tens of thousands of currency can be lost. I once had an issue with multi-threading, and Tim didn't say "ooh, that is going to be hard, can't help", he asked for the source. He tried it, hacked it about to make it compile for him, made a change to show the problem, and fixed the obscure situation. Two days work, and has been rock solid since.

Maybe that makes me biased, but I've never had such good support from any other business, and the product quality is very high too.

--

Matthew Jones

“ooptimum” wrote:

>> They are exist in Smart Pascal, why not here too?
>> I just love object pascal

From your comments it’s clear that you have yet to undertake a significant project using EWB. However you clearly like Object Pascal and also have some experience of Smart (perhaps significant, but not clear).

My advice would be to attempt a significant project using both platforms and then take a view on the effectiveness of EWB in its current guise. You could also throw in some other environments for good measure. Many on this forum, including myself, have done this.

We’re still here and there is good reason for that. You likely just need some experience to see it.

First of all, I beg your pardon for misspelling your name earlier. It was unintentional fault, and forum gives me no chance to fix it.

erickengelke wrote:

> Big companies cause more pain than small ones.

I am not talking about companies nor I compare big vs. small. It seems that everyone has already forgotten what I actually wrote. Here it is: "everything you write raises concerns for the fate of projects that depend on one person". It was about projects, not companies.

> My investment here is ... in the effort I put into writing solutions that would have no upgrade path.

Is it a kind of similar to what I wrote above? The problem, as I see it, is that Elevate's "bus factor" is exactly 1. Steve grasped this in his message above, but then he tried to veil its importance.

> But Tim is honest and has shared his general game plans for ages.  I don't think there are any big secrets that he trades honest good development work for our reasonable subscription every year.

This approach works for many companies, even in a FOSS world, maybe especially in a FOSS world. You may give your goods for free and sell your expertise then. Exactly as it is on this forum, IMO. I suppose we all paid for this.

It's not my business and I do not know how much Tim earns on this, but I'm very surprised that he spends so much effort in supporting his database products that in my opinion do not stand the competition, instead of focusing on his unique product.

<< No, not only that. As I wrote earlier, lambdas have access to the context where they were called, i.e.
parameters and local variables of the calling function. That's a big difference. >>

Okay, one thing that might help here is that you stop assuming that the person on the other end of the conversation doesn't know what they're talking about.

I know how closures work in JS - the whole language is effectively a set of closures.  And, what you say isn't entirely correct: closures capture the context in which they were *created*, not called.  They might not be called until a later point because all that is getting creating is an instance of a function (or in JS, another hash table instance, er, I mean, "class instance" ).  As you already stated, EWB creates closures in order to implement method pointers that have "this" bound to the method properly for EWB's Object Pascal implementation.  You'll also notice that EWB's compiler does one other thing: it NULLs out any method pointers during class instance destruction (it also does this for other class variables).  This is to avoid a problem with closures in JS, namely that they can cause resource leakage if the closure references are not explicitly NULLed.

But, aside from all that, none of this really has anything to do with what I said.  I said "in terms of code", meaning the code that the developer types.  The primary difference between the lambda/closure version and a method is the class prefix - the rest stays the same.  Yes, the internal runtime *execution context* is different, but for callbacks *in EWB* it doesn't matter one bit.  EWB just wants to capture the value of Self (this) and make sure that it is bound properly as the "this" context for the method call.  This distinction is important because EWB uses method pointers everywhere, and moving to using closures/Lambdas would involve re-writing the way that all callbacks work in EWB, as well as breaking the entire model of Self as it relates to event handlers.  It would effectively involve making EWB's Object Pascal deal with event handling like JS, instead of like Object Pascal.

<< I'd better give you an example in pascal. >>

No, not necessary.  See my first sentence above.

<< Let's imagine that we have a class for communicating with the server via XHR: >>

You already do - it's called TServerRequest and it wraps all of the XHR functionality for you.  So, zero lines of code required.

<< It's 68 lines of code (without comments and empty lines), and auxiliary class invented just to pass a client's callback. And now compare it to 12-line version if there were lambdas: >>

Yes, and the lambda version *directly* calls the XHR functionality.  IOW, you're coding EWB like you're coding functional JS without proper classes, method pointers, etc., and I've already told you this is a bad idea.  The TServerRequest class provides all of the functionality that you keep trying to re-implement, and all you need to do is create an instance and attach an event handler to it.  IOW, 2 or 3 lines of code, at best.

Tim Young
Elevate Software
www.elevatesoft.com

"Matthew Jones" wrote:

> Worth saying perhaps that I wrote a software product 15 years ago that uses DBISAM to serve a 24/7 line of business system that really must be reliable or tens of thousands of currency can be lost.

I would say your choice is questionable, particularly in light of this: https://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&msg=14763&page=1
"tens of thousands of currency" are incompatible to this DB, IMO. (Sorry for saying this, Tim) Maybe you had no choice then?

> I once had an issue with multi-threading, and Tim didn't say "ooh, that is going to be hard, can't help", he asked for the source. He tried it, hacked it about to make it compile for him, made a change to show the problem, and fixed the obscure situation. Two days work, and has been rock solid since.

No doubt the support is superb, but the pace of development is depressing.

> Maybe that makes me biased, but I've never had such good support from any other business, and the product quality is very high too.

I believe you. No questions here.

<< There are three parts in EWB for me: the IDE, the language itself and its RTL/framework. And to be honest, I'm not very satisfied with first two of them. Can't say much about fremework yet. I'm not productive at all. Please, be honest, the editor is a kind of rudimentary. There is no many important features the full fledged programmers editor has to have. >>

It just so happens that the first two are the problems that everyone *else* solves. Why ? Because they're fairly easy and don't require much original thought.

However, with EWB, my main goal was to solve the *last* problem *first*.  Most solutions in this space involve punting back to HTML/CSS and not offering any sort of design-time environment at all (unless they run in the browser itself).  EWB actually solves this issue and allows for a WYSIWYG designer, cohesive layout management, dual design-time and run-time environments with unified UI management, installation of 3rd party components/controls with visual design capabilities, run-time serialization of classes to/from JSON (and no, it's not the same as JS), control interfaces and customization, etc.  It just so happens that such hard problems take a lot of time, and this has delayed some of the other parts of the product (and we're right back to where we started in this conversation).

So, I suggest that you spend some more time with the product before passing judgement.  Right now you're solely looking at certain features in isolation without taking in the whole picture.

Tim Young
Elevate Software
www.elevatesoft.com

Mark Brooks wrote:

> We’re still here and there is good reason for that. You likely just need some experience to see it.

You've got used to it, I am not yet. Take my opinions as a fresh view, not more than that.