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?
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).
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?
Also, there was a major difference between what the secretaries would have been using before troff and their experience with troff. In particular, at that time, they were probably using typewriters. A digital workflow would have been a massive improvement in experience. Need multiple copies? No more carbon copies or retyping, now it just comes off the printer (which may still use a carbon copy, but at least you don't have to retype it). Need to adjust something? At least for future printouts it's just changing the file, and maybe using whiteout and handwriting the correction in a few printouts. Want to reflow the entire page? On a typewriter you start over, with troff you edit.
Today, people have Word and Google Docs, why do they need troff/Markdown/TeX/LaTeX/Asciidoc/org-mode/etc.?
The experience, for the user, is not as qualitatively different as those secretaries would have experienced at the time. Not just secretaries, my parents (a pilot and an engineer) took to computers in the 1970s (in college)/1980s (work, later home) for the same reason, it was a better experience than using typewriters and hand calculating things (even with a calculator).
Because what they write has structure and they don't want to be distracted by the looks.
Regarding your "don't want to be distracted", Word has had an outline mode since at least 1995 (first time I used Word). Not sure about Google Docs, but it's a perfectly fine distraction free writing environment. So that's not even a selling point for users of Word.
I just don't object to anything but that one question.
> Word has had an outline mode since at least 1995
I haven't had Word for years so I can't check it out, but if you take WYSIWYG out of a WYSIWYG editor, what is left? Why would I use it instead of other tools you listed? I have used some of 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.
Instadeq: A Live Programming Environment for End User Data Analysis and Visualization
Video: https://www.youtube.com/watch?v=mTEkYqnGICE Slides: https://marianoguerra.github.io/presentations/2021-live/
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.
In Python’s case, the language isn’t bad, but the implementation is horrible for performance. It sits on the back of lots of fast C/Fortran/whatever code, and polished the (relative) turd a lot, making the end result quite usable, but the “sitting on top of part” also makes it hard to improve the performance of the implementation.
For both R and python the end result is good, but they still are local optima in the space of what is possible.
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.
Logo
Bring back the turtle.
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
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.
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.
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!
Anyway, the language you describe wouldn’t work well as a tool, but not all programming languages are tools and are still worth making.
Using your example, this language could be a fun DSL for interacting with pictures. “Find all cars and make them red” I could imagine a backend tied to machine learning algorithms and a database query engine to make this possible. Parse with nlp, extract a query, form a plan with appropriate backends, execute, render output image. I dunno how useful that is, it would be fun and doable. You just gave me a great idea for my next senior capstone group. Thanks.
Yes, but what are the chances that they make their new language that is not influenced by any other programming related knowledge to be specified at the right abstraction level using abstractions that are easy to implement? A language that they come up with is not going to be good. Similarly if you were to ask a non engineer to design you an airplane, it wouldn't be a good design. Experts are always going to be able to do a better job than those with less knowledge. I personally do not even think a kid is going to come up with some revolutionary concept that should be included into a language designed by experts.
Why do they need to be easy to implement? We're talking about design. A lot of PL design is hard to implement. And why does it need to be programming related knowledge? We shouldn't restrict them to things that are easy to implement because then we'd restrict them to a very small subset of possible languages.
So when you say "A language they come up with is not going to be good", then I have to ask how are we measuring good? Because if you think that a teacher would not write a good programming language to write programs in, then I would probably agree with you, because writing programs is not something teachers do.
But like I said, not all programming languages are used to make programs. Most people use a programming language to do things that decidedly don't look like programming to you and I. For example a lot of developers consider Excel to be a not good language for writing programs. Programmers usually lament that Excel users would be better served by a "proper database", but they neglect to appreciate that making this change would quite literally ruin the tool for them. But there are more Excel programmers than all other developer-centric languages combined.
I think a teacher who uses Excel to to manage their classes could design a very compelling DSL for classroom automation.
> I personally do not even think a kid is going to come up with some revolutionary concept
We were talking about teachers designing the language. The children came into the picture because they would provide teachers a model for relating to the pedantic nature of computers.
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
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.
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
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.
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.
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.
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
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.
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.
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.
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 :)
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.
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.
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.
If my memory serves me correctly, Leslie Lamport [1] created TeX because he wanted to write a book on math but there were no good systems to write math, so he made TeX. So to me, it sounds like he were a math teacher at that time, I have no idea if he actually knew programming when starting to work on TeX.
Lamport didn't make TeX. It was Don Knuth. Lamport wrote the LaTeX macros for TeX to simplify typesetting books and articles.
> I would also argue that it's quite hard to determine from a Wikipedia article if a person were a good programmer at the time of creating a certain thing about 40 years ago.
Ironically, the informative and relevant article you linked does answer this:
Leslie Lamport was a computer scientist from 1970 to 1985. He released LaTex in 1984. So he was a full time computer scientist for more than 14 years before LaTeX. This (plus of course his subsequent career including winning the Turing Award) suggests he was a "good programmer" for most common usages of "good" and "programmer".
Lamport was only a math teacher (at Marlboro College) from 1965 to 1969, 15 years before LaTeX. He was a computer scientist for his entire post-PhD career.
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.