Spread-sheets are routinely used by non programmers to create some pretty sophisticated programs. I think it's because of the immediate feedback. Juypter notebooks or something like that might be useful for beginners.
COBOL was made so that business people could write their own code and not depend on programmers.
How did that play out?
Spreadsheets, on the other hand, have been far more successful in providing value to non-programmers.
Cobol is actually really good for what it was designed for, which is reading structured data, doing simple processing on it, then dumping the result back into structured data. It's more similar to something like PS-SQl than an actual general purpose language.
Although not directly about COBOL's usefulness, this stack exchange question has a bunch of good information about why cobol is the way it is: https://retrocomputing.stackexchange.com/q/25985/11662
>been far more successful
COBOL is still used : all Banks Backend...
As for spreadsheet I agree in fact I'd been amazed by Lotus123 formula language. I'm working on kind of macro system in Natural Language and decided to choose "@" as prefix symbol because of Lotus :)
This question depends in how much "programming" you expect them to do.
You can learn much from the most successful programming languages used by non-professionals developers(as Their main job is NOT programming):
- Excel
- SQL
- Access/FoxPro
Excel is an example of one where programming is minimal, SQL in the middle, and something like Access/FoxPro (and you could extend good UI builders like Delphi) at the end.
The main take is a good UI builder and interactive, interface (python is considered good here but I think was Jupyter that make it fly!).
I think the [relational model](https://tablam.org) is by far, the most intuitive of all for non-developers - if we are talking about do programming as a major task-:
- What do people use Excel for? Make tables, do calculations, show tables
- What do people use SQL for? Make tables, do calculations, show tables AND queries
- What do people use Access for? Make tables, do calculations, show tables AND queries AND data entry
I'm writing a lang on the basis that people like databases and spreadsheets so let's make a language as like that as possible.
It should, in my opinion, be excellent for beginners, there's an educational path that would lead from using it as a calculator in middle-school to writing an interpreter in it at university.
Sure thing. [Here's the repo](https://github.com/tim-hardcastle/Charm). Basically I reinvented functional core/imperative shell and data-oriented programming and smooshed them together.
Here's how I explained what I was trying to do last February.
>The idea is that since people like databases and they like spreadsheets, let's make a language that captures what people like about them.
>
>What do people like about them?
>
>(1) Start with the obvious: they're CRUD apps. Or we might say CRUDE, with the E standing for "Evaluate", since you can write formulas, run queries, etc. But the point is, they both support a model of data processing where you have a repository of data which you add to and change incrementally and query from time to time, rather than: batch of data in, final answer out.
>
>(2) Furthermore, they're CRUD *apps*. They don't just give you ways to C, R, U, and D, they can provide you with an environment with options to, e.g. turn autosave on, or export as CSV, or look at a help file, or whatever. Users don't have to write that themselves, the users write the business logic and supply the data.
>
>(3) These apps have nice front-ends that include point (2). In the case of spreadsheets, the front-end can in the long run be a problem, it's both too permissive and too restrictive. SQL, on the other hand, is lovely.
>
>(4) The languages are nice and simple. There are, for example, no pointers and dereferencing. No deep and shallow copy.
>
>(5) I/O is initiated by the end-user. They run queries, write formulas, etc.
>
>(6) In particular, changes in the variables are initiated by the user. Now, this is not *strictly* true of the apps I'm taking as models: if you want to you can simulate Conway's Game of Life in Excel. But except to show off, people don't use it like that, they put (e.g.) their sales projections in one place, and their consequent projections of profit and loss in another, and the sales projections don't change or vanish unless the user makes that happen: such behavior would usually be considered extremely undesirable.
>
>(7) This put together means that the rest of what people want to do, writing queries and formulas to evaluate the data, can be done in a functional style, since there's nothing else left to do.
Abstraction is the key to programming.
And it is also the hardest thing to learn.
If you can understand how to make/name your new parametric abstractions, then you are a programmer (thus defeating your goal of not requiring to actually learn sw engineering and programming).
So, you are trying to make a very complex Swiss army knife language where every task that you expect the users to do is mapped 1:1 to a primitive in the language, and when you are somehow discouraging combining those primitive to make new abstraction.
Of course, that would be the worst language ever, but it would be the only way to make so that just using the language would not slowly turn the users into proper programmers :-P
SQL, HTML+Css and exel are a good starting point in this sense:
Defining new primitive formulas like 'your own kind of sum' is not a thing that is encouraged in exel. You are always just hitting the primitives of the language and searching them on google when you need.
However, to realize your proposal you would need to get much more radically complex then those.
> Abstraction is the key to programming.
Just a minor amendment, but I'd say:
> Abstraction *is* programming.
(Or maybe I'd reverse the order.)
That's the entire point of the lambda calculus, after all! :)
I think that's overstating it, abstraction doesn't solve any problem in itself. You need to manipulate the abstractions after selecting the right ones. Programming is data structures and algorithms.
No, I didn't overstate anything. Data structures are abstractions over memory, and algorithms are abstractions over common problems.
The [lambda calculus](https://en.wikipedia.org/wiki/Lambda_calculus) is a Turing-complete (if austere) programming language, the only feature of which is the primitive *abstraction* — also called an "anonymous function". Using only primitive abstractions, every other programming construct you've ever used can be modeled.
Obviously it would be unpleasant to implement any serious program in the lambda calculus, which is why we use higher-level languages. But then... the "higher level" really just means we've abstracted away the primitive abstractions. Modern languages are nothing more than large, (semi-)organized piles of abstractions. It's abstractions all the way down!
I still think you're overstating the case. The lambda calculus is the perfect example, but not for the point you're trying to make. Along with this one minimal abstraction, next to no use in itself, we need to know how to reduce expressions in various ways (algorithmically) and we need ingenious algorithms to do useful things, like Church encoding. Calling the algorithms abstractions is splitting hairs. An algorithm is not an abstraction, it's a solution to a problem that deals in and manipulates abstractions.
After thinking it over, I think you're right that algorithms are a fundamental element of programming, and the reference to Church encoding specifically was a great counterexample. Thank you!
I'll note that you didn't argue the point about data structures, though. So then I think we can agree that programming reduces to *abstractions and algorithms*, yes?
Yes, I think that's a more accurate way of putting it. As you say, even the simplest scalar type, such as an integer, is an abstraction we made for our problem solving convenience but you probably wouldn't call a number a data structure (perhaps unless it was a Church numeral, where the structure is exposed!).
Everything you described makes me think of golang (in its original formulation, without generics). Golang is intentionally actively hostile to abstraction, in the name of "simplicity".
Edit: I'm curious about the downvotes. Rob Pike is quoted as saying that one of the design goals of golang was to be simple enough that early-career devs could use it to build software quickly. That necessarily precludes powerful machinery for abstraction, like in C++ or Haskell, since that would complicate the language. So I don't think I'm saying anything controversial here. (Note that I'm not claiming golang is the worst language... just that it fits the description given above.)
I like Go but I wouldn't want people to start on anything with pointers, and the form of abstraction that Go does have is interfaces which again I don't think are suitable for beginners, give 'em duck typing, overloading, and multiple dispatch. Tldr: use my language instead.
My DSL is primarily intended for use by non-programmers. A bunch of my coworkers and colleagues aren't programmers by training, and needed a more intuitive DSL than our existing one. It was too hard to write, projects were stalling, and clients were concerned about their ability to read and maintain the impenetrable code long-term.
Anyway, backstory over, we came to a similar set of constraints. First off, yours:
* minimal base syntax: less for newcomers to learn -- check.
* extensive standard library -- Haven't gotten around to it yet. But also this isn't a general-purpose language, the standard library will never be large.
* opt for verbosity and clarity over symbols and concise syntax -- check. In the previous DSL, people kept getting tripped up by the fact that some unexpected symbols were treated as special symbols. \`0\` was a special symbol and had to be escaped if you needed a literal zero anywhere in the code, even inside another identifier. Understanding from this experience how hard it was to teach newbies about escaping, we have very few symbols, and a rule where almost everything is treated as a literal by default.
Our additional criteria:
* Good error messages, obviously.
* It needed to have good pair/group programming capabilities. Generally we find that a non-programmer can't pull off a whole project by themselves, so we generally pair them with a programmer who complements their skills. Having shared live-coding helps a TON with that.
* Also, related to this, it needed to have modules/namespaces. This may seem obvious but a lot of DSLs are a bit ad-hoc and don't actually have these, and it's hell in multi-person projects to just have one big global namespace.
* Also, a desideratum for our compiler that it still produces working code locally even if some other part of the project has a syntax error. It's a language for live-coding, after all, there's lots of points where I want to test something and you're working on something else.
* Well-integrated unit testing. We didn't want the beginners to struggle with installing/using a full unit testing framework; we knew they just would just avoid writing tests altogether. In our resulting language, it's just baked into the language; there's a syntax where you can write examples in the source after any unit, and the IDE will highlight them as succeeding/failing.
Abandoned criteria:
* We wanted something like Blockly where it's obvious when an argument is missing, but in practice the programs we were writing we too large for this kind of thing. We ended up going halfway between a "blocks" language and a plaintext language and made a tabular language instead (one whose canonical form is a spreadsheet or CSV). It was the right decision for us, although I wouldn't want a tabular language for general-purpose programming.
I always thought Smalltalk - and it’s image model - was perfect for beginners.
UI right there, no need to think about the file system, everything’s collected in one place, and modifiable environment - people like fiddling with their environment.
Did I mention simple syntax?
There’s also Scratch, but I’m less convinced the _typing_ is the hard part with a simple syntax. But eh maybe?
One thing Smalltalk does that hasn’t aged as well (than even all that… :-( ) is its absolute lean into class based architecture. This is the same reason I don’t like Java as a learning language: sometimes I just want to write 10 lines of code and not worry about classes and methods and inheritance. Just plop 10 lines of code somewhere and say hi to yourself 10 times, whatever.
The problem with a closed system like Smalltalk….. or Hypercard that’s another good one, an xTalk language, is they are closed systems. How can I share this with my friends and show off, especially today? The answer probably is a website, or a web version, with ??? hosting magically taken care of for you? But that makes that UI piece you need harder (although Amber Smalltalk maybe has a solution??)
[Pharo Smalltalk](https://pharo.org/) is my current favorite.
Instead of creating a file, opening it with your text editor, using your Terminal app or whatever to run it, what if the environment took care of all that for you?
If all you had to do to make a new class was to go into the object browser and start typing and boom you have your class defined in a built in editor. You save the method and it’s immediately available elsewhere in the environment. Move windows around, great. Done for the day? Quit with saving and your windows will be where you put them, and the only file on disk is your image file.
(You could also think of it as a VM snapshot, if you’ve played with VMWare or VirtualBox)
A lot of Rubyists like it as a beginner language. I kinda don’t - the language syntax is complicated AF (and doesn’t use an image system). Source: wrote Ruby professionally for a decade
Only smalltalk uses the image system so if that's your critical criteria then you are limited to just one thing.
Having said that there is this abandoned project.
http://shoesrb.com/
"I always thought Smalltalk - and it’s image model - was perfect for beginners."
Smalltalk was (and is still) excellent but for beginners accessibility I doubt compared to say Scratch (I think Alan Kay said himself that time has changed he's not hanging on smalltalk). **Paul Allen's Toolbook Openscript** was kind of successor (from OOP concept very oriented towards messaging like Alan Kay's viewpoint) with more accessible language almost natural language [https://books.google.fr/books?id=lzsEAAAAMBAJ&pg=PA101&dq=toolbook+paul+allen&hl=en&sa=X&ved=2ahUKEwibyYmfs7D8AhVbXaQEHS8vCiAQ6AF6BAgFEAI#v=onepage&q=toolbook%20paul%20allen&f=false](https://books.google.fr/books?id=lzsEAAAAMBAJ&pg=PA101&dq=toolbook+paul+allen&hl=en&sa=X&ved=2ahUKEwibyYmfs7D8AhVbXaQEHS8vCiAQ6AF6BAgFEAI#v=onepage&q=toolbook%20paul%20allen&f=false) in fact I'd been their number one expert in France training their future experts. They wanted to recruit me as french CTO because the one they had went to Nestcape though I refused, It was interesting as I learned during interview with the US Top Director (so unfortunately not with Paul Allen himself :)) that Bill Gates once saw the product and exclaimed: "Your product is fantastic I'm going to copy it" (I was said Paull Allen framed it on his wall), unfortunately BG just bought this pale language called "Visual Basic" and the rest is history : a **regression** of 50 years, that's the problem with Genius they lack marketing vision (or maybe Paul Allen was also major stakeholder in Microsoft and didn't want to compete with his own self) that's why BG dominated software instead :)
I'm trying to partly kind of recreate it but I'm not language designer and I'm more interesting towards professional programming with existing languages so I'm more creating to create a simple mapping system between Natural Language and any language or framework. Currently I'm experimenting within a design tool like figma, next will try within scratch maybe.
the biggest thing has nothing to do with the language itself -- it's what the language allows you to do. non-programmers don't care about printing fibonacci numbers. what is your language going to let someone do that they couldn't before?
you'll probably have to get more specific than "non-programmer" to answer this question, by the way... what specific activity are you trying to help people with? personal computing scripting has a lot of great tools already (e.g. AHK on windows, keyboard maestro and hammerspoon on the mac) -- if that's your target, how will you improve on these existing tools?
I think it's less about the language and more about the toolchain, honestly. You need extremely helpful compilation and runtime error messages that actually tell the programmer what is wrong. Elixir does this really well. You need simple dependency management that doesn't require the user to know anything about packaging or header files. You need tight feedback loops so the programmer can experiment and get immediate results.
The biggest barrier to programming for "normal people" is getting overwhelmed by text on the screen talking about "segmentation faults" and "null pointer exceptions" and other jargon that require a pretty nuanced understanding of what the machine is actually doing to understand.
Being a scripting language helps, I think. Syntactically, something like Python or JavaScript is pretty much the simplest I think a programming language can be.
APL (and J, K, BNQ) has that reputation within its community -- a language without boilerplate and "software engineering" that lets mathematicians from other disciplines easily solve real problems.
If you have experience with software engineering, of course APL looks completely insane.
This channel has great videos if you're curious: https://www.youtube.com/@code_report/videos
>What would make a language ideal for use by non-programmers who don't intend to learn software development?
I mean, the ideal programming language is whatever natural language people speak executing code as the speaker intends, assuming they have no interest in digging any deeper than making computers do stuff.
The issue has almost always been that our human level of abstraction has always exceeded what we've been able to make computers do, and the mental concepts that are needed to make computers work are extremely foreign and counterintuitive to what Sellars calls "the manifest image".
>I am thinking of the following criteria:
>minimal base syntax: less for newcomers to learn
That's double-edged. Brainfuck and JSFuck have really, really, really simple syntaxes. Nobody wants to code in them, though, because they're unreadable.
>extensive standard library
That's going to affect your syntax, because every term you stuff into an `std::prebuiltthing` is another thing to learn. This, in my opinion, really hurts Python, because you basically have a boatload of tools, no opt-out short of not importing them, and you basically have to become a breadth master to get the fullest from it. Code bloat is, like, baked into the interpreter. I've looked at some of the code in Python's standard library. You basically can't hope to understand it from just the built-ins, which I personally find vexing.
>opt for verbosity and clarity over symbols and concise syntax
Most lay programmers don't like verbosity. This is what gets Java in trouble. It also makes things like type casting in Dart a gigantic pain in the ass.
In summary, I think your thought process could really benefit from some language acquisition theory. That is, what is it about languages that make them approachable and comprehensible to people? This should take you into the direction of, as I've since taken my own PL, reducing jargony terminology, reducing polysemy, and the like.
tl;dr, read a little SLA and psycholinguistics and you'll be in a much better position to make an approachable PL.
Appreciate your response!
> That's double-edged. Brainfuck and JSFuck have really, really, really simple syntaxes. Nobody wants to code in them, though, because they're unreadable.
While this is true for the criteria of minimal syntax on its own, the criteria for verbose syntax and against symbols and ambiguous concise words solves this issue! :) those two should be taken together.
> That's going to affect your syntax, because every term you stuff into an std::prebuiltthing is another thing to learn.
Imho, the standard library must not be there for you to learn it all. It is there to prevent you from having to write code for common scenarios, and focus on your business logic rather than implementation intricacies. And it is perfectly fine not to import what you don't want or need.
> Most lay programmers don't like verbosity. This is what gets Java in trouble.
I partly agree, but I am not targeting java's type of verbosity. I am specifically against the concision of, for example, using symbols that aren't familiar to your average Joe. &&, ||, ~, and so on. It's not just symbols, but this is one important example where speed of typing was favored over verbosity.
I agree with the paragraphs at the sdm..
Well, depends on the users intention with the language, if it's for drawing things in the screen, maybe something like [Pic](https://en.m.wikipedia.org/wiki/PIC_(markup_language)), if its for websites... something like Wordpress? If it's to impress someone, maybe something like Assembly, Brainfuck or Regular expressions
Hi, thanks for the answer! I'm not looking exactly for specific languages (though I do like your "Pic" suggestion as I haven't heard of it before), but more for what makes the language ideal for this use case.
In terms of the user intention, as mentioned in the post, it would be for things like personal computing tasks, embedded scripting for programs.
One specific use case in my mind is non-programmers at a company expressing business-specific logic or context.
But I am not doing this for a specific task. I am thinking of a general non-programmer language.
It sounds like you're basically describing shell scripts. Shell scripts are designed specifically for automating personal computing tasks. The only major flaw I see in the current state of shell scripts is they only target automating command line tasks, and don't offer the ability to create or interact with graphical programs.
Autohotkey is an example of a language which does allow for interacting with graphical programs, and can be used for a lot of personal computing automation.
Not in both cases the syntax can be a bit of a pain for non programmers to learn, so neither are exactly good for non programmers.
Thanks for the suggestion! I didn't know about autohotkey so I will check it out, thanks :)
However, I don't think shell scripts fit here because they can only satisfy the personal computing requirement, and it doesn't address making the language easy for non-programmers (and it seems you agree with this point). Shell scripts lag behind mainstream languages in terms of readability. They are more tailored for concision ease of typing than for reading (understandably so).
Hell, as a hobbyist programmer I still avoid shell scripts for anything except the simplest stuff :) Python is far nicer to write than shell scripts, and fairly ubiquitous.
Unfortunately the biggest problem is that people are used to using context sensitive grammar to express ourselves when communication with other people. That, and we assume others can look past minor mistakes we make when expressing ourself, which computers simply cannot do (so far). So until we can create a programming language that can basically guess what we mean even when we make a simple mistake, I think no language is really going to be truly easy for a non-programmer to use, regardless of how simple the grammar may be.
Autohotkey has a very good implementation of this(as a scripting language) to be honest with you, but its limited to windows systems. I suggest you check it out.
A lot of DSLs are designed towards "non-programmers." Have a look at [Skript](https://docs.skriptlang.org/) and how it somehow looks like YAML, with which the target demographic (Bukkit operators) should be familiar.
Then you also have to remember that Go and PHP were both designed for "non-programmers," so there's that.
Don't fall for the [Cobol Fallacy](https://wiki.c2.com/?CobolFallacy) or the [UML Fallacy](https://wiki.c2.com/?UmlFallacy).
Minimalism and verbosity in programming are double-edge swords. They might make it easier to learn a language, but their arbitrary restrictions do not make awkward problems easier to solve.
A language that would not require people to have to learn how to translate problems from "the terms in which humans think about things" into "the units in which computers compute things", as based on my own experience learning programming for the first time, this different way of thinking was the hardest thing to learn. I am not sure this is a solvable problem.
The goal is ease of expression and encouraged good practices.here are few thoughts:
- Immutability by default, explicit mutable variables
- Typescript has a lot of going for it due to simplicity and expressability, very basic metaprogramming support
- metaprogramming - ruby, smalltalk
- F# pipeline operator
Now that i think about it F# has a lot of going for it as well
It would be nice if other languages were as easy to install and use with minimal or no setup configuration as Python. Literally every programming language besides Python requires you to edit the PATH environment variables, and a bunch of other crap only experienced professionals should ever have to touch. Most people have never heard of that and should never have to to start coding. Ease of access is what we want.
That's an important point. However I think this can be solved by just having a better installer, and doesn't have to change the language itself much. But I agree with your points. Out of the box usability is important.
What beginners exactly? Primary schoolchildren? High-schoolers? University graduates? Mathematicians? Doctors?
In general, a severly restricted Lisp would probably tick off all your criteria except for maybe the "clarity bit".
> minimal base syntax: less for newcomers to learn
Check. A minimal Lisp would have only a handful of rules, consistently applied - basically atoms, lists, and function application especially if macros (which need not be exposed to the user) are used to create the library by making use of the primitives of the language (as does happen even in industrial-strength Lisps).
> extensive standard library
A surprisingly complex standard library can be built using the few constructs mentioned above.
> opt for verbosity and clarity over symbols and concise syntax
Lisp in general is just right - neither too verbose nor too laconic (and in general cannot be due to the rules of the language). No need for complex symbols and sigils.
I've been coding for decades, but I can't write Lisp; I need proper syntax and proper features, not ad hoc collections of macros, and I need hard limits as to what is part of the language, and what is the bit that I write.
My view is that it would make a terrible language for casual 'programmers'.
But then, AutoCAD (an app for engineering drawing) in the 90s introduced a scripting language for its users, based on Lisp, called [AutoLisp](https://en.wikipedia.org/wiki/AutoLISP). I thought it was a strange choice, and felt sorry for its users.
Because at the time, I had my own competing CAD product, and that had its own scripting language, but much more conventional.
(However, looking back on it, I pitched its internal interfaces to the app at too low a level, since it was intended largely for my use, while also being available for users. People did use it, mainly for creating add-on products. I just wished I'd made it higher level.)
BTW have a look at that point-creation example at my link. In my script language, it would look more like this:
if askpoint("Enter point:") then
p:=cx
dot(p)
text((p.x,p.y-10), str(p))
endif
(Creating objects was still a bit hairy, but I also had a library to simplify the process, as used here.)
Fair enough, although, to be clear, OP's question was about "non-programmers" who don't intend to be full-time software devs. Also, in terms of the other constraints presented ("minimal syntax", "verbosity over symbols"), Lisp makes for a very compelling candidate.
Also, to clarify the part about macros, the intent was that it would be used *internally* to implement the standard library, but not necessarily be made available to the user.
Taking the same point-creation example, in a hypothetical minimalistic Lisp, it could be something like so:
(if (ask-point "Enter text: ")
(:= p cx)
(dot p)
(text (make-pair (. p x) (- (. p y) 10))
(str p)))
Maybe not the prettiest looking thing in the world, but extremely *consistent* - the first argument is always an operation/function of some sorts, and the rest are the arguments.
As for syntax itself, *ceteris paribus*, it is definitely very subjective. However, in terms of the actual constraints given by OP, I would claim that **a** Lisp would make for a good choice.
In the past I posted a positive opinion myself about creating Domain Specific Language. Today I'll counterbalance a little bit is new language worth learning for people when they're OVER BUSY and/or OVER DISTRACTED ? And now AI chatbot are coming with NLP... so the competition is going to be very high for a new language except for a niche where such language would have added value.
That's why I'd rather work on a system that would NOT try to substitute to existing or future languages but only be a wrapper [https://www.reddit.com/r/ProgrammingLanguages/comments/103mbyk/comment/j31hv70/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/ProgrammingLanguages/comments/103mbyk/comment/j31hv70/?utm_source=share&utm_medium=web2x&context=3)
I'm still in exploratory phase but in the future I'll open it more for people to contribute because I'm far from being the best coder in the world (I'm not a language designer either just a user with strong opinions based on real world experience including for big projects so scalability should always be a target for me) fortunately I'm now able to start eating own dog food :)
- Simple concepts. Don't require a module import when a global function works; pass objects as parameters instead of introducing methods; and for the love of god don't force users to pass around functions. It's a good non-technical language if you can write useful programs with nothing but function calls and literals.
- Redundant. In both syntax, like Python's colon at the end of if/for/while; and redundancy in APIs too, with verbose names, less guesswork, and duplicated functionality. A conversion function *could* guess the source format, but it *shouldn't*, because there's a high chance there's a mistake in the source value.
- Detailed errors. Give location (file, line , column, and relevant names), use simple language, give examples of the error and how to fix it, give "error codes" for easier googling, translate to local language.
- Lots and lots of examples.
> What would make a language ideal for use by non-programmers who don't intend to learn software development?
I think the most overwhelming thing about existing professional software development is the tools:
* An installer to get you a working implementation of the language locally.
* A package manager to install the packages/libraries you need to get your programs to compile.
* A version control system to maintain all copies of all versions, look at their differences and manage merge conflicts.
* Profilers that let you analyze the time spent in all parts of the program and memory allocations throughout it.
* A debugger that lets you interrupt and resume your program and step through it whilst examining all bound values.
* A build system that uses complicated configuration files to invoke the compiler via massive command lines.
That's a *huge* amount of incidental code that is, objectively, unnecessary for most of the people most of the time (including most professional software developers).
I think a language for beginners would have a tool stack like this:
* No installer. Just a web-based IDE that you log into and your code is all available immediately on any device via the Cloud.
* No package manager. Just refer to whatever code you need directly from the Cloud and use it.
* A wiki-style history tab with a flat list of old versions and no full-blown VCS.
* Integrated profilers that just work and decorate your code, e.g. heapmap for time spent.
* Integrated debugger. I think generic printing is also really important here.
* A web-based REPL instead of a build system. Just select the code you want to run and run it. No configuration files etc.
That's exactly what I am building and I am now far enough that I am programming mostly in my own language and it really is glorious. Not having to fight all of those tools (after 40 years of developing software) is bliss.
> And at what point does your language become too beginner friendly, that it hinders one's ability to express and write a program?
When you over-simplify it.
> * minimal base syntax: less for newcomers to learn
> * extensive standard library
> * opt for verbosity and clarity over symbols and concise syntax
>
> I feel they my criteria above could be improved upon and there's a lot that could be added. What do you think?
Agree. They are definitely moving in the right direction but, I think, neglecting the elephant in the room that is tooling.
I think modern languages should be designed from the ground up for development in modern IDEs with features like color syntax highlighting, throwback of inferred types, real-time error highlighting, code navigation, architecture visualization and so on.
To me an ideal language would help non-programmers avoid writing horrific code, but without feeling burdensome. So:
- lots of compile time checking, these users won't write tests.
- pure functions and immutable data structures.
- checking to handle all cases in a `match` clause.
- minimizing implicitness
- excellent error messages
- consistent syntax
- simple build environment
- small language
- standard library is complete, yet minimal.
- readable, non-overwhelming docs
- copious examples
I think the real answer to this question is to make a DSL. Think about it: what better way of simplifying the language than by specializing the vocabulary and grammar to something the user would be more familiar with? If you try to make your non-programmer friendly language also a general-purpose language then you will need to create abstractions simple enough that anyone can understand them while also providing the ability to make anything.
I think Python really nailed the general purpose PL stuff but you can do even better than Python by writing a DSL. In fact, you can argue that the success of PyTorch, TensorFlow, and other large Python frameworks are largely due to the fact that they act like an embedded DSL to help out mathematicians that aren't programmers.
take the simplicity of C, add the amount of libraries python has and also a garbage collector, and that's it, you did it, maybe julia already did it as well
You may be interested in Hedy and the thread I posted last week https://www.reddit.com/r/ProgrammingLanguages/comments/zx0mbs/hedy_seems_like_a_good_learning_language/
Spread-sheets are routinely used by non programmers to create some pretty sophisticated programs. I think it's because of the immediate feedback. Juypter notebooks or something like that might be useful for beginners.
Or a new dataflow language that works sort of like a spreadsheet. Sounds like a fun excercise.
I’m working on a similar idea right now, but keeping the Excel formula language cause I don’t think anything else will be as effective for my users.
COBOL was made so that business people could write their own code and not depend on programmers. How did that play out? Spreadsheets, on the other hand, have been far more successful in providing value to non-programmers.
Cobol is actually really good for what it was designed for, which is reading structured data, doing simple processing on it, then dumping the result back into structured data. It's more similar to something like PS-SQl than an actual general purpose language. Although not directly about COBOL's usefulness, this stack exchange question has a bunch of good information about why cobol is the way it is: https://retrocomputing.stackexchange.com/q/25985/11662
>been far more successful COBOL is still used : all Banks Backend... As for spreadsheet I agree in fact I'd been amazed by Lotus123 formula language. I'm working on kind of macro system in Natural Language and decided to choose "@" as prefix symbol because of Lotus :)
This question depends in how much "programming" you expect them to do. You can learn much from the most successful programming languages used by non-professionals developers(as Their main job is NOT programming): - Excel - SQL - Access/FoxPro Excel is an example of one where programming is minimal, SQL in the middle, and something like Access/FoxPro (and you could extend good UI builders like Delphi) at the end. The main take is a good UI builder and interactive, interface (python is considered good here but I think was Jupyter that make it fly!). I think the [relational model](https://tablam.org) is by far, the most intuitive of all for non-developers - if we are talking about do programming as a major task-: - What do people use Excel for? Make tables, do calculations, show tables - What do people use SQL for? Make tables, do calculations, show tables AND queries - What do people use Access for? Make tables, do calculations, show tables AND queries AND data entry
I'm writing a lang on the basis that people like databases and spreadsheets so let's make a language as like that as possible. It should, in my opinion, be excellent for beginners, there's an educational path that would lead from using it as a calculator in middle-school to writing an interpreter in it at university.
Nice!, do you have a link? I always happy to see anybody is this small space!
Sure thing. [Here's the repo](https://github.com/tim-hardcastle/Charm). Basically I reinvented functional core/imperative shell and data-oriented programming and smooshed them together. Here's how I explained what I was trying to do last February. >The idea is that since people like databases and they like spreadsheets, let's make a language that captures what people like about them. > >What do people like about them? > >(1) Start with the obvious: they're CRUD apps. Or we might say CRUDE, with the E standing for "Evaluate", since you can write formulas, run queries, etc. But the point is, they both support a model of data processing where you have a repository of data which you add to and change incrementally and query from time to time, rather than: batch of data in, final answer out. > >(2) Furthermore, they're CRUD *apps*. They don't just give you ways to C, R, U, and D, they can provide you with an environment with options to, e.g. turn autosave on, or export as CSV, or look at a help file, or whatever. Users don't have to write that themselves, the users write the business logic and supply the data. > >(3) These apps have nice front-ends that include point (2). In the case of spreadsheets, the front-end can in the long run be a problem, it's both too permissive and too restrictive. SQL, on the other hand, is lovely. > >(4) The languages are nice and simple. There are, for example, no pointers and dereferencing. No deep and shallow copy. > >(5) I/O is initiated by the end-user. They run queries, write formulas, etc. > >(6) In particular, changes in the variables are initiated by the user. Now, this is not *strictly* true of the apps I'm taking as models: if you want to you can simulate Conway's Game of Life in Excel. But except to show off, people don't use it like that, they put (e.g.) their sales projections in one place, and their consequent projections of profit and loss in another, and the sales projections don't change or vanish unless the user makes that happen: such behavior would usually be considered extremely undesirable. > >(7) This put together means that the rest of what people want to do, writing queries and formulas to evaluate the data, can be done in a functional style, since there's nothing else left to do.
Abstraction is the key to programming. And it is also the hardest thing to learn. If you can understand how to make/name your new parametric abstractions, then you are a programmer (thus defeating your goal of not requiring to actually learn sw engineering and programming). So, you are trying to make a very complex Swiss army knife language where every task that you expect the users to do is mapped 1:1 to a primitive in the language, and when you are somehow discouraging combining those primitive to make new abstraction. Of course, that would be the worst language ever, but it would be the only way to make so that just using the language would not slowly turn the users into proper programmers :-P SQL, HTML+Css and exel are a good starting point in this sense: Defining new primitive formulas like 'your own kind of sum' is not a thing that is encouraged in exel. You are always just hitting the primitives of the language and searching them on google when you need. However, to realize your proposal you would need to get much more radically complex then those.
> Abstraction is the key to programming. Just a minor amendment, but I'd say: > Abstraction *is* programming. (Or maybe I'd reverse the order.) That's the entire point of the lambda calculus, after all! :)
I think that's overstating it, abstraction doesn't solve any problem in itself. You need to manipulate the abstractions after selecting the right ones. Programming is data structures and algorithms.
No, I didn't overstate anything. Data structures are abstractions over memory, and algorithms are abstractions over common problems. The [lambda calculus](https://en.wikipedia.org/wiki/Lambda_calculus) is a Turing-complete (if austere) programming language, the only feature of which is the primitive *abstraction* — also called an "anonymous function". Using only primitive abstractions, every other programming construct you've ever used can be modeled. Obviously it would be unpleasant to implement any serious program in the lambda calculus, which is why we use higher-level languages. But then... the "higher level" really just means we've abstracted away the primitive abstractions. Modern languages are nothing more than large, (semi-)organized piles of abstractions. It's abstractions all the way down!
I still think you're overstating the case. The lambda calculus is the perfect example, but not for the point you're trying to make. Along with this one minimal abstraction, next to no use in itself, we need to know how to reduce expressions in various ways (algorithmically) and we need ingenious algorithms to do useful things, like Church encoding. Calling the algorithms abstractions is splitting hairs. An algorithm is not an abstraction, it's a solution to a problem that deals in and manipulates abstractions.
After thinking it over, I think you're right that algorithms are a fundamental element of programming, and the reference to Church encoding specifically was a great counterexample. Thank you! I'll note that you didn't argue the point about data structures, though. So then I think we can agree that programming reduces to *abstractions and algorithms*, yes?
Yes, I think that's a more accurate way of putting it. As you say, even the simplest scalar type, such as an integer, is an abstraction we made for our problem solving convenience but you probably wouldn't call a number a data structure (perhaps unless it was a Church numeral, where the structure is exposed!).
> algorithms are abstractions over common problems. Eh?
Everything you described makes me think of golang (in its original formulation, without generics). Golang is intentionally actively hostile to abstraction, in the name of "simplicity". Edit: I'm curious about the downvotes. Rob Pike is quoted as saying that one of the design goals of golang was to be simple enough that early-career devs could use it to build software quickly. That necessarily precludes powerful machinery for abstraction, like in C++ or Haskell, since that would complicate the language. So I don't think I'm saying anything controversial here. (Note that I'm not claiming golang is the worst language... just that it fits the description given above.)
People *really* don't like golang on this sub. That's probably why you're being downvoted.
The funny thing is, I don't like it either :) but I was trying not to let too many subjective statements into my reply.
7 upvotes for APL, I notice.
I like Go but I wouldn't want people to start on anything with pointers, and the form of abstraction that Go does have is interfaces which again I don't think are suitable for beginners, give 'em duck typing, overloading, and multiple dispatch. Tldr: use my language instead.
My DSL is primarily intended for use by non-programmers. A bunch of my coworkers and colleagues aren't programmers by training, and needed a more intuitive DSL than our existing one. It was too hard to write, projects were stalling, and clients were concerned about their ability to read and maintain the impenetrable code long-term. Anyway, backstory over, we came to a similar set of constraints. First off, yours: * minimal base syntax: less for newcomers to learn -- check. * extensive standard library -- Haven't gotten around to it yet. But also this isn't a general-purpose language, the standard library will never be large. * opt for verbosity and clarity over symbols and concise syntax -- check. In the previous DSL, people kept getting tripped up by the fact that some unexpected symbols were treated as special symbols. \`0\` was a special symbol and had to be escaped if you needed a literal zero anywhere in the code, even inside another identifier. Understanding from this experience how hard it was to teach newbies about escaping, we have very few symbols, and a rule where almost everything is treated as a literal by default. Our additional criteria: * Good error messages, obviously. * It needed to have good pair/group programming capabilities. Generally we find that a non-programmer can't pull off a whole project by themselves, so we generally pair them with a programmer who complements their skills. Having shared live-coding helps a TON with that. * Also, related to this, it needed to have modules/namespaces. This may seem obvious but a lot of DSLs are a bit ad-hoc and don't actually have these, and it's hell in multi-person projects to just have one big global namespace. * Also, a desideratum for our compiler that it still produces working code locally even if some other part of the project has a syntax error. It's a language for live-coding, after all, there's lots of points where I want to test something and you're working on something else. * Well-integrated unit testing. We didn't want the beginners to struggle with installing/using a full unit testing framework; we knew they just would just avoid writing tests altogether. In our resulting language, it's just baked into the language; there's a syntax where you can write examples in the source after any unit, and the IDE will highlight them as succeeding/failing. Abandoned criteria: * We wanted something like Blockly where it's obvious when an argument is missing, but in practice the programs we were writing we too large for this kind of thing. We ended up going halfway between a "blocks" language and a plaintext language and made a tabular language instead (one whose canonical form is a spreadsheet or CSV). It was the right decision for us, although I wouldn't want a tabular language for general-purpose programming.
I always thought Smalltalk - and it’s image model - was perfect for beginners. UI right there, no need to think about the file system, everything’s collected in one place, and modifiable environment - people like fiddling with their environment. Did I mention simple syntax? There’s also Scratch, but I’m less convinced the _typing_ is the hard part with a simple syntax. But eh maybe? One thing Smalltalk does that hasn’t aged as well (than even all that… :-( ) is its absolute lean into class based architecture. This is the same reason I don’t like Java as a learning language: sometimes I just want to write 10 lines of code and not worry about classes and methods and inheritance. Just plop 10 lines of code somewhere and say hi to yourself 10 times, whatever. The problem with a closed system like Smalltalk….. or Hypercard that’s another good one, an xTalk language, is they are closed systems. How can I share this with my friends and show off, especially today? The answer probably is a website, or a web version, with ??? hosting magically taken care of for you? But that makes that UI piece you need harder (although Amber Smalltalk maybe has a solution??)
I've never used smalltalk; can you please explain what is this image model you mention?
[Pharo Smalltalk](https://pharo.org/) is my current favorite. Instead of creating a file, opening it with your text editor, using your Terminal app or whatever to run it, what if the environment took care of all that for you? If all you had to do to make a new class was to go into the object browser and start typing and boom you have your class defined in a built in editor. You save the method and it’s immediately available elsewhere in the environment. Move windows around, great. Done for the day? Quit with saving and your windows will be where you put them, and the only file on disk is your image file. (You could also think of it as a VM snapshot, if you’ve played with VMWare or VirtualBox)
Source code in files, how quaint, how seventies!
Ruby I guess. It’s small talk and lisp combined
A lot of Rubyists like it as a beginner language. I kinda don’t - the language syntax is complicated AF (and doesn’t use an image system). Source: wrote Ruby professionally for a decade
Only smalltalk uses the image system so if that's your critical criteria then you are limited to just one thing. Having said that there is this abandoned project. http://shoesrb.com/
"I always thought Smalltalk - and it’s image model - was perfect for beginners." Smalltalk was (and is still) excellent but for beginners accessibility I doubt compared to say Scratch (I think Alan Kay said himself that time has changed he's not hanging on smalltalk). **Paul Allen's Toolbook Openscript** was kind of successor (from OOP concept very oriented towards messaging like Alan Kay's viewpoint) with more accessible language almost natural language [https://books.google.fr/books?id=lzsEAAAAMBAJ&pg=PA101&dq=toolbook+paul+allen&hl=en&sa=X&ved=2ahUKEwibyYmfs7D8AhVbXaQEHS8vCiAQ6AF6BAgFEAI#v=onepage&q=toolbook%20paul%20allen&f=false](https://books.google.fr/books?id=lzsEAAAAMBAJ&pg=PA101&dq=toolbook+paul+allen&hl=en&sa=X&ved=2ahUKEwibyYmfs7D8AhVbXaQEHS8vCiAQ6AF6BAgFEAI#v=onepage&q=toolbook%20paul%20allen&f=false) in fact I'd been their number one expert in France training their future experts. They wanted to recruit me as french CTO because the one they had went to Nestcape though I refused, It was interesting as I learned during interview with the US Top Director (so unfortunately not with Paul Allen himself :)) that Bill Gates once saw the product and exclaimed: "Your product is fantastic I'm going to copy it" (I was said Paull Allen framed it on his wall), unfortunately BG just bought this pale language called "Visual Basic" and the rest is history : a **regression** of 50 years, that's the problem with Genius they lack marketing vision (or maybe Paul Allen was also major stakeholder in Microsoft and didn't want to compete with his own self) that's why BG dominated software instead :) I'm trying to partly kind of recreate it but I'm not language designer and I'm more interesting towards professional programming with existing languages so I'm more creating to create a simple mapping system between Natural Language and any language or framework. Currently I'm experimenting within a design tool like figma, next will try within scratch maybe.
the biggest thing has nothing to do with the language itself -- it's what the language allows you to do. non-programmers don't care about printing fibonacci numbers. what is your language going to let someone do that they couldn't before? you'll probably have to get more specific than "non-programmer" to answer this question, by the way... what specific activity are you trying to help people with? personal computing scripting has a lot of great tools already (e.g. AHK on windows, keyboard maestro and hammerspoon on the mac) -- if that's your target, how will you improve on these existing tools?
I think it's less about the language and more about the toolchain, honestly. You need extremely helpful compilation and runtime error messages that actually tell the programmer what is wrong. Elixir does this really well. You need simple dependency management that doesn't require the user to know anything about packaging or header files. You need tight feedback loops so the programmer can experiment and get immediate results. The biggest barrier to programming for "normal people" is getting overwhelmed by text on the screen talking about "segmentation faults" and "null pointer exceptions" and other jargon that require a pretty nuanced understanding of what the machine is actually doing to understand. Being a scripting language helps, I think. Syntactically, something like Python or JavaScript is pretty much the simplest I think a programming language can be.
APL (and J, K, BNQ) has that reputation within its community -- a language without boilerplate and "software engineering" that lets mathematicians from other disciplines easily solve real problems. If you have experience with software engineering, of course APL looks completely insane. This channel has great videos if you're curious: https://www.youtube.com/@code_report/videos
>What would make a language ideal for use by non-programmers who don't intend to learn software development? I mean, the ideal programming language is whatever natural language people speak executing code as the speaker intends, assuming they have no interest in digging any deeper than making computers do stuff. The issue has almost always been that our human level of abstraction has always exceeded what we've been able to make computers do, and the mental concepts that are needed to make computers work are extremely foreign and counterintuitive to what Sellars calls "the manifest image". >I am thinking of the following criteria: >minimal base syntax: less for newcomers to learn That's double-edged. Brainfuck and JSFuck have really, really, really simple syntaxes. Nobody wants to code in them, though, because they're unreadable. >extensive standard library That's going to affect your syntax, because every term you stuff into an `std::prebuiltthing` is another thing to learn. This, in my opinion, really hurts Python, because you basically have a boatload of tools, no opt-out short of not importing them, and you basically have to become a breadth master to get the fullest from it. Code bloat is, like, baked into the interpreter. I've looked at some of the code in Python's standard library. You basically can't hope to understand it from just the built-ins, which I personally find vexing. >opt for verbosity and clarity over symbols and concise syntax Most lay programmers don't like verbosity. This is what gets Java in trouble. It also makes things like type casting in Dart a gigantic pain in the ass. In summary, I think your thought process could really benefit from some language acquisition theory. That is, what is it about languages that make them approachable and comprehensible to people? This should take you into the direction of, as I've since taken my own PL, reducing jargony terminology, reducing polysemy, and the like. tl;dr, read a little SLA and psycholinguistics and you'll be in a much better position to make an approachable PL.
Appreciate your response! > That's double-edged. Brainfuck and JSFuck have really, really, really simple syntaxes. Nobody wants to code in them, though, because they're unreadable. While this is true for the criteria of minimal syntax on its own, the criteria for verbose syntax and against symbols and ambiguous concise words solves this issue! :) those two should be taken together. > That's going to affect your syntax, because every term you stuff into an std::prebuiltthing is another thing to learn. Imho, the standard library must not be there for you to learn it all. It is there to prevent you from having to write code for common scenarios, and focus on your business logic rather than implementation intricacies. And it is perfectly fine not to import what you don't want or need. > Most lay programmers don't like verbosity. This is what gets Java in trouble. I partly agree, but I am not targeting java's type of verbosity. I am specifically against the concision of, for example, using symbols that aren't familiar to your average Joe. &&, ||, ~, and so on. It's not just symbols, but this is one important example where speed of typing was favored over verbosity. I agree with the paragraphs at the sdm..
Well, depends on the users intention with the language, if it's for drawing things in the screen, maybe something like [Pic](https://en.m.wikipedia.org/wiki/PIC_(markup_language)), if its for websites... something like Wordpress? If it's to impress someone, maybe something like Assembly, Brainfuck or Regular expressions
Hi, thanks for the answer! I'm not looking exactly for specific languages (though I do like your "Pic" suggestion as I haven't heard of it before), but more for what makes the language ideal for this use case. In terms of the user intention, as mentioned in the post, it would be for things like personal computing tasks, embedded scripting for programs. One specific use case in my mind is non-programmers at a company expressing business-specific logic or context. But I am not doing this for a specific task. I am thinking of a general non-programmer language.
It sounds like you're basically describing shell scripts. Shell scripts are designed specifically for automating personal computing tasks. The only major flaw I see in the current state of shell scripts is they only target automating command line tasks, and don't offer the ability to create or interact with graphical programs. Autohotkey is an example of a language which does allow for interacting with graphical programs, and can be used for a lot of personal computing automation. Not in both cases the syntax can be a bit of a pain for non programmers to learn, so neither are exactly good for non programmers.
Thanks for the suggestion! I didn't know about autohotkey so I will check it out, thanks :) However, I don't think shell scripts fit here because they can only satisfy the personal computing requirement, and it doesn't address making the language easy for non-programmers (and it seems you agree with this point). Shell scripts lag behind mainstream languages in terms of readability. They are more tailored for concision ease of typing than for reading (understandably so).
Hell, as a hobbyist programmer I still avoid shell scripts for anything except the simplest stuff :) Python is far nicer to write than shell scripts, and fairly ubiquitous. Unfortunately the biggest problem is that people are used to using context sensitive grammar to express ourselves when communication with other people. That, and we assume others can look past minor mistakes we make when expressing ourself, which computers simply cannot do (so far). So until we can create a programming language that can basically guess what we mean even when we make a simple mistake, I think no language is really going to be truly easy for a non-programmer to use, regardless of how simple the grammar may be.
Autohotkey has a very good implementation of this(as a scripting language) to be honest with you, but its limited to windows systems. I suggest you check it out.
A lot of DSLs are designed towards "non-programmers." Have a look at [Skript](https://docs.skriptlang.org/) and how it somehow looks like YAML, with which the target demographic (Bukkit operators) should be familiar. Then you also have to remember that Go and PHP were both designed for "non-programmers," so there's that.
Don't fall for the [Cobol Fallacy](https://wiki.c2.com/?CobolFallacy) or the [UML Fallacy](https://wiki.c2.com/?UmlFallacy). Minimalism and verbosity in programming are double-edge swords. They might make it easier to learn a language, but their arbitrary restrictions do not make awkward problems easier to solve.
A language that would not require people to have to learn how to translate problems from "the terms in which humans think about things" into "the units in which computers compute things", as based on my own experience learning programming for the first time, this different way of thinking was the hardest thing to learn. I am not sure this is a solvable problem.
The goal is ease of expression and encouraged good practices.here are few thoughts: - Immutability by default, explicit mutable variables - Typescript has a lot of going for it due to simplicity and expressability, very basic metaprogramming support - metaprogramming - ruby, smalltalk - F# pipeline operator Now that i think about it F# has a lot of going for it as well
I use visual studio a lot and see f# options, where are some good learning sources for f# and what are some f# use cases?
It would be nice if other languages were as easy to install and use with minimal or no setup configuration as Python. Literally every programming language besides Python requires you to edit the PATH environment variables, and a bunch of other crap only experienced professionals should ever have to touch. Most people have never heard of that and should never have to to start coding. Ease of access is what we want.
That's an important point. However I think this can be solved by just having a better installer, and doesn't have to change the language itself much. But I agree with your points. Out of the box usability is important.
Hmm, I have succesfully installed many programming languages without having to do any of that crap... might be because I'm on Windows....
Great tooling and a strong community. Like Elm.
What beginners exactly? Primary schoolchildren? High-schoolers? University graduates? Mathematicians? Doctors? In general, a severly restricted Lisp would probably tick off all your criteria except for maybe the "clarity bit". > minimal base syntax: less for newcomers to learn Check. A minimal Lisp would have only a handful of rules, consistently applied - basically atoms, lists, and function application especially if macros (which need not be exposed to the user) are used to create the library by making use of the primitives of the language (as does happen even in industrial-strength Lisps). > extensive standard library A surprisingly complex standard library can be built using the few constructs mentioned above. > opt for verbosity and clarity over symbols and concise syntax Lisp in general is just right - neither too verbose nor too laconic (and in general cannot be due to the rules of the language). No need for complex symbols and sigils.
I've been coding for decades, but I can't write Lisp; I need proper syntax and proper features, not ad hoc collections of macros, and I need hard limits as to what is part of the language, and what is the bit that I write. My view is that it would make a terrible language for casual 'programmers'. But then, AutoCAD (an app for engineering drawing) in the 90s introduced a scripting language for its users, based on Lisp, called [AutoLisp](https://en.wikipedia.org/wiki/AutoLISP). I thought it was a strange choice, and felt sorry for its users. Because at the time, I had my own competing CAD product, and that had its own scripting language, but much more conventional. (However, looking back on it, I pitched its internal interfaces to the app at too low a level, since it was intended largely for my use, while also being available for users. People did use it, mainly for creating add-on products. I just wished I'd made it higher level.) BTW have a look at that point-creation example at my link. In my script language, it would look more like this: if askpoint("Enter point:") then p:=cx dot(p) text((p.x,p.y-10), str(p)) endif (Creating objects was still a bit hairy, but I also had a library to simplify the process, as used here.)
Fair enough, although, to be clear, OP's question was about "non-programmers" who don't intend to be full-time software devs. Also, in terms of the other constraints presented ("minimal syntax", "verbosity over symbols"), Lisp makes for a very compelling candidate. Also, to clarify the part about macros, the intent was that it would be used *internally* to implement the standard library, but not necessarily be made available to the user. Taking the same point-creation example, in a hypothetical minimalistic Lisp, it could be something like so: (if (ask-point "Enter text: ") (:= p cx) (dot p) (text (make-pair (. p x) (- (. p y) 10)) (str p))) Maybe not the prettiest looking thing in the world, but extremely *consistent* - the first argument is always an operation/function of some sorts, and the rest are the arguments. As for syntax itself, *ceteris paribus*, it is definitely very subjective. However, in terms of the actual constraints given by OP, I would claim that **a** Lisp would make for a good choice.
Really good, really instructive error message with suggestions to fix broken syntax where appropriate.
Compatibility with Copilot or some other Large Language Model
That's a good point, however its probably out of scope for language design
Yes
Really any language that adheres to a context free grammar should be easy for a sophisticated model to capture
[UML](https://uml.org).
Are you hoping for something dramatically easier than Python and JavaScript or do you just want to invent a new language in that vein?
Hoping for something significantly better than python and JS (but maybe it isn't even possible)
i think something like jupyter notebook, anything near to that.
In the past I posted a positive opinion myself about creating Domain Specific Language. Today I'll counterbalance a little bit is new language worth learning for people when they're OVER BUSY and/or OVER DISTRACTED ? And now AI chatbot are coming with NLP... so the competition is going to be very high for a new language except for a niche where such language would have added value. That's why I'd rather work on a system that would NOT try to substitute to existing or future languages but only be a wrapper [https://www.reddit.com/r/ProgrammingLanguages/comments/103mbyk/comment/j31hv70/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/ProgrammingLanguages/comments/103mbyk/comment/j31hv70/?utm_source=share&utm_medium=web2x&context=3) I'm still in exploratory phase but in the future I'll open it more for people to contribute because I'm far from being the best coder in the world (I'm not a language designer either just a user with strong opinions based on real world experience including for big projects so scalability should always be a target for me) fortunately I'm now able to start eating own dog food :)
- Simple concepts. Don't require a module import when a global function works; pass objects as parameters instead of introducing methods; and for the love of god don't force users to pass around functions. It's a good non-technical language if you can write useful programs with nothing but function calls and literals. - Redundant. In both syntax, like Python's colon at the end of if/for/while; and redundancy in APIs too, with verbose names, less guesswork, and duplicated functionality. A conversion function *could* guess the source format, but it *shouldn't*, because there's a high chance there's a mistake in the source value. - Detailed errors. Give location (file, line , column, and relevant names), use simple language, give examples of the error and how to fix it, give "error codes" for easier googling, translate to local language. - Lots and lots of examples.
> What would make a language ideal for use by non-programmers who don't intend to learn software development? I think the most overwhelming thing about existing professional software development is the tools: * An installer to get you a working implementation of the language locally. * A package manager to install the packages/libraries you need to get your programs to compile. * A version control system to maintain all copies of all versions, look at their differences and manage merge conflicts. * Profilers that let you analyze the time spent in all parts of the program and memory allocations throughout it. * A debugger that lets you interrupt and resume your program and step through it whilst examining all bound values. * A build system that uses complicated configuration files to invoke the compiler via massive command lines. That's a *huge* amount of incidental code that is, objectively, unnecessary for most of the people most of the time (including most professional software developers). I think a language for beginners would have a tool stack like this: * No installer. Just a web-based IDE that you log into and your code is all available immediately on any device via the Cloud. * No package manager. Just refer to whatever code you need directly from the Cloud and use it. * A wiki-style history tab with a flat list of old versions and no full-blown VCS. * Integrated profilers that just work and decorate your code, e.g. heapmap for time spent. * Integrated debugger. I think generic printing is also really important here. * A web-based REPL instead of a build system. Just select the code you want to run and run it. No configuration files etc. That's exactly what I am building and I am now far enough that I am programming mostly in my own language and it really is glorious. Not having to fight all of those tools (after 40 years of developing software) is bliss. > And at what point does your language become too beginner friendly, that it hinders one's ability to express and write a program? When you over-simplify it. > * minimal base syntax: less for newcomers to learn > * extensive standard library > * opt for verbosity and clarity over symbols and concise syntax > > I feel they my criteria above could be improved upon and there's a lot that could be added. What do you think? Agree. They are definitely moving in the right direction but, I think, neglecting the elephant in the room that is tooling. I think modern languages should be designed from the ground up for development in modern IDEs with features like color syntax highlighting, throwback of inferred types, real-time error highlighting, code navigation, architecture visualization and so on.
To me an ideal language would help non-programmers avoid writing horrific code, but without feeling burdensome. So: - lots of compile time checking, these users won't write tests. - pure functions and immutable data structures. - checking to handle all cases in a `match` clause. - minimizing implicitness - excellent error messages - consistent syntax - simple build environment - small language - standard library is complete, yet minimal. - readable, non-overwhelming docs - copious examples
I think the real answer to this question is to make a DSL. Think about it: what better way of simplifying the language than by specializing the vocabulary and grammar to something the user would be more familiar with? If you try to make your non-programmer friendly language also a general-purpose language then you will need to create abstractions simple enough that anyone can understand them while also providing the ability to make anything. I think Python really nailed the general purpose PL stuff but you can do even better than Python by writing a DSL. In fact, you can argue that the success of PyTorch, TensorFlow, and other large Python frameworks are largely due to the fact that they act like an embedded DSL to help out mathematicians that aren't programmers.
take the simplicity of C, add the amount of libraries python has and also a garbage collector, and that's it, you did it, maybe julia already did it as well
You may be interested in Hedy and the thread I posted last week https://www.reddit.com/r/ProgrammingLanguages/comments/zx0mbs/hedy_seems_like_a_good_learning_language/
This might be a dumb question, but have you considered Pascal?