Tim, I finally said "what the heck" and am giving my blunt opinions below.
Don't take the torrent as directed at you. I think that you made an
intelligent and high-level argument. I mean, you're wrong, but at I don't
hold that against you ;-) That's not an ironic smiley face...I grew up in
schools where the whole class period might be spent fighting about stuff.
They thought it was good for us. In a way, it was...in another way, not so
much.
> 4D supports only a single level of components. You can’t have components
> inside of components. It would be a nice feature to have in some
situations.
Thanks for the confirmation. This makes 4D components pretty much a
non-starter for me. I can see how if you know this (and the other)
restrictions in mind, you could do an okay job. As an example, Cannon's
Obj_ module isn't a component, but I just compiled it to one and, so far,
it seems fine.
> I think we sometimes forget that 4D is not a 3GL programming language
like C
> or C++. 4D is a 4GL language. You don’t get all the feature, benefits and
> capabilities of a 3GL language in a 4GL language. Remember why we all use
4D
> instead of using C++. You can get so much more done with 4D in less time
and
> with less programming effort than doing it in C++.
I appreciate your point, but don't forget for a minute that 4D is what it
is. Then again, the language hasn't been improved since the 1980s, and that
has nothing whatever to do with it being a nGL. I tend to think of it as a
structure language because, well, it's sort of a subset of Pascal. Pascal
is famous as a structured language because that's where it comes form. Many
structure paradigms are with us today, albeit in different outfits, and
many new concepts have been added as computer science has advanced.
Structure programming was *obsessed* with the flow of control through the
system and the use of proper control structures. We've got the basics in 4D
(and always have)
If...then...else
Begin...end (in various flavors)
Case of...
That's it. The 4D collection is somewhat simplified, but that's not all
bad. I like 4D's version of the case structure, for example, although a
purist would declare it Forever Unclean! Case was meant to be a clean way
of doing a multi-part if. More like a switch in a lot of languages. 4D lets
you combine different tests in the same structure. Nice, but less easy to
test formally. Back in the Day, Dijkstra and the crew really believed that
it would be possible to prove the correctness of computer programs, like
math proofs. They tried, made a ton of progress, gave us some great ideas
and practices...and realized that formal proofs weren't going to happen.
(The world of formally correct program still exists, but tends not to use
languages anything like Pascal or C++, for that matter.)
Structured Programming wanted there to be a single point of entry for any
method, and a single exit. Again, obsessed with testable and predictable
code. It was a different world, when "GOTO considered harmful" came out,
the basic control structures that we can take for granted didn't exist. We
take them for granted now because they solved a fundamental problem that
didn't change. The point of Pascal was to make the language itself remove
entire categories of problem before they ever happened. (As is the
motivation for many new languages.)
So, way back in the day, before 4D, we had things like:
* Semaphores
* Constants
* Message queues
* Records (structs, the basis of Abstract Data Types, part of what evolved
into Objects)
* Enumerated types
* Domains (custom types defined by a range of possible values)
...and more.
When was this? The late 1970s? I'm not talking about anything particularly
modern or particularly hard. Man, our life would be *so* much easier with
what Pascal called 'records' and C called 'structs." Here, I just dug up a
Pascal example:
type
record-name = record
field-1: field-type1;
field-2: field-type2;
...
field-n: field-typen;
end;
Here is the way you would declare the Book record −
type
Books = record
title: packed array [1..50] of char;
author: packed array [1..50] of char;
subject: packed array [1..100] of char;
book_id: integer;
end;
The record variables are defined in the usual way as
var
r1, r2, ... : record-name;
Alternatively, you can directly define a record type variable as −
var
Books : record
title: packed array [1..50] of char;
author: packed array [1..50] of char;
subject: packed array [1..100] of char;
book_id: integer;
end;
4D could throw in with some syntactic sugar to make it look less geeky but,
honestly, how hard is that? It's *vastly* simpler than trying to do
something like that with C_OBJECT. with C_OBJECT, you get a kind of data
structure, but you get *no* help from the compiler on type validation.
Beyond that, the 4D language's incomplete support for JSON makes it
*impossible* to retrofit your own meta-data/schema system to (laboriously)
do your own type enforcement.
Man, wouldn't it be nice if you had a structure defining, oh, let's say a
process setup:
$customers := New(ProcessSetup)
$customers.name := "Customers"
$customers.table := ->MyBigArrayOfStuff
$customers.max_rows := 100
...and then the 4D compiler kicks back the obvious error:
$customers.table points to an array instead of a table.
So much easier and better than what we have today. Despite using dots,
that's not an object. It's a typed data structure. We need it, we've always
needed it, and it's easier than what we've got now.
Since I've used 4D, here's what they've added to the language:
Processes
GOTO or eval in a variety of sexy skirts
That's it. I'm afraid that the Structured Programming's prohibition on
GOTO, which was broadly misunderstood, has lead to an avoidance of proper
approaches to exception handling. There just isn't a better way to do
exceptions or other interrupts than a goto. I mean, regardless if it is
managed through a callback or a control structure, regardless of what you
get (an event record or object, a code, whatever), it's still formally a
goto. What else would it be? Right now we've got ON ERR CALL and it doesn't
really work reliably or universally. What we need is something more like
Try/Catch.
Why am I talking about Structured Programming at all?
-- Because 4D came from Pascal
-- Because Pascal came form Structured Programming
-- Because Structured Programming came from Dijkstra thinking hard and well
about the complete nightmare that was code in his day. (I just read up on
him and have a total nerd crush. The guy was intense and amazing. We owe
him, well, almost everything. there is a straight line form him through to
the most advanced languages today.)
> 4D provides many things that you can get from 3GL languages with less
effort
> but with limitations. If you want something without the limitations you
can
> have it, but not with 4D. Switch to C++ and you can have everything that
you
> want.
Yeah, it won't be C++. I also think your argument is a bogus. I mean, 4D
has added tons of features down the years, why on earth couldn't they
improve the language? Why is this most fundamental and important of
features supposed to be "take it or leave it." That may well be the case
(it seems to be), but I completely reject that there's a defensible reason
for this. You could easily have a 4DGL with a better language (Delphi!)
Plenty have existed. An improved language would be a huge benefit to us,
reduce bugs, make it easier for us to scale out our code, etc. I'm not
asking them to reject their structured roots, I'm asking them to embrace
them. Instead, they've been bolting on yet more versions of EXECUTE (eval),
which is about as antithetical to structured principles as you can possible
get. And no scaffolding. They don't protect us at all with EXECUTE in its
many forms. I mean, the amount of time poured into object fields. Object
fields? Why? It's a feature to be used sparingly, if at all. Cool when you
need it, but if you need it often - you are definitely are misunderstand
something. But the core language features? EVERYONE benefits from
improvements there.
And again, I'm not asking for 4D to do a completely new language. No
thanks, we have a zillion modern languages to choose from. I'm asking for a
sensible evolution of the language:
* Data structures that were in Pascal back when 4D was a baby.
* Exception handling like any sensible language.
Those two alone would help improve quality by huge, huge amounts.
> Also 4D is an environment that has a long history with a tremendous
amount of
> legacy support.
For sure. And there is no end to my respect for 4D for maintaining support
so well for so long. They have done an amazing job, and not one to be taken
for granted. I don't think anyone even comes close to them in this area.
Kudos^2. We should all be grateful. I am.
> To provide many new features and capabilities that many want
> could quite possibly require dropping legacy support.
Adding structures? Nope, that breaks absolutely nothing. Improving
exception handling? That might. Well, it also might because silent
exceptions now appear. But if they added it through a new control structure
(try/catch), then, presumably, old code could work as it does until you
choose to use the new structure.
> I’m sure the 4D engineers, when they were designing the component
> architecture, did the best they could in the 4D environment they were
working
> with. They had to work within a system that they already had. They
couldn’t
> start from scratch. They had to integrate components into the existing 4D
> environment. And that includes supporting the 4D Compiler.
Sure, but that doesn't mean that they came up with a great solution, albeit
perhaps the best they could. Given how various features have been
implemented in the past few years, I don't get the impression they've got a
language guy on the team. They're a special breed and a bit rare. I never
hear anything out of France that sounds like they've been thinking about
the language itself.
Anyway, I've tossed everything I need into one giant component and then
compiled OJB_Module on its own. (It's in my big component but not shared.)
I'll try it out and see how it goes. If it works and keeps all of the
distracting plumbing out of view, I'll try and use it.
> Consider the complexities of integrating components that may or may not be
> compiled and then building a final compiled 4D application incorporating
these
> components. Now include a multi-level component architecture that goes n
> levels deep. Think 4D compiler linking nightmares.
Yes, a linker. That's what's needed. Otherwise, it leaves us with not so
many great choices. If they did the linker, we would all benefit. Linkers
aren't exactly a modern tool - there's plenty of existing art out there.
> Makes me think of the proverb “You can’t have you cake and eat it too”. :)
I'm pro cake! I'm pro eating it, and I'm pro having it.
**********************************************************************
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
**********************************************************************
