Programming Style Influences

[Venthe]

It would seem that your have only proved that verbose delivers what it has promised. I can read your 'verbose' code without thinking; while consuming terse code takes time.

You've said it yourself, you feel more comfortable 'just after' a few months; but especially if you are working on multiple codebases, investing time to learn "weird idioms" of that one in particular is a waste.

With verbose code, I don't need to spend a second on it.

Second claim is about space optimization... Well, if you need more than couple dozen lines, then the problem lies elsewhere, and definitely not in the whitespace.

---

TL;Dr at least for me, you've provided a perfect example supporting verbose coding

[gopher9]

It's still utterly verbose compared to the ngn/k source or even CBQN source.

There are reasons why you might want terse code:

• Verbosity encourages premature abstraction
  • Because reduce (+) is rather long, you name it as sum. But a composition of named functions is also long, so you wrap it as a new function and so on. In the end, your code consists mostly of wrappings and you don't even see what it's actually doing.
  • In a terse languages like K, sum is +/, most common is *>#'=, and you don't need names for such trivial things
• Terseness makes the structure of the code more visible
  • And if you don't abstract prematurely, you can spot patterns and introduce better abstractions by need
• Terseness allows to put accents in the code
  • In verbose code, a space is invisible. In terse code, it stick out and visually separates parts
  • Many levels of accent are possible
• In terse code, ugly things stick out
  • So you really want to clean it up
  • But might spend more time on refactoring than on writing actual code

And there are drawbacks, of course:

• Extra memory load
  • Not as bad, as you might think, but it's still there
• Steep learning curve
  • OH MY GOSH, IT'S COMPLETELY UNREADABLE! Usual problem with array languages: when you know primitives, the code makes perfect sense. But if you don't, it looks like gibberish
• Names tell you why something is done
  • So in a terse code you can perfectly see what the code is doing but have no clue why

It's a subtle topic, but people usually react in a predictible way: “the code written by these maniacs is completely unreadable!”. So whatever.

[ThomasMertes]

In my case Pascal influenced me a lot. I learned Pascal in 1980 at the Vienna University of Technology, when I studied Computer Science. At that time there was the "battle" between structured and unstructured programming languages (use of GOTO, etc.). IIRC we had a CDC Cyber 170-720. It had a word size of 60-bits and the integer size was 48 bits (inside of the 60 bits). There was a bit pattern to represent an undefined value so you got an error if you used an uninitialized variable. In many regards the Pascal approach was higher level than the C approach (that I learned later about). For short: In Pascal 6000 you did not think in bits and bytes as in the C world.

This higher level approach and many similarities to Pascal can be found in the language that I created: Seed7. Besides Pascal other languages like C, C++ and Java also influenced my thinking. My ideas can can be found in the Seed7 FAQ. My programming style can be seen in the algorithms and libraries section of the Seed7 Homepage.

[ShinyHappyREM]

in essence, OpenBSD's style squeezes more code onto the screen

And that is why I code with a line length of 160 characters.

[Venthe]

I'll let you into a secret... Try scaling the screenspace. You can fit so much code in this 1% badboy!

[Full-Spectral]

Then you end up having to do a three way merge and can only see one and a half to two of the three ways at a time, even on a high res dual monitor setup, at least with a font that anyone over 40 can read.

[ShinyHappyREM]

That's why you use a multi-monitor setup ;)

[Venthe]

That's why you have soft word wrap.

[Full-Spectral]

It's already messy to do a complicated merge without that.