On fonts and editors [was dfmt 0.1.0]

[Russel Winder via Digitalmars-d-announce]

On Fri, 2015-03-06 at 15:22 -0500, Ben Boeckel via
Digitalmars-d-announce wrote:
[…]
> 
> Well it is now more apparent with more quoting. It now appears that the
> first block is using 3-space indents while the bottom looks just fine
> even with the quote markers.

But there is no semantic difference in the code and it is all being
replaced anyway. I think the fact that a codebase should have a
formatter run over any change before being committed, to enforce the
rules of the codebase, will get round the issue anyway. Pythons pep-8,
gofmt, dfmt,… the use of such a tool, enforcing the standard of the
codebase is a good thing.

[…]
> Well, when that means you're going to have absurdly long lines to deal
> with in anything other than your definition "real" editors (and I've
> never seen one which fits your definition).

Such editors were being researched and created in the 1980s but
computers were a bit too slow for the necessary infrastructure and, more
importantly, a vocal section of the development community screamed,
these things are wasteful of resources, and we must have ASCII encoded
files as the storage of our code. This attitude has, in my view, been
the biggest stumbling block to progress in software development for the
last 30 years.

Now with suitably fast processors and graphics, we are seeing all the
technology of the 1980s reentering the arena, but instead of doing it
right, IDEs are having to spend huge resources continually
reconstructing AST data from the flat file input. Some of them do it
better than others, but if only it had been accepted that AST is the
correct unit of editing in the 1980s we would be a lot further forward
today.

> > I really dislike the Go obsession with block style alignment of
> > declarations.
> 
> I won't say I'm a fan of it indiscriminently, but if it's that or
> 200+-character lines, I'll chop argument lists up a bit to fit something
> more reasonable.

There is more than one way of chopping things up, and even aligning
them. Stepping away from monospace fonts, and the obsession with 2D
rendering of 1D data, gives a different view on chopping up which ends
up no better, but no worse.

[…]
> 
> And I find that monospace fonts tend to make it much easier to tell the
> difference between 'l', '1', and 'I'. Not so important in English, but
> it can be all the difference in code.

Important point. Fonts are context dependent. A font for easy reading of
plain English novels, may not be appropriate for other uses exactly
because the different uses and contexts of the characters mean the
glyphs must have different relationships. But this is a font design
thing and monospace versus proportional is not the major determinant.

> > In a real editor there is no hard line break, no need for this form of
> > indentation. Should a line be too long for the rendering area either
> > viewport or syntax directed soft line wrap are used. Having overflow is
> > mixing content with rendering.
> 
> You're making assumptions about the features of your users' editors.
> These features are not trivial to implement and this basically requires
> things like pygments and other tools used to render code to the web with
> all kinds of logic to handle dynamic viewports of the shown code. IMO,
> it is even worse than putting #vim:, #kate:, or emacs formatting
> directives in your code since it is implicit.
> 
> Personally, I use Vim because it works similarly for all uses. I don't
> know what I'd do if I had to work with a different editor for each
> language I work with.

I do not disagree. The problem is that Emacs, VIM, IntelliJ IDEA,
Eclipse, Netbeans, are editors based fundamentally on a 1970s view of
editing and resources and the world has changed. Fortunately, I am
hearing that some of the ideas of the SOE and AST editors of the 1980s
are being re-raised, now with the resources to deal with it. Should this
go forward, I can see VIM dying, Emacs dying or being rewritten, and
IntelliJ IDEA, Eclipse, Netbeans, etc. losing at least half their code
or more. The IDEs with all their "refactoring support" are almost
reproducing what comes for free with SOE and AST focused editors. 

As actors, dataflow, CSP were rejected by programmers in the 1970s and
1980s because they had processes and threads and really enjoyed
shared-memory multi-threaded programming (*), SOE and AST based editors
of the 1980s are effectively being recreated by the IDEs of the 2010s.
They are hamstrung by the continued obsession with the text file as the
primary unit of editing. As soon as they and programmer users get over
this, the sooner we can get on with better UX for development. (**)


(*) OK so operating system developers are allowed to do this stuff
because they have to, but applications people should not be doing any
such thing.

(**) And yes the very foundation of version control will have to change
as well.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20150307/c59084b1/attachment.sig>