Hacker News Reader

Comment by dTal | Hacker News Reader

Pff, these are nothing. Buckle up!

* 1-based indexing is superior to 0-based indexing.

* If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.

* Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense.

* Vim and Emacs both have terrible user interfaces, and are an inferior experience to even a normal text editor let alone a decent IDE. Users have Stockholm Syndrome.

* For beginners, BASIC is great and Python is terrible.

* There are many languages with a 'mystique', like Lisp and APL. The correlation between 'mystique' and practical utility is inverse.

* Source code should liberally use Unicode symbols.

* Sigils to indicate variable type are actually pretty great, especially if enforced by the compiler. (See above regarding BASIC)

Let the flames begin!

View on HN

> 1-based indexing is superior to 0-based indexing.

“Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.” - Stan Kelly-Bootle

> Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense.

Horizontal scrolling is almost always a bad experience for the user. But 80 is way too restrictive. I'd say no more than half a standard monitor wide is the character limit. What's a standard monitor depends on what's used by the devs writing the code of course.

> Source code should liberally use Unicode symbols.

Give it a few years. But make sure there's a good normalization (there are several ways to print the same glyph on the screen that are different bytes in memory)

The 80 column “rule” also discourages the use of descriptive naming, which IMO is far more important to readability than short lines.

Also 80 columns is near impossible to adhere to for more verbose language.

For both Python and Go I use descriptive (often long) names and ~90-char line limit, and use linebreaks liberally to reconcile the two

Descriptive naming usually isn't.

    E=m*c^2 or 
    objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ?

Now imagine that you're not looking at a famous equation and you tell me which one you would rather have to sus out the intention of.

    a = b/c

    numApples = numBananas/apple BananaConversionRate

The first one, no question about it.

Yes. We would want the descriptive names for identifiers which have broad scope, but short names for the local variables that work with them.

I would rather give a function the descriptive name in such a way that the parameters can then be given trivial, mnemonic names.

Strawmannish example:

   incrementAccountBalance(a, n)
   {
      ...
   }

The descriptive function name gives away what a and n are, so it is unhelpful to make this:

   incrementAccountBalance(account, amountToIncrementBy)

Reasonable middle ground:

   incrementAccountBalance(acct, delta)

With incrementAccountBalance(a, n), it's impossible to tell exactly what each argument is from the function signature alone. Of course I could assume that a = account and n = amount to increment by, but that's nothing more than an assumption, which only invites inevitable bugs. Alternatively I could look at the function body, and try to figure out what's going on, but that's time wasted that could be spent more productively.

Further, non-descriptive naming often assumes that the programmer reading and modifying the code has domain-specific knowledge. That might be true of mid level or senior engineers have have been with a particular company for years, but the new grad coming into a financial services company (a field he has no training or familiarity with) will have no idea what "a" or "b" means. I was in that position, and the descriptive naming absolutely would have helped me to learn and become productive with the codebase faster.

I'd say that your reasonable middle ground would be the best practice.

Opposite of my choice of which I also have no question.

> Also 80 columns is near impossible to adhere to for more verbose language.

Not if you use Unicode (and Chinese language).

At google (at least when I was there) they have a hard rule of 120 character lines or something. (I think it varies by language).

I thought the rule was ridiculous - until I realised one of my colleagues had set his computer up with 3 tmux sessions side by side, each perfectly fitting a 120 column code window. He never had to scroll sideways, and he was very productive with his setup. The fact he knew exactly how wide to make his terminals made his workflow much better.

I don’t follow that rule on my own projects, beyond keeping line lengths “reasonable”. But that rule might be on to something.

I don't think the fact that it worked for one guy (or more accurately, that he adjusted his workflow according to this rule) makes it a good rule by definition.

It's not that they contorted their workflow to satisfy some arbitrary rules, it's that the fact of the dependable consistent rule made it possible for them to formulate an efficient dependable consistent workflow at all.

This is why I’ve come around on the 80 character rule after switching to Emacs, fitting four buffers side by side on my 27” monitor just works.

120 characters/3 columns is great for more verbose languages, but I find it a bit too wide for a vertical split on a 15” laptop monitor.

I just enable word wrap in my editor

I settled on 100 characters as the sweet spot, with an exception for trailing punctuation being allowed to go beyond (because you don’t want to wrap a line just because of some trailing punctuation).

Also sometimes comments.

Nah, comments are important and should be in the main field of view. :)

I remember hitting the punctuation dilemma with my self-imposed character limit. Putting the punctuation on the next line, looking at it displeased, moving it back, questioning the purpose of rules if they're not followed; racking my brain over the world's least consequential conundrum. Ultimately I decided to adhere to my limit, but to treat punctuation and the word that precedes it as a single unit to be wrapped together.

Horizontal scrolling can be avoided with line-wrapping. It's not always a good way to deal with the problem, but it's useful for some edge cases.

Line wrapping is often difficult to read as well. If programmers wrap the line themselves, they can break it up logically, rather than letting the computer break lines wherever it's convenient. Further, they can respect the indentation level of the line, whereas most line wraps I've seen wrap starting all the way to the left.

Vim has a setting to make line wraps start at the same indent as the line.

Word wrap. Turn on word wrap.

In every editor I've tried it on, word wrap wraps the lines all the way to the left, instead of respecting indentation levels. This makes for very difficult grokking of control flow, both in languages with significant whitespace and C-style languages. If programmers simply wrap their own lines, they can respect the white space conventions of their language and make it much easier for other developers to read later.

VS Code respects the indentation level (provided editor.wordWrap has some value other than "off" and editor.wrappingIndent has some value other than "none"). In other words, if a line needs to be split into 2 "virtual" lines to fit in the window, VS Code inserts a "virtual copy" of the line's initial whitespace before the second virtual line. By "virtual copy", I mean that the copy of the whitespace is never inserted into the file, but is added during the rendering of the contents of the file into the window.

Emacs on the other hand, has the problem you describe, and probably always will because of how hard xdisp.c is to modify and because the maintainers of Emacs probably do not consider the problem important enough to justify a big change to xdisp.c.

I was never a vim user, but my cursory investigation led me to conclude that vim, too, has the problem you describe.

The parent assumes that word wrap, a feature we take for granted today, is even a thing in the editors/terminals of legacy systems that this 80-character rule likely targets.

> I'd say no more than half a standard monitor wide is the character limit.

So if "monitor wide" is 80 characters, like a DEC VT-100 terminal, or WYSE-50 or whatever, then we have a 40 column rule.

Have you tried formatting tools like prettier / black / gofmt / rustfmt? I used to have lots of tabs vs spaces type opinions but now “use a formatting tool and stop arguing about it” has replaced all of my style opinions. Once you have more than one person working on a project it’s just so nice to never have a stupid argument about formatting again.

Agreed. It's a controversial opinion that opinionated languages/formatters are the way to go. :)

It will always baffle me how some programmers believe that meetings are the bane of their existance because "they only waste time", while at the same time they can entertain the "tabs vs. spaces" (or "vim vs. emacs") discussion for hours.

I don't care about the indentation method, I just want to press Tab, or Ctrl+S and have it do the right thing. Not waste any brainpower thinking about it.

I pretty much agree with all of these but two.

> 1-based indexing is superior to 0-based indexing.

this breaks the identity `arr[idx] == *(arr + idx)`. as a c++ (and sometimes c) dev, I tend to consider "index" and "offset" to be functionally equivalent. hard pass.

> If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.

I find "lining things up" to be pretty helpful for spotting mistakes in tedious code (eg, matrix initialization) where you have a bunch of similar lines of code in a row. am I missing your point, or do you just not agree this is useful?

> this breaks the identity `arr[idx] == (arr + idx)`. as a c++ (and sometimes c) dev, I tend to consider "index" and "offset" to be functionally equivalent. hard pass.

And I think that's the problem. Programmers have collectively conflated the concept of "offset from the address" and "position in the list" as the same concept, and they're not the same thing. Both concepts have their uses but they're separate distinct concepts. C and C++ don't index* a list, they simply offset it, and too many other languages that don't care about in-memory addresses or offsets have carried the concept from offset over to index erroneously.

I can see how in a higher-level language it might make sense to use 1-based indices. this is, after all, how humans typically count. I just don't agree with it as a general statement over all programming languages. in low-level contexts where you are working directly with memory, it is quite natural for indices (or idx * element_size) to be equivalent to offsets.

Depending on the context of the program, both can be more comfortable. Pointers/enumerators? 0-based Heavy math problem? 1-based

I believe there is a few languages which can let you set it

> this breaks the identity `arr[idx] == * (arr + idx)`.

Well, then, make the identity `arr[idx] == * (arr + idx-1)`.

Right. But while I'm just trying to do my work as a programmer, which of those two identities is going to be easier to work with, reason about, and come out of it with correct code? Hint: It doesn't have a "1" in it.

Your identity perfectly illustrates why 1-based arrays are worse rather than better.

That's true for C/C++, but in most languages used today where we don't use pointers, where is the advantage?

I'm hundreds of times more likely to have to write lastElement = array[array.length - 1] (there's the 1 again!) than I am to have to reason about the equivalent pointer arithmetic.

I thought we settled on lastElement = array[-1] for this problem (a little, but not entirely, tongue-in-cheek).

Even in a language without pointers, in a multidimensional array you can index the data one-dimensionally by array[index0 + N * index1] with 0-based indexing, as opposed to array[index0 + N * (index1-1)]. Where N is the length of the inner nested array.

And for that matter all algorithms for which zero-based indexing makes more sense are simpler, such as working with polynomials and expansions where the zeroth power is included in the expansion.

Having said that, I too prefer 1-based indexing because the list of algorithms that are written more cleanly (i.e. without constantly causing bugs when you implement them) is far larger for me personally, including all of linear algebra and related numerical methods.

In a language that has one-based indexing, can you treat a multidimensional array as one-dimensional? Or will it give you an array index out of bounds error?

That is, are there any languages that are both one-based, and will let you do that trick?

You would need it to support one-dimensional views (unless your data is just stored as one-dimensional to begin with). Certainly matlab and Julia do. Don't know of any new 1-based languages either way.

Yeah, let's use Unicode symbols. That lets us, for example, make it a challenge for others to figure out how to type stuff that they need to type. It lets us create variables that use characters that have almost exactly the same appearance as latin characters, but aren't. For bonus hilarity, create two versions of the same variable name, one with a non-latin-but-similar-appearance character, and the other with the latin character.

No thanks. Hard pass.

You could also use six different “right arrow” Unicode symbols, and have them each mean multiple different things, automatically inferred by the compiler depending on context! See the Lean mathlib ;-)

Indeed. If there's no button to type it directly on my keyboard, I'm not interested in having it in my code.

Not all keyboards are the same...

!@#$%^&*()_+}

That's why I said my keyboard. I'm not aware of any keyboards that would let you type the arcane runes used in APL without resorting to ALT-sequences or the Compose Key.

On a related note, if I could get a keyboard with an extra 50-60 keys that would send the proper scan codes to type unicode characters in one keypress that would be awesome.

I'm a big fan of unicomp keyboards, heavy steel buckling spring keyboards still made in kentucky. They make one with 24 function keys I suppose you could map.

https://www.pckeyboard.com/page/product/UB40B5A

Then there are the point of sale keyboards, this one has 60 keys you insert your own paper labels.

https://www.officedepot.com/a/products/361528/CHERRY-SPOS-Sm...

I don't know a lot about how keyboards work at the low level but wouldn't that require custom firmware to add new keycodes?

Well, you can either have software running on the machine that interprets "F15" as a particular key macro, and the keyboard doesn't care what you do with it, OR, yes many keyboards (especially the RGB variety) have tools to update the keyboard firmware to send different keys no matter what computer you plug it into, programming stays on keyboard. (often a simple arduino chip)

In this instance the Unicomp keyboard is not reprogrammable, while the Cherry is fully programmable.

Clojure is a highly practical Lisp that retains most of the Lisp mystique.

Previous Lisps were impractical largely due to lack of libraries, but Clojure comes with first class Java interop out of the box. But you still get macros.

I know you're joking, but the key difference is that OP's "controversial opinions" are high impact, whereas yours are not (e.g. spaces vs. tabs, 1-based vs. 0-based indexing). I don't think most of the opinions in the post are that controversial. Everyone who has ever worked for a fast-growing business knows it's OK to write garbage code sometimes, that some engineers 10x others, that unit tests are good, that SQL is to be treated as code, etc.

Spaces for indentation work perfectly fine without fixed-width fonts. If you indent code with leading spaces, things will "line up" with any font.

By the way, what's the misunderstand with lining things up?

I'll demonstrate using periods due to the forum eating spaces. The parts after the dots line up in a monospaced font.

Fixed width:.good

Flexible:....not good

.............so not good

This doesn't make any sense. Indented code does not have non-whitespace characters to its left.

Sure it does.

  const ONE      = 1;
  const MILLION  = 1_000_000;

Even without non-whitespace it's a problem:

def foo(arg1,

........arg2,

........arg3)

Your first example isn't what I'd call indentation. "Alignment" maybe. I don't think anyone would expect that to work in a proportional font.

For the second one, I'd write it this way.

def foo(

....arg1,

....arg2,

....arg3)

I prefer that even in a fixed width font.

This still matches the parent's picture

> If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.

As long as the limitations of lining things up "exactly" are avoided, spaces shouldn't be any different than whatever way comes from true understanding.

I do use spaces to indent code. And I still have no idea what my fundamental misunderstanding is supposed to be.

My take on it is that (most) code isn't a picture, so drawing with it (alignment especially) is missing the point that code is a form of text instructions.

If anything, the editor should "render" the text in a form that is pleasant to the eye, divorcing the meaning from the presentation.

Lining up things too much is a "works for me" way of baking presentation into the data, where the writer assumes that because it looks good o their setup, it will look well for the reader too.

Similarities can be seen to building web pages on tables, sending around Word documents, or hard-wrapping emails.

Spaces work well for indentation. You could argue here that typing one character (tab) is more efficient and maintainable than writing N (also semantically more powerful).

The real problem comes when people start aligning things on the middle of the line.

I think the solution is to rely on hanging indents rather than trying to align with the column of the previous opening parenthesis, bracket, etc.

So instead of this:

  def some_method(param1
                  param2):
      statement1

you do this:

  def some_method(
          param1,
          param2):
      statement1

Hanging indents work regardless of whether you use tabs or spaces for indentation.

My IDE types 4 spaces when I hit tab shrug

> the 80 column "rule" is as stupid in code as it would be in prose

I follow the 80-column rule in prose.

Emacs was a godsend for my 16 year old self.

It's an immensely self-documenting and self-explanatory system, and vastly different in that regard than anything else.

(Though once you go down the rabbit hole you eventually start to realize that elisp is a crappy way to program and the whole thing has a big-ball-of-mud architecture... Oh well.)

Point is, your preconceptions, from the heights of your experience, of what "newbies" find intuitive are likely very wrong.

> Vim and Emacs both have terrible user interfaces, and are an inferior experience to even a normal text editor let alone a decent IDE. Users have Stockholm Syndrome.

Well yeah, the UI isn't great. The whole point is to make it your UI, no?

I agree that Python isn't great for beginners, but I don't think BASIC is great either beyond a simple introduction to how we make computers do our bidding.

I learnt C as a first language, but think Python is a great language for beginners!

Forces okayish formatting, error codes are pretty readable, good library support for doing everyday useful things (for people not in the cs community), you don't have to strictly worry about type for your tiny scripts...

Why do you think it's not great? (in all sincerity)

Python teaches people that Python is a good way to do software.

The indentation is nice, but the language is not much more high-level than C, teaches bad habits by not thinking in types and granular interfaces, and encourages a counterproductive style of defensive programming - i.e. C++ is an awful language, but at least I can encode basic information about my code in the type system. Python trades that away so I have to write tests for the entire surface area - inside and out - of my code.

If there is something fundamentally wrong with my code, tell me now, not when it's half way through a job or worse attached to spending money.

You can write bad code in any language, but bad languages influence the way you think about programming. For example, C++ encourages you to think about side-effects in the language like SFINAE, D encourages you to metaprogram everything, Rust encourages you to think like a compiler (lifetimes), Haskell teaches you how to manage stateful code in a controlled and measured manner, etc. etc.

In conclusion, Python is not a terrible place to start (JS takes that award to my eye), but the progression to writing genuinely reliable and fast code is too obfuscated. I'd rather we teach people C. C requires a helping hand, you can fumble around with Python.

Now we're talking!

Although given that I, random internet stranger, agree on 6 out of 8 of your points, it mean that they aren't too unpopular. :)

>Although given that I, random internet stranger...it mean that they aren't too unpopular. :)

there is a common perception that programmers often don't get statistics. Not that I do either, but just saying.

controversial opinion: the need of statistics and hard math for programmers is overrated :)

really controversial opinion: the abilities of programmers to use statistics and math is just right!

> Let the flames begin!

Yeah, it seems that your evil plan works. People just can't stand it despite your clearly stated intent.

"Give your controversial opinion" always, always just leads to to people saying the thing they know people they like will agree with and, and that they imagine people they dislike will disagree with. In practice, they end up just saying things that are entirely uncontroversial and immensely boring.

You, though, you're getting there.

I agree with every item in principle, and disagree with every one in practice. Here's to a better world!

>If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.

What if I just like the aesthetics of consistently-indented code?

Can I marry you?

I will add:

* Tabs > spaces

* Proportional > monospaced

* White background > dark theme

Though I hate what you say, I will defend to the death your right to say it.

But holy cow the white background made me angry hahah

White background if there's a window near-by. Dark background if in a dimly lit space.

I don't know if I use tabs or spaces anymore. I hit tab, but my IDE just sort of makes it up from there. Works well enough.

Visual Studio (not Code) handles it quite nicely. If you hit tab and it replaces it with 4 spaces, then you backspace, it removes the 4 spaces as if they were a tab. So it saves with spaces, but treats them like tabs.

I've been switching over to tabs to mark indentation levels and spaces for alignment after that. I used to use all spaces. Disagree completely on the proportional fonts, but maybe I just haven't tried one. Code presentation is important to me, since it makes it really easy to grok the structure of what's going on and to find some simple errors if you align certain things together.

Fluorescent white is for accountants and managers.

Can you elaborate on the fixed-width fonts point?

As long as source code resides in plaintext files, writing in columns (i.e. vertically aligning blocks of text) seems like an excessive endeavor with little gain.

We are not typesetting; formatting resources should be kept to a minimum to make the code easy to handle in plaintext. Fortunately, code is restricted enough that we can do pretty well without those.

You don't write spaces to align text in Word: it's a nightmare to maintain and the software provides better tools for that purpose. Why do we still write code as if we were using a typewriter?

You may think you are improving readability by aligning columns of text, but then, the impossibility of standardizing such baroque formatting rules goes against that. Furthermore, you are preventing people from using a variable-width font, which is actually better for readability.

So you’re against any indentation? I don’t think you’ll find many programmers at all who agree with that statement.

Indentation is OK, sure. I was talking about aligning stuff on the middle of a line.

I find tabs better for indentation but in practice end up using spaces.

I believe you'd like elastic tabstops: http://nickgravgaard.com/elastic-tabstops/

I love them! It's a shame they didn't really catch on.

If you are interested in experimenting with non-fixed width fonts for programming, you could try Source Insight. I was at a company that used it for a while and surprisingly, I didn't miss using fixed width fonts at all.

* 1-based indexing is superior to 0-based indexing.

1-based indexing is a special case of 0-based indexing.

* If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.

Fundamental misunderstanding of what? Not having shit PRs on Github?

* Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense.

Yeah okay true

* Vim and Emacs both have terrible user interfaces, and are an inferior experience to even a normal text editor let alone a decent IDE. Users have Stockholm Syndrome.

Also true

* For beginners, BASIC is great and Python is terrible.

The language for a beginner is irrelevant, the only metric that matters is: Are you enjoying your coding experience? Keeping students coding is all that matters the language is irrelevant.

* There are many languages with a 'mystique', like Lisp and APL. The correlation between 'mystique' and practical utility is inverse.

This is almost a tautology, of course mystique will lead to less practical utility because their is simply less interest, less tooling, and less understanding about how to use the tool.

* Source code should liberally use Unicode symbols.

Someone has never looked at Agda source code before and it shows.

* Sigils to indicate variable type are actually pretty great, especially if enforced by the compiler. (See above regarding BASIC)

Gross.

zero index makes sense because (and i will use C syntax here)

a[b]

is equivalent to

*(a + b)

with a being a pointer and b an integer. this can be seen as well in the fact that

a[b]

is equivalent to

b[a]

where in both cases a is a pointer and b is an integer.

Thus, the index into an array is fundamentally the same as an offset into that array. Usually, in languages that do use 1-based indexing (like in pascal strings), the 0th byte is used for something else.

The point being that thinking in terms of 1-based indices means that you have to use a system where addr+0 is invalid, and the first element of an array at address X is X+1.

Now you could just shift everything by 1 and just declare that +1 means +0, but then you lose all meaning to the offset vs index and ahhhhhh

In my view, the fact that a[b] is equivalent to *(a + b) in C and C++ (in most languages with arrays the latter notation is meaningless) is a sort of a neat coincidence which we shouldn't feel bound to in language design in general.

There are many reasons to depart from this idea in languages far removed pointer arithmetic. For example, Julia has 1-based indexing and I appreciate it for that when doing computational mathematics. It is closer to familiar notation: A[1][1] is the element of matrix A in row 1 and column 1. In a language with zero-based indexing, it is sometimes easier for me to allocate an extra row and column, wasting memory, than to shift indices and risk an inevitable off-by-one somewhere.

"For beginners, BASIC is great and Python is terrible." I am curious about this. Do you mind elaborating?

What was your first language? Mine was Basic.

Pascal was the first language I was taught in.

I still have not (after 40 years) learnt Python... Hang on, when did Python start....That long

Consider the the classic koan:

  10 PRINT "Retardo_88"
  20 GOTO 10

To fully grok this, the concepts you need are: the idea that you can instruct a computer to do things, the notion of source code as a list of such instructions which will normally be executed one at a time, in order, and - crucially - that the instructions can reference other instructions and that this is the fundamental leap that makes computers interesting. In other words, Turing Machines 101. It's a perfect demonstration.

Now consider the simplest equivalent program in Python:

  while(true):
      print("Retardo_88")

In addition to all of the insights mentioned above, you need the concept of higher order control flow statements, the concept of nested execution, the concept of boolean literals, the concept of a function call... there are so many questions that are hard to answer. Why do I need parentheses? Why do I need the colon? What's the deal with the indent? What gives with the weird grammar of "while true"? Etc...

It gets worse the moment you want to do anything nontrivial and have to wrestle with objects, methods, and dot-syntax. BASIC sends the message that computers are simple, easy to grok things that follow simple, logical rules; Python sends the message that they are a bottomless well of dizzying complexity.

As a perpetual beginner, I feel BASIC is under-rated. We should use BASIC to start children off with computing. They'll learn the hairy stuff in due time, but the key is to get them hooked early; and BASIC does an awesome job of that.

I would argue that a more measured alternative to your conclusion is “people should learn computers from the bottom up”, starting with direct exposure to a program counter and ending with high abstraction. I’m not sure this is the best way to learn, but I think it would be a lot better than what we teach now.

A great intro CS curriculum could be some RISC assembly -> C -> Lua -> Haskell -> Agda, maybe also branching off into lisp and prolog.

If you wanted to get really extreme, you could even tack on “Discrete transistors -> logic ICs -> FPGA ->”

"Modern" BASICs/Pascal are also otherwise decent languages that suffer from a reputation of newbies writing bad code with them.

I’m triggered

>The correlation between 'mystique' and practical utility is inverse.

lol tell that to the banks and trading firms that pay Arthur Whitney millions for his APL interpreter that looks like something out of the IOCCC

Vim is not a gui aka no user interface. I know you are joking though: vim > emacs > any IDE!

emacs is essentially a framework for building custom IDEs.

> 1-based indexing is superior to 0-based indexing.

Yes! But programmers are weird like that,I understand the rationale in case of C(Nothing that couldnt be solved then and there) but for high level or scientific computing? How many off by one bugs caused by this?

> If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.

Agree, that's one of the things I hate about python, the indentation are probably the worst solution to the problem of scoping code.

> Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense.

Agree

> Vim and Emacs both have terrible user interfaces, and are an inferior experience to even a normal text editor let alone a decent IDE. Users have Stockholm Syndrome.

Agree, both are very good pieces of software but I feel 99% of the new people swearing by them just do it to try to appear l33t

> For beginners, BASIC is great and Python is terrible.

In 1995? Perhaps. Now? Hell, no.

> Source code should liberally use Unicode symbols.

Hell no.

> There are many languages with a 'mystique', like Lisp and APL. The correlation between 'mystique' and practical utility is inverse.

More or less, great, but difficult, programming languages would never become mainstream, and like good old Joe Stalin used to say "quantity is a quality on its own"

> Let the flames begin!

As always with these type of comment OP is not as alone as they think they are.

Not sure why 1-based indexing is more logical in high-level or scientific computing.

The concept of x[k] meaning the object k spaces away from the beginning of x is very general, and still intuitively meaningful in languages without pointer arithmetic.

> Not sure why 1-based indexing is more logical in high-level or scientific computing.

Because mathematics and physics use 1-based array index since ever? I first learned about matrices in math classes, then in numerical methods (All 1-based) and then we programmed in Fortran (1-based).

It is not that is more logical, it is just a convention. But I have seen wayyyy more people complaining about 1-based index languages than about 0-based languages.

Reply on news.ycombinator.com