|
"The Configurable System"
|
|
|
|
|
...and less efficient in development and performance.
PowerBI and DAX are perfect examples.
|
|
|
|
|
There is only one I like, and that's Synthmaker (now Flowstone) and it's more like low code in that you usually don't need code, but you can drop to ruby (and maybe psuedo asm with SSE type instructions if they still have that) and code modules with it. Most of it is dragging and dropping these nodes together and building sort of like "circuits" out of them.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Sounds like SSIS, but I "drop to" C#.
And easy enough to use SQL.
|
|
|
|
|
I like only such systems which I have developed myself.
Even then, I can rarely remember how to use them.
modified 13-Dec-22 14:39pm.
|
|
|
|
|
You did document them, right?
No? Well there you go....
|
|
|
|
|
A simple readme file, plus example scripts.
|
|
|
|
|
They have been claiming solutions like that work since at least the 80s.
They don't.
To be fair they try to approach other problems in the same way by applying generalizations to certain types of problems.
Comparable to building houses. They presume it is a tract house. They presume it will be built on an endless tract of land that represents a mathematical plane with an endless unchanging supply of the same materials and with no possible change in things like building codes, water supply etc.
It works as well as that.
|
|
|
|
|
Reminds me of the report generator in CR, or the venerable BizTalk or any number of systems designed to move the coding to the power user, not just a waste of time by the bane of any developer.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
|
Which went back to coding in ILE. Ah the joys of RPG calcsheets.
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Now that reminds me of a time we (my boss) thought to do the same. The project was scuttled after we tested the proof of concept on fellow employees and managers. They couldn’t/wouldn’t do it, so we decided against rolling out to clients.  
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Like trying to program your smart TV with the remote.
Quote: and yes I know THEY "think" and THEY "say ..."
THEY are the THEM. It's all a conspiracy created by the pronoun police.
Nothing succeeds like a budgie without teeth.
To err is human, to arr is pirate.
|
|
|
|
|
No-code systems are just a framework to the max. Convention over configuration.
|
|
|
|
|
I was mouth open amazed that I only learned yesterday, that Azure Portal, the web site, has a command line button, at top, which opens, in page, a terminal to do all your work. and can select to do in bash or powershell
i tottaly suck at using command line, but was like wow, all those guides which use terminal only be very useful.
|
|
|
|
|
You seem to assume it's SQL Server, but it may not be, and even if it is it may not be next year. If you code against the database directly your work will break when the data is moved, to another server, another database system, or whatever. I imagine the system designers want to prevent that.
The system is not there for your convenience, it's there to benefit the business and you are presumably engaged for your professional skills in working with it.
Why not suggest improvements to the interface that would simplify matters, instead of ranting that it doesn't suit your skill level? If you can show how much time and cost they would save, you might find them welcomed....
|
|
|
|
|
What you are saying may be right on some level. The OP wants to vent. Let’s let him do that.
And why don’t you pull your lip over your face and swallow.
|
|
|
|
|
My suggestion was more sensible, and more likely to achieve a useful outcome.
Anyway a 'nocode' system suggests that you don't write SQL code to use it. The questioner doesn't say but I inferred that the API returns data structured in some way (maybe JSON, maybe XML, maybe some other technique that you have to further work with. The intent must be to decouple the data repository from the user, and apart from security that usually is to ensure that if/when the data repository is changed the client side doesn't break.
|
|
|
|
|
haughtonomous wrote: The intent must be to ...
And they might have even rationalized the design that way.
But very seldom does it work.
Adding complexity because something might happen in an unknown future is almost always guaranteed to lead to increased maintenance costs.
And more coupling. That is because the API/interface was not in fact designed to be independent but rather was designed as a wrapper for the existing functionality. So in other words instead of starting with business requirements they started with the functional definition of the very system they are trying to make it independent from.
|
|
|
|
|
The criticism here seems to be confusing the idea with the implementation. Maybe this one wasn't well implemented, maybe so far few, if any, such systems have been because it is a hard nut to crack and as is normal, people are still working out how to do it well. But the idea is just another evolutionary step in software development - and 'proper programmers' are naturally very defensive about preserving their occupation. IMHO their arguments against the nocode idea are no different in intent than the unnecessarily convoluted and opaque documents produced by lawyers, for example, to protect their profession against redundancy. At its heart the nocode idea is just another level of abstraction and decoupling, both important principals in software, but the more of this you have, the less flexibility and more constraints you have on what you can do, and that can be frustrating. Horses for courses.
And of course any well designed system will lend itself to catering for what might happen in future, because otherwise it will have a very short life!
|
|
|
|
|
I think the heart of the problem is all these "no code" systems, fully commit into themselves and leave no room for traditional coding or scripting. I can't stress how much I hate "Flow" and "Power Automate" because of this.
These systems need to be more like the Office/VBA marriage. Sure... you can do some mighty complex stuff in Excel... and spread your calculations and sub-calculations across multiple columns and worksheets and everything... BUT... if you know how to write some VBA code, you can do all that work in a macro much faster. Traditional Excel for the "benefit of businesses" and the "code" side for the power users and developers.
|
|
|
|
|
Migrating to a different DB would mean re-writing the SQL anyway, plus possible changes to the interface as well. I don't see how removing the ability to work directly with SQL would help with this, unless the people using the system can't be trusted with SQL (in which case, maybe there are bigger problems).
I also don't get how you can design the structure and indexing on a DB without knowing how the data is going to be used.
|
|
|
|
|
The great thing about no-code systems is that you create more coding jobs. What about AI? Well, someone has to code those systems too. The problem is like you found, the interface layer will drive a tech-minded person insane because these tools are not made for us. They are made for and sold to managers who spent time in a marketing seminar watching a few examples that were perfectly crafted for the data. They pay incredible amounts of money for a tool that doesn't require health insurance and think they are saving a bundle. Suddenly there's a job opening for a SharePoint/App manager, and too often, it ends up being some non-tech-minded ex-business manager and friend of the HR lady you can't stand that suckered their last organization into moving everything to the cloud...and they need to hire some fakers - "tech-minded" assistants - to actually do the work, and they bother you all day because they can't figure out how to Google.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
|
|
|
|
|
I'm actually working on building a no-code tool for our staff to use for custom reports for our customers, and I'm trying to avoid "... only a real tech can actually figure it out" at all costs. I am putting a great deal of effort into making it make sense and be easy for those with little to no clue about SQL to be able to generate these reports without having to go into the db themselves or waiting for us to do it for them. I wonder if I can do it - make it easier/quicker for those who are uncomfortable with SQL, and maybe no harder nor slower for us.
I'm giving it my best shot.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
