On Tue, Jun 29, 2010 at 17:08, Robert Casto <[email protected]> wrote:
> Can't we just move on from simple text files and use something better to
> hold our source code? Why always such an unwieldy medium? Seriously, why do
> we have to use ASCII text files anyway? Couldn't we put something in place
> that would get rid of the parts we don't want the compiler to see? A
> pre-processor that gets rid of all the formatting, comments, or whatever
> else we want to put into the files. They would become smart documents that
> we happen to compile down to something the computer could run. Personally,
> I'm tired of all the debate about spaces, tabs, and other formatting. How
> about every programmer sets their own rules for how they like to see the
> code. They check check it back in and voila, the file is stored in a
> standardized format. The next developer could see the code just how they
> like it.
>
> Spaces and tabs are invisible. What we need is more formatting like we have
> in word processing documents. Let me put an image into the code. A link to a
> document. Anything. When it compiles, only the programming parts will be
> seen by the compiler. Until then though, we are all wasting a lot of time
> dealing with a file format that is beyond ancient.
A few (fairly random) thoughts:
Wirth's Oberon system supplied a rich text editor with fonts/styles
and embedded images. All source was written in this editor, giving one
the option of embedding images in comments, choosing tab stops etc.
Later iterations ("Oberon System 3") also provided a compound-document
based GUI ("Gadgets"). But, alas while you could embed images and
indeed arbitrary chunks of GUI into your source code, say for
documentation, all this was ignored by the compiler. It'd have been
cool if you could have said something like:
myGui := [ actual, live functioning GUI embedded in source right here ]
myGui.doSomething;
"cool", but not really useful since Oberon's approach to GUI was such
that this kind of code-driven GUI programming was unheard of. The GUI
was a document you created interactively, it was not something you
wrote a boat-load of ugly unmaintainable code to produce (a'la Swing).
Didn't IBM's Visual Age (for Smalltalk, later for Java, a fore-runner
of Eclipse) store project source in some kind of a database? Didn't
that suck?
Sure, you could store augmented parse trees in place of source, but
diff/merge of tree-like structures is monumentally more difficult than
diff/merge of textual lines (which is nothing more than a flat
sequence). Witness, for example, the memory consumption of XML-aware
diff tools. Witness how few of them exist.
There has been quite a bit of research on structured editors: i.e.
editors where you manipulate your program at the level of the parse
tree, not as raw text. The results have been mixed. If you'd like to
experiment with the idea, you could try paredit.el, which provides
syntax-driven editing for lisp-like languages in emacs. Some people
even like it.
Speaking of Lisp... a Lisp would make this kind of thing so much
easier to experiment with. After all *code is data* is one of the
central concepts of Lisp-like languages. For full editor
round-tripping, however, you'd have to figure out some way of working
comments into said data structure.
// ben
> On Tue, Jun 29, 2010 at 10:50 AM, Lyle <[email protected]> wrote:
>>
>> Reinier's Rules (ha!) are the best argument I've seen for tab characters
>> infiltrating source files, but when the bits hit the disk I agree with Ben.
>> For collaborative work, it's often tough enough to get people to indent
>> logically and consistently with just *one* type of whitespace character.
>> -Lyle
>>
>> On Tue, Jun 29, 2010 at 9:35 AM, B Smith-Mannschott
>> <[email protected]> wrote:
>>>
>>> On Tue, Jun 29, 2010 at 14:41, Reinier Zwitserloot <[email protected]>
>>> wrote:
>>> > I don't understand the tabs v. spaces war. There's clearly a right
>>> > answer:
>>> >
>>> > Tabs for indents. Spaces for spacing.
>>> >
>>> That's my thinking too! And yet I'm still an acolyte of "tabs are
>>> evil". It's too easy to screw up in practice. I have little confidence
>>> that most programmers are aware enough of what white space they are
>>> typing to stick to these rules consistently.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "The Java Posse" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>
>
>
> --
> Robert Casto
> www.IWantFreeShipping.com
> Find Amazon Filler Items easily!
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
