I absolutely hate no-code systems.
-
I prefer IBM System\360 Machine Language, entered via toggle switches, one for each bit.
Bring back Colossus and the Manchester Baby, I say.
-
and yes I know I am speaking to the choir here. But I just have to vent. so I am working in this system that is based upon data and everything I am sure is in SQL somewhere in the clouds. but am I allowed to connect with like SQL management studio or heck even some sort of command terminal? Nope! so no SQL select available. You HAVE to use their interface. you have to select the whole table first and then you deselect the fields you dont want then you can apply a where clause it is all a stupid IDE with no way to write any freakin Code! and yes I know THEY "think" and THEY "say" you don't need a tech to do this. But only a real tech can actually figure it out. So the no code is less than useless because you actually haven't eliminated a tech job. You have just made it harder.
To err is human to really elephant it up you need a computer
No-Code is just snake oil for incompetent project managers...
-
Which went back to coding in ILE. Ah the joys of RPG calcsheets.
-
The suggestion that C++ is "the best possible language" will probably elicit some choice words from a large section of the profession! I notice how defensive all you coders are (I'm one myself, by the way, nearly a half century of coding experience behind me, come of it on very complex applications) at the idea that "nocode" systems may have merit. I remember way back when Pascal was similarly and widely derided by "real programmers" as a limited language of no merit outside beginners' classrooms, and then found myself managing and supporting a network of CAD workstations running a very stable multi-user, multi-tasking Unix-like operating system written wholly in....Pascal! Not such a Mickey Mouse language after all. Decent programmers will always be in demand, especially those who can adapt to new approaches. Those who can't or won't will wither away, and being defensive about progress or contemptuous towards those who see opportunity in it isn't going to change that.
By best possible end result I mean the best possible compiled native performance. Not necessarily the easiest to program, but the best result for the end user of the app. I think some of the higher level languages suffer from the same problems and shortcomings of no-code but to a lesser degree. Higher level languages such as Java, C#, and even web programming in general were created to save coding time. But they all sacrifice something to get there, runtime performance. I think we need to find better solutions that increase developer productivity without sacrificing native performance and native user interface capabilities.
-
I completely agree. Think of it this way, if you make a "program" that only increments an INT by a number, but then someone asks you to increment by 0.5 :confused:. Originally it was an INT. The no code says the same, I can only work with INTs, so don't change the parameter. No code = More Work = Hype = forgotten in 1 Year. :zzz:
This is exactly what I experienced when trying to build such a system. What would be a better approach in your opinion to provide tools to dramatically enhance the productivity of developers?
-
and yes I know I am speaking to the choir here. But I just have to vent. so I am working in this system that is based upon data and everything I am sure is in SQL somewhere in the clouds. but am I allowed to connect with like SQL management studio or heck even some sort of command terminal? Nope! so no SQL select available. You HAVE to use their interface. you have to select the whole table first and then you deselect the fields you dont want then you can apply a where clause it is all a stupid IDE with no way to write any freakin Code! and yes I know THEY "think" and THEY "say" you don't need a tech to do this. But only a real tech can actually figure it out. So the no code is less than useless because you actually haven't eliminated a tech job. You have just made it harder.
To err is human to really elephant it up you need a computer
Preach Brother Preach. No Code means NO Repair when you need it NO UpDate when you need it and LOTS AND LOTS OF UNNEEDED AND UNWANTED OVERHEAD!
-
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.
-
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!