The bit that distinguishes GUIs from CLIs is that the computer recognizes millions upon millions of inputs that mean nothing to it, and thousands upon thousands more that are duplicates. I.e., there are x * y pixels on your screen and depending on your mouse's resolution they can all be clicked, but in practice any given screen only has a select few meaningful "clicks". I assert that the amount of effort required by our brains to aim a mouse is substantially more than typing a command, even for a lamer. It isn't really very difficult to learn how to use well documented commands. It's quite difficult to figure out how to use unintuitive, poorly documented commands; but then the same is true of GUIs. Not only is the GUI much more exhausting to use, but it's also much more exhausting to program, debug, and test. GUIs are substantially more complex than CLIs, and even TUIs; that complexity necessarily introduces more programming errors.

The number of subcommands and complexity of parameters available to a command line program is equivalent to, if not greater than, the number of inputs available to a graphical program. After all, at the end of the day graphical programs are implemented on top of command line programs. Even if that weren't the case there's no reason that a command line interface (in theory) ever has to accept fewer subcommands than a graphical interface.

Well, sure, if you're going to go to the trouble of programming them in yourself, instead of letting a shell do it.

With new storage technologies like memristors, we could store ALL of our stuff "in rom" except its not ROM, it's non volatile storage as fast as RAM is. So everything will load and save stupid fast, and no more waiting for boot, it'll already be booted since everything is running from non volatile media.

Hehe, well I assume there would be an option to "ignore" current state, and reload all processes.

Pkrcel, i am disappointed that such simple facts cause you to "give up".

Except most of those things are not "discoverable" from the GUI. For example, I had no idea Alt+Up would move up a directory (and I don't know which file explorers support that). It would be fine if you learned a shortcut for every single function, but most software has too many functions for the available shortcuts (there's a very good reason that vi is modal and emacs is horrid ).

In any case, there's no reason that a command line file explorer couldn't also support that same shortcut. In fact, your command shell could even be modal and allow shortcuts like that too. Essentially, everything a GUI can do a CLI can do better (except for graphics).

Perhaps I should have been a bit more strict in my terminology because it isn't clear that I mean text-based (i.e., text terminal) programs. I personally don't require a command shell only. Interactive, visual programs are great. Vi is an example. The point is, the text-based interface keeps things simple. There's no question where focus is. The keyboard always inputs to the right place. Etc. It's simpler, but it can do everything a GUI can. Graphics are completely unnecessary and generally don't add any value that cannot be achieved in plain text. I would know because I use a text interface for 99% of what I do on a computer. A well designed text-based program can be discovered just as easily as a GUI.

I wish more people were interested in having alternatives to Null. It's an outdated concept, and it speaks more to the low-level value of a pointer than the implicit meaning we give it in context.

Depending on the context, Null can mean:
- This variable hasn't been initialized; nobody has decided what the value should be yet, so it is Null by default.
- The variable has been initialized, but the value isn't known at time of initialization, so it is left Null until the value is known.
- The value is known, but the value is "no value", so Null is deliberately assigned like a placeholder for "None".
- There was an error in calculating the value, so the value can't be known, so Null is a signal to fail gracefully.

I'd love it if a language came along that had specific kinds of Nulls for these four cases, especially if you still got the old Null behavior by default but you could opt in to being more specific.

I actually saw a talk where a guy implemented these in Ruby, and it was pretty interesting. The errors you get from relying on a more-specifically-null value really tell you a lot more about where to start debugging.

The paradigma "form follows function" means more than only to speed up.

It means, the most important is the purpose of the program. Some programs have evil purposes, like viruses. Many are only time waster, like games, although you can say some are training for quick reaction or brain jogging. And there are technical, office and learning programs you need for serious work.

After Vedanta philosophy the best programs are those whose intention is to serve God. Such a program could be about herbs and healing plants. To show how senseful nature has created healing plants for all purposes together with the humans. Bear in mind that most modern pharma products are nothing but isolated active ingredients of plants. But in plants you have a natural combination which makes it easier for the body to handle without byeffect. And through byeffects of medication more people die than through car accidents.

Many programmers want to program something, but they don't know what. The result often is a time waster for the user. If you make a program that makes people realise God you are going in the direction of heaven. Thats the most important paradigma.

I found out a few years ago that you can "simulate" named parameters in C++ via the Builder pattern. Useful if you have an object with lots of variables to construct it:

FooBuilder builder;
builder
    .setName("Foo")
    .setDescription("Lorem ipsum dolor sit amet")
    // ...

Foo foo = builder.create();

Those functions will return a reference to this. So yes, that's the wiki definition of method chaining.

append: This is not a language feature, but then it kind of is since it's parsed by a meta object compiler: Qt's signal/slot mechanism.