"Unnecessary complexity" is all those arcane coding rituals that we do, that our users don't know or care about, but we have to do because our current tools demand it.
We can't get rid of necessary complexity and so we probably can't design a programming interface for someone that is completely illiterate in math & logic.
But what we can do is 1) Eliminate unnecessary complexity, and 2) Provide helpful, structured, interactive, learnable tools, which help guide the author as they do all the "necessary" steps. If we just did that then that would be a huge improvement from the state of the art.
What exactly do you mean by this? I can think of many things that fit this description but none that don't have good reasons to exist or remain.
PRINT "This is nice"
Then, you would type:
10 FOR I=1 TO 10
20 PRINT "This works too! Number ",I
30 NEXT I
40 GOTO 10
Today, you go to your computer and ...
open an IDE, define a project, pick your Java environment, select "file new", write some random incantation of "public static void main", accept the suggesting missing imports if you are lucky (if your ide doesn't figure them out, you have to do them yourself), and after a while you actually start running.
In the BASIC example, the only "unnecessary detail" are the unreferenced line numbers 20 and 30, which indeed become optional in later basics. In the Java example, everything I described above is incidental. It is not useless in the grand scheme of things of projects with millions of LOC and tens of developers and stuff -- but it is unnecessary for small examples. Java does not scale down.
Python mostly scales both up and down, but it still isn't as easy to start writing stuff the way it was in the 80s.
The most popular programming environment, by far, is a spreadsheet - it's not imperative or object oriented, but rather functional. and it also fails to scale up or down.
echo "This is nice."
Then, I type:
for i in {1..10}; do
echo "This works too! Number $i"
done
Now, how do you replicate
SAVE "myprogram"
LOAD "myprogram"
RUN
My point is that the old environments, while limited, scaled from zero to useful with much less requirements than today's environments, which scale much higher at the expense of a beginner's joy of experimentation.
But I still think there are simple things that beginners can do. The whole SAVE, LOAD, RUN concepts also had to be learned. And you only need to know some text editor to be able to save a file. It can then be run with `bash myprogram`. And then later you can add the concepts of adding a shebang and making the file executable.
Also, the huge advantage of teaching shell commands is that it is actually, currently useful. I use those commands every day at work, despite having learnt them initially on an old Sun server many moons ago. I can't say the same for Spectrum Basic! :)
AFAIK, the closest in Ruby would be something like:
for i in 1..10 do
puts "This works too! Number " + i.to_s
end
First, it looks awesome. You should do a Show HN sooner than later.
Having a few decades of experience under my belt, I'm sure I'm blind to some things newcomers/starters would see, but what I did notice:
- Camel case is bad for mobile typing, and bad for non-coders in my experience; underscore is better for the latter but not for mobile typing, so that's not really a solution unless you can add an underscore or some other character (non-minus-dash? center-dot?) that can be pressed directly.
- Case sensitivity in general is best avoided in beginner languages, which if adopted might make the above point moot.
- I personally find the pairing of "end" and ":" confusing, possibly because of years of "begin/end", "{/}" and "indent: dedent" experience. Most people seem to have a better intuitive grasp of the indent/dedent than any other block scoping, but for mobile I guess ":/end" is acceptable although "{/}" might be better.
- What is the distinction between "let" and "variable" ?
- The "#number" syntax is not intuitive - I goess it's a replacement for function names or line numbers, for refernece purposes?
- One of the conceptual problems that some people have is with the "=" sign for assignment, as it conflicts with its use in mathematics. All overcome it sooner or later, but when I've shown APL ( where assigment of 3 to a is written A <- 3 ) or Pascal ( A := 3 ) to non-programmers, this confusion never comes up. I would recommend keeping = for comparison, and using another symbol for assignments.
- Consider adding a variable value display. I've used PythonTutor[1] to teach basic JavaScript and Python non-programmers with great success. A complete value trace is likely beyond the scope of codechat, but a variable display might be very useful.
All in all, I think it's awesome. Are you familiar with Atari VCS 2600 BASIC[0]? That's what it reminded me of.
[0] http://boston.conman.org/2015/06/16.1 [1] http://www.pythontutor.com/
Case sensitivity: I'd prefer to make the language case-insensitive (or at least avoid uppercase in anything builtin), but then I'd need some other way to distinguish types and other identifiers. Any suggestions? There is already an issue for this: https://github.com/stefanhaustein/codechat/issues/1
Blocks: I was using {} before but it was inconvenient on mobile. Significant indent also seemed tricky. So I went for this combination for now.
let vs. variable: let declares a constant. Typing effort for let vs. variable is on purpose O:)
The #number syntax is for identifying specific instances if they are not explicitly named. Makes sure editing an "on x" trigger replaces it (opposed to adding another one).
Assignment syntax: Will change to := as suggested.
Variable value display: Will add "something" to do this.
I wasn't familiar with Atari VCS 2600 BASIC, but I must admit that my first programming language was (Spectrum) BASIC and I am trying to avoid some of the issues I found confusing in 1983 O:)
Maybe some kind of GUI would be better, as a way to ease typing commands.
Something like Pythonista or Lisping on iOS.
On another note
[Flashing Block here]
- Java code needs to be in a class. I can't open up a file and start typing immediately
- bool(midnight) being false
- C header ifdef silliness to make sure you don't double include a header
- circular dependency import issues in many languages
- strings and bash as the lowest common denominator meaning that almost everything that glues commands together must first write a parser for the output of `ls`
- our not putting encoding explicitly into files meaning that there have been decades of people getting weird glyphs when sending files to each other.
- implicit str to bytes and back in Py2 causing billions of spurious decode/encode calls. And many more incorrect calls
All this stuff is small , and has reasons. But it's also stuff that's been around for decades and decades and cascades into massive weirdness. Death by a bazillion idiosyncrasies.
Since Java 9 not anymore, thanks jshell.
(Note that this is orthogonal to namespaces - i.e. ways to handle naming conflicts- nor encapsulation -providing a single entry point for changing a variable. Lexical scope was not created to solve either of that).
And an upper bound to how long it can theoretically take to build something is the same as the time to transmit that information for a human plus some small epsilon: computers can run very fast.
So getting a computer to do what you want ideally should not be close to as slow and difficult as it is today. This is sort of the true goal, rather than formally specifying what you wish the computer would do. If you believe the goal is formally specifying what the computer does on top of bulletproof abstractions, we're already very far away from that - programmers today don't tell a CPU how to do branch prediction, or a compiler how to optimize their code, for instance.
Probably a really good system could do even better than the upper bound above - what if you knew what someone wanted before they could even describe it to you, and you built that for them?
We need better tools that let someone who masters programming to take their vision and realize it in production ready code as quickly as possible. This is a very different goal from "allowing a newbie to pick up a programming language in 15 minutes".
I desire master tools. Tools that I know if I invest the time to learn (whether that takes months or years) will allow me to achieve unparalleled productivity as a programmer.
Of course this goes all the way back to all the programming language that used to be used around the time of SQL's development, such as things like COBOL. They're just really tough to work with, even for those of us who learned it as one of our first languages. Anecdotally at least C structure languages now feel 'natural' to me, whereas the natural language programming languages always felt (and feel) like trying to fit a square peg in a round hole.
I don't; and the fact that I've known plenty of people who are not programmers before and do not consider themselves such afterward who have picked up SQL fairly quickly seems consistent with it not being that much of a barrier.
I think SQL had some design decisions that are particularly frustrating to programmers who are familiar largely with currently popular general purpose languages, though.
But outside the sweetspot, things tend to go south very rapidly and you end up needing detailed implementation knowledge that the language will fight against.
1) Specifying something in an unambiguous way.
2) Knowing what assumptions you are making.
3) Anticipating contingencies.
Read a contract or the tax code. Even though they are using English (in the US), it requires an advanced degree to be able to craft such legal documents well.
It is the same thing in software. No matter how easy and intuitive you make the language and environment, you will still run into those 3 issues, and it will require dedication, training (whether formal or informal), and time to make a great programmer.