(a) just because a language has more advanced things doesn't mean they have to get used (b) the history of this industry is full of 'simple' languages that produced all sorts of terrible results, practices, and habits.
No, scheme and lisp both force newcomers to think in a totally different way: prefix. It's very unnatural for non-programmers and even for seasoned programmers. Balancing all those trees in your head is difficult and taxes the memory. It takes you away from solving the problem and keeps you working the language itself. This is the primary reason the lisps haven't taken over in 50+ years now.
My 14 y/o daughter is having no trouble with it - in fact she asked why doesn't everyone use S-expressions? Regarding the parentheses, that's simply a non-issue. Both vim and Emacs handle the parentheses so you don't have to worry about it.
Finally, the reason Lisps haven't had much traction over the past 50 years is the Von Neumann computing model proved very useful on anemic hardware and languages such as C were designed to this model. Today's hardware is forcing us to rethink our approach. That's why the Lisps, especially Clojure, have recently gained a lot of traction. You ma want to revisit these languages again.
Modern BASICs don't use line numbers or even the let Keyword. In old BASIC you had to use a $ sigil after your variable for strings. In modern BASIC compilers you have to declare the type e.g. DIM Name AS STRING. Keywords don't have to be type in all caps either in a modern BASIC.
I think a lot of these suggestions are trade-offs in complexity. For instance, sure you could have one type of looping mechanism but really you're just moving the complexity inside it. It forces you to use more if, then, else statements within the loop.
It reminds me a lot of Linus Torvalds arguing for monolithic kernels over microkernels. Microkernels might have nice simple atomic units but they have very complex interactions. Where as monolithic kernels have more complex atomic units but less complex interactions.
Most of the complexity I find in programming comes from libraries and frameworks. When I started programming, I thought I would be able to easily make full-blown GUI application. I thought that's what programming did. Once I actually started to learn how programming worked, the biggest leap for me was figuring out how real-world applications were made from such basic units as variables, loops, and if statements. Learning frameworks has always taken me much longer than languages.
This, I also feel is the gap between academics and real world coding. Students learn all kinds of programming constructs, type systems, garbage collection, memory mapping, data structures and algorithms, yet are extremely ill prepared to write a non trivial real world application.
The world is full of simplified programming languages. The problem with newb adoption isn't just a function of ease-of-use, the simple programming language must also interact with a familiar UI. Why would I, as a newb, want to write in a simple programming language if it can't do something sufficiently complex, like create form UI, or change a web page, or interact with my OS to do something useful?
This is why VBA is so common. It's a simple scripting language that is exceedingly forgiving and interacts with a built in UI that most folks are already comfortable using. There is a "Macro Recorder" that writes the script for you if you wish. As you advance in your VBA skills you can interact with other VBA enabled applications on your machine and then graduate to shared libraries and com objects and interact with the OS. Furthemore, Microsoft Office applications come with a built in IDE (VBE), so you are ready to go, out of the box.
I'm not convinced. The existence of "complex" features in a language aren't an issue IMO as long are they're not shown right away. You almost always present to beginners variables, functions, conditions, loops, basic types and one kind of list, and let them play with that.
They'll quickly get the gist of it and be wanting to do something actually useful...
The scary part is not usually in the language itself, it's at the boundaries: interaction with the APIs of the platform it's running on, UI manipulation, file read/write, etc.
It's hard to build anything useful without I/O, and that's when things start to become hairy.
That, and when you have to master abstracting things away, which comes pretty fast.
The only people who might comment on this are those who already know how to program so no longer see the complexity as a problem. However, the level of incidental complexity in programming languages, libraries, frameworks, environments is astonishing. Please keep encouraging others to focus on simplicity even if you don't get much support here.
16 comments
[ 3.4 ms ] story [ 37.9 ms ] threadFinally, the reason Lisps haven't had much traction over the past 50 years is the Von Neumann computing model proved very useful on anemic hardware and languages such as C were designed to this model. Today's hardware is forcing us to rethink our approach. That's why the Lisps, especially Clojure, have recently gained a lot of traction. You ma want to revisit these languages again.
20 LET H = "HELLO WORLD"
30 IF L = "BASIC" GOTO 40
40 PRINT H
50 END
It's not only simple, but it also is as powerful and complex as you want it to be.
It reminds me a lot of Linus Torvalds arguing for monolithic kernels over microkernels. Microkernels might have nice simple atomic units but they have very complex interactions. Where as monolithic kernels have more complex atomic units but less complex interactions.
Most of the complexity I find in programming comes from libraries and frameworks. When I started programming, I thought I would be able to easily make full-blown GUI application. I thought that's what programming did. Once I actually started to learn how programming worked, the biggest leap for me was figuring out how real-world applications were made from such basic units as variables, loops, and if statements. Learning frameworks has always taken me much longer than languages.
This is why VBA is so common. It's a simple scripting language that is exceedingly forgiving and interacts with a built in UI that most folks are already comfortable using. There is a "Macro Recorder" that writes the script for you if you wish. As you advance in your VBA skills you can interact with other VBA enabled applications on your machine and then graduate to shared libraries and com objects and interact with the OS. Furthemore, Microsoft Office applications come with a built in IDE (VBE), so you are ready to go, out of the box.