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?
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.
It has been said that non-programmers used to catch on to APL quite quickly back in the day. Faster than regular programming languages in fact. The designers, Ken Iverson, didn't even design the language to be run on computers but rather as a mathematical notation.
Someone else mentioned Excel, and that is an example of data-oriented programming. It actually hides the code and displays the data, which is why most programmers hate it. It's not the data that is important when doing development, but the code.
Array oriented languages like APL and R allows you to work with data like Excel, but you work with the code, not the numbers. I'd argue that once you learn more about programming, one tends to want to work with the code rather than just looking at data.
I've observed the opposite trend. The more senior people get the more they care about the data and less about the code.
Programming = Datastructures + Algorithms
But it's the Data-structures/-models that dictate the algorithms and it's the domain and data therein that dictates the model.
Most companies could survive their code being lost. None would survive loosing all their customer data.
Functional programming is all about data, react is about data, machine learning is about data, google and facebook are about data.
Code is an incidental means to an end, in 90% of all cases, except flight software and games maybe, but even there the trend is towards data driven ECS-Systems and "collect all data for a timestep, and execute your flight control program to compute all actuator outputs in one go"-approaches.
And observability is one of THE hot topics in the biz right now.
Thompson and Ritchie also said their secretaries happily wrote troff.
Do people get pampered too much today or are we severely underestimating them?
This is still true today. I used to run a program for kids where they coded with robots. We used C for a while and we spent the whole time teaching C, never really getting to cool robot activities. Then we switched to Matlab, and it was like night and day. They took to Matlab so quickly, and I think you are right that the array nature of the language is the main reason. Others include the ubiquitous table datatype, and a REPL interface.
R is ugly because it encourages users to use it wrong. For loops are slow as a snail, but are what everybody uses and teaches, while the proper/fast way to wrangle data, with higher order functions like map, is hidden behind idiosyncratic names and obscure APIs.
Even the creator of R considered making it a language instead of the scheme library that it started iut as, as a mistake.
There is no world in which listing the columns before the tables in a SELECT statement is a good idea. It makes intellisense/autocomplete awkward.
These probably shouldn’t matter but did for me. FWIW the statistical offering was fantastic.
I'm sure it is poorly designed from a computer science perspective, but there is no programming language out there which makes it so easy to run any model under the sun as does R.
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.
Culture, tooling, standard library, testing practices, 3rd party libraries and other things carry significant weight.
I find it a stretch to claim that we are dealing with a monospaced text. As you mentioned, it is more than that. The text we deal with is at least: monospaced linted color-coded hypertext.
Basically in hand-wavy terms: the more self-aware the text is, the better.
The main thing I wish for is not a feature in the language, but introductory books for an audience like myself.
I’ll give you some examples of people who possess the kind of logical mind you describe here yet lack programming ability:
- lawyers work with legal code trying to figure out ways to hack it to help their clients. Say what you will about lawyers, but they are good at finding and exploiting holes in logic.
- doctors debug and apply patches to complex, opaque, nonlinear systems. As a programmer, I can relate.
- teachers break down complex subjects into small digestible chunks that when consumed, produce a desired result. You have to be very literal and precise when giving children instructions; they tend to do what you say, not what you mean.
These three professions are removed from coding but it’s not hard to find analogues to programming in what they do. I think with the right language these people could integrate coding into their work the same way they do writing. And in many cases, with Excel they are. Show me a teacher who doesn’t use a spreadsheet or similar tool to manage their class. You can’t!
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.
I don't know of many visual programming languages like this that have production uses. I've seen things like node based editing in Quartz Composer, various game engines, 3D modelling software, etc, but it's almost always only really for pipelines of graphical values rather than truly general purpose programming (even if they might be Turing complete).
I love the output it gives, but the language is quite horrible.
He's not really a programmer, so much as he is a scientist first and foremost. When I think of a "programmer", I think of John Carmack and Tim Sweeney. When I think of computer scientist, I think of Donald Knuth.
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.
https://www.academia.edu/download/51057466/Studying_the_lang...
It's the 2nd top result by citations on Pane's google scholar page
https://scholar.google.com/citations?user=cOeUEwEAAAAJ&hl=en
Thanks GP for the lead - I looked at a few of his papers studying how average people use and talk about program features, all very interesting stuff. Just started to check out the Natural Programming site - the rock-based acronyms alone are so awesome hehe.
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.
I've spend probably 20-40 hours with those and I must say that I like "normal" programming more
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.
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.
The IDEs for it would be more like Delphi (without the price tag) or Lazarus (open source). Way more likely to want WYSIWG GUI designers. They can't go no code (total visual programming), if they want a more useful language, but would want it to be low code. In addition, very helpful to use IDEs and fast compilers (like Pascal/Object Pascal has).
Pascal, for instance, is more like Scheme: Reduce a procedural language to its core concepts and build on top of that. No non-expert would design something meant to used to compositionally like that, it requires a particular mental model they'd lack.
Ada had an advanced (especially for when it was developed and for a procedural language) type system, a comprehensive module system, generics, a task system, and protected objects (thread safe objects) from the start. All of those are things you'd have to recognize a need for and how they would be used which a non-expert would likely not come up with (though an expert may come up with as an answer to a non-expert's requirements).
Probably the only thing coming from Ada that a non-developer may think of (and they'd be brilliant for it) would be the ability to use an arbitrary range for indexing into arrays, including arbitrary discrete types (I actually hate that no mainstream language permits this). They might also come up with ranged types like being able to specify Alphabet as 'a' to 'z' (or 'A' to 'Z').
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".
For those who don't get the reference: https://www.youtube.com/watch?v=WPc-VEqBPHI
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.
Check out the answer threads in r/AdventOfCode, you'll not get the real-time sense of things, but you will see many different ways a problem gets solved in many languages.
To the extent that I have made languages (mostly re-implementations or extensions) that were meant to be used by others (usually engineers doing analysis, or operators of a complex system), they had developed a bespoke DSL that represented their problem domain. They tended to fall into two modes: command oriented with mutation, declarative query languages.
The declarative query languages were often the most consistent and uniform throughout. Not totally, but no "Wait, why are we changing the model in the middle of this?" question arose. The command languages tended to be more ad hoc. Like they'd have procedures that changed things and looked more like conventional procedure calls, but suddenly there's a print statement or a query that looks very different than the rest. Like it was multiple languages jammed together, which in a way it was. Taken as a whole it's inconsistent, but taken in context different people wanted the queries than wanted the commands. An operator wanted the commands, an analyst wanted the queries, and the way they spoke to the initial developers resulted in a mishmash design. At one point they may even have been two different products that get combined because analyst/operators were increasingly common (also, automation, why automate via two tools when you can do the same job with one?).
Declarative query languages are where it's at for non programmers IMO. SQL + Excel + Matlab is the sweet spot IMO. Why? Because non-programmers have the most success with these languages! No need to explain Excel. SQL is known by all kids of non-programmers. For example, my father in law sells directory ads. He is one of the least knowledgeable people about computers, and even he knows SQL. Matlab and other array languages also have quick uptake by non-programmers in my experience.
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 "normal" here I meant that you don't have to be some kind of genius in order to model real world using OOP.
And we have shitton of programmers that everyday model real world complexities using OOP
>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.
Well, on the other hand C# doesn't have all of that XML fetish/Annotation Oriented Programming (@Transactional :P)/Aspect Oriented Programming magic, so it's not like there's only one interpretation and implementation of OOP and it must be Java's
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.
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.
So it would be asking a non-carpenter to design whatever tool they need to get nails to go into wood. You'd probably end up with some caveman looking rock strapped to a stick and then it would evolve into something very similar to a hammer. The claw on the back to remove nails may or may not be combined with the hammer.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
Although I suppose in the age of GPT-3 that will probably take over.
Through iterations and deliberate design choices, you may end up with a workable language. But you are no longer a non-programmer by then.
"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 :)
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.
I could see the appeal of something like voice and copilot.
You could also support inline literal values, etc. similar to Color Forth.
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.
