by tester34 on 12/17/21, 11:15 AM with 130 comments
I do wonder how it'd be designed, maybe current approach sucks?
OOP is beautiful itself, it *enables normal people* to model complex systems that'll be running on computers, but can we get even better?
by danpalmer on 12/17/21, 11:43 AM
Most people I work with who are non-programmers but who could benefit from coding spend a lot of their working life in Excel. When we teach them SQL and give them access to our data warehouse, a lot of the time the explanations that stick are thinking of it like a big spreadsheet with lots of pages and columns/rows. Spreadsheets are fundamentally very visual, and have few abstractions to get your head around before you can start work. (There have been "visual programming languages", but these often look like graph editors and I think that's a complex enough abstraction that it complicates the process).
From this we've then seen a whole load of tools that are trying to be "smarter" spreadsheets. Things like Airtable. Is it a spreadsheet? Is it a database? Is it a no-code application? Is it a project management system? Is it a calendar? Well, yes. Retool, and others also fit into this. They all have a lot of spreadsheet like functionality.
by j-pb on 12/17/21, 11:38 AM
The good: Excel, Dataflow Diagrams (commonly found in game, music and arts), SQL, Declarative Dataflow Paradigms in general. Mutablity is counterintuitively counterintuitive if you don't have a model of the underlying execution system.
The weird: Prolog, APL, languages done by mathematicians and logicians
The ugly: SPSS, R, two languages done by statisticians, and they are absolutely abhorrent, and often missused.
If we reinvented programming today my guess is that it would be a lot less text driven and a lot more data oriented.
by jasonhong on 12/17/21, 2:39 PM
In particular, one of his PhD students John Pane did a number of studies looking at how people would naturally describe the behaviors in Pac Man. It was really nice work.
You should also take a look at Programming by Demonstration. One book, Watch What I Do, is published online in its entirety by the editor Allen Cypher, see here http://acypher.com/wwid/.
Another book in this space, Your Wish is My Command, is also published online https://web.media.mit.edu/~lieber/Your-Wish/
Both of these are collections of research papers showing how people can demonstrate what they want to a computer, and have the computer figure out what they want. There's a more recent book on programming by demonstration, but I don't recall the title.
But definitely check out the first link on Natural Programming, Brad Myers is one of the world experts on this topic.
by depaya on 12/17/21, 3:06 PM
I don't think this was necessarily created by non-programmers, but it was certainly created for them. The language is designed to mimic electrical schematics with the idea being electricians, electrical engineers, etc can easily program and debug in the language.
I'm a software engineer who has worked extensively programming PLCs with Ladder Logic and I must say it can be quite fun to work with.
by OJFord on 12/17/21, 1:06 PM
I got there by thinking 'probably not that far off python, but even more pseudocodey, a load of redundant keywords like `for every item in` instead of `for v in`' -- and such constructs probably wouldn't bind variables, you'd repeat yourself referring to `the item` or something.
I also think there'd probably be a lot of focus on (high school) mathematical functions (since that would be the expectation of what computers must be like) and graphics (because that's what computers look like). So everything would be about identifying pixels on the screen and colouring them, locating the cursor by position, that sort of thing.
by JackMorgan on 12/17/21, 1:22 PM
I definitely would not agree that it "enables normal people to model complex systems". Not once in my entire career have I seen a business person provide anything of any value to a software's architecture. Even thinking they could is so strange to me I don't even know where to start to unpack it. Software architecture is so different to the processes it models, it would be nonsensical to even have them try. Like asking someone illiterate to organize a book.
Wasn't that whole concept just marketing by Sun to sell Java and OOP to the world? These days everyone using Java uses so much spring and xml I'm not sure it even makes sense to call it OOP anymore. It's more like AOP+DI with a little OOP thrown in.
If anything, I'd think trying to have a customer design your objects would result in a tremendous mess. The nouns and verbs they would think of are going to be extremely limiting once you add in the common needs like caching, parallelism, network boundaries, async processing, auth, logging, monitoring, protocol formatting, API versioning, etc. The hard parts we need help on from business people are understanding the business models completely, not where X function should live and if it should be in a class or not. And even if they did have strong opinions about that, logic is actually much easier to test when it's not in OOP, and I'd rather have automated unit tests.
by open-source-ux on 12/17/21, 12:10 PM
Programming in plain text (in a monospace font) hasn't changed for decades. It doesn't look like it will change for the foreseeable future either. This isn't because plain text is inherently superior. We're still relying on clumsy, cryptic syntax determined by the limited characters available on a keyboard.
The simplicity of text is very appealing to developers. But arguably, it's modern IDEs that make dealing with plain text tolerable - without them, the simplicity of text would rapidly lose its shine. And modern IDEs are enormous in their complexity and millions of lines of code.
So new programming ideas may come from unexpected quarters. And maybe less likely from developers conditioned by existing languages and tools.
by AnimalMuppet on 12/18/21, 4:21 AM
Then he'd draw this beautiful menu. And I'd say, "How does it know that you want to do X instead of Y?"
We'd go back and forth, and wind up with something that was both graphically good and also unambiguous.
If you just have the non-programmer doing the design, I worry that it would stop at the "ambiguous" stage. There's a level of technical rigor that is needed, and non-programmers may find it hard to achieve it.
by bsenftner on 12/17/21, 1:01 PM
by efitz on 12/17/21, 1:02 PM
by ksec on 12/17/21, 3:17 PM
I think Non-programmers would want programming to be more graphical, Diagram Dataflow and Graph-like with the help of "script" / functions describing actions. Something like the how current Game Engine are structured.
May be Game Engine should be programming engine.
by Jtsummers on 12/17/21, 3:52 PM
For instance, a friend worked in "manpower" (operations research work, trying to understand and improve the workflow of a 15k person industrial workforce). One of the tools was a hybrid of a graphical model + R-kin language. The model looked like any ordinary flowcharting kind of thing, though the data attached were numbers like throughput, reliability, etc. And when "executed" it would produce a report based on real or modeled data about expected results. The graphical model lended itself well both for the users (would you want to write out thousands of lines of: engine removed -> load engine on cart -> move cart to workroom -> clean engine -> ...?) and the people it was meant to communicate with ("Is this really your workflow? Do we have a detail wrong?"). The R-kin language was something that she made use of, but mostly for generating reports and it was, to her, "math" not "programming".
by Smithalicious on 12/17/21, 12:59 PM
by saltyfamiliar on 12/17/21, 10:16 PM
So my guess is that a programming language created by a non-programmer would be extremely tolerant to typos. References to non-existent variables and functions would resolve to the nearest existing options. Semicolons, commas, parentheses and brackets would be strictly optional. This seems to be closer to the way people naturally use language.
by knbknb on 12/17/21, 12:28 PM
For starters, TYPOscript has very odd semantics for terms like "Object", "datatype", "register", and so on. You can have lines of code like "page = ", or "page < ".
Typoscipt was designed in the late 1990s, then by an autodidact or very young CS student(s). I don't know exactly, and I don't want to blame anyone. (nothing personal).
However, as a consequence, as a TYPO3 user I have countless files in my work-related directories that have a ".ts" filename extension - now used by TypeScript a well designed language for which rich toolsets exist.
So when I open a TYPOscript .ts file, practically every word on every line has these red squiggly lines from the linter ... very scary.
TYPOscript has its strengths, though.
by knbknb on 12/17/21, 12:47 PM
A work from the early 20th century, mathematics, logic.
I think some expert called Bertrand Russell's and A.N. Whitehead's "Principia Mathematica" initiative a "bizarre" piece of work, when seen from the perspective of a programming language designer.
I can't make a qualified statement about this, as I am neither a mathematician nor a language designer. And I cannot find the exact quote on the internet, sorry. Just saying.
In code? See for yourself :
https://www.principiarewrite.com/ or https://github.com/LogicalAtomist/principia/blob/master/PL.v
by jerf on 12/17/21, 3:26 PM
What if we ignored all the road workers and asked non-construction people who kinda know how to build some stuff in their house to design & build a highway instead?
What if ignored all the architects and asked a non-architect who has put up a couple of sheds from scratch to build the next skyscraper?
What if we ignored all the doctors and asked a random person who knows some biology to treat cancer?
I think this may make it more obvious how this would go.
You may, very rarely, get some sort of interesting insight out of such things. I won't claim the probability is a flat mathematical zero. But it's not a very rich vein of insights. There's much richer veins available.
by 32gbsd on 12/27/21, 11:45 PM
by pmelendez on 12/17/21, 3:16 PM
by exogenousdata on 12/17/21, 3:32 PM
From there I'd imagine the best thing we can do is discuss features/tools that are used today that would be good for non-programmers. As many commenters have suggested, this will probably appear like the existing suite of tools that non-programmers use.
First, maybe an interactive graphical component that allows a users to define the flow of data. Something like Visio to allow users to draw data & input/output, mixed with a component like MSAccess to define the data model. Then a natural language tool that would take normal language and apply rules on the data (Hypercard). Finally, a visual component (like Excel) to validate that the data is correct and potentially generate reports for other non-programmers.
by tlb on 12/17/21, 11:31 AM
Essentially all modern languages were designed by people who were good enough programmers to implement compilers/interpreters/runtimes in a language like C, so it's hard to avoid some intellectual crossover. You'd need to have a separate team implementing the design proposed by this outsider.
by Arete314159 on 12/17/21, 9:29 PM
by kbob on 12/17/21, 11:33 AM
A good starting point is the video, 50 in 50, by Guy Steele and Richard Gabriel. It reviews 50 programming languages from the first 50 years of computing.
by charlieyu1 on 12/17/21, 3:21 PM
People thought writing code is the hard part. It is not. It is the underlying problem that is hard. And no language can really help you about that
by tyingq on 12/17/21, 2:45 PM
by tiborsaas on 12/17/21, 12:30 PM
A programming language will never be a solution for people who can't program, break down problems to smaller chunks and be able to generalize and create abstractions.
Think about someone who can't drive. To them no matter how good a car is, a car alone will never be the solution to move around (ignore self driving cars for now since you are still required a driving license).
For these people one solution might be a taxi driver who can translate commands to actions to move the car to the destination.
by hzlatar on 12/17/21, 6:58 PM
They expected us to imagine a simple instruction set with 7-10 commands. But one clever guy wrote this: "My CPU has only one instruction - manage_elevator. The code for elevator management is: "manage_elevator". He passed with A.
I guess that is how a non-programmer would imagine a programming language.
by logicalmonster on 12/17/21, 4:49 PM
This is more of a fantasy answer, but I think Star Trek: TNG characters describing a desired holodeck scene to the ship's computer is probably an example of what the ultimate programming language would look like. No memorization of syntax required: computers are just magic tools that always understand what you intend.
by 999900000999 on 12/17/21, 3:45 PM
I would pay good money to watch random people try to do something like get all the names from a CSV file in different programing languages.
Have them on a zoom with a Senior Software Engineer. But said Senior Engineer is not allowed to write any code directly.
In this hypothetical game show, I'd imagine most software engineers would pick python to try and teach remotely. Although it would be funny to see the same exercise with Rust.
by thom on 12/17/21, 12:42 PM
Although I suppose in the age of GPT-3 that will probably take over.
by cranium on 12/17/21, 12:46 PM
Through iterations and deliberate design choices, you may end up with a workable language. But you are no longer a non-programmer by then.
by vb6sp6 on 12/17/21, 6:05 PM
"show me orders placed today in Excel"
"send an email to bob@company.com with the order details"
"backup the database to my dropbox account and do it every monday"
"setup a server in new york"
Non-technical people do this all day, giving these simple instructions to the programmers and letting them figure out the details :)
by skadamat on 12/21/21, 11:22 PM
by 8K832d7tNmiQ on 12/17/21, 7:34 PM
In general, it helps students to write a quick application and focus to the important part at the cost of limiting the environment to labVIEW.
by t-3 on 12/17/21, 2:09 PM
by petra on 12/17/21, 12:34 PM
They're done by well funded companies, so I assume a lot of work(by very skilled people) has be done at understanding the answer to OP's question, and so a lot could be learned from them.
by NinjaViking on 12/17/21, 11:46 AM
by thehappypm on 12/17/21, 2:23 PM
by jcun4128 on 12/17/21, 11:36 AM
I could see the appeal of something like voice and copilot.
by onion2k on 12/17/21, 12:40 PM
by kangnkodos on 12/17/21, 3:27 PM
by mikewarot on 12/17/21, 4:10 PM
by tmaly on 12/17/21, 5:43 PM
by mikewarot on 12/17/21, 10:52 PM
You could also support inline literal values, etc. similar to Color Forth.
by wodenokoto on 12/17/21, 8:52 PM
If designed by a well educated philosopher or linguist, probably similar to some 70s or 80s language.
If by someone with no prerequisites then it would be full of ambiguity - just like natural languages.
by TT-392 on 12/18/21, 11:00 AM
by charcircuit on 12/17/21, 11:48 AM
by pcthrowaway on 12/17/21, 5:59 PM
by mesozoic on 12/17/21, 7:47 PM
by etu on 12/17/21, 12:12 PM
I love the output it gives, but the language is quite horrible.
by karjudev on 12/17/21, 2:33 PM
by aristofun on 12/19/21, 9:20 AM
by ModernMech on 12/17/21, 12:55 PM
by Koshkin on 12/18/21, 12:02 AM
by thrower123 on 12/17/21, 12:59 PM