“Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.” - Stan Kelly-Bootle
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)
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.
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.
Also 80 columns is near impossible to adhere to for more verbose language.
E=m*c^2 or
objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ? a = b/c
numApples = numBananas/apple BananaConversionRateI 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)
{
...
}
incrementAccountBalance(account, amountToIncrementBy)
incrementAccountBalance(acct, delta)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.
Not if you use Unicode (and Chinese language).
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.
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.
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.
> 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?
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 believe there is a few languages which can let you set it
Well, then, make the identity `arr[idx] == * (arr + idx-1)`.
Your identity perfectly illustrates why 1-based arrays are worse rather than better.
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.
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.
That is, are there any languages that are both one-based, and will let you do that trick?
No thanks. Hard pass.
!@#$%^&*()_+}
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.
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...
In this instance the Unicomp keyboard is not reprogrammable, while the Cherry is fully programmable.
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.
By the way, what's the misunderstand with lining things up?
The real problem comes when people start aligning things on the middle of the line.
So instead of this:
def some_method(param1
param2):
statement1
def some_method(
param1,
param2):
statement1
Fixed width:.good
Flexible:....not good
.............so not good
const ONE = 1;
const MILLION = 1_000_000;
def foo(arg1,
........arg2,
........arg3)
For the second one, I'd write it this way.
def foo(
....arg1,
....arg2,
....arg3)
I prefer that even in a fixed width font.
> 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.
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.
I follow the 80-column rule in prose.
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.
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.
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)
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.
Although given that I, random internet stranger, agree on 6 out of 8 of your points, 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.
Yeah, it seems that your evil plan works. People just can't stand it despite your clearly stated intent.
You, though, you're getting there.
What if I just like the aesthetics of consistently-indented code?
I will add:
* Tabs > spaces
* Proportional > monospaced
* White background > dark theme
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.
But holy cow the white background made me angry hahah
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.
I find tabs better for indentation but in practice end up using spaces.
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.
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
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.
10 PRINT "Retardo_88"
20 GOTO 10
Now consider the simplest equivalent program in Python:
while(true):
print("Retardo_88")
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.
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 ->”
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
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
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.
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.
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.
* 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!