Hacker News new | past | comments | ask | show | jobs | submit login

The problem with programming isn't solving simple problems. The hard part is dealing with the hard problems. An important contribution of Computer Science is the recognition that abstractions (functional, procedural, object-oriented, relational, ...) are necessary when writing software of any significance. The paper's simple problems perhaps give insight into how a programming language for children should be designed, but for the most part its recommendations should be ignored.

The paper points out that non-programmers (5th graders) have trouble with NOT, AND, and OR and suggest in a separate paper that table based queries can avoid some confusion with these Boolean operators. I'm sorry, but a programming language without Boolean operators is going to be worthless. Just because 5th graders haven't learned De Morgan's Laws doesn't mean that we should throw out Boolean operators. What about lambda expressions, functions as first class elements, higher dimensional arrays, recursion, complex numbers, binary and decimal internal integer representations, floating point with exponents, built in log functions, setjump/longjump, call-with-continuation, threads, concurrency, interrupt handlers, atomic locking, streams, files, relational data bases, the list goes on and on.

Programming in a programming language for Kids tends to be tedious and very concrete. Scratch bored me to tears. Perhaps its a good fit for kids, but it's not going to be used to write a web server. I just don't see how these "experiments" give us any insight into non-toy programming.

In the 1970's there were still plenty of professional programmers and fellow grad students that felt like programming in assembly language was the highest form of programming. It was challenging, I did my fair share, but it was also brutish and nasty. There were no powerful abstractions to facilitate ones programming. Everything was concrete and explicit and terrible. The history of programming languages has been to build a tower of increasingly powerful abstractions over the hardware below. C++ templates, Haskell's type system, Scheme's call-with-continuation, SQL, these are so far removed from the simple little operations being performed by the processor, but they give us the power to write the programs that we do.

The use of abstraction in programming isn't limited to programming languages. Libraries supporting matrix operations won't make sense to a 5th grader or anyone else that hasn't studied matrices. So how is a 5th grader going to describe rotation of a graphical element? They don't know matrix math or trigonometric functions? Should these be eliminated from programming languages? Operating systems also insulate us from the hardware through abstractions not present in the physical hardware: processes, scheduling, virtual memory, files, abstract sockets, networks, threads. What about the other tools we use like relational data bases, source code control systems like git, and bug trackers? How about pseudo-random numbers and encryption? What do 5th graders know of these?

Finally, some professional programmers have to understand deeper issues, programming complexity, turing incompleteness, regular expressions, context-free grammars, LR parsing, performance of algorithms, correctness arguments. All of these issues have some impact on programming. Are we really going to throw all of this out because it is confusing to 5th graders? or even adults that haven't studied these issues?




Firstly, no-one is suggesting we get rid of the hard programming. But actually, I disagree with your point of view.

I do research into A.I., and often work with companies. I find problem fall into 3 categories. Approximately:

50% of problems are extremely trivial problems which we've know how to solve for at least 10 years, we just need to help the companies use the existing techniques.

15% of problems require techniques from the last 10 years or so, so require extensive up-to-date expertise but aren't interesting research.

5% of problems are interesting, hard problems which lead to interesting research problems.

30% of problems are so far beyond the state of the art they are impossible.

Helping people in that first 50% solve their problems without having to talk to us is an interesting area. At the moment they use tools like Excel and Microsoft Access. I believe there must be better tools for those problems, which aren't any more complicated. Why can't my mother easily produce (for a concrete example) create and update a schedule for her darts league, without needing me to help?


I took a business analytics class which taught SQL and basic machine learning. We exclusively used an excel plugin, and it was exceptionally easy to get great results. This sounds like something that would help that 50%.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: