[throwaway_pdp09]

I'm going to disagree here, though sort of understand what you and the original poster are saying.

In short I've seen the mess that 'unsilled' people make using complex tools. Tools such as databases (my area) are presented as being easy to use by microsoft, who make a lot of effort to make it easy to use. Too easy. Not because I want to keep people out, far from it, but because if they don't know what they are doing they get only so far, then things go bad and they've no idea why. Drag/drop, point/click only goes so far.

I guess no complex tool can be (or should be?) used with concomitant levels of training. It's not an argument for code gurus to make themselves a comfortable walled garden to preside over and keep others out, it's an argument that tools should come with training, always.

The problem these days is the hirers just want everything (blah blah full stack blah) and don't understand the cost of getting it wrong because it works - up to a point. MSSQL, Spark, Kafka, down to failure to understand how CPUs work. They all get treated as black boxes, and that's fine up to a point. Then things break or don't scale. Out of my sphere I see so many websites that have no basic understanding of usability, or standards, or accessibility, security and by web devs that barely understand HTTP.

If it's plain line of business, unimaginative gruntwork that keeps a business alive with spreadsheets etc, then that's what's needed and basic understanding is sufficient. I've done plenty of jobs like that, they keep the economy going, but if you want heftier dev work, I don't think that will suffice.

I guess that makes me sound a snob. Not intended that way, just saying complex tools may not be usable to their full capacity without understanding them. I may be wrong too.

[oblib]

I get what you're saying, and you're right.

But... so am I. The gap between us is education. What I propose is that one could take a class to learn how to make apps, as oppose to a CS class. I don't think a GUI app maker is the right approach to lowering the bar to custom apps. I think learning how to use API's is.

HTML is a great way to start. Then CSS. Then basic Javascript. From there you start bringing in tools like Bootstrap, jQuery, and PouchDB.js. From there you teach how to integrate most any JS toolset, like Mustache.js and Accounting.js. At that point things like React and Angular are already accessible.

When you focus on the tools and techniques to build apps it becomes more accessible and, yes, there will be some really crappy apps made, but there will also be those who do it very well.

Now... if you add into that mix turnkey opensource apps that already do something well that anyone can twiddle with it can really make a difference for all kinds of businesses.

Big businesses already have access to that kind of specialization of software but we're close right now to being able to lower the bar for medium and even small businesses to have affordable access to tailored apps. Local shops that make websites could offer those services to local businesses.

So I see it as a way to raise all the boats in the waters. But yeah, there will some trash and flotsam there too. Same as it ever was really. Just lowering the bar of entry.

[slifin]

I don't know, if a system exposed a EAVT database like Datomic where you don't need to normalise tables and you don't have to index manually and the n query problem isn't an issue then I think a non expert could get a lot further with the right UI then someone given a traditional SQL/NoSQL database

It's easy to make things complex and its hard to make things simple but if we can simplify to a data model then we can do declarative programming and make systems more tenable

Thinking in declarative data models is hard if you're not used to doing it, I'd recommend looking at the following libraries in Clojure: Garden, Hiccup, HoneySQL or Drupal's form management, or kind of ReactJS if you stretch your idea is what data is, they can all handle complex but focused tasks

[throwaway_pdp09]

I have to be sceptical about what you say, so understand that comes from lack of knowledge of what you're getting at (but I do know my SQL very well, and I do know declarative programming, of which SQL is an instance)

> EAVT database like Datomic where you don't need to normalise tables

That is a strange comment to me. Normalisation is not about databases but about data management. The value of normalisation doesn't go away just because you're using a different DB, because it's solely about relationships in the data.

> and you don't have to index manually

Woo, don't know what to say to that. Could you provide some pointers to both of these (normalisation and indexing) and I'll do some reading, thanks. I find that very hard to believe (no offence!)

Agreed about the 'hard to make things simple' but

> if we can simplify to a data model then we can do declarative programming

That data model is arguably normalisation. SQL is declarative, and I've seen the results of ignorance applied to that, so I can't buy that just using SQL protects you much (although it does to an extent, I suppose).

Declarativeness makes things easier on the programmer up to a point. When things break, there's not much you can do - and things can break easily in SQL. Writing good SQL, like any program, takes skill.

Also I recall many years ago finding out the hard way that you have to understand prolog's (relatively simple) search strategy to get decent results from it. Just 'declaring' your relationship between input and output didn't work at all well (I don't remember the details but I remember the lesson I learned).