Discussion:
Non-text format for source code
(too old to reply)
Ivan Shmakov
2013-02-01 19:06:37 UTC
Permalink
[...]
For me, the issue is that I'd like to have a document that I directly
edit and work with (not unlike using DreamWeaver, for example, in
editing HTML) that supports the inclusion of good diagrams and
perhaps, if I'm crazy enough, a short video tutorial if I'm in the
mood to produce it.
Well, I'm getting the same feeling occasionally; e. g., when
posting to a Usenet newsgroup [aside: cross-posting to
news:news.misc]. Still, even as there are standard ways of
including all the sorts of nice stuff (such as SVG diagrams, or
digital signatures) into Usenet messages, there're those who'd
oppose even the inclusion of non-ASCII characters (or, if a
non-English newsgroup is considered, the use of an encoding
other than a prescribed one) or OpenPGP signatures along with
the message, even if done according to the standards.

Somehow, I come to believe that the use of a message format more
elaborate than "pure ASCII" (say: HTML5/XML) for email-like or
news-like communication may have its benefits. (Perhaps as well
as the use of such a format for the source code.)
Unfortunately, there's a catch...

[...]
It seems to me that in this day of so much work on standards, which
include not only HTML5 but also XML and many others, that we could
have compilers which aren't stuck parsing simple ASCII text. It was
fantastic (and the only way to go) when all I had was an ASR-35
clacking away and a video display (if you dared to even consider the
idea) could set you back US$40,000 or more. (I wonder how many
remember the old Plato terminals?) But today? With workstations
absolutely everywhere? And disk space almost as cheap as dirt
(though not nearly as likely to serve its purpose quite as long?)
Not just one video display; nay, not even two; but often three per
workstation??
... The problem is that these new facilities, once they appear,
are most surely going to be misused.

For an example, take a look at the contemporary Web [aside:
cross-posting to news:comp.infosystems.www.misc, too]. Every
other Web page is designed as if it's some kind of picture, not
a text (which it is, first and foremost.) Digging a bit into
CSS, what you're likely to find? Here comes an example:

body {
width: 1024px; /* 'cause everybody's screen is at least that wide */
font-size: 14px; /* it's enough for everyone, no? */
}
#leftbar { width: 384px; /* that's about 40 characters; good */ }
#forum { width: 768px; /* that's the rest of the screen */ }

Naturally, as soon as the reader of the Web page opts for
another font size (e. g., my preference would be no less than
20px), the design is screwed up instantly. (Not that this issue
is not relevant to the source code as it is right now: we have
those who adhere to the 80 characters per line limit, and those
-- who use newer code editors and IDE's, and wider screens or
smaller fonts, -- who don't; we have those who indent with 2
spaces per nesting level, and those who use 8; etc. And while a
switch to a non-ASCII code representation may obviate some of
these issues, it will certainly bring a bunch more.)

Given all the sorts of such poor designs I've seen on the Web,
I'd hesitate to use a system which /requires/ the code to be
worked on in a "WYSIWYG" fashion. Why, for the Web, my browser
of choice is Lynx, specifically for its ability to ignore CSS,
images, and all of such "creative freedom" that's so easy to
misuse. I still believe that there /are/ valid uses of such
technologies, both existing and to be developed, but for me,
there remains a big fat warning regarding their possible (as in:
most certain) misuse.

Hopefully, the technologies of tomorrow will come with some kind
of "safety mechanisms" against such...

PS. Also to note is that I don't know of any version control system
with good support for non-line-oriented data. Somehow, I feel
that even computing the "difference" (as in: diff(1)) between
two trees (as in: XML) is much more an issue than computing one
between two lists (as in: ASCII text.)
--
FSF associate member #7257
dp
2013-02-01 19:28:04 UTC
Permalink
...
        Hopefully, the technologies of tomorrow will come with some kind
        of "safety mechanisms" against such...
I think we do not need "tomorrow"s technologies to make most
if not all of Vladimir's suggestion.

Me, I would just include html links in the source such that
they will be treated as comments by the compiler/assembler/whatever
and be done with it. Without a lot of effort the source will
be both compilable and viewable with a browser, pictures
and all.
Now, I just put it all in a directory or make the suitable directory
tree so it will still be quite easy for anyone to locate the
relevant information but I can see how Vladimir's idea could
save time for someone seeing something I have done for the
first time. Even to me if I look at it some 10 years later
(though I must say I don't have much if any of a problem
reading 20 and even almost 30 years old sources of mine;
writing the correct comments is the most important part
when it comes to readability, after all).

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Jon Kirwan
2013-02-01 21:28:44 UTC
Permalink
Post by dp
...
        Hopefully, the technologies of tomorrow will come with some kind
        of "safety mechanisms" against such...
I think we do not need "tomorrow"s technologies to make most
if not all of Vladimir's suggestion.
Me, I would just include html links in the source such that
they will be treated as comments by the compiler/assembler/whatever
and be done with it. Without a lot of effort the source will
be both compilable and viewable with a browser, pictures
and all.
Now, I just put it all in a directory or make the suitable directory
tree so it will still be quite easy for anyone to locate the
relevant information but I can see how Vladimir's idea could
save time for someone seeing something I have done for the
first time. Even to me if I look at it some 10 years later
(though I must say I don't have much if any of a problem
reading 20 and even almost 30 years old sources of mine;
writing the correct comments is the most important part
when it comes to readability, after all).
Yeah, that's what I do, as well. However, I happen to
actually LIKE the idea of not having to force others (or me)
to put their fingers into several applications at the same
time just to understand ONE function. It would be nice to
have an international source code standard that goes past
ASCII, after all these years.

But yeah, I do what everyone else does and it works. I can
just imagine something nicer. Sometimes, change doesn't occur
unless you can imagine your goals.

Jon
Mel Wilson
2013-02-01 22:13:11 UTC
Permalink
Post by Jon Kirwan
Yeah, that's what I do, as well. However, I happen to
actually LIKE the idea of not having to force others (or me)
to put their fingers into several applications at the same
time just to understand ONE function. It would be nice to
have an international source code standard that goes past
ASCII, after all these years.
If you had a "compiler" that stripped away everything not immediately inside
a <code>...</code> block, and handed the code to gcc, then you could invoke
your compiler from the makefile and all would be well, no?

Mel.
Ivan Shmakov
2013-02-04 13:45:10 UTC
Permalink
[Cross-posting to news:comp.infosystems.www.misc.]

[On a second though, cross-posting to news:comp.lang.misc, too.]

[...]
I was too elliptical. I was actually thinking about HTML as the
markup lanugage. I just forgot to say so.
Then you get into which HTML subset you allow that does not have
deprecated or browser specific HTML tags
Why not to take just what's needed from, say, [1]?

There's a catch, however: to make the better use of XML
processing tools and libraries, there should be a way to write
the code itself in XML, too. Of which the only example I know
is XSLT, and I'm not certain if it's a particularly good one.

[1] http://www.w3.org/TR/xhtml-modularization
--
FSF associate member #7257
Paul
2013-02-04 16:21:04 UTC
Permalink
In article <***@violet.siamics.net>, ***@gmail.com
says...
Post by Ivan Shmakov
[Cross-posting to news:comp.infosystems.www.misc.]
[On a second though, cross-posting to news:comp.lang.misc, too.]
[...]
I was too elliptical. I was actually thinking about HTML as the
markup lanugage. I just forgot to say so.
Then you get into which HTML subset you allow that does not have
deprecated or browser specific HTML tags
Why not to take just what's needed from, say, [1]?
There's a catch, however: to make the better use of XML
processing tools and libraries, there should be a way to write
the code itself in XML, too. Of which the only example I know
is XSLT, and I'm not certain if it's a particularly good one.
[1] http://www.w3.org/TR/xhtml-modularization
The trouble is every tool will have its own different implementation
which wont necessarily be compatible. Even XHTML across browsers is
bad enough, let alone effectively vendor specific extensions.

And great another three layers of DLL and bloatware potentially, which
of course will be different on each platform and platform version :-)
--
Paul Carpenter | ***@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
dp
2013-02-04 17:52:54 UTC
Permalink
Post by Paul
...
And great another three layers of DLL and bloatware potentially, which
of course will be different on each platform and platform version :-)
:D
As if the bloatware is insufficient at its present what, 99+%? of
all ware indeed...

But including a few html links and images in the source
comments could be practical. If they point to resources
in the same archive, at least. Even if the source would confuse
browsers etc. copying the link is not a big deal anyway.
If someone finds *that* a big deal then programming should
not be that persons job of choice. Which I suppose is the reason
why we stick with plain ASCII to this day; nothing has beaten
the Latin alphabet for millenia, in fact it has beaten lots
of hieroglyph based languages. So it can't be all bad, I
suppose, we should stick to it for the time being.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
John Devereux
2013-02-04 19:10:14 UTC
Permalink
Post by dp
Post by Paul
...
And great another three layers of DLL and bloatware potentially, which
of course will be different on each platform and platform version :-)
:D
As if the bloatware is insufficient at its present what, 99+%? of
all ware indeed...
But including a few html links and images in the source
comments could be practical. If they point to resources
in the same archive, at least. Even if the source would confuse
browsers etc. copying the link is not a big deal anyway.
If someone finds *that* a big deal then programming should
not be that persons job of choice. Which I suppose is the reason
why we stick with plain ASCII to this day; nothing has beaten
the Latin alphabet for millenia, in fact it has beaten lots
of hieroglyph based languages. So it can't be all bad, I
suppose, we should stick to it for the time being.
I think to really do what Vladimir wanted it would need a full "compound
document" format, like ODF perhaps. So he can do what he wants in the
document, include pictures, spreadsheets, videos, a facebook game,
whatever. Actual code would be formatted in a "code" style, say. A
preprocessor (possibly a macro) would extract these into a source code
file and call make etc.

Sounds awful :)
--
John Devereux
Roberto Waltman
2013-02-04 20:08:53 UTC
Permalink
Post by John Devereux
I think to really do what Vladimir wanted it would need a full "compound
document" format, like ODF perhaps. So he can do what he wants in the
document, include pictures, spreadsheets, videos, a facebook game,
whatever. Actual code would be formatted in a "code" style, say. A
preprocessor (possibly a macro) would extract these into a source code
file and call make etc.
Sounds awful :)
Yes it does.

What about the other way around?
Compilable code files as the main format, with commands embedded in
comments to include graphics, control the page layout, update/retrieve
file from SCM, etc.

A dedicated "browser" (for lack of better term) cowould bring all the
components needed to display a compound document, while a language
compiler will just process the files as-is.

Sounds awful :)

Yes it does...

R.

PS: As others pointed out, I believe literate programming tools
already can do that. (Anything that Tex/Latex can do could be
available.) The result will be anything but easy to use.
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]
John Devereux
2013-02-04 20:52:44 UTC
Permalink
Post by Roberto Waltman
Post by John Devereux
I think to really do what Vladimir wanted it would need a full "compound
document" format, like ODF perhaps. So he can do what he wants in the
document, include pictures, spreadsheets, videos, a facebook game,
whatever. Actual code would be formatted in a "code" style, say. A
preprocessor (possibly a macro) would extract these into a source code
file and call make etc.
Sounds awful :)
Yes it does.
What about the other way around?
Compilable code files as the main format, with commands embedded in
comments to include graphics, control the page layout, update/retrieve
file from SCM, etc.
A dedicated "browser" (for lack of better term) cowould bring all the
components needed to display a compound document, while a language
compiler will just process the files as-is.
Sounds awful :)
Yes it does...
But that is what doxygen et al already do AIUI.
Post by Roberto Waltman
R.
PS: As others pointed out, I believe literate programming tools
already can do that. (Anything that Tex/Latex can do could be
available.) The result will be anything but easy to use.
I think that was me. I have a programming textbook or two written using
this technique, which is explained a bit in the first chapter. ("C
interfaces and implementions" by Hanson). Good book I thought.

[...]
--
John Devereux
David Brown
2013-02-05 08:59:41 UTC
Permalink
Post by John Devereux
Post by dp
Post by Paul
...
And great another three layers of DLL and bloatware potentially, which
of course will be different on each platform and platform version :-)
:D
As if the bloatware is insufficient at its present what, 99+%? of
all ware indeed...
But including a few html links and images in the source
comments could be practical. If they point to resources
in the same archive, at least. Even if the source would confuse
browsers etc. copying the link is not a big deal anyway.
If someone finds *that* a big deal then programming should
not be that persons job of choice. Which I suppose is the reason
why we stick with plain ASCII to this day; nothing has beaten
the Latin alphabet for millenia, in fact it has beaten lots
of hieroglyph based languages. So it can't be all bad, I
suppose, we should stick to it for the time being.
Doxygen has this covered.

And I expect that most compilers are quite happy for you to use a
slightly wider character set (Latin-1, UTF-8, etc.) in comments, even if
you can't use them in actual program identifiers.
Post by John Devereux
I think to really do what Vladimir wanted it would need a full "compound
document" format, like ODF perhaps. So he can do what he wants in the
document, include pictures, spreadsheets, videos, a facebook game,
whatever. Actual code would be formatted in a "code" style, say. A
preprocessor (possibly a macro) would extract these into a source code
file and call make etc.
Sounds awful :)
Indeed it does sound terrible.

But perhaps Vladimir could tell us what he wants - there seems to be a
lot of guessing going on in this thread. There has been some
interesting discussion and ideas here, but I don't think we are helping
the OP much. (This is no bad thing, of course - after all, these are
discussion groups rather than helplines.)
Walter Banks
2013-02-05 19:37:17 UTC
Permalink
Post by David Brown
And I expect that most compilers are quite happy for you to use a
slightly wider character set (Latin-1, UTF-8, etc.) in comments, even if
you can't use them in actual program identifiers.
Most if not all compilers that support 8 bit chars (as opposed to
truncating to 7 bits) will support extended wider character sets.

I think that was an issue in the design of the character extensions and
comment delimiters in most languages.
Post by David Brown
But perhaps Vladimir could tell us what he wants - there seems to be a
lot of guessing going on in this thread. There has been some
interesting discussion and ideas here, but I don't think we are helping
the OP much.
Missing from most of the discussion has been the intended audience.
Are we documenting an application design and doing a running
implementations with the design as a handy reference. Are we
documenting the implementation considerations or are we
providing user documentation.

I'm sure that most is part of all of the above, but the considerations
and requirements are different for each.

Order is also significant. I personally use spread sheets to
gather material for a project. In truest sense of an electronic
blackboard with spec pages, images and design calculations
spread out on several pages.

User requirements and documentation come next in a
document that eventually has implementation choices
and implementation overview documented. I personally
like to keep the actual code sparse of additional material
so I have a better overview of the code when reading
through it.

This too is a strawman guessing at Vladimir's intentions.

w..

Paul
2013-02-01 20:31:30 UTC
Permalink
In article <***@violet.siamics.net>, ***@gmail.com
says...
Post by Ivan Shmakov
[...]
For me, the issue is that I'd like to have a document that I directly
edit and work with (not unlike using DreamWeaver, for example, in
editing HTML) that supports the inclusion of good diagrams and
perhaps, if I'm crazy enough, a short video tutorial if I'm in the
mood to produce it.
Anything these days without a youtube link is useless to todays
youngsters :-)

........
Post by Ivan Shmakov
It seems to me that in this day of so much work on standards, which
include not only HTML5 but also XML and many others, that we could
have compilers which aren't stuck parsing simple ASCII text. It was
fantastic (and the only way to go) when all I had was an ASR-35
clacking away and a video display (if you dared to even consider the
idea) could set you back US$40,000 or more. (I wonder how many
remember the old Plato terminals?) But today? With workstations
absolutely everywhere? And disk space almost as cheap as dirt
(though not nearly as likely to serve its purpose quite as long?)
Not just one video display; nay, not even two; but often three per
workstation??
... The problem is that these new facilities, once they appear,
are most surely going to be misused.
They are always misused rarely properly used.
Post by Ivan Shmakov
cross-posting to news:comp.infosystems.www.misc, too]. Every
other Web page is designed as if it's some kind of picture, not
a text (which it is, first and foremost.) Digging a bit into
body {
width: 1024px; /* 'cause everybody's screen is at least that wide */
font-size: 14px; /* it's enough for everyone, no? */
}
#leftbar { width: 384px; /* that's about 40 characters; good */ }
#forum { width: 768px; /* that's the rest of the screen */ }
My view if marketing types want the thing to look the same as printed
paper they should print it on paper, not on the infinite combinations
of screen sizes and resolutions.

My personal bugbear is NEVER specify anything other than images on web
pages in pixels, that is what point (pt) for height and em, el en used
as widths are for oh hang on they come from printing terms... I wonder
why 300+ year old technology definitions still work and the new ones
dont.
--
Paul Carpenter | ***@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
Loading...