Ask HN: How would a programming language look if designed by non-programmer
Since it's hard to find such a person, who understands CS/Math/can program machines but never used "normal" programming languages
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?
131 comments
[ 2.6 ms ] story [ 143 ms ] threadEssentially 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.
I could see the appeal of something like voice and copilot.
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.
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.
[1] https://docs.python.org/3/howto/functional.html
These probably shouldn’t matter but did for me. FWIW the statistical offering was fantastic.
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.
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/
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.
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).
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.
I love the output it gives, but the language is quite horrible.
[1] https://en.wikipedia.org/wiki/Donald_Knuth
[2] https://en.wikipedia.org/wiki/Leslie_Lamport
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.
[1]: https://en.wikipedia.org/wiki/Leslie_Lamport
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.
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.
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 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'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.
http://inform7.com/
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.
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
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’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.
The main thing I wish for is not a feature in the language, but introductory books for an audience like myself.
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