On Apr 20, 2017, at 10:23 PM, David Adams wrote: > 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.
Just before I clicked “Send” on my post I thought “this is probably gonna crawl under David’s skin, I can’t wait to read his reply”. You certainly did not disappoint. :) And that is a smiley face because I was smiling the entire time I was reading it. I’m a glass is 1/2 full kind of guy and try to not dwell on the things i don’t have. With 26 years of making a living doing 4D work, I really don’t have much to complain about. > 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. Current 4D components are a good fit for some things and a horrible fit for others. And the only way to find out is to try out your idea. That’s what I’ve done. I’ve been about 50% successful on my component projects. Half turned out to be a success and I was happy with the end result. Half I had to abandon and never finished. I just couldn’t make it work. But I learned a lot by trying different things and learning what the limits are. Now if I have an idea for a component I have a sense of “I can make this into a component" or "this is going to be a problem to make as a component”. > 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. > > 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. I totally agree with this. Adding support for Pascal type record structures would be so useful. 4D should have done it a long time ago. I was hoping the new C_OBJECT variable type would provide that functionality. But it falls short in that it lacks strong typing of the record structure items. We really need a new C_STRUCTURE variable type. Maybe it could be based on C_OBJECT internally but with the addition of typing that the compiler could use. Throw in a try/catch control structure for exception handling and my glass goes from 1/2 full to 3/4 full! But alas they have neglected improving the language. It’s just not a priority for them now. > 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. I think you are right about that. If they would hire a “language” guy that would make a big difference. They wanted to support XML so they hired a guy to do that. They wanted to support SQL, so they got a guy for that. If they are going to update the 4D language — and the compiler to support it — they need to hire a language guy for that. > 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. Too bad David Hemmo — Mr. 4D Compiler — is working at Apple now. Now there’s a guy who could write an awesome 4D linker. Tim ******************************************** Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ******************************************** ********************************************************************** 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 **********************************************************************
