Well, I've answered your various points but, overall, I'm disappointed that
you've again failed to offer any actual technical content. Perhaps Thomas
Maul would contribute? He often does not agree with me, but his arguments
are always well-reasoned and technically interesting. Even if Thomas scolds
someone, it's after providing good information.
I also think it may be too easy to get caught up in how cranky I sound. So
I sound cranky, so what? That's more my problem than anyone else's. Does it
make me or my arguments more convincing when I sound like that guy on the
bus that no one will sit next to? No, not really. I do myself no favor,
your best option is to ignore my frustrated sounds and focus on the
technical merits of what I'm saying. If I'm missing something or being
stupid, I invite correction. And at least I'm still here, the other 4D
people of my generation are quiet...because mostly they are gone. Hey, I
like 4D! We all do. I mean, there's no real need to convince 4D people to
use 4D. We all want it to be better.
Since this whole thing has gotten absurdly long, I'll repeat my basic point
on its own:
CALL WORKER is a remote procedure call system that injects EXECUTE(code)
into a process.
If cooperative code is injected into a preemptive process, bad things
happen.
4D should do less bad things and tell us about the problem via ON ERR call.
That's it. It strikes me as a pretty uncontroversial statement so I don't
understand what the fuss is about. Why wouldn't someone thing it makes
sense to provide an error at this point?
> Concept of Workers is very new in V16, you know that you can expect
improvements in the future.
Of course! Discussion of the subject would be pointless if there were no
chance of change. However, I cannot make any plans based on what *might*
happen in the future. So, speculation is of zero practical value for me.
I'll also note that while "workers" are new in 4D V16, the underling
concepts and tools are neither new nor unfamiliar. They're just new in 4D.
Meaning, there are many, many long-standing implementations that 4D very
likely looked at and considered while developing their design. Like any
other programming team, the crew at 4D must have considered alternative
designs when they came up with what is now CALL WORKER and CALL FORM. I can
see why they picked a remote procedure call scheme, but I can't think of a
single other messaging architecture that works that way. But either way, it
was a design choice made in France, not some sort of discovery and not some
sort of law of nature. Their is nothing sacred about the design.
Now, they had to make choices to deliver a product. Their choices have very
good results and less desirable results. I have been continuously praising
the good aspects. So much so that these features convinced me to move my
own development from V13 to V16. I was also excited enough about these
features arriving in 4D to sign up to do my first 4D presentations in a
decade. So, yeah, I'm a fan.
I'm also willing to say what is a weak spot and what I see as preferable
design choices going forward. Error handling has always been a terrible
weak spot in 4D and my latest "feature request" (it's really about a
bug/design flaw) shows me that 4D still doesn't appreciate the importance
of consistent and reliable exception handling.
> You cannot get something at this level of complexity and have all
finished at once, in a perfect way.
And you cannot expect customers not to say that are unsatisfied by an
incomplete implementation. As it stands, the current design makes a great
many normal messaging patterns difficult or impossible to implement. 4D
could have done this sort of design *without more work* and given us a very
different system:
LAUNCH WORKER("Worker_Name";"Worker_Handler_Name"")
CALL WORKER("Worker_Name";$object)
// Worker_Handler_Name (Object)
C_OBJECT($1;$message)
$message:=$1
// Do whatever you like.
That's the simplest alternate version. At that point, the problem I have
been describing *would be impossible to create.* The flaw doesn't come from
some future feature not being implemented, it's a consequence of the design
itself. 4D can improve the situation by trapping the error when running
EXECUTE inside the worker....but the underlying design is what makes it
possible. The positive side of the design is that it's very easy for people
to reuse existing code without having to mess with C_OBJECT. The downside
is that you can blow up your server.
> IMHO, it's the new way (for 4D Developers) to think their application's
programming.
> We go from a synchronous way of programming, into a totally asynchronous
way, from
> loops to messaging (CALL FORM & CALL WORKER), which is not simple for
many developers.
I can't say. Anyone that's dealt with JavaScript has dealt with a vastly
harder to deal with version of asynchronous programming. In order to
achieve many normal results in 4D you'll need to roll your own versions of
features provided by asynchronous environments. I'm sure you get these
questions all the time:
Q: How do I get an answer from a worker?
A: You don't. A worker can send another message. But only to a worker or a
form.
Q: What form event is triggered by CALL FORM.
A: There isn't one. It's not a form event.
Q: So how does my form method catch CALL FORM?
A: It doesn't. The code is executed in the process that runs the form in
the context of that form. (In case you're using form variables.)
So, there's plenty to learn anyway and some obvious features
(call-response) that aren't implemented.
4D's implementation is only partially asynchronous anyway, but in a good
way. It's not that hard to follow. I don't see how using remote EXECUTE is
easier to understand than sending messages.
> I don't really care the way it works today, as long as I can use
> it until the next 4D versions, in which these concepts will be expanded.
Just to get back to the original report, I'm talking about a *bug* in the
*current version* that makes these features *unreliable* for use in the
very situation they were supposedly designed for. As far as "future
versions" go. I don't care. How can I? They're completely imaginary. 4D
doesn't publish road maps so I can't even go on something like that. And,
based on history, there's no way to count on what I want or need being
implemented.
A bunch of examples:
-- Improvements to the SQL engine? Nope.
-- Object fields in SQL: Nope. Don't put them in your tables.
-- Proper JSON parsing? Nope. You don't need it. (Every other on earth has
it.)
-- Decent SVG support? No, we have a widgety thing.
-- 4D Chart? No. But we did give you a little graphing toy.
-- Support for later versions of XSLT? Answer: We're dropping all support.
-- 31 frickin characters. Seriously?
-- No structs/rects/classes
-- No data hiding
-- No try/catch
-- No dots in "objects". Actually, that seems to be coming. But if it's
just dot syntax and nothing more, it's only a convenience & I use Cannon's
tool already.
Contrarily, I saw 'contextual mode' in *alpha* and said, more or less "Nuke
it from orbit, it's the only way to be sure!"...but it lingered on for,
what, a decade?
Then again, 4D Write did come back to life and is looking great.
So, no, plans based on future versions aren't a safe bet. And given how
long the future is, I might not have time to wait long enough. 4D might do
something very welcome (4D Write users must be happy), or something very
disappointing (no 4D Chart, no JSON parsing.) Either way, "the future"
hasn't arrived yet so it's not worth a plan.
> I do not concentrate on the missing features in 4D, I prefer to learn how
to use the new ones,
> and to do the preliminary work in order to find the easiest practical way
to use it, for
> developers to not waste time disentangling the different possible paths.
I find it deeply disturbing that a representative of 4D France somehow
thinks that basic error checking is a weird thing to worry about. It's
basic. I need to know and consider what happens when things go wrong.
Otherwise, you can't deploy reliable software. Quality control is a
fundamental part of modern software development. It's not some exotic or
optional idea. When I'm doing due diligence, I try things out to assess if
they are reliable enough to use. Nothing, nothing at all could be more
practical. This is a fundamentally practical concern. In this case, I'm not
talking about a weird condition, an edge case, or anything unlikely. I'm
talking about a very basic problem that the design absolutely allows. It's
a simple fix for 4D and I absolutely reject your implication that I'm
somehow not understanding or doing something wrong. No.
Now, if I were looking for trouble with these new features, I could find
them. I stumbled across a race condition *that should be impossible* having
to do with the file system. I found this (by accident) and put together a
demo to reproduce the problem in about a minute. On Windows, it crashes the
machine. On Mac, it just locks up 4D so badly you have to force quit it. I
submitted everything through official channels and it's in the bug system.
Here's what I've heard from 4D France:
Full quote. I've tried it out again in 16R2 and 16.1, no difference. So,
yeah, I'm concerned about quality. I talk to lots of developers and my
impression is (and has been for years) that people care more about
*reliability* than features. Speed bumps and features are great! But people
most need reliability. When things crash or don't work right, customers get
very upset and it's stressful. That's most developers #1, #2, and #3
>> That's true. But you know, Life is unsafe at any speed.
> ? That's just an odd thing to say.
Yes, probably, but this is the way it works...
I honestly have no idea what you're trying to say. That everything carries
a risk so don't worry about it? That's a frankly frightening attitude
towards risk analysis or software quality. Not all risks are of the same
likelihood, size, or consequence.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
