I haven't been programming long and don't get the nuances of functional and declarative paradigms. But I have a hunch that even if people made some new languages that balanced out the various concerns of complex compilers, programmer control, LOC, boilerplate, ugly syntax etc, it wouldn't fix much.
So, using research into how people best solve problems, I’m making a tool that helps people solve the problem of having an idea and not being able to make it a reality.
Novices will still have lots of problems. They don't really think about how sprites move in a game, they think they want to make a game kinda like Asteroids or more like Mario. What will really help them is a well organized, well documented template.
The problem is with documenting, organizing and making available the multitude of libraries and solved problems. Making them accessible through visual examples and natural language.
split array by pairs == arrayPairTransform([1,2,3]) == [[1,2]]
make array of pairs == arrayPairTransform([1,2]) == [[1,2]]
This is closer imho. You don't really have to worry about the [1,2].byPairs being prettier than splitArrayIntoPairs([1,2]). You can use your queries as the pretty documentation. You can choose which lower level language to use in the code column, without having to remember its particular syntax. You don't have to worry about naming as much, you're using tags instead.
A lot of novice programming is looking up code samples and libraries, getting them to run. Organizing existing code in libraries and samples for a specialized natural language search engine like in Mathematica seems like it would change some design decisions of the lower level language.
It's not as important if the lower level language is a bit more verbose. Your priorities for it would be performance, control, parallelism/concurrency, regularity. Expressiveness/verbosity can matter less if you offload it to another layer.
So, using research into how people best solve problems, I’m making a tool that helps people solve the problem of having an idea and not being able to make it a reality.
Novices will still have lots of problems. They don't really think about how sprites move in a game, they think they want to make a game kinda like Asteroids or more like Mario. What will really help them is a well organized, well documented template.
The problem is with documenting, organizing and making available the multitude of libraries and solved problems. Making them accessible through visual examples and natural language.
http://blog.wolfram.com/2010/11/16/programming-with-natural-...
The Wolfram approach of writing a query, seeing the output, confirming or rejecting it is the right direction. Memorizing syntax is a big problem.
This doesn't solve syntax memorization. This is closer imho. You don't really have to worry about the [1,2].byPairs being prettier than splitArrayIntoPairs([1,2]). You can use your queries as the pretty documentation. You can choose which lower level language to use in the code column, without having to remember its particular syntax. You don't have to worry about naming as much, you're using tags instead.A lot of novice programming is looking up code samples and libraries, getting them to run. Organizing existing code in libraries and samples for a specialized natural language search engine like in Mathematica seems like it would change some design decisions of the lower level language.
It's not as important if the lower level language is a bit more verbose. Your priorities for it would be performance, control, parallelism/concurrency, regularity. Expressiveness/verbosity can matter less if you offload it to another layer.