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 **********************************************************************