I have seen some of these but I have very little experience but I am thinking about the complexities and nuances of some of my recent projects and I don’t think, unless the tool let me add some very specific procedural code, that I could create whole apps, especially Web Apps, that would meet the requirements.
In my engineering days I used a flow chart style development language for SCADA systems. It was the only way to program the damn thing so you figured it out. It was not an easy to read format. Graphics is always going to be harder than text.
In more recent years I’ve had various interactions with graphical languages for robotics. FIRST LEGO League (elementary school) uses Mindstorms software and the kids hated it (so did I). To get the details you have to click on the block and sometimes multiple clicks to get the details of what’s going on. The printouts were worthless. Teams that actually figured out how to do sub-blocks win awards for something so standard in OO programming.
In FIRST Robotics Competition (high school) we have the option of Java, C++, and LabView (a graphical flow chart style environment), and some other non-supported languages (meaning you use them you’re on your own - don’t ask FRC for help). I’ve not used LabView but I can only think of a handful of teams I’ve talked to that actually use it. It’s hard to understand what’s going, the details require clicking through objects and viewing their properties. Teams struggle mightily with it unless a mentor uses it for work. Most go with Java because their high schools are teaching it and it’s easy to understand and the built-in Robot Builder gets you 85% of the way there to a working program (and finding mentors for it isn’t that tough).
To put it in perspective in a 15 second autonomous period you get big points, literally for just driving 4 feet forward but yet I’d say 75% of all teams don’t do it. I would bet the a good chunk of those teams are using LabView and struggle to figure out even the basics of autonomous robot programming but it ‘looks’ easy because it’s graphical. In Java and C++ this is a couple lines of code that can be done by setting the motor outputs manually to some value and resetting them to zero after a certain length of time, or if you have encoders on your motors, a certain distance has been traveled. Of course some of these struggles can be laid at the feet of not reading the fine manuals that come along with the control system. These are high school kids after all.
If it makes sense for your users then I’d give it a qualified ‘maybe’. Looping and complex decision branches is where the graphical languages get ugly real fast. But for very simple stuff it’s not bad but ‘simple’ is the keyword. Simple works for examples but real-world applications tend to get complicated and complex and then it’s worse, IMO, than text based languages. Anyway, that’s been my experience.
Bob’s comments would also be my feelings but I just wanted some other perspectives. Simple stuff is simple to do but complicated stuff is still complicated and you need tools that can deal with that complexity.
I think data also comes to play. If your data is not structured well or has anomalies, and sometimes you cannot fix it since it comes from some legacy source, having a “real” programming language is a requirement.
As an “old timer” I have seen many things in Information Technology come along that were “better than sliced bread” but so far we have not eliminated all of the programmers as some have predicted.
Back in my 4D days, there was a competitor called Double Helix by Odesta Systems. It had a visual programming language. Each function had an icon and you connected icons together to create the program flow. As others have mentioned, this is easy and intuitive but it quickly becomes unwieldy. I remember visiting a friend who was doing a large medical application in Double Helix. He had printed out one of the larger routines in his app and it covered an entire wall from floor to ceiling. This will give you an idea of what just a tiny bit of code looked like in Helix.
I had to modify someone else’s LabView code that controlled a custom instrument years ago… Learned just enough to do what was needed, and had it dump the data to text files, and did the additional data processing and reporting in RB!
Dealing with strings in LabView was big pain using the wiring diagram paradigm for sure!!!
Prographs paradigm was very different though
It was inherently parallel as things executed when all the inputs were present
They had to add special “operators” (dont recall the right term from prograph) to make sequencing work
literally so you could say “this runs after this”
Where’s Dr Steinman when you need him ?
He’s the prograph guru
I remember Helix! I might even have bought it… Its Wikipedia page sums up the issue very well: “programming is difficult not because you have to type, but because the complexity very quickly reaches a level where the project can no longer be understood”.
I worked at a place where we evaluated a bunch of these for various uses
Prograph and Helix were on the list - was were 4D SmallTalk HyperCard and a couple others
LabView was only using in a couple spots in engineering
It is incredible to me that Helix still exists. I spent considerable money and time with the product when it first came out believing the pitch that graphical programming was the way to go.It got good reviews. I assumed that my difficulties with the language had to do with my deficiencies. I finally escaped to 4D which I use to this day and enjoy. Helix was such a nightmare that to learn that it is still sort of being upgraded is a testament to the unflagging human spirit of some people.
I think Xojo could help a lot with ‘Less Code’ in regard to database apps. @Geoff Perlman did an AMA on Reddit and mentioned that he wished there was more database integration.
There’s a huge opportunity right now to bring FileMaker developers to Xojo due to changes in FileMaker pricing. FileMaker is low code, which makes moving to Xojo difficult considering amount of code that is needed to list and edit records along with related lists of records. More controls for money, date, time, and timestamp would make the transition easier too.
Moving Filemaker to Xojo requires a lot more than just the database code
Filemaker also incorporates forms and processing logic that is hard to easily transition to Xojo
Now if a person could point some tool at Filemaker and it would pull the forms and scripts etc into some form you could turn into Xojo layouts etc THAT would make a huge difference
EDIT : I have no idea how feasible that is. Its been ages since i touched Filemaker
I’m not suggesting converting. That would be over the top. I’m suggesting making it easier for FileMaker Devs to create a Hello World database by requiring less Xojo code.
Bringing back an updated DataControl http://documentation.xojo.com/DataControl would be huge along with Controls that are DataControl aware. Imagine dragging in a DataControl, set the db creds, set a table name. Then drag a Listbox, attach to the DataControl, set the columns or a calculated column. Then drag Controls, attach to the DataControl, set the column name.
That would make it easier for many FileMaker developers to move to Xojo. Once they see it working, they could learn more about Xojo code by adding in Maps, Emailing, Printing, etc.
Once they see it working, they could learn more about Xojo code by adding in Maps, Emailing, Printing, etc.
