To add more context to that https://en.wikipedia.org/wiki/Walter_Bright

Although i have never though of actually write a language i can agree on those. Especially Minimizing keystrokes. I want the language to be verbose and easy to understand. Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on !

> I want the language to be verbose and easy to understand.

So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction.

What I want is the language to minimize language entities used to do a task (from parser's perspective those would be AST nodes), and I want those tasks to be general and high-level. This is what makes source code comprehensible, not verbosity.

Each instruction may be easy to understand, but the programs are not easy to understand at scale. So that's probably not what stevoo wants.

Of course it's not (or rather, I would be surprised if it was), but he phrased it in very wrong way.

>> I want the language to be verbose and easy to understand.

> So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction.

Please don't do that: You took what he said, jumped to the most extreme case, and then attributed it back to him. He never implied that he wanted to write in assembler. In fact, based on the part you didn't quote, I think he would not want to work in assembler.

You may dislike this form, but it shows exactly why stevoo's opinion is formed on wrong basis.

> In fact, based on the part you didn't quote, I think he would not want to work in assembler.

I have hard time to understand what he meant in this sentence:

> Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on !

Is it a praise of having plenty of code for a simple thing? Or is it a rant?

For an analogy, before there was anything like modern math notation people would write out the problem and solution in plain language. On one hand, that made it very accessible as long as you knew a few terms like "sum". On the other hand, the reader has to build a relatively small mental model out of a lot of words.

Is it better to concentrate hard on a system of equations taking 1/4 of a page (with lots of whitespace) until you grok it, or read five pages of prose at fairly normal speed and try to build a mental model of it? Which better confers the ability to quickly come to the realization of something like "that's a parabola" or "the minimum of that function is obviously seven" or whatever?

Analogies are only so useful, but I think there are enough parallels there to shed some light.

Right, but your verbose example reduces ease of use.

It's two axes. J is not verbose, but is impenetrable (certainly to a novice, others more familiar see a lot of benefits to it). Ada is fairly verbose, but is pretty easy to understand. A page of Ada code is probably a handful of lines, mostly to aid in clarity, of J code. Though the Ada code has type safety that the J code lacks. Assembly, as someone else referenced, is very verbose, but hard to understand once you get beyond a certain scale.

Write once, read often.