3 ms·

I don't think it's about whether a graphical tool is performant. Many programming languages aren't performant either. It's more that graphical tools don't gene

I don't think it's about whether a graphical tool is performant. Many programming languages aren't performant either. It's more that graphical tools don't generally serve their stated purpose of making it possible for non-programmers to get things done because it appears that the main skill behind programming is actually problem decomposition and modelling rather than syntax. Additionally, graphical tools tend to have a bunch of problems inherent to them, such as being unable to write comments and harder to store in git and work on collaboratively and only having one single editor, which is usually much buggier than a text editor and compiler. So: graphical "languages" don't make most things much easier, and make other things much harder.

ibejoeb 6y ago
> it appears that the main skill behind programming is actually problem decomposition and modelling rather than syntax Totally. This is where declarative and intention-oriented systems shine. Take something like SQL, where, in the majority of cases, the end-user needs to know next to nothing about algorithmic complexity and can still achieve excellent performance and correct results. It'd be neat to see a system that was actually designed toward problem decomposition. What's the state of the art around this kind of stuff?
- tonyarkles 6y ago
  We have very obviously worked on different types of end-user SQL. One that springs to mind had 30 or 40 tables, evolved over the years as “special cases” popped up, and by time I was asked to look at it, it was maybe too far gone. I tried. Maybe if the schema had been tended like a garden, the queries wouldn’t have been so crazy, but... Mind, though, that this system had made a ton of money for 15 years, so in a way it was a huge win for them! They just eventually painted themselves into a corner and performance started to get worse faster than Moore’s law could save them. Last I heard, the great untangling is still in progress, and I stepped away from that project a few years ago. They likely have still come out on top when you take the sum of revenue they made from the system, but they incurred a huge unanticipated cost and got backed into a pretty bad corner. Sales people were still selling features that didn’t exist, and the team was desperately trying to build new things while also fixing the ever degrading performance.
hermitcrab 6y ago
I think GUI tools come a cropped when they try to do too much, but can work very well in limited domains. We have recently released a GUI tool to do data transformation/ETL ( https://www.easydatatransform.com https://www.easydatatransform.com ). It is aimed more at power Excel users, than programmers or data scientists. We have tried to overcome some of the issues mentioned here: * It is only intended for the limited domain of data transformation, which limits the complexity. * No need to remember any syntax/commands for the vast majority of use cases. * The transformation template is stored in a single XML file, so it can be versioned. * You can use regexp, Javascript and command line arguments to get extra power if you need it. * It is written in C++ and is fast. Obviously it can't do everything you can do with a general purpose programming language, but it hopefully do enough for many use cases and is much easier to learn.

ibejoeb 6y ago

> it appears that the main skill behind programming is actually problem decomposition and modelling rather than syntax Totally. This is where declarative and intention-oriented systems shine. Take something like SQL, where, in the majority of cases, the end-user needs to know next to nothing about algorithmic complexity and can still achieve excellent performance and correct results. It'd be neat to see a system that was actually designed toward problem decomposition. What's the state of the art around this kind of stuff?

tonyarkles 6y ago
We have very obviously worked on different types of end-user SQL. One that springs to mind had 30 or 40 tables, evolved over the years as “special cases” popped up, and by time I was asked to look at it, it was maybe too far gone. I tried. Maybe if the schema had been tended like a garden, the queries wouldn’t have been so crazy, but... Mind, though, that this system had made a ton of money for 15 years, so in a way it was a huge win for them! They just eventually painted themselves into a corner and performance started to get worse faster than Moore’s law could save them. Last I heard, the great untangling is still in progress, and I stepped away from that project a few years ago. They likely have still come out on top when you take the sum of revenue they made from the system, but they incurred a huge unanticipated cost and got backed into a pretty bad corner. Sales people were still selling features that didn’t exist, and the team was desperately trying to build new things while also fixing the ever degrading performance.

hermitcrab 6y ago

I think GUI tools come a cropped when they try to do too much, but can work very well in limited domains. We have recently released a GUI tool to do data transformation/ETL ( https://www.easydatatransform.com https://www.easydatatransform.com ). It is aimed more at power Excel users, than programmers or data scientists. We have tried to overcome some of the issues mentioned here: * It is only intended for the limited domain of data transformation, which limits the complexity. * No need to remember any syntax/commands for the vast majority of use cases. * The transformation template is stored in a single XML file, so it can be versioned. * You can use regexp, Javascript and command line arguments to get extra power if you need it. * It is written in C++ and is fast. Obviously it can't do everything you can do with a general purpose programming language, but it hopefully do enough for many use cases and is much easier to learn.