On Mon, Jun 5, 2017 at 6:08 PM, Jeremy Roussak via 4D_Tech < 4d_tech@lists.4d.com> wrote:
> I’ve missed enumerated types and structs very much, just as I’ve missed such > things as pre- and post-increment and decrement, the ?: construct ... The language is in desperate need of improvement. I have been using 4D since V2 shipped and in that time, there's been arguably no improvements made to the language itself. Yes, we've gotten heaps of great commands and features, but no new *language* features. Processes are a clear exception here as are the various forms of eval() 4D's added. But eval(), in all of its forms, is arguably closer to a poor use of GOTO than any sort of sensible language improvement. Basically, we've got a small subset of what Pascal had 40 years ago. 40. Years. Ago. I think that it's time that 4D got a language person to come in and make some changes. Am I talking about a full OO rewrite? No. I think 4D's procedural language is kind of charming in its way - and procedural code is really easy to follow. (That was the whole point.) I'm after some basic language improvements, not throwing away what everyone knows already. Perhaps the fabled 4D product team should have a language advocate. Someone that would really stick up for the language. So far, I've heard of the product team, enjoyed the blog (it's really good - everyone should check it out), but have seen no engagement from them. They don't seem to comment here or on the Forums, at least in English. A shame. In order of complexity: * 31 characters? Please, it's a source of endless frustration for me. There's no excuse. http://forums.4d.fr/Post/EN/18946884/1/18946885 * How about some normal operators? I mean, you don't have to license ++ and the like, do you? Here's the deal with an interpreter. When you've got a line of code, you have to parse it into a tree. From there, you read up from the bottom towards the top. (This isn't the standard way of reading trees in XML, etc., it's how you process an algabraic expresson.) In that setup, an operator is a node. It's a node that tells you how to act on its immediate children. So, adding new operators should be *very easy.* I don't know how 4D wrote their parsers, etc. - but what I've described is the standard approach. They may be using a parsing library, they may have rolled their own. Either way, operators are nearly the easiest thing to add. * Enumerated types! Once you have them, you wonder how you could have lived without them. * I'm with you on the ternary operator...I ended up writing my own. * The Compiler doesn't work as hard as it should. Some nice changes would be super easy fixes. Super easy. http://forums.4d.fr/Post/EN/19107688/1/19107689 * Full JSON support. * A dictionary of extended properties for *every item there is.* If it's addressable through code, it should have an optional dictionary attached. Just use the C_OBJECT syntax with a unique path as the key into the object. So, form objects, form methods, tables, forms, etc. http://forums.4d.fr/Post/EN/19051683/1/19051684 * No structs or classes. In Pascal these were called 'records' and in C 'structs'. If anyone has worked with C_OBJECT, they let you create data structures a bit like that...but not really. With a struct, you have the ability to declare a custom type. So, you declare a type of Customer and it might have fields like Customer Last_name Text First_name Text First_contact Date ID UUID And so on. Then when you pass a Customer as a parameter, you code can test that 1) It's a Customer. 2) It's a valid Customer. So, the compiler, interpreter and your code can do smart checking of all of these things. As it stands, there is nothing like this in 4D and *it is the single biggest problem with the language.* Having structs would let us do away with a huge range of stuipid little problems. More than that, it allows you to do much more complex and sensible things with no greater effort or complexity in your code. Sometimes I notice 4D developers feeling kind of down about their language abilities. Honestly, a lot of it comes from using a language *that handicaps you.* Better language, better code. Mostly this is work for the compiler developer, it's something that an undergraduate in CS in a serious program could write. * Error handling: This should finally be taken seriously. I always get the impression that it's pretty ad hoc under the hood. If 4D were to commit to implementing Try/Catch, that would force them to sort it out once and for all. * Modules! Another area where 4D devlopers think they're doing something wrong when it's the language letting you down. 4D's peculiar approach to scope and data hiding is fighting for the #1 position in the "ways the language makes us write brittle code" competition. In fact, maybe it is #1. * No libraries. Such a bummer. Components are fine if you're trying to put a big bunch of functionality into a box with a GUI. But for sensible, well divided, reusable code libraries? No, it just doesn't work. Other people will have other items on the list, like: -- It would be nice to have standard packages for text and array processing. 4D's needlessly hard at this stuff. -- The method editor needs some work. -- No built-in version control (yeah, you can export, but not forms, etc.) * Give us access to the code parse tree for a method! We could write our own code scanners. Replace the SanityCheck verification passes, replace the 4D Insider browser. Give it to us and a thousand flowers bloom. ********************************************************************** 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 **********************************************************************
