Might be a bit of a struggle without syntax highlighting? Contrast won't get you very far.
edit: Also, and probably a lot more controversial, code structure matters a lot. No syntax highlighting will save you if your code consists of opaque blocks of text.
I remember using Think Pascal on the Apple II (too slow to be of any use) but it did a great job of highlighting the structure of the program under the source code. This is what I want syntax/semantic highlighting to do for me.
These screens are higher resolution and can have multiple shades of gray, which is much more than what those pioneers had to communicate with their users.
Horrendously expensive though.
In my experience syntax highlighting as a tool mostly help with certain classes of errors (e.g unclosed string or comment), not visually tokenising text for me to understand.
I've seen some such uncoloured theme (nofrils) that would de-emphasise either comments or code, and you could toggle between the two states, which I found quite useful in nicely commented files:
https://robertmeta.com/posts/syntax-highlighting-off/
There are a bunch of learnings and a couple of links to references in that article. Ironically one of the most prevalent I experienced was this one, which I found very odd because picking a colorscheme for my $EDITOR is quite literally a choice that would affect only myself:
> People on the internet will get very angry at you if you tell them you don’t like syntax highlighting. VERY ANGRY.
Some of these vim "color"schemes:
https://github.com/robertmeta/nofrils
https://github.com/clinstid/eink.vim
https://github.com/ikaros/smpl-vim
Example:
1. Goto here: http://goto.ucsd.edu:8090/index.html#?demo=Order.hs
2. Run Check, it should turn green
3. Break the code, e.g. turn around the >= sign in line 147
4. Run Check again, it will turn red and highlight line 147 and 148
We told the compiler that elements in an ordered list will be in increasing order (l.119). Now the compiler is able to check that constraint and by turning around the comparison we violated the it.
Ie by telling the compiler a tiny bit about our goals (have ordered lists) it is now able to check that our algorithm is correct.
All of today's human languages were developed in a time without computers, pens (and their predecessors) have trouble switching ink color for every word. If goose quills and inkwells could change color as easily as computer monitors, I bet there would have been at least a few languages that use color to denote meaning.
But in general, I'd agree, I've been using a monochrome color scheme for a few weeks (although mostly for the novelty) and it's definitely usable. When given the choice, I will use a full-color one though.
I feel like it does not really lose anything in grayscale.
Bonus: On a eInk display black on white is probably nicer: https://i.imgur.com/99DSGrV.png
(Does Imgur allow direct links to images?)
As stated above, I think that how the code is structured also heavily influences readability. Maybe even more than syntax highlighting.
Case in point: I was fortunate enough to work on a Haskell project some time ago ... and one of my colleagues from another team at asked me how I manage to make my code look that concise. No secret there, it is just pretty easy if the language is that expressive.
It's Elixir (https://elixir-lang.org/), but wow, Euphoria looks pretty slick too! https://www.rapideuphoria.com/