On Tue, 2013-01-15 at 17:33 +0100, mist wrote:
[…]
> :O You are probably the very first programmer I have encountered so far that prefers proportional fonts for code. I need some time to even try to imagine how this may look.

Use an editor like GEdit and change the font to a proportional one and admire how much nicer the code looks!

(There are some aspects of some coding styles that work well with monospace fonts, that make code look dreadful in proportional fonts, and vice versa. For a fair comparison make sure a style that is reasonable for both monospace and proportional is used.)

I really cannot understand the obsession computing people have with using monospace fonts, I just assume it is a hang over from the line printer era which created a mindset that most people do not challange. As soon as computers moved from 80x24 terminals to editors with pixel based accuracy and nice fonts I ditched all use of monospace fonts.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2013-01-15 at 11:49 -0500, Andrei Alexandrescu wrote: […]
> I, too, prefer proportional fonts in code and tried hard to use them in TDPL. I couldn't find a reasonable way to make them work in LaTeX/listings (indentation and vertical align are pervasive issues) and besides there are really elaborate monospace fonts to be had nowadays, so I chose Bitstream Vera which is beautiful. (Took me a week to decide on TDPL fonts alone but it was time well spent.)

LaTeX and listings works fine with proportional fonts for me. What problem were you having.

I'll bear Bitstream Vera in mind for the book I am just starting.

> Same deal in Emacs - there's just no good editor support for proportional fonts in code yet. Russel, what editor do you use?

I use the one true kitchen sink, Emacs, mostly. Using Ocean Sans Std. Eclipse, PyCharm, IntelliJ IDEA, NetBeans, GEdit, all using Ocean Sans Std.

XTerms are a problem, command line tools assume monospace fonts and so terminal have to use monospace fonts, which makes VIM use really awful.

gVIM is no help. It allows you to choose a proportional font and then uses it in monospace mode.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 1/15/13 11:59 AM, Russel Winder wrote:
> LaTeX and listings works fine with proportional fonts for me. What
> problem were you having.

In book code samples you need frequently to align things vertically (e.g. comments):

int a = 42;   // the meaning of everything
a += 0.1;     // error! cannot assign double to int

> I'll bear Bitstream Vera in mind for the book I am just starting.

Hope it's a book on D :o).

> I use the one true kitchen sink, Emacs, mostly. Using Ocean Sans Std.
> Eclipse, PyCharm, IntelliJ IDEA, NetBeans, GEdit, all using Ocean Sans
> Std.

Guess I'll just try it!!!


Andrei

On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote:
> On Tue, 2013-01-15 at 17:33 +0100, mist wrote:
> […]
>> :O You are probably the very first programmer I have encountered so far that prefers proportional fonts for code. I need some time to even try to imagine how this may look.
>
> Use an editor like GEdit and change the font to a proportional one and
> admire how much nicer the code looks!

GEdit is rather weak :( I am using VIM and Eclipse for coding and changed Eclipse font to monospaced Terminus font from default proportional. Problem I have with proportional fonts - they are not random-access ranges but sequential ones :) My brain is not capable of computing required offset for 30-40 proportional symbols in no observable time, contrary to monospaced.

I still prefer proportional for books and web, of course, because it looks better and normal reading is indeed sequential.

sorry if this has already been posted, but Phoronix did an article on John Carmack's words as well, and the forum discussion has a bit of talk about D in it (specifically how it compares to C++).

http://phoronix.com/forums/showthread.php?76719-John-Carmack-s-Comments-On-C-C#post306255

On Tue, Jan 15, 2013 at 04:30:55PM +0000, Russel Winder wrote:
> On Tue, 2013-01-15 at 17:02 +0100, mist wrote:
> […]
> > monospaced fonts everywhere to rule them all! :)
> 
> Monospace fonts are an aberration of the typewriter era.
> 
> All text, including code, should be displayed in proportional fonts, in my case Ocean Sans Std on my machines.
[...]

Eeek! That would make it impossible to indent code correctly, especially when there are wrapped lines. I much prefer my grid-based typewriter display, I have to say.


T

-- 
Guns don't kill people. Bullets do.

On Tue, Jan 15, 2013 at 05:30:34PM +0100, monarch_dodra wrote:
> On Tuesday, 15 January 2013 at 16:17:27 UTC, H. S. Teoh wrote:
> >On Tue, Jan 15, 2013 at 03:07:08PM +0100, monarch_dodra wrote:
[...]
> >>I always change the font size of my editor, depending on how concentrated I am, my position in my seat, or by how complicated the current algorithm is. Or simply if somebody is looking over my shoulder.
> >
> >Huh. I'm glad I don't have the latter problem. Well, good ole ctrl-Z to return to the shell, or just ctrl-T ctrl-T (I use ratpoison) to switch to another window, etc., works for me. But then I don't work in a situation where people I don't want looking at my code can simply walk by and look over my shoulders. Office security, man! ;-)
> 
> ROFL, I meant when a colleague is helping me debug. Things are easier if I bump up the font size by a couple of points, so they don't have to bend down to my level or sit next to me just to see my code.

LOL... talk about lost in translation^W I mean, transmission.

OTOH, that's why I prefer using very large fonts (18pt on 1600x1200, or 15pt on 1280x1024), period. It's easier on my eyes, and also easy for my colleagues to read from behind my shoulders.


T

-- 
MSDOS = MicroSoft's Denial Of Service

On Tue, Jan 15, 2013 at 05:31:04PM +0100, mist wrote:
> On Tuesday, 15 January 2013 at 16:22:19 UTC, H. S. Teoh wrote:
[...]
> >Heh. On the contrary, I find ssh to be a pleasant experience. Most GUI-heavy editors are so painfully inefficient to use that I find VT100 emulators far more pleasant to work with.
> 
> I am vim user myself, but some legacy shells did not support more than 80 symbol width, thus the pain and according code style guidelines for us poor programmers on that project :)

I'm perfectly fine with 80 column max, actually. I find that overly long lines are very difficult to scan. But then if the coding style requires 8-space tabs and you're writing XML, then, well, I can understand why that would be painful. ;-)

On a tangential note, I used to write Perl code with 2-space indentation, with code blocks nested 8-10 levels deep. The cascade of }'s that often occurred at the end of functions was quite a sight to behold.  :-P


[...]
> >I have a 1600x1200 screen, and an 18-point font, which gives me 93*41 terminal size. I find that just about right. (Like I said, I maximize everything, and anything significantly smaller than 18-point font, I find quite unreadable.)
> 
> Well this is probably the main reason of different spacing tastes. I have literally twice as much vertical space fitting ( 1920x1080 @ 9pt ), can imagine how it makes you favor more compact style.

Probably. And it's probably the reason I dislike today's trend of half-height^W^W I mean, half-width, monitors: I always work with maximized windows, and I don't like overly long lines, so resizing the font to approximately 80 columns at 1920x1080 would literally be half-height for me, even worse than 80x24.


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg

On 01/15/13 18:52, H. S. Teoh wrote:
> Probably. And it's probably the reason I dislike today's trend of half-height^W^W I mean, half-width, monitors: I always work with maximized windows, and I don't like overly long lines, so resizing the font to approximately 80 columns at 1920x1080 would literally be half-height for me, even worse than 80x24.

xrandr  --output DVI-0 --rotate left

:^)

artur

On Tue, Jan 15, 2013 at 10:58:47AM +0000, Russel Winder wrote: [...]
> Go has an extreme position on this, there is one and only one style of code that is acceptable, the one defined in the gofmt program that is used to format all Go code. I happen not to like some parts of it, but I live with the enforced style.
> 
> Python is less extreme, in that there are many styles of code allowed, but there is PEP-8 which is "Python style as Guido intended".  This is supported by the pep8 program for enforcing elements of style. I have disagreement with some of the choices, but I live with it, and format my code to PEP-8 except for the line length rule – which is just so 1980s.
> 
> C, C++, D, Fortran, Groovy, probably need to learn a lesson from one or other of these.
> 
> The issue is that having a single global style standard for a programming language makes it easier to read code in that language.
[...]

I used to despise Python, because of its imposed indentation conventions. But after I started using SCons, I acquired a liking to the "whitespace thing". It's actually very nice to be able to indicate nesting just by whitespace alone. No need to worry about pathologies like }'s on the wrong line, leading to wrong indentation and misleading code appearances, etc..

I used to hate being forced to code in any other style than my own, too. But after working with my previous supervisor, who used what I considered an overly verbose style, I started very much liking the fact that the code is so easy to read, and identifier names so easy to guess. There were no creative (aka inconsistent) abbreviations, shortcuts, etc., everything followed a predictable scheme, and declarations and wrapped lines line up correctly. You didn't even have to know much about the code to be able to correctly guess what it does.

Compare that with the other project that I worked on, in which everything was in terse C coding style: inconsistent abbreviations everywhere, unhelpful local variable names, gratuitous omission of whitespace, etc..  It was anybody's guess what a piece of code actually does. Sometimes, when enough pointer-to-struct-of-pointers-to-structs coupled with tables of callback function pointers (with unhelpfully terse names) which are initialized by calling tables of function pointers which are initialized in diverse obscure places, the exact location of which depended upon runtime parameters, it was impossible to understand what the code does even upon a careful reading. Needless to say, plenty of bugs abound due to people not understanding what exactly the code is doing.

Having a global coding style annoys most programmers (probably because it insults their creativity), but it does a world of good when you're working in a large collaborative project.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.