Icon View Thread

The following is the text of the current message along with any replies.
Messages 21 to 30 of 63 total
Thread New language features
Tue, Jun 26 2018 12:04 AMPermanent Link

Steve Gill

Avatar

<< ooptimum wrote:

So you are a biased one, Jeff. On the other hand, if you provide some service, it perfectly ok to be a one-man-company, but if you are a tool-maker, it's another story, IMO. &#1057;onfidence in the future for the consumer - that's what's important.>>

That's your perception based on the belief that bigger is better, which IMHO is faulty logic. Yes, a one person team could get run over by a homicidal bus driver - that is generally an argument that is used. But how many large companies have dropped products suddenly regardless of "consumer confidence"?

I personally know of a global company that bought a smaller national company that produced medical software.  They paid tens of millions of dollars for it.  The medical software company had around 60 employees.  All went well initially but then a few months later the global company shut the whole thing down because they wanted to change their focus, despite the large amount of money they spent (which was peanuts to them as their annual revenue was in the billions).  Tens of thousands of medical practitioners relied on that software.  And then it was gone.

I have purchased lots of software in the past produced by large companies, which were then dropped with very little warning.  In fact, I'm going through this right now, trying to find a replacement because the company decided to drop a product that has a very large customer base.  You only have to look at the forums to see that no-one is happy but the company is ignoring this.  It only takes a new CEO for it all to hit the fan.

If you're looking for security or guarantees there aren't any, anywhere, no matter what size the company is.  The confidence you're looking for is an illusion IMHO.

= Steve
Tue, Jun 26 2018 3:30 AMPermanent Link

ooptimum

Tim Young [Elevate Software] wrote:

> I don't think you are correct here. In terms of code, the only difference between a lambda and a method is the class prefix on the method.

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.

>I suspect that it's a lot easier than you think once you wrap the functionality in a class.

I'd better give you an example in pascal. Let's imagine that we have a class for communicating with the server via XHR:

type
 // This is a callback function called when record is retrieved
 clientCallback = procedure(HTTPstatus: integer; data: variant) of object;
 // This is an intermediate callback
 serverResposeCallback = procedure(HTTPstatus: integer; response: string; callback: clientCallback) of object;

 DataRequest = class
 private
   // All internal work with XHR is done here
   function DoRequest(url, httpVerb: string; sendData: variant;
     Callback1: serverResposeCallback = nil;
     Callback2: clientCallback = nil;
     asynchronous: boolean = true): integer;
   // Prepare retrieved record for the client and call its callback
   procedure onRecAvail(HTTPstatus: integer; response: string; callback: clientCallback);
 public
   // A client calls this function to get a record. The callback function must be called after the record is extracted.
   procedure getRecord(table: string; id: integer; callback: clientCallback);
 end;

procedure DataRequest.getRecord(table: string; id: integer; callback: clientCallback);
begin
 DoRequest(ServerURL, 'GET', nil, onRecAvail, callback);
end;

procedure DataRequest.onRecAvail(HTTPstatus: integer; response: string; callback: clientCallback);
begin
 callback(HTTPstatus, JSON.parse(response));
end;

Now we will declare what I called an artificial container.

type
 THttpRequest = class
   Request: TXMLHttpRequest;
   HttpVerb: string;
   Callback1: serverResposeCallback;
   Callback2: clientCallback;
   constructor Create; override;
 private
   procedure CallbackOnDone;
 end;

constructor THttpRequest.Create;
begin
 Request := TXMLHttpRequest.Create;
 Request.onreadystatechange := CallbackOnDone;
end;

procedure THttpRequest.CallbackOnDone;
begin
 if (Request.readyState = rrsDone) and Assigned(Callback1) then
   Callback1(Request.status, Request.responseText, Callback2);
end;

function DataRequest.DoRequest(url, httpVerb: string; sendData: variant;
     Callback1: serverResposeCallback = nil;
     Callback2: clientCallback = nil;
     asynchronous: boolean = true): integer;
var
 XHR: THttpRequest;
begin
 XHR := THttpRequest.Create;
 XHR.HttpVerb := httpVerb;
 XHR.Callback1 := Callback1;
 XHR.Callback2 := Callback2;

 XHR.Request.open(httpVerb, url, asynchronous);
 if (httpVerb = 'POST') or (httpVerb = 'PUT') then
   XHR.Request.setRequestHeader('Content-type', 'application/json');
 XHR.Request.send(sendData);

 if asynchronous then
   result := 0
 else
   result := XHR.Request.status;
end;

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:

procedure DataRequest.getRecord(table: string; id: integer; callback: clientCallback);
var
 XHR: TXMLHttpRequest;
begin
 XHR := TXMLHttpRequest.Create;
 XHR.onreadystatechange := lambda
   if (XHR.readyState = rrsDone) then
     callback(XHR.status, JSON.parse(XHR.responseText))
 end; // lambda
 XHR.open('GET', ServerURL, true);
 XHR.send(nil);
end;

Do you feel a difference?
Tue, Jun 26 2018 4:10 AMPermanent Link

ooptimum

Tim Young [Elevate Software] wrote:

> Okay, so what exactly is your concern here ?

Not my personal concern, or mine, but not so big at the moment. I meant what COULD be the reason for doubts for choosing EWB as a tool in a major business project. Hans Reiser got in prison and what happened to ReiserFS? It's still in the kernel, AFAIK, but stagnant and not supported. I guess nobody use it anymore in new installations of linux. Also we are all mortals and sometimes suddenly mortals. I apologize for reminding of this, but this is another unpleasant possibility.
https://arstechnica.com/information-technology/2015/12/ian-murdock-father-of-debian-dead-at-42/
https://www.wired.com/story/giving-open-source-projects-life-after-a-developers-death/
These projects are still alive because they are OSS. Yours ain't. So yes, this is a concern.

Steve Gill wrote:
> That's your perception based on the belief that bigger is better, which IMHO is faulty logic.

Steve, how do you know what is my belief? Do not impute something to me that I did not say.
Tue, Jun 26 2018 5:40 AMPermanent Link

Matthew Jones

ooptimum wrote:

> Do you feel a difference?

Your code is overkill for the first example, and doesn't do all the same things in the second. I've done a lot of request operations, and with a little utility function they amount to:

   xRequest := GetNewRequest(rmGet, rqFetchUserOptions, OnServerOperationComplete, 'api/v1/UserOptions/');
   xRequest.Execute;

procedure TfrmWelcome.OnServerOperationComplete(Request: TServerRequest);
begin
   if Request.StatusCode = 200 then
   begin     
      case Request.Tag of
      rqFetchUserOptions:
          begin
              DoSomething(Request.ResponseContent.Text);
          end;
     end;
   end;
end;

and that has the added complexity of the request type for multi-use handlers. But my handlers also end up doing quite complicated things, and putting all that complication in a lambda doesn't help at all.


So yes, Lambdas might be nice, but they aren't necessary and the existing method is not hard to use. If you are converting, then I could see that they might help, but converting is always complex.

--

Matthew Jones
Tue, Jun 26 2018 5:49 AMPermanent Link

Matthew Jones

Anything you use is like this. Most people here use Delphi - is that any better? Currently it is owned by a company who's strategy is to milk the remaining users hard. And it is DRM protected. What would happen if they stopped selling it tomorrow? The same as would happen with EWB - you'd keep using it, and would have a year or two to use it still before you'd move to something new. In the meantime, we can benefit from the massive productivity it gives.

--

Matthew Jones
Tue, Jun 26 2018 5:51 AMPermanent Link

Matthew Jones

ooptimum wrote:

> These projects are still alive because they are OSS.

Plenty of open source projects end up as dead ends too. And EWB is partly open in that the framework is all there for us to customise.

--

Matthew Jones
Tue, Jun 26 2018 7:17 AMPermanent Link

ooptimum

"Matthew Jones" wrote:

> Your code is overkill for the first example, and doesn't do all the same things in the second.

No, they're completely equal from the user's perspective.

> So yes, Lambdas might be nice, but they aren't necessary and the existing method is not hard to use. If you are converting, then I could see that they might help, but converting is always complex.

Yes, I am converting, not myself, but the code, so I know what the difficulties I am facing with. Why you all are against them? Does someone force you to use them? They are present in the underlying javascript, into which they can be directly transpiled with no difficulty, as Tim recently stated. If they will make EWB a little more fancy, will that ruin your life? They are exist in Smart Pascal, why not here too? EWB is NOT Delphi.

> Most people here use Delphi - is that any better?

Dephi has anonymous functions. You can make closures in Delphi, so yes, it's much better in this aspect.

> Currently it is owned by a company who's strategy is to milk the remaining users hard. And it is DRM protected. What would happen if they stopped selling it tomorrow?

We have a FOSS alternative - FPC and Lazarus, and CodeTyphon if you wish. So it wouldn't be a catastrophe.
Tue, Jun 26 2018 8:14 AMPermanent Link

Matthew Jones

ooptimum wrote:

> No, they're completely equal from the user's perspective.

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');

>  Why you all are against them?

I think you'll find if you read it we are happy that they have their place. Just that they are not necessary, and not there now, so not much point in worrying about them until there are no more higher priority things to be focussed on.

>> Most people here use Delphi - is that any better?
>
>Dephi has anonymous functions. You can make closures in Delphi, so yes, it's much better in this aspect.

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

--

Matthew Jones
Tue, Jun 26 2018 8:20 AMPermanent Link

ooptimum

"Matthew Jones" wrote:

> In the meantime, we can benefit from the massive productivity it gives.

Frankly, I wish EWB a long life and prosperity. I realize that it's a small company behind it, and this company needs our support too, just to exist. So I bought it. Not because I need it desperatedly, but mostly because I just love object pascal. So if something from what I write seems unpleasant, it's caused by the desire to make EWB even better, not to just blame it. 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.
Tue, Jun 26 2018 8:36 AMPermanent Link

Matthew Jones

ooptimum wrote:


> Frankly, I wish EWB a long life and prosperity. I realize that it's a small company behind it, and this company needs our support too, just to exist. So I bought it. Not because I need it desperatedly, but mostly because I just love object pascal. So if something from what I write seems unpleasant, it's caused by the desire to make EWB even better, not to just blame it. 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.

Tim has improved the editor over time, and he has listed improvements he intends to add. But it does what it needs to do now, and can of course be improved as well. The language is very close to Delphi, and one of the things I've appreciated in the past is the ability to essentially copy and paste core classes between the two and have them just work. The main benefit is that you are guaranteed good JavaScript, even if you write bad code (I do wish browsers could handle infinite loops in the debugger!).

--

Matthew Jones
Previous PagePage 3 of 7Next Page
Jump to Page:  1 2 3 4 5 6 7
Image