27 Nov
2018
27 Nov
'18
2:05 a.m.
At 09:49 PM 26/11/2018 -0700, Grant wrote:
It was a core of the underlying philosophy, that html would NOT allow
any kind of fixed formatting. The reasoning was that it could be displayed
on any kind of system, so had to be free-format and quite abstract.
Which is great, until you actually want to represent a real printed page,
or book. Like Postscript can. Thus html was doomed to be inadequate for
capture of printed works. That was a disaster. There wasn't any real reason
it could not be both. Just an academic's insistense on enforcing his ideology.
Then of course, over time html has morphed to include SOME forms of absolute
layout, because there was a real demand for that. But the result is a hodge-podge.
And that's why in html that character is written " "
You just rephrased my 1.2 lines as 5 lines.
We already established that they thought it a good idea to insert fancy
'no-break'
coding if the user typed two spaces. They thought they were adding a useful feature.
I meant there's no point trying to determine why they were so deluded, and failed to
recognise that maybe some users (Ed) would want to just type two spaces.
YES! I'm not arguing ASCII was _bad_. It was a great advance. There was
no way they could have included the experience of 50 more years if comp-sci.
And now 'we' (the world) are stuck with it for legacy compatibility reasons.
Any extensions have to be retro-compatible.
[snip]
That's what you are talking about.
Which exceptions would those be? (That weren't built on top of ASCII!)
[big snip]
I assume you're thinking that ASCII serves just fine for program source code?
This is a bandwagon/normalcy bias effect. "Everyone does it that way and always has,
so it must be good."
Sigh. Well, I can't go into that without revealing more than I wish to atm.
You're making my point for me. Of course there are many ways to interpret
existing codes to achieve this effect. Some use control codes, others
overload functionality on printable characters. eg html with < and >.
My point is the base coding scheme doesn't allocate a SPECIFIC mechanism
for doing this. The result is a briar-patch of competing ad-hoc methods.
Hence the 'babel' I'm referring to, in every matter where ASCII didn't
define needed functionality.
And so every different devel project that needed it, added some kludge on top.
This is what I'm saying: ASCII has no facility for this, but we need a basic
coding scheme that does (and is still ASCII-compatible.)
And yet written texts do have adornments (which can be of different forms
in different languages.) So, you're saying a text encoding scheme should not have
any way to represent such things? Why not?
The ASCII printable character set does not have adornments, BECAUSE it is purely a
representation of the alphabet and other symbols. That's one of its failings, since
all 'extras' have to be implemented by ad-hoc improvisations.
I'm pretty sure you've missed the whole point. The ASCII definition 'avoided
responsibility'
thus making itself inadequate. Html, postscript, and other typographic conventions layer
that stuff on top, messily and often in proprietary ways.
Then you never tried to represent a series of printed pages in html.
Can be sort-of done but is a pain.
ASCII doesn't understand 'lines' either. It understands physical head
printers.
Hence 'carriage return' and 'line feed'. Resulting in the CR/CR-LF/LF wars
for
text files where a 'new line' was needed.
Even in format-flowed text there is a typographic need for 'new line'.
It means 'no matter where the current line ends, drop down one line and start
at the left.'
Like I'm typing here.
A paragraph otoh is like that, but with extra vertical space separating from above.
Because ASCII does not have these _absolutely_fundamental_ codes, is why html
has to have <br> and <p>. Not to get into the whole </p> argument.
Note that including facility for real newline and paragraph symbols in the basic
coding scheme, doesn't _force_ the text to be hard formatted. That's a display
mode
option.
Ha ha... consider how does the Tab function work in typewriters? What does
pressing a Tab key actually do?
ASCII has a Tab code, yes. It does NOT have other things required for actual use
of tabular columns. So, the Tab functionality is completely broken in ASCII.
That was actually a really bad error on their part. They didn't need foresight,
they just goofed. Typewriters had working Tabs function since 1897.
Specifically, ASCII does not provide any explicit means to set and clear an array of
tabular positions (whether absolute or proportional.)
Hence html has to implement tables, grid systems, etc. But it SHOULD be possible to
type columnar text (with tabs) exactly and as ergonomically as one would on a typwriter.
ASCII is not solely a 'character encoding scheme', since it also has the control
codes.
But those implement far less functionality than we need.
There you go again, assuming 'styling' has no place in the base coding scheme.
You keep assuming that a basic coding scheme should contain nothing but the
common printable characters. Despite ASCII already containing more than that.
Also tell me why there should not be a printable character specifically meaning
"Start of comment" (and variants, line or block comments, terminators, etc.)
You are just used to doing it a traditional way, and not wondering if there
might be better ways.
Oh well.
It wasn't then, but the lack of it is our problem now.
Something got lost there. "^W' ??
Surely you understand that point. English: left to right, secondary flow: downwards.
Many other cultural variants exist.
There are many old codings.
Hmmm... well this is what happens when I post a short snippet from a larger text.
Short because I have to carefully read anything I cut-n-past post to be sure I didn't
include stuff I don't want to expose yet. Anyway, here's a bit more, that may
make things clearer.
----------------
Starting Over
What began as my general interest in the evolution of information encoding schemes, gained
focus as more and more instances of early mistakes became apparent. Eventually it spawned
a deliberate project to evaluate 'starting over.' What would be the result of
trying?
Like this:
* Revisit the development history of computing science, identifying points at which, in
hindsight, major conceptual shortcomings became cemented into foundations upon which
today's practices rest.
* Evaluate how those conceptual pitfalls could have been avoided, given understandings
arrived at later in computing science.
* Integrate all those improvements holistically, creating a virtual 'alternate
timeline' of computing evolution, as if Computing Science had evolved with prescience
of future conceptual advances and practical needs. Aiming to arrive at an information
processing and computing architecture, that is what we'd already have now if we knew
what we were doing from the start.
The resulting computing environment's major components are the ****** coding scheme,
the ***** operating system and hardware platform, the ***** scripting language, and the
***** file system.
----------------
Hey, we totally agree on something! I *HATE* PDF, and the Adobe DRM-flyblown horse it rode
in on.
When I scan tech documents, for lack of anything more acceptable I structure the
page images in html and wrap as a RAR-book.
Unfortunately few know of this method.
Soon. Few weeks. Got to get some stuff out of the way first. I have way too many
projects.
Guy
On 11/26/18 7:21 AM, Guy Dunphy wrote:
Oh yes, tell
me about the html 'there is no such thing
as hard formatting and you can't have any even when
you want it' concept. Thank you Tim Berners Lee.
I've not delved too deeply into the lack of hard formatting in HTML.
I've also always considered HTML to be what you want displayed, with
minimal information about how you want it displayed. IMHO CSS helps
significantly with the latter part.
Yes, it should be capable of that. But not enforce 'only that way'.
By 'html' I mean the kludge of html-css-js. The three-cat herd. (Ignoring all the
_other_ web cats.)
Now it's way too late to fix it properly with patches.
Except that
'non-breaking space' is mostly about inhibiting line wrap at
that word gap.
I wouldn't have thought "mostly" or "inhibiting line wrap". I
view the
non-breaking space as a way to glue two parts of text together and treat
them as one unit, particularly for display and partially for selection.
Granted, much of the breaking is done when the text can not continue (in
it's natural direction), frequently needing to start anew on the next line. But anyway,
there's little point trying to psychoanalyze the writers of
that software. Probably involved pointy-headed bosses.
I like to understand why things have been done the way they were.
Hopefully I can learn from the reasons. Of course not. It was for American English only.
This is one of the
major points of failure in the history of information processing.
Looking backwards, (I think) I can understand why you say that. But
based on my (possibly limited) understanding of the time, I think that
ASCII was one of the primordial building blocks that was necessary. Containing
extended Unicode character sets via UTF-8, doesn't make it a
non-hard-formatted medium. In ASCII a space is a space, and multi-spaces
DON'T collapse. White space collapse is a feature of html, and whether
an email is html or not is determined by the sending utility.
Having read the rest of your email and now replying, I feel that we may
be talking about two different things. One being ASCII's standard
definition of how to represent different letters / glyphs in a
consistent binary pattern. The other being how information is stored in an
(un)structured sequence
of ASCII characters.
What I'm talking about is not that. It's about how to create a coding scheme
that serves ALL the needs we are now aware of. (Just one of which is for old
ASCII files to still make sense.) This involves both re-definition of some
of the ASCII control codes, AND defining sequential structure standards.
For eg UTF-8 is a sequential structure. So are all the html and css codings,
all programming languages, etc. There's a continuum of encoding...structure...syntax.
The ASCII standard didn't really consider that continuum.
[snip] ACK - ACK.
> ----------
[snip]
Human
development of computing science (including information coding
schemes) has been effectively a 'first time effort', since we kept on
developing new stuff built on top of earlier work. We almost never went
back to the roots and rebuilt everything, applying insights gained from
the many mistakes made.
With few notable (partial) exceptions, I largely agree. This is a scan
from the 'Recommended USA Standard Code for Information
Interchange (USASCII) X3.4 - 1967' The Hex A-F on rows 10-15, added
here. Hexadecimal notation was not commonly in use in the 1960s. Fig. ___
The original ASCII definition table.
ASCII's limitations were so severe that even the text (ie ASCII) program
code source files used by programmers to develop literally everything
else in computing science, had major shortcomings and inconveniences.
I don't think I'm willing to accept that at face value. A few specific
examples of ASCII's flaws:
?? Missing concept of control vs data channel separation. And so we
needed the "< >" syntax of html, etc.
I don't buy that, at all.
ASCII has control codes to that I think could be (but isn't) used for
some of this. Start of Text (STX) & End of Text (ETX), or Shift Out
(SO) & Shift In (SI), or Device Control 1 - 4 (DC1 - DC4), or File /
Group / Record / Unit Separators (FS / GS / RS / US) all come to mind. Either you're going to need two parallel byte
streams, one for data and
another for control (I'm ignoring timing between them), -or- you're
going to need a way to indicate the need to switch between byte
(sub)streams in the overall byte (super)streams. Much of what I've seen
is the latter.
By definition, in a single baseband data stream it's ALWAYS the case that
time-interleaving is the only way to achieve command/data separation.
It just happens that different languages have decided
to use different
(sequences of) characters / bytes to do this. HTML (possibly all XML)
use "<" and ">". ASP uses "<%" and
"%>". PHP uses "<?(php)" and ">?".
Apache HTTPD SSI uses "<!--#" and "-->". I can't readily
think of
others, but I know there are a plethora. These are all signals to
indicate the switch between data and control stream.
Exactly. Because ASCII does not provide a specific coding. It didn't
occur to those drtafting the standard. Same as with all the other...
?? Inability to embed meta-data about the text in
standard programatically
accessible form.
I'll agree that there's no distinction of data, meta, or otherwise, in a
string of ASCII bytes. But I don't expect there to be. Is there any distinction in the Roman alphabet (or any
other alphabet in
this thread) to differentiate the sequence of bytes that makes up the
quote verses the metadata that is the name of the person that said the
quote? Or what about the date that it was originally said?
Doesn't matter. The English alphabet (or any other human language) naturally
do not have protocols to concisely represent data types. That's no reason to
not build such things into the character coding scheme used in computational
machinery. In a way we can read.
Like, for instance written decimal numbers, sci-notation, units, etc.
The written form is much more compact than the spoken forms.
This is about the time that I really started to feel
that you were
talking about a file format (for lack of a better description) than how
the bytes were actually encoded, ASCII or EBCDIC or otherwise.
The project consists of several parts. One is to define an extension of ASCII
(with a different name, that I'm not going to mention for fear of pre-emptive
copyright bullshit.) Other parts relate to other areas in comp-sci, in the same
manner of 'see what happens if one starts from scratch.'
It's a fun hobby project. That text I quoted is a small part of one chapter of the
docs.
Atm the whole thing is undergoing _another_ major refactoring, due to seeing a better way
to do some parts of it.
?? Absense of
anything related to text adornments, ie italics, underline
and bold. The most basic essentials of expressive text, completely
ignored.
Again, alphabets don't have italics or underline or bold or other. They
have to depend on people reading them, and inferring the metadata, and
using tonal inflection to convey that metadata. ?? Absense of
any provision for creative typography. No awareness of
fonts, type sizes, kerning, etc.
I don't believe that's anywhere close to ASCII's responsibility. ?? Lack of logical 'new line', 'new
paragraph' and 'new page' codes.
I personally have issues with the concept of what a line is, or when to
start a new one. (Aside: I'm a HUGE fan of format=flowed text.)
We do have conventions for indicating a new paragraph, specifically two
new lines.
Sigh. Like two spaces in succession being interpretted to do something special?
You know in type layout there are typically special things that happen for
paragraphs but not for newlines? You don't see any problem with overloading
a pair of codes of one type, to mean something else?
Is there an opportunity to streamline that? Probably.
Factors to consider:
- Ergonomics of typing. It _should_ be possible to directly type reasonably
typographically
formatted text, with minimal keystrokes. One can type html, but it's far from
optimal.
There are many other conventions. None arising from ASCII, because it lacks
_everything_ necessary.
- Efficiency of the file/stream encoding. Allowing for infinitely extensible character
sets,
embedded specifications of glyph appearances (fonts), layout, and dynamic elements.
- Efficiaency and complexity of code to deal with constructing, processing and displaying
texts.
I also have unresolved issues of what a page is. (Think reactive web
pages that gracefully adjust themselves as you dynamically resize the
window.)
Sure. Now you think of trying to construct a digital representation of a
printed work with historical significance. So it NUST NOT dynamically reformat.
Otoh it might be a total simulation of a physical object/book, page turn physics and all.
[snip]
?? Inadequate
support of basic formatting elements such as tabular
columns, text blocks, etc.
ASCII has a very well defined tab character. Both for horizontal and
vertical. (Though I can't remember ever seeing vertical tab being used.) I think there is some use for File / Group / Record /
Unit Separators
(FS / GS / RS / US) for some of these uses, particularly for columns and
text blocks.
Not the same thing.
?? Even the
extremely fundamental and essential concept of 'tab
columns' is impropperly implemented in ASCII, hence almost completely
dysfunctional.
Why do you say it's improperly implemented? It sounds as if you are commenting about what programs
do when
confronting a tab, not the actual binary pattern that represents the tab
character.
Why would I be talking of the binary code of the tab character?
What would you like to see done differently?
Sigh. You'll have to wait.
?? No concept
of general extensible-typed functional blocks within text,
with the necessary opening and closing delimiters.
Now I think you're asking too much of a character encoding scheme. I do think that you can ask that of file formats.
Now tell me why you think the fundamental coding standard, should not be the same as
used in file formats. You're used to those being different things (since ASCII is
missing so much),
but it doesn't have to be so.
?? Missing
symmetry of quote characters. (A consequence of the absense
of typed functional blocks.)
I think that ASCII accurately represents what the general American
populous was taught in elementary school. Specifically that there is
functionally a single quote and a double quote. Sure, there are opening
and closing quotes, both single and double, but that is effectively
styling and doesn't change the semantic meaning of the text. ?? No
provision for code commenting. Hence the gaggle of comment
delimiting styles in every coding language since. (Another consequence
of the absense of typed functional blocks.)
How is that the responsibility of the standard used to encode characters
in a binary pattern? That REALLY sounds like it's the responsibility of
the thing that uses
the underlying standard characters.
You think that, because all your life you've been typing /* comment */ or whatever.
In truth, the ASCII committee just forgot.
?? No
awareness of programatic operations such as Inclusion, Variable
substitution, Macros, Indirection, Introspection, Linking, Selection, etc.
I see zero way that is the binary encoding format's responsibility. I see every way that is the responsibility of the
higher layer that is
using the underlying binary encoding.
a) ASCII is 7 bits.
b) UTF-8
This is getting a bit pointless.
?? No facility for embedding of multi-byte
character and binary code
sequences.
I can see how ASCII doesn't (can't?) encode multi-byte characters. Some
can argue that ASCII can't even encode a full 8 bit byte character. But from the standpoint of storing / sending /
retrieving (multiples of
8-bit) bytes, how is this ASCII's problem?
IMHO this really jumps the shark (as if we hadn't already) from an
encoding scheme to a file format.
You're going to need to wait a few years, till you see the end product.
That bit of text I quoted is a very, very brief points list. Detailed discussion
of all this stuff is elsewhere, and I _can't_ post it now, since that would
seriously damage the project's practical potential. (Economic reasons.)
?? Missing an informational equivalent to the
pure 'zero' symbol of
number systems. A specific "There is no information here" symbol. (The
NUL symbol has other meanings.) This lack has very profound implications.
You're going to need to work to convince me of that. Mathematics has zero, 0, for a really long time. (Yes,
there was a time
before we had 0.) But there is no numerical difference between 0 and 00
and 0000. So, why do we need the latter two?
Column multiplier significance. That's a different thing from the nature of
'0'
as a symbol. At present there is no symbol meaning 'this is not information.'
Nevermind, it's difficult to grasp without a discussion of the implications for
very large mass storage device structure. And I'm not going there now.
?? No facility
to embed multiple data object types within text streams.
How is this ASCII's problem? How do you represent other data object types if you
aren't using ASCII?
Sure, there's raw binary, but that just means that you're using your own
encoding scheme which is even less of a common / well known standard
than ASCII.
UTF-8 is multi-byte binary, of a specific type. Just ONE type. No extensibility.
We have all sorts of ways to encode other data objects
in ASCII and then
include it in streams of bytes.
??? Are you deliberately being obtuse? The point is to attempt to formulate
a new standard that allows all this, in one well defined, extensible way that
permits all future potential cases. We do know how to do this now.
Again, encoding verses file format.
No. People who do scan captures of documents will understand that. They face the
choice: keep the document as page images (can't text search), or OCR'd text
(losing the page's visual soul.) But it should be possible to do BOTH, in
one file structure - if there was a defined way to link elements in the symbolic
text to words and characters in the images.
You'll say 'this is file format territory.' True at the moment, but only
because
the basic coding scheme lacks any such capability.
?? No facility to correlate coded text elements
to associated visual
typographical elements within digital images, AV files, and other
representational constructs. This has crippled efforts to digitize the
cultural heritage of humankind.
Now I think you're lamenting the lack of computer friendly bytes
representing the text that is in the picture of a sign. Functionally
what the ALT attribute of HTML's <IMG> tag is. IMHO this is so far beyond a standard meant to make
sure that people
represent A the same way on multiple computers.
You realise ASCII doesn't do that?
??
Non-configurable geometry of text flow, when representing the text
in 2D planes. (Or 3D space for that matter.)
What is a page ^W 2D plane? ;-) I don't think oral text has the geometry of text
flow or a page either.
Again, IMHO, not ASCII's fault, or even it's wheelhouse.
Huh? This is pretty random.
It's a common response syndrome when someone discusses deviating from the common
paradigm.
If I'm being silly enough to try discussing this in fragmentary form, I expect a lot
of it.
?? Many of the
32 'control codes' (characters 0x00 to 0x1F) were allocated
to hardware-specific uses that have since become obsolete and fallen
into disuse. Leaving those codes as a wasted resource.
Fair point.
I sometimes lament that they control codes aren't used more.
?? ASCII defined only a 7-bit (128 codes) space,
rather than the full
8-bit (256 codes) space available with byte sized architectures. This
left the 'upper' 128 code page open to multiple chaotic, conflicting
usage interpretations. For example the IBM PC code page symbol sets
(multiple languages and graphics symbols, in pre-Unicode days) and the
UTF-8 character bit-size extensions.
I wonder what character sets looked like for other computers with
different word lengths. How many more, or fewer, characters were encoded? Did it really make a difference?
Not after ASCII became a standard - unless you were using a language that needed more
or different characters. ie most of the world's population.
Would it make any real difference if words were 32-bits
long?
Hah. In fact, the ability to represent unlimited-length numeric objects,
is one of the essentials of an adequate coding scheme. ASCII doesn't.
The whole 'x-bits long words' is one of the hangups of computing architectures
too.
But that's another story.
What if we moved to dictionary words represented by
encoding schemes
instead of individual characters?
You're describing Chinese language programming. Though you didn't realise.
And yes... :) A capable encoding scheme, and computing architecture built
on it, would allow such a thing.
Or maybe we should move to encoding concepts instead of
words. That way
we might have some loose translation of the words for mother / father /
son / daughter between languages. Maybe. I'm sure there would still be
issues. Gender and tense not withstanding.
Point? Not practical.
The coding scheme has to be compatible with the existing cultural schemes
and existing literature. (All of them.)
[snip]
?? Inability
to create files which encapsulate the entirety of the visual
appearance of the physical object or text which the file represents,
without dependence on any external information. Even plain ASCII text
files depend on the external definition of the character glyphs that the
character codes represent. This can be a problem if files are intended
to serve as long term historical records, potentially for geological
timescales. This problem became much worse with the advent of the vast
Unicode glyph set, and typset formats such as PDF.
Now even more than ever, it sounds like you're talking about a file
format and not ASCII as a scheme meant to consistently encode characters. The PDF
'archival' format (in which all referenced fonts must be defined
in the file) is a step in the right direction ??? except that format
standard is still proprietary and not available for free.
Don't get me started on PDF. IMHO PDF is where information goes to die. Once data is in a PDF, the only reliable way to get the
data back out to
be consumed by something else is through something like human eyes.
(Sure it may be possible to deconstruct the PDF, but it's fraught with
so many problems.)
There *was* at one point a freeware utility for deconstructing PDF files and analysing
their structure.
I forget the name just now. It apparently was Borged by the forces of evil, and no longer
can be found.
Anyone have a copy?
Photoshop is able to extract original images from PDFs, but it's a nightmare process.
> ----------
>>
>> Sorry to be a tease.
>
>Teas is not how I'd describe it. I feel like it was more of a bait
>(talking about shortcomings with ASCII's) and switch (talking about
>shortcomings with file formats).
No, they are not intrinsically different things. It just seems that way from the viewpoint
of convention
because ASCII lacks so many structural features that file (and stream) formats have to
implement on their own.
(And so everyone does them differently.)
That being said, I do think you made some extremely
salient points about
file formats.
Ha, wait till (eventually - if ever) you see the real thing.
I'm having lots of fun with it. Result is like 'alien tech.'
Soon I'd
like to have a discussion about the functional evolution of
the various ASCII control codes, and how they are used (or disused) now.
But am a bit too busy atm to give it adequate attention.
I think that would be an interesting discussion. 
27 Nov
27 Nov
11:47 a.m.
On 11/27/2018 03:05 AM, Guy Dunphy wrote:
It was a core of the underlying philosophy, that html
would NOT allow any
kind of fixed formatting. The reasoning was that it could be displayed
on any kind of system, so had to be free-format and quite abstract.
That's one of the reasons that I like HTML as much as I do.
Which is great, until you actually want to represent a
real printed page,
or book. Like Postscript can. Thus html was doomed to be inadequate for
capture of printed works.
I feel like trying to accurately represent fixed page layout in HTML is
a questionable idea. I would think that it would be better to use a
different type of file.
That was a disaster. There wasn't any real reason
it could not be
both. Just an academic's insistense on enforcing his ideology. Then of
course, over time html has morphed to include SOME forms of absolute
layout, because there was a real demand for that. But the result is
a hodge-podge.
I don't think that HTML can reproduce fixed page layout like PostScript
and PDF can. It can make a close approximation. But I don't think HTML
can get there. Nor do I think it should.
Yes, it should be capable of that. But not enforce
'only that way'.
I question if people are choosing to use HTML to store documentation
because it's so popular and then getting upset when they want to do
things that HTML is not meant to do. Or in some cases is actually meant
to /not/ to.
Use the tool for the job. Don't alter the wrong tool for your
particular job.
IMHO true page layout doesn't belong in HTML. Loosely laying out the
same content in approximately the same layout is okay.
By 'html' I mean the kludge of html-css-js.
The three-cat herd. (Ignoring
all the _other_ web cats.) Now it's way too late to fix it properly
with patches.
I don't agree with that. HTML (and XML) has markup that can be used,
and changed, to define how the HTML is meant to be interpreted.
The fact that people don't do so correctly is mostly independent of the
fact that it has the ability. I say mostly because there is some small
amount of wiggle room for discussion of does the functionality actually
work or not.
I meant there's no point trying to determine why
they were so deluded,
and failed to recognise that maybe some users (Ed) would want to just
type two spaces.
I /do/ believe that there /is/ a point in trying to understand why
someone did what they did.
now 'we' (the world) are stuck with it for
legacy compatibility reasons.
Our need to be able to read it does not translate to our need to
continue to use it.
Any extensions have to be retro-compatible.
I disagree.
I see zero reason why we couldn't come up with something new and
completely different.
Granted, there should be ways to translate from one to the other. Much
like how ASCII and EBCDIC are still in use today.
What I'm talking about is not that. It's about
how to create a coding
scheme that serves ALL the needs we are now aware of. (Just one of
which is for old ASCII files to still make sense.) This involves both
re-definition of some of the ASCII control codes, AND defining sequential
structure standards. For eg UTF-8 is a sequential structure. So are
all the html and css codings, all programming languages, etc. There's a
continuum of encoding...structure...syntax. The ASCII standard didn't
really consider that continuum.
I don't think that ASCII was even trying to answer / solve the problems
that you're talking about.
ASCII was a solution for a different problem for a different time.
There is no reason we can't move on to something else.
Which exceptions would those be? (That weren't
built on top of ASCII!)
It is subject to the meaning of "back tot he roots" and not worth taking
more time.
I assume you're thinking that ASCII serves just
fine for program source
code?
I'm not personally aware of any cases where ASCII limits programming
languages. But my ignorance does not preclude that situation from existing.
I do believe that there are a number of niche programming languages (if
you will) that store things as binary data (I'm thinking PLCs and the
likes) but occasionally have said data represented (as a hexadecimal
dump) in ASCII. But the fact that ASCII can or can't easily display the
data is immaterial to the system being programmed.
I have long wondered if there are computer languages that aren't rooted
in English / ASCII. I feel like it's rather pompous to assume that all
programming languages are rooted in English / ASCII. I would hope that
there are programming languages that are more specific to the region of
the world they were developed in. As such, I would expect that they
would be stored in something other than ASCII.
Could the sequence of bytes be displayed as ASCII? Sure. Would it make
much sense? Not likely.
This is a bandwagon/normalcy bias effect.
"Everyone does it that way
and always has, so it must be good."
Nope, not for me.
It may be the case for some people. But I actively try to avoid such
biases. Or if I do use them, I acknowledge that they are biases so that
others can overcome them.
Sigh. Well, I can't go into that without revealing
more than I wish
to atm.
Fair.
I will say that I don't think there's any reason why English based
programming languages can't be encoded in Morse code, either American or
International. Sure, it would be a variable bit length word, but it
would work. Nothing mandates that ASCII is used. ASCII is used by
convention. But nothing states that that convention can't be changed.
Hence why some embedded applications use something else that's more
convenient for them.
You're making my point for me. Of course there are
many ways to interpret
existing codes to achieve this effect. Some use control codes, others
overload functionality on printable characters. eg html with < and >.
I disagree.
My point is the base coding scheme doesn't
allocate a SPECIFIC mechanism
for doing this.
I think there are ASCII codes that could, or should, have been used for
that.
The result is a briar-patch of competing ad-hoc
methods. Hence the
'babel' I'm referring to, in every matter where ASCII didn't define
needed functionality.
I don't believe that the fact that people didn't use it for one reason
or another is not ASCII's fault.
Exactly. Because ASCII does not provide a specific
coding. It didn't
occur to those drtafting the standard. Same as with all the other...
I believe that ASCII did provide control codes that could have been used.
I also question how much of the fact that the control codes weren't used
was / is related to the fact that most people don't have keys on their
keyboard for them. Thus many people chose to use different keys ~>
bytes to perform the needed function.
And so every different devel project that needed it,
added some kludge
on top. This is what I'm saying: ASCII has no facility for this, but
we need a basic coding scheme that does (and is still ASCII-compatible.)
How would you encode the same string of characters, "Lincoln", used in
both the name of the person speaking, Abraham Lincoln, and the phrase
they said, "I drive a Lincoln Town Car". Would you have completely
different ways of encoding "Lincoln" in each of the contexts? Or would
you have a way to indicate which context is applied to the sequence of
seven characters / words of memory?
If it's the latter, you must have some way to switch between the two
contexts. This could be one of the ASCII control codes, or it could be
an overload of one (or sequence of) characters.
I believe that ASCII is a standard (one of many) that defines how to
represent characters / control codes in a binary pattern. I also
believe that any semantics or meanings beyond the context of a single
character / control code is outside of the scope of ASCII or comparable
standards.
I believe such semantic meaning sits on top of the underlying character
set. Hence file format.
Doesn't matter. The English alphabet (or any other
human language)
naturally do not have protocols to concisely represent data types.
So if I apply (what I understand to be) your logic, I can argue that the
English language is (similarly) flawed.
That's no reason to not build such things into the
character coding
scheme used in computational machinery.
I agree there is need for such data. I do not agree that it belongs in
the character encoding. I believe that it belongs in file formats that
sit on top of character encoding.
Does a file format need additional characters that are outside of the
typical language so that the file format can contain typical characters
without overloading? Sure. That's where the control codes come in.
The project consists of several parts. One is to
define an extension of
ASCII (with a different name, that I'm not going to mention for fear
of pre-emptive copyright bullshit.) Other parts relate to other areas
in comp-sci, in the same manner of 'see what happens if one starts
from scratch.'
Why do you need to define them as an extension of ASCII? Rather why not
define it completely anew and sluff off the old. I don't see any reason
why something brand new can't be completely it's own. The only
requirement I see is a way to convert between the old and the new.
So, you're saying a text encoding scheme should
not have any way to
represent such things? Why not?
I don't believe that the letter "A", be it bold and / or italic and / or
underline is still the letter "A". The formatting and display of it
does not change the semantic meaning of the letter "A". As such, I
don't think that the different forms of the letter "A" should be encoded
as different letters.
I do think that file formats should have a way to encode the different
formats of the same semantic letter, "A". If a control code is needed
to indicate a formatting change, so be it. ASCII has some codes that
can be used for this. Or other character sets can have more codes to do
the same thing.
The ASCII printable character set does not have
adornments, BECAUSE it
is purely a representation of the alphabet and other symbols. That's
one of its failings, since all 'extras' have to be implemented by ad-hoc
improvisations.
I think the fact that all four forms of "A" are same ASCII byte is a
good thing.
It's both good and bad that programmers are free to implement their
ideas how they see fit. Requiring all programmers to use the same thing
to represent Italic underlined text would be limiting.
I'm pretty sure you've missed the whole point.
The ASCII definition
'avoided responsibility' thus making itself inadequate. Html, postscript,
and other typographic conventions layer that stuff on top, messily and
often in proprietary ways.
We can agree to disagree.
Then you never tried to represent a series of printed
pages in html.
Can be sort-of done but is a pain.
I would not choose to accurately represent printed pages in HTML.
That's not what HTML is meant for.
I would choose a page layout language to represent printed pages.
ASCII doesn't understand 'lines' either.
It understands physical head
printers. Hence 'carriage return' and 'line feed'. Resulting in the
CR/CR-LF/LF wars for text files where a 'new line' was needed.
I don't consider that to be a war. I consider it to be three different
file formats (each with it's own way of encoding a new line). And LOTS
of ignorance about the fact.
It is trivial to convert between the formats. Trivial enough that many
editors automatically detect the format that's being used and behave
appropriately for the detected format.
Even in format-flowed text there is a typographic need
for 'new line'.
It means 'no matter where the current line ends, drop down one line and
start at the left.'
Like I'm typing here.
I'll agree that there is a new line in the underlying text that makes up
the format=flowed line.
But I believe that format=flowed text is a collection of lines
(paragraphs) that are stored using format=flowed encoding. Each line
(paragraph) is independent of the others. As such, the "new line" that
you speak of is outside the scope of format=flowed text. Or rather, the
"new line" that you speak of means the end of one format=flowed line
(paragraph) and the start of another (assuming it also uses format=flowed).
A paragraph otoh is like that, but with extra vertical
space separating
from above. Because ASCII does not have these _absolutely_fundamental_
codes, is why html has to have <br> and <p>.
I suspect that even if ASCII did have a specific purpose code that
either people wouldn't use it and / or HTML would also ignore it with
it's white space compaction philosophy.
Not to get into the whole </p> argument.
I'm not going there. I don't think it's germane to this discussion.
Note that including facility for real newline and
paragraph symbols in the
basic coding scheme, doesn't _force_ the text to be hard formatted. That's
a display mode option.
Much like HTML's philosophy to compact white space?
Sigh. Like two spaces in succession being interpretted
to do something
special?
I'm not aware of any special meaning for two spaces in succession. I am
aware of shenanigans that different applications do to preserve the
multiple spaces. Ergo this conversation.
I'm also aware that the two spaces after punctuation is a relatively
modern thing, introduced by (I believe) typewriters as a mechanism to
avoid a mechanical problem. A convention that persisted into computers.
A convention that some modern devices actively thwart. I.e. the iPad
/ iPhone turning two spaces into a period space ready for new sentences.
You know in type layout there are typically special
things that happen
for paragraphs but not for newlines?
Nope. I've done very little with typography / layout.
You don't see any problem with overloading a pair
of codes of one type,
to mean something else?
It depends on what the file format is. If the file format expects
everything to be a discrete (8-bit) word / byte, then yes, there can be
complications ~> problems with requiring use of two. If the file format
does not make such expectations, and instead relies on chords of (8-bit)
words / bytes, then I don't see any overt problem. The biggest issue
will be ensuring that chords are interpreted properly.
Factors to consider:
- Ergonomics of typing. It _should_ be possible to directly type
reasonably typographically formatted text, with minimal keystrokes. One
can type html, but it's far from optimal. There are many other
conventions. None arising from ASCII, because it lacks _everything_
necessary.
I don't believe that the way that text is typed must be directly related
to how it's stored and / or presented.
I'm curious what you've had difficulty with over the years with related
to new lines, paragraphs, page breaks, formatting, etc.
- Efficiency of the file/stream encoding. Allowing for
infinitely
extensible character sets, embedded specifications of glyph appearances
(fonts), layout, and dynamic elements.
Yes. This is part of a file format and not part of the character
encoding. File have been storing binary data that is completely
independent of the encoding for years. ? Granted, transferring said
files between systems can run into complications.
- Efficiaency and complexity of code to deal with
constructing, processing
and displaying texts.
I've LONG been a fan of paying it forward to make things easier to use
in the long run. I'd much rather have more complex code to make my day
to day life easier and more convenient.
Sure. Now you think of trying to construct a digital
representation of
a printed work with historical significance. So it NUST NOT dynamically
reformat. Otoh it might be a total simulation of a physical object/book,
page turn physics and all.
I would never try to digitally reproduce such a work in HTML. I would
copy contents into HTML so that it is easily accessible via HTML. But I
would never expect that representation to accurately reproduce the
original work.
Ha ha... consider how does the Tab function work in
typewriters? What
does pressing a Tab key actually do?
Based on memory, the tab key advances to the next tab stop that the type
writer / operator has configured.
Note: The tab key itself has no knowledge of where said tab stop is
located.
ASCII has a Tab code, yes. It does NOT have other
things required for
actual use of tabular columns.
The typewriter's tab key "does NOT have other things required for
actual use of tabular columns" either. Other parts of the typewriter do.
Similarly, the text editor has "other things required for actual use of
tabular columns".
So, the Tab functionality is completely broken in
ASCII. That was
actually a really bad error on their part. They didn't need foresight,
they just goofed.
I disagree. See above for why.
Typewriters had working Tabs function since 1897.
I've been able to actual use of tabular columns for years, if not
decades, on computers without any problem.
Specifically, ASCII does not provide any explicit
means to set and
clear an array of tabular positions (whether absolute or proportional.)
I disagree.
Again, ASCII is a way to encode characters and is independent of how
those characters are used.
I could easily use Device Control 1 to tell a device that I'm sending it
information that it should use to ""program / configure a tab stop distance.
Quite similar to how the tab key on the typewriter does not tell the
typewriter how far to advance. Instead I have to use other keys /
buttons / knobs on the typewriter to define where the tab stop should
be. The tab simply advances to the next tab stop.
Hence html has to implement tables, grid systems, etc.
But it SHOULD be
possible to type columnar text (with tabs) exactly and as ergonomically
as one would on a typwriter.
First, HTML's white space compaction will disagree. (For better or worse).
Second, tabs are 8 characters by convention. A convention that can very
easily be redefined.
As such, it's somewhere between impractical and impossible to rely on
the following content to appear the same on a computer or typewriter
without specifying what the tab stop is. A tab stop of 32 will align
things. A tab stop of 8 will not.
bob<tab>ed
abcdefghijklmnopqrstuvwxyz<tab>0123456789
IMHO this is a flaw with the concept of tab and not the aforementioned
implementations.
Why would I be talking of the binary code of the tab
character?
Your comment was about what is done when the character is encountered
when the overarching discussion is about ASCII, which is a standard for
how to encode characters, not what is done when a character is encountered.
Sigh. You'll have to wait.
Fair enough.
ASCII is not solely a 'character encoding
scheme', since it also has the
control codes. But those implement far less functionality than we need.
Sorry, when I said "character encoding scheme", I was meaning character
s and control codes. Thus asking too much of the {character,control
code} encoding scheme.
Now tell me why you think the fundamental coding
standard, should not be
the same as used in file formats. You're used to those being different
things (since ASCII is missing so much), but it doesn't have to be so.
I think of ASCII as being a way to encode characters / control codes.
Conversely I think of file formats as being a way to define how the
encoded characters / control codes are used in concert with each other.
The file format builds on top of the character / control code encoding.
There you go again, assuming 'styling' has no
place in the base coding
scheme.
Correct. I believe that styling is part of a file format, not the
underlying character / control code encoding.
You keep assuming that a basic coding scheme should
contain nothing but
the common printable characters. Despite ASCII already containing more
than that.
No, I do not. I can understand why you may think that. Please allow me
to clarify.
I believe that a basic coding scheme contains printable characters and
control codes.
Sorry for omitting the "control codes", which are part of the defined
ASCII standard.
Also tell me why there should not be a printable
character specifically
meaning "Start of comment" (and variants, line or block comments,
terminators, etc.)
I don't perceive a need for a control code that means "start of
comment". Much less the aforementioned variants.
I do perceive a need for a file format that uses characters and / or
control codes to represent that.
You are just used to doing it a traditional way, and
not wondering if
there might be better ways.
Nope. That's a false statement.
I have long pontificated a file format that made it easy to structure
text (what I typically deal with) such that it's easy to reference
(include) part of it in other files. I've stared at DocBook and a few
other file formats that do include meta-data about the text such that
things can be referenced. All of the file formats that I looked at
re-used ASCII. But nothing stopped them from using their own binary
encoding. Much the way that I believe that Microsoft Word documents do.
Suffice it to say that I'm not just using the traditional methods. I'm
actively looking for and evaluating alternatives to see if they will
work better for me than what I'm currently doing.
You think that, because all your life you've been
typing /* comment */
or whatever.
No I have not. I've been using different comment characters / chords of
characters for years.
In truth, the ASCII committee just forgot.
I disagree.
Oh well.
I am willing to entertain discussions of the need of additional control
characters. But I expect such discussions to include why the file
format can't re-use a different control character and why it's necessary
to define another one. (Think Word document's binary format.)
You're going to need to wait a few years, till you
see the end product.
Okay.
That bit of text I quoted is a very, very brief points
list. Detailed
discussion of all this stuff is elsewhere, and I _can't_ post it
now, since that would seriously damage the project's practical
potential. (Economic reasons.)
Fair enough.
Column multiplier significance. That's a different
thing from the nature
of '0' as a symbol. At present there is no symbol meaning 'this is not
information.'
Why would there be a "this is not information" in a field that is
specifically meant to hold information?
I can see a use for "this information is unavailable". But null is
typically used for that (and other things).
Nevermind, it's difficult to grasp without a
discussion of the
implications for very large mass storage device structure. And I'm not
going there now.
Okay.
That sounds like it borderlines on file systems and / or database
structures. Which I consider as being a higher layer than file format,
used to differentiate different files / records.
It wasn't then, but the lack of it is our problem
now.
I disagree.
I don't think that this is a character / control code encoding problem.
I think this is a file format problem.
UTF-8 is multi-byte binary, of a specific type. Just
ONE type. No
extensibility.
I find the lack of extensibility questionable. Granted I don't know
much about UTF<anything>. But I do think that I routinely see new
characters / glyphs added. So either it's got some modicum of
extensibility, or people are simply defining previously undefined /
unused code points.
??? Are you deliberately being obtuse?
No.
I'm saying that we have multiple ways to encode binary data (pictures,
sound, programs, you name it) such that it can safely be represented in
printable ASCII characters:
? Base 16
? Base 32
? Base 64
? UUEncode
? Quoted-Printable
I'm sure there are more, but that's just what comes to mind at the moment.
MIME structures allow us to include multiple different types of content
in the same printable ASCII file.
I've worked with Lotus Notes files (I don't remember the extension) that
easily stored complex data structures. Things like a document with
embedded video, sound, programs, pictures, links to other files, other
files themselves, could all easily be put into a single file.
The point is to attempt to formulate a new standard
that allows all this,
in one well defined, extensible way that permits all future potential
cases. We do know how to do this now.
I feel like the Lotus Notes file was extremely extensible.
But that's a file format, not an character / control code encoding scheme.
No. People who do scan captures of documents will
understand that. They
face the choice: keep the document as page images (can't text search),
or OCR'd text (losing the page's visual soul.)
My understanding is that there are multiple file types (formats) that
can already do that.
I believe it's possible to include the document as page image -and-
include OCR'd text so that it is searchable.
I feel confident that an Epub can include an HTML page that includes the
image(s) and ATL value on IMG tags.
I bet there are a number of other options too.
But it should be possible to do BOTH,
Agreed. I think that it is possible to do both.
in one file structure
That sounds dangerously close to a file format. Or at LOT closer to a
file format than a character / control code encoding scheme.
if there was a defined way to link elements in the
symbolic text to
words and characters in the images.
I believe there likely is, or can be.
I wonder if an image map would work in an Epub or Microsoft's HTML
Archive files.
You'll say 'this is file format
territory.'
Yep.
True?
:-)
?at the moment,
What will change that will prevent that the same file formats that exist
today won't exist or won't be able to continue to do this in the future?
Or why will what works today stop working in the future?
but only because the basic coding scheme lacks any
such capability.
Even if the new encoding scheme that you're working (which you can't
talk about) on does include these capabilities, that does not preclude
the current file formats from continuing to work in the future.
You realise ASCII doesn't do that?
Sorry, I was talking within the context of ASCII.
I believe that any computer that uses ASCII (and doesn't do a
translation internally) does represent a capital A as binary 01000001.
If that is not the case, please enlighten me.
Something got lost there. "^W' ??
Sorry, ^W, is how unix geeks represent control w, which is a readline
key sequence to erase the last word.
So I was effectively asking "What is a 2D plane?".
Surely you understand that point. English: left to
right, secondary
flow: downwards. Many other cultural variants exist.
Yes, I understand that English is primarily left to right, and
secondarily top to bottom. However, that is within a defined 2D plane.
(Or page as I was calling it.)
My real point was to ask what defines a 2D plane (page)? Is it it's
size? Is it how much text can fit on it? What point size is the text
there on?
A 2D plane (page) is rather nebulous without context to define it.
Huh? This is pretty random.
I was making a comparison to a defined 2D plane (page) that can hold a
finite amount of information / text at a given point size.
I was then wondering if there was similar definition of a unit for oral
speak.
Not after ASCII became a standard - unless you were
using a language that
needed more or different characters. ie most of the world's population.
EBCDIC is still quite popular, even here in the US. Well, at least in
IBM shops. I hear that it's also popular in other mainframe shops
around the world that want to interoperate with IBM mainframes.
Unicode / UTF-* are also gaining traction.
Thus I think the other encoding methods are making a difference. ;-)
Hah. In fact, the ability to represent
unlimited-length numeric objects,
is one of the essentials of an adequate coding scheme. ASCII doesn't.
I disagree. ASCII does just as well as numbers taught to kindergartners
in the English speaking world. Where the numbers are a collection of
individual characters, 0 - 9.
Granted, that's not the same thing as a single word of memory holding a
64-bit number. But, humans don't have tens / hundreds / thousands of
different numbers representing different values that are their own
discrete character. Instead, humans use different sets of digits to
represent different values in different places.
The whole 'x-bits long words' is one of the
hangups of computing
architectures too.
Sure. I think doing something like humans do might be more scalable.
But then we could get by with probably 4 or 5 bit representations of
numbers. Binary Coded Decimal comes to mind. }:-)
But that's another story.
Agree.
You're describing Chinese language programming.
Though you didn't realise.
And yes... :) A capable encoding scheme, and computing architecture
built on it, would allow such a thing.
Something that is most decidedly outside of the scope of what ASCII was
meant to solve.
Point? Not practical.
It might not be practical for most day-to-day computing. But I do think
that there are merits to it for specific use cases.
The coding scheme has to be compatible with the
existing cultural schemes
and existing literature. (All of them.)
Why does the coding scheme have to be compatible? Why can't it be
completely different as long as there is a way to translate between them.
What began as my general interest in the evolution of
information
encoding schemes, gained focus as more and more instances of early
mistakes became apparent. Eventually it spawned a deliberate project to
evaluate 'starting over.'
There in lies some critical meta-data. You have a purpose behind what
you're doing, which happens to seem related to deriding ASCII.
Like this:
* Revisit the development history of computing science, identifying
points at which, in hindsight, major conceptual shortcomings became
cemented into foundations upon which today's practices rest.
* Evaluate how those conceptual pitfalls could have been avoided,
given understandings arrived at later in computing science.
* Integrate all those improvements holistically, creating a virtual
'alternate timeline' of computing evolution, as if Computing Science
had evolved with prescience of future conceptual advances and practical
needs. Aiming to arrive at an information processing and computing
architecture, that is what we'd already have now if we knew what we were
doing from the start.
Learning from others mistakes is usually a good thing.
Hey, we totally agree on something! I *HATE* PDF, and
the Adobe
DRM-flyblown horse it rode in on. When I scan tech documents, for lack
of anything more acceptable I structure the page images in html and wrap
as a RAR-book. Unfortunately few know of this method.
~chuckle~
There *was* at one point a freeware utility for
deconstructing PDF
files and analysing their structure. I forget the name just now. It
apparently was Borged by the forces of evil, and no longer can be found.
Anyone have a copy?
I've been able to get raw data out of PDFs before. But it's usually so
badly broken that it's difficult if not impossible to make it practical
to use. I'm usually better of just retyping what I want.
No, they are not intrinsically different things. It
just seems that way
from the viewpoint of convention because ASCII lacks so many structural
features that file (and stream) formats have to implement on their own.
(And so everyone does them differently.)
I disagree.
ASCII is a common way of encoding characters and control codes in the
same binary pattern.
File formats are what collections of ASCII characters / control codes
mean / do.
Ha, wait till (eventually - if ever) you see the real
thing. I'm having
lots of fun with it. Result is like 'alien tech.'
Please don't blame me for not holding my breath.
Soon. Few weeks. Got to get some stuff out of the way
first. I have way
too many projects.
:-)
--
Grant. . . .
unix || die
12:07 p.m.
I have long wondered if there are computer languages
that aren't rooted
in English / ASCII. I feel like it's rather pompous to assume that all
programming languages are rooted in English / ASCII. I would hope that
there are programming languages that are more specific to the region of
the world they were developed in. As such, I would expect that they
would be stored in something other than ASCII.
APL.
--
Will
6:23 p.m.
> I have long wondered if there are computer
languages that aren't rooted
> in English / ASCII. I feel like it's rather pompous to assume that all
> programming languages are rooted in English / ASCII. I would hope that
> there are programming languages that are more specific to the region of
> the world they were developed in. As such, I would expect that they
> would be stored in something other than ASCII.
On Tue, 27 Nov 2018, William Donzelli via cctalk wrote:
APL.
APL requires adding additional characters. That was a major obstacle to
acceptance, both in terms of keyboard and type ball (my use preceded CRT),
but also asking the user/programmer to learn new characters. I loved APL!
I love the use of an arrow for assignment. In teaching, a student's FIRST
encounter with programming can be daunting. Use of an equal sign
immediately runs up against the long in-grained concept of commutative
equality. You would be surprised how many first time students try to say
3 = X . Then, of course,
N = 1
N = N + 1
is a mathematical "proof by induction" that all numbers are equal!
(Don't let a mathematician see that, or the universe will cease to
exist, and be replaced by something even more inexplicable!)
Even the archaic keyword "LET" in BASIC helped clarify that.
We tend to be dismissive of such problems, declaring that
students "need to LEARN the right way".
I remember a cartoon in a publication, that might have been Interface Age,
where an archeologist looking at hieroglyphics says that it looks like a
subset of APL.
But, I think that the comment was more in regards to programming by
non-English speaking programmers. While FORTRAN, COBOL, BASIC can be
almost trivially adapted to Spanish, Italian, German, etc.,
What about Chinese? Japanese?
Yes, there IS a Chinese COBOL!
But, THOSE programmers essentially have to learn English before they can
program!
Surely a Chinese or Japanese based programming language could be
developed.
--
Grumpy Ol' Fred cisin at xenosoft.com
7:06 p.m.
New subject: Non-English programming languages was Re: Text encoding Babel.
Surely a Chinese or Japanese based programming
language could be
developed.
The Tomy Pyuuta has a very limited BASIC variant called G-BASIC which has
Japanese keywords and is programmed with katakana characters (such as "kake"
for PRINT). It freely interchanges with the Tomy Tutor's GBASIC (no dash)
with the same tokens, documented here:
https://www.floodgap.com/retrobits/tomy/gbkeyw.html
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- There's more to life than books, you know. But not much more. -- Morrissey -
28 Nov
28 Nov
6:16 a.m.
New subject: Non-English programming languages was Re: Text encoding Babel.
On Nov 27, 2018, at 10:06 PM, Cameron Kaiser via
cctalk <cctalk at classiccmp.org> wrote:
There appear to be quite a number of non-English languges, though it isn't clear how
many of these have significant user bases. See
https://en.wikipedia.org/wiki/Non-English-based_programming_languages.
In particular, that article mentions the fact that Algol 68 explicitly aimed for
translation into other languages, both of the language definition (the "Report")
and of the language itself. And indeed this was done; the Wikipedia article has a link to
the Russian specification which clearly shows a Russian version of the language.
paul
Surely a Chinese or Japanese based programming
language could be
developed.
The Tomy Pyuuta has a very limited BASIC variant called G-BASIC which has
Japanese keywords and is programmed with katakana characters (such as "kake"
for PRINT). It freely interchanges with the Tomy Tutor's GBASIC (no dash)
with the same tokens, documented here:
https://www.floodgap.com/retrobits/tomy/gbkeyw.html 
27 Nov
27 Nov
7:48 p.m.
On 11/27/18 6:23 PM, Fred Cisin via cctalk wrote:
I love the use of an arrow for assignment.? In
teaching, a student's
FIRST encounter with programming can be daunting.? Use of an equal sign
immediately runs up against the long in-grained concept of commutative
equality.? You would be surprised how many first time students try to
say 3 = X .? Then, of course,
N = 1
N = N + 1
is a mathematical "proof by induction" that all numbers are equal!
(Don't let a mathematician see that, or the universe will cease to
exist, and be replaced by something even more inexplicable!)
It's worth noting that in 1963 ASCII, hex 5E was the up-arrow (now the
circumflex) and hex 5F was the left-arrow (now underline).
It's also worth nothing that in the original CDC 6-bit display code,
there were symbols, not only for left-to-right arrow, but not equals,
logical OR and AND, up- and down-arrow, equivalence, logical NOT,
less-than-or-equal, and greater-than-or equal--pretty much the original
Algool-60 special characters.
--Chuck
28 Nov
28 Nov
6:27 a.m.
On Nov 27, 2018, at 9:23 PM, Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
I learned it about 15 years ago (OpenAPL, running on a Solaris workstation with a modified
Xterm that handled the APL characters). Nice. It made a handy tool for some
cryptanalysis programs I needed to write.
I wonder if current APL implementations use the Unicode characters for APL, that would
make things easy.
> I have long wondered if there are computer
languages that aren't rooted
> in English / ASCII. I feel like it's rather pompous to assume that all
> programming languages are rooted in English / ASCII. I would hope that
> there are programming languages that are more specific to the region of
> the world they were developed in. As such, I would expect that they
> would be stored in something other than ASCII.
On Tue, 27 Nov 2018, William Donzelli via cctalk wrote:
APL.
APL requires adding additional characters. That was a major obstacle to acceptance, both
in terms of keyboard and type ball (my use preceded CRT), but also asking the
user/programmer to learn new characters. I loved APL! I love the use of an arrow for assignment. ...
One of the strangest programming languages I've used is POP-2, which we used in an AI
course (Expert Systems) at the University of Illinois, in 1976. Taught by a visiting prof
from the University of Edinborough, I think Donald Mickie but I may have the name
confused.
Like APL, POP-2 had the same associativity for all operators. Unlike APL, the designers
decided that the majority should win so assignment would be left-associative like
everything else -- rather than APL's rule that all the other operators are
right-associative like assignment. So you'd end up with statements like:
n + 1 -> n
More at https://en.wikipedia.org/wiki/POP-2
paul
1:16 p.m.
On Wed, 28 Nov 2018 at 09:27, Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
I learned it about 15 years ago (OpenAPL, running on a
Solaris workstation with a modified Xterm that handled the APL characters). Nice. It
made a handy tool for some cryptanalysis programs I needed to write.
I am interested in this cryptanalysis program...
I wonder if current APL implementations use the
Unicode characters for APL, that would make things easy.
I can confirm that both NARS 2000 and Dyalog APL both use the Unicode
APL characters.
Regards,
Christian
--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
27 Nov
27 Nov
12:30 p.m.
On 11/27/2018 12:47 PM, Grant Taylor via cctalk wrote:
ASCII is a common way of encoding characters and
control codes in the
same binary pattern.
File formats are what collections of ASCII characters / control codes
mean / do.
It also was designed for hard copy. Over strikes don't work well on a
CRT screen.
Ben.
3:43 p.m.
I'm a bit dense for weighing in on this as my first post, but what the heck.
Our problem isn't ASCII or Unicode, our problem is how we use computers.
Going back in time a bit, the first keyboards only recorded letters
and spaces, even line breaks required manual intervention. As things
developed, we upgraded our input capabilities a little bit (return
keys! delete keys! arrow keys!), but then, some time before graphical
displays came along, we stopped upgrading. We stopped increasing the
capabilities of our input, and instead focused on kludges to make them
do more. We created markup languages, modifier keys, and page
description languages, all because our input devices and display
devices lacked the ability to comprehend anything more than letters.
Now we're in a position where we have computers with rich displays
bolted to a keyboard that has remained unchanged for 150 years.
Unpopular opinion time: Markup languages are a kludge, relying on
plain text to describe higher level concepts. TeX has held us back.
It's a crutch so religiously embraced by the people that make our
software that the concept of markup has come to be accepted "the way".
I worked with some university students recently, who wasted a
ridiculous amount of time learning to use LaTeX to document their
projects. Many of them didn't even know that page layout software
existed, they thought there was this broad valley in capabilities with
TeX on one side, and Microsoft Word on the other. They didn't realize
that there is a whole world of purpose built tools in between. Rather
than working on developing and furthering our input capabilities,
we've been focused on keeping them the same. Markup languages aren't
the solution. They are a clumsy bridge between 150 year old input
technology and modern display capabilities.
Bold or italic or underlined text shouldn't be a second class concept,
they have meaning that can be lost when text is conveyed in
circa-1868-plain-text. I've read many letters that predate the
invention of the typewriter, emphasis is often conveyed using
underlines or darkened letters. We've drawn this arbitrary line in the
sand, where only letters that can be typed on a typewriter are "text",
Everything else is fluff that has been arbitrarily decided to convey
no meaning. I think it's a safe argument to make that the primary
reason we've painted ourselves into this unexpressive corner is
because of a dogged insistence that we cling to the keyboard.
I like the C comment example; Why do I need to call out a comment with
a special sequence of letters? Why can't a comment exist as a comment?
Why is a comment a second class concept? When I take notes in the
margin, I don't explicitly need to call them out as notes. This
extends to strings, why do I need to use quotes? I know it's a string
why can't the computer remember that too? Why do I have to use the
capabilities of a typewriter to describe that to the computer? There
seems to be confusion that computers are inherently text based. They
are only that way because we program them and use them that way, and
because we've done it the same way since the day of the teletype, and
it's _how it's done._
"Classic" Macs are a great example of breaking this pattern. There was
no way to force the computer into a text mode of operating, it didn't
exist. Right down to the core the operating system was graphical. When
you click an icon, the computer doesn't issue a text command, it
doesn't call a function by name, it merely alters the flow of some
binary stuff flowing through the CPU in response to some other bits
changing. Yes, the program describing that was written in text, but
that text is not what the computer is interpreting.
I'm getting a bit philosophical, so I'll shut up now, but it's an
interesting discussion.
- Keelan
5:33 p.m.
On 11/27/2018 04:43 PM, Keelan Lightfoot via cctalk wrote:
I'm a bit dense for weighing in on this as my
first post, but what
the heck.
Welcome. :-)
Our problem isn't ASCII or Unicode, our problem is
how we use computers.
Okay.
Going back in time a bit, the first keyboards only
recorded letters
and spaces, even line breaks required manual intervention. As things
developed, we upgraded our input capabilities a little bit (return
keys! delete keys! arrow keys!), but then, some time before graphical
displays came along, we stopped upgrading. We stopped increasing the
capabilities of our input, and instead focused on kludges to make them do
more.
Do you think that we stopped enhancing the user input experience more
because we were content with what we had or because we didn't see a
better way to do what we wanted to do?
We created markup languages, modifier keys, and page
description
languages, all because our input devices and display devices lacked
the ability to comprehend anything more than letters. Now we're in a
position where we have computers with rich displays bolted to a keyboard
that has remained unchanged for 150 years.
Hum....
Unpopular opinion time: Markup languages are a kludge,
relying on plain
text to describe higher level concepts.
I agree that markup languages are a kludge. But I don't know that they
require plain text to describe higher level concepts.
I see no reason that we can't have new control codes to convey new
concepts if they are needed.
Aside: ASCII did what it needed to do at the time. Times are different
now. We may need more / new / different control codes.
By control codes, I'm meaning a specific binary sequence that means a
specific thing. I think it needs to be standardized to be compatible
with other things -or- it needs to be considered local and proprietary
to an application.
TeX has held us back. It's a crutch so
religiously embraced by the
people that make our software that the concept of markup has come to be
accepted "the way". I worked with some university students recently,
who wasted a ridiculous amount of time learning to use LaTeX to document
their projects. Many of them didn't even know that page layout software
existed, they thought there was this broad valley in capabilities with
TeX on one side, and Microsoft Word on the other. They didn't realize
that there is a whole world of purpose built tools in between.
I actually wonder how much need there is for /all/ of those utilities.
I expect that things should have streamlined and simplified, at least
some, in the last 30 years.
Rather than working on developing and furthering our
input capabilities,
we've been focused on keeping them the same. Markup languages aren't the
solution. They are a clumsy bridge between 150 year old input technology
and modern display capabilities.
What would you like to do or see done differently? Even if it turns out
to be worse, it would still be something different and likely worth
trying at least once.
Bold or italic or underlined text shouldn't be a
second class
concept, they have meaning that can be lost when text is conveyed in
circa-1868-plain-text. I've read many letters that predate the invention
of the typewriter, emphasis is often conveyed using underlines or darkened
letters.
I don't think of bold or italic or underline as second class concepts.
I tend to think of the following attributes that can be applied to text:
? bold
? italic
? overline
? strike through
? underline
? superscript exclusive or subscript
? uppercase exclusive or lowercase
? opposing case
? normal (none of the above)
I don't think that normal is superior to the other four (five) in any
way. I do think that normal does occur VASTLY more frequently than the
any combination of the others. As such normal is what things default to
as an optimization. IMHO that optimization does not relegate the other
styles to second class.
We've drawn this arbitrary line in the sand, where
only letters that
can be typed on a typewriter are "text", Everything else is fluff that
has been arbitrarily decided to convey no meaning.
I don't agree that the decision was made (by most people). At least not
consciously.
I will say that some people probably decided what a minimum viable
product is when selling typewriters, and consciously chose to omit the
other options.
I think it's a safe argument to make that the
primary reason we've
painted ourselves into this unexpressive corner is because of a dogged
insistence that we cling to the keyboard.
I see no reason that the keyboard can't have keys / glyphs added to it.
I'm personally contemplating adding additional keys (via an add on
keyboard) that are programmed to produce additional symbols. I
frequently use the following symbols and wish I had keys for easier
access to them: ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?, ?.
When I say frequently, I mean that I use some of them daily, many of
them weekly, and others monthly. I've written tiny shell scripts that I
can run that insert the character into the clipboard so that I can
easily paste the character where I need them. (The order of the symbols
above comes from the alphabetical nature of their names.)
Frequently enough that I'd like about ? of them to be on keys on my
keyboard(s) that I can press. Ideally, they would just be inserted
directly instead of going through the clipboard.
How could I forget:
(????)?? ???
?\_(?)_/?
???? ?( ?-??)
So ? I'm in favor of extending the keyboard. :-)
I like the C comment example; Why do I need to call
out a comment with
a special sequence of letters? Why can't a comment exist as a comment?
Why is a comment a second class concept? When I take notes in the
margin, I don't explicitly need to call them out as notes.
Ah, but you are explicitly calling them out by where you place them.
We need a way to tell the computer that something is a comment. One
method is to use markup / control key sequences. Another method is to
use what Google Docs uses, namely highlight text to comment, click the
comment balloon, enter the comment in the comment box. There's no key
sequence. But there is an explicit indication that something is a
comment. Said comment is displayed in the right hand margin, so I know
it's a comment.
Note: That's all the user interface and user experience. It says
nothing for the underlying storage method. I'm getting that the
document is a collection of JSON markup. Or a "file format" as I've
been saying.
This extends to strings, why do I need to use quotes?
I know it's a
string why can't the computer remember that too? Why do I have to use
the capabilities of a typewriter to describe that to the computer?
I don't have to tell m4 that something is a string or a number or
anything else. I simply define the thing, what ever I want to call it,
and assign it a value. Then anywhere I use that name, the name is
substituted with the value that I assigned to it.
I believe that some language treat strings, arrays, hashes, etc. as
separate namespaces. Thus you must indicate which namespace you are
meaning. I don't see any reason that we can't have a common namespace
and allow the named entity to include information about what type of
entity it is. ? This seems like a programming language design issue,
not a human keyboard issue.
Or did I completely misinterpret what you meant by strings?
There seems to be confusion that computers are
inherently text based. They
are only that way because we program them and use them that way, and
because we've done it the same way since the day of the teletype, and
it's _how it's done._
I will concede that many computers and / or programming languages do
behave based on text. But I am fairly confident that there are some
programming languages (I don't know about computers) that work
differently. Specifically, simple objects are included as part of the
language and then more complex objects are built using the simpler
objects. Dia and (what I understand of) Minecraft come to mind.
I'm fairly confident that NeXT Step also did some things along these
lines, but I'm not sure.
"Classic" Macs are a great example of
breaking this pattern. There was
no way to force the computer into a text mode of operating, it didn't
exist. Right down to the core the operating system was graphical. When
you click an icon, the computer doesn't issue a text command, it doesn't
call a function by name, it merely alters the flow of some binary stuff
flowing through the CPU in response to some other bits changing. Yes,
the program describing that was written in text, but that text is not
what the computer is interpreting.
I don't think that the text mode vs GUI mode is a good comparison. Text
mode happens to be common, likely because it's simpler to start with,
but I don't see it as a requirement.
Visual Basic keeps coming to mind as I read your paragraph. (From what
I understand) VB is inherently visually / graphically oriented. You
start with the visual components, and then assign actions to various
pieces. Those actions are likely text. But I see no reason that you
couldn't extend the model to execute other things.
I'm getting a bit philosophical,
I don't see any problem with that.
so I'll shut up now,
Please don't do that.
but it's an interesting discussion.
Yes, it is. :-)
--
Grant. . . .
unix || di
6:10 p.m.
On 2018-11-27 8:33 PM, Grant Taylor via cctalk wrote:
...
This covers only a small fraction of the Latin-centric typographic
palette - much of which has existed for 500 years in print (non-Latin
much older). Computerisation has only impoverished that palette, and
this is how it happens: Checklists instead of research.
Work with typographers when trying to represent typography in a
computer. The late Hermann Zapf was Knuth's close friend. That's the
kind of expertise you need on your team.
--Toby
Bold or italic or underlined text shouldn't
be a second class concept,
they have meaning that can be lost when text is conveyed in
circa-1868-plain-text. I've read many letters that predate the
invention of the typewriter, emphasis is often conveyed using
underlines or darkened letters.
I don't think of bold or italic or underline as second class concepts. I
tend to think of the following attributes that can be applied to text:
?? bold
?? italic
?? overline
?? strike through
?? underline
?? superscript exclusive or subscript
?? uppercase exclusive or lowercase
?? opposing case
?? normal (none of the above)
I don't think that normal is superior to the other
four (five) in any
way.? I do think that normal does occur VASTLY more frequently than the
any combination of the others.? As such normal is what things default to
as an optimization.? IMHO that optimization does not relegate the other
styles to second class.
...
7:45 p.m.
It was thus said that the Great Grant Taylor via cctalk once stated:
On 11/27/2018 04:43 PM, Keelan Lightfoot via cctalk
wrote:
[ snip ]
Unpopular opinion time: Markup languages are a kludge, relying on plain
text to describe higher level concepts.
I agree that markup languages are a kludge. But I don't know that they
require plain text to describe higher level concepts.
I see no reason that we can't have new control codes to convey new
concepts if they are needed.
Aside: ASCII did what it needed to do at the time. Times are different
now. We may need more / new / different control codes.
By control codes, I'm meaning a specific binary sequence that means a
specific thing. I think it needs to be standardized to be compatible
with other things -or- it needs to be considered local and proprietary
to an application. I don't think of bold or italic or underline as
second class concepts.
I tend to think of the following attributes that can be applied to text:
? bold
? italic
? overline
? strike through
? underline
? superscript exclusive or subscript
? uppercase exclusive or lowercase
? opposing case
? normal (none of the above)
But there are defined control codes for that (or most of that list
anyway). It's not ANSI, but an ISO standard. Let's see ...
^[[1m bold
^[[3m italic
^[[53m overline
^[[9m strike through
^[[4m underline
^[[0m normal
The superscript/subscribe could be done via another font
^[[11m ... ^[[19m
Maybe even the opposing case case ... um ... yeah.
By the way, ^[ is a single character representing the ASCII ESC character
(27).
I see no reason that the keyboard can't have keys
/ glyphs added to it.
I'm personally contemplating adding additional keys (via an add on
keyboard) that are programmed to produce additional symbols. I
frequently use the following symbols and wish I had keys for easier
access to them: ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?.
Years ago I came across an IBM Model M keyboard that had the APL character
set on the keyboard, along with the normal characters one finds. I would
have bought it on the spot if it weren't for a friend of mine who saw it 10
seconds before I did.
I did recently get another IBM Model M keyboard (an SSK model) that had
additional labels on the keys:
http://boston.conman.org/2018/10/31.2
The nice thing about the IBM Model M is the keycaps are easy to replace.
I will concede that many computers and / or
programming languages do
behave based on text. But I am fairly confident that there are some
programming languages (I don't know about computers) that work
differently. Specifically, simple objects are included as part of the
language and then more complex objects are built using the simpler
objects. Dia and (what I understand of) Minecraft come to mind.
You might be thinking of Smalltalk.
-spc
30 Nov
30 Nov
10:34 a.m.
Welcome. :-)
Thanks!
Do you think that we stopped enhancing the user input
experience more
because we were content with what we had or because we didn't see a
better way to do what we wanted to do?
Both. In the beginning we were content, because the keyboard was well
suited to the capabilities of the technology available at the time it
was invented. We didn't see a better way, because when compared to
using a pen and paper (for writing) or using toggle switches (to
control a computer), a keyboard was a significant improvement. It's
the the explosive growth and universal adoption of computers that has
locked us in to the keyboard as the standard.
I agree that markup languages are a kludge. But I
don't know that they
require plain text to describe higher level concepts.
I see no reason that we can't have new control codes to convey new
concepts if they are needed.
I disagree with this; from a usability standpoint, control codes are
problematic. Either the user needs to memorize them, or software needs
to inject them at the appropriate times. There's technical problems
too; when it comes to playing back a stream of characters, control
characters mean that it is impossible to just start listening. It is
difficult to fast forward and rewind in a file, because the only way
to determine the current state is to replay the file up to that point.
Aside: ASCII did what it needed to do at the time.
Times are different
now. We may need more / new / different control codes.
By control codes, I'm meaning a specific binary sequence that means a
specific thing. I think it needs to be standardized to be compatible
with other things -or- it needs to be considered local and proprietary
to an application.
Do you mean modal control codes? As in "everything after here is bold"
and "the bold stops here"?
I actually wonder how much need there is for /all/ of
those utilities.
I expect that things should have streamlined and simplified, at least
some, in the last 30 years.
We've gone backwards sadly. For a brief while, this kind of rich user
interface stuff was provided by the OS. A text box, regardless of the
application, would use the OS's text box control, and would have a
universal interface for rich text. But the growth of the web has
resulted in an atavism. We're back to plain text, and using markup to
style our text. If I want bold text in Slack, I have to use markup.
Facebook Messages and YouTube comments also support markup, but the
syntax is slightly different between them. Back in 1991, If I wanted
bold text in any application that supported rich text on my SE/30, I
hit command-B and I got bold text. Sure, there are Javascript rich
text editors that can be bolted on, but they all have their own UI
concepts, and they're all a trainwreck.
What would you like to do or see done differently?
Even if it turns out
to be worse, it would still be something different and likely worth
trying at least once.
In addition to crusty old computers, I also enjoy the company of three
crusty old Linotypes. In fact, that's what got me thinking about this
stuff in the first place. The Linotype keyboard has 90 keys, which
directly map to the 90 glyphs a Linotype can "render". The keyboard is
laid out in three qual sized sections: lowercase letters on the left,
uppercase on the right, with numbers and punctuation in the middle.
Push the button, and what's marked on the button is what ultimately
ends up on the page. Each Linotype mat (matrix; letter mold) has two
positions, which can be selected by flipping a little lever when
they're being assembled into a line. The two positions are almost
always used to select between two versions of a font; roman/bold or
roman/italic are the most common pairings.
But what it means is that you can walk up to a machine with a
half-typed line in the assembler and immediately determine its state.
Any mats set in the bold position are in a physically different
position in the assembler. The position of the switch tells you if
you're typing in bold or roman. When you push the 'A' key, you know an
uppercase 'A' in bold will be added to the line. Additionally, the
position of that switch can be verified without taking your eyes off
of the copy. There is no black magic, no spooky action at a distance.
The capabilities of the machine are immediately apparent.
I don't think of bold or italic or underline as
second class concepts.
I tend to think of the following attributes that can be applied to text:
? bold
[snip]
I don't think that normal is superior to the other four (five) in any
way. I do think that normal does occur VASTLY more frequently than the
any combination of the others. As such normal is what things default to
as an optimization. IMHO that optimization does not relegate the other
styles to second class.
I agree. I think that they're normal enough that they should exist as
their own code points in unicode. Our 'standard' coding treats
'formatting' as optional. IOW, I agree more!
I will say that some people probably decided what a
minimum viable
product is when selling typewriters, and consciously chose to omit the
other options.
Consciously omitted in the beginning, yes, otherwise typewriters would
have never been affordable enough to become mainstream. But that has
led to "plain text" becoming the de-facto standard. It's 2018, and I
can't type italic text in this e-mail without potentially causing some
people problems, ??? ?'? ??????? ?? ???? ?? ?
???.
I see no reason that the keyboard can't have keys
/ glyphs added to it.
I agree. But if they're added as a touch screen, shoot me now.
"Haptics" has mutated into "shakes when you touch it", instead of
"you
can feel the button".
I'm personally contemplating adding additional
keys (via an add on
keyboard) that are programmed to produce additional symbols.
I have the little DigiStump Arduino thingy somewhere that I bought to
use for exactly that purpose! My goal is to create a Linotype style
keyboard, the middle bank of 30 keys tailored to my application, as
was often done with the Linotype. I have one Linotype with dedicated
E13B keys for setting the magnetic ink characters at the bottom of
cheques.
When I say frequently, I mean that I use some of them
daily, many of
them weekly, and others monthly. I've written tiny shell scripts that I
can run that insert the character into the clipboard so that I can
easily paste the character where I need them. (The order of the symbols
above comes from the alphabetical nature of their names.)
I find that having the extra glyphs readily available means that I use
them more in everyday communication; I use the trademark symbol (which
is only slightly buried on a mac keyboard) quite often to convey a
sense of sarcasm (i.e. "sure, we could do that, but there is no One
True Way?, regardless of what the sales people told you...").
So ? I'm in favor of extending the keyboard. :-)
When my Linotype 2000 keyboard enters production, I'll let you know ;)
We need a way to tell the computer that something is a
comment. One
method is to use markup / control key sequences. Another method is to
use what Google Docs uses, namely highlight text to comment, click the
comment balloon, enter the comment in the comment box. There's no key
sequence. But there is an explicit indication that something is a
comment. Said comment is displayed in the right hand margin, so I know
it's a comment.
What if comment characters had their own unicode code points? A bit
silly, yes, but that's the lines I'm thinking along. It would allow me
to put comments right inside my code if I found myself stricken with
such a desire to produce prodigiously incomprehensible programming!
I believe that some language treat strings, arrays,
hashes, etc. as
separate namespaces. Thus you must indicate which namespace you are
meaning. I don't see any reason that we can't have a common namespace
and allow the named entity to include information about what type of
entity it is. ? This seems like a programming language design issue,
not a human keyboard issue.
Or did I completely misinterpret what you meant by strings?
I'm going to lavish on the unicode for this example, so those of you
properly unequipped may not see this example:
foo := ???? ?? ? ?????? ???? ?? ? ???????
printf(??? ?????? ?? ? ???? ???? ????????, foo)
if ???? ?? ? ?????? ?????? ??????? foo ==
???? ?? ???? ? ??????, ??? ??? ??? ????
??? { ???? ?? ???? ? ???????
...
An atrocious example, but a good demonstration of my point. If I had a
toggle switch on my keyboard to switch between code, comment and
string, it would have been much simpler to construct too!
I will concede that many computers and / or
programming languages do
behave based on text. But I am fairly confident that there are some
programming languages (I don't know about computers) that work
differently. Specifically, simple objects are included as part of the
language and then more complex objects are built using the simpler
objects. Dia and (what I understand of) Minecraft come to mind.
I don't deny that they exist, but there are no significant
applications being developed with them.
Visual Basic keeps coming to mind as I read your
paragraph. (From what
I understand) VB is inherently visually / graphically oriented. You
start with the visual components, and then assign actions to various
pieces. Those actions are likely text. But I see no reason that you
couldn't extend the model to execute other things.
I'm not sure how VB puts things together behind the scenes. The
example I am more familiar with is HyperCard, where instead of the UI
existing in the code, the code exists in the UI as you describe. This
of course violates all the religious tenets of Model-View-Controller
design (for the most part, dogmatic adherence to that pattern has
mainly served to give us government software projects that die as
multi-trillion dollar failures before seeing the light of day. I am of
course being a bit facetious, but not entirely). Back on topic, the
tools exist, but they are often seen as toys and not serious software
development tools. Are we at the point where the compiler for a visual
programming language is written in the visual programming language?
- Keelan
1:33 p.m.
Back on topic, the tools exist, but they are often
seen as toys and
not serious software
development tools. Are we at the point where the compiler for a visual
programming
language is written in the visual programming language?
- Keelan
Hi Keelan,
I was going to mention this further back in the thread when visual
programming was first mentioned, but for those not aware, there has been a
shift in emphasis in teaching computing principles to newbies who have no
idea what a bit, byte, assembler, compiler, interpreter, etc., are. UC
Berkeley's "The Beauty and Joy of Computing" (and a follow-on "The
Beauty
and Joy of Data", offered at some institutions) curricula are increasingly
being taught (starting in high school advanced placement computer science,
as well as in freshman coursework in universities) to convey fundamental
computing concepts:
https://bjc.berkeley.edu
The associated courses are taught using a visual programming environment
called Snap!, where the (now browser-based, thank goodness) ease-of-use of
Scratch (drag-and-drop interface, visual metaphors for loops, conditionals,
etc., as well as easy animation tools) is combined with the power of Scheme
(first class procedures, first class lists, first class objects, and first
class continuations).
https://snap.berkeley.edu
Some universities have begun offering Bachelor of Arts degrees in CS, in
addition to BSCSs, where about half of the BACS coursework is
technically-oriented, and the remainder is oriented to more traditional
arts offerings. TB&JoC, TB&JoD, and Snap! form a bridge so that students
who ordinarily would never even consider studying CS can become
knowledgeable enough to truly comprehend and appreciate computing's
possibilities and limitations in its role in civilization (or at least
what's left of it).
There's enough slack in the approved offerings that electives can be
weighted more toward the technical direction (e.g., user interface and
experience) or the arts direction (e.g., psychology and history). The idea
was to close the severely-growing gap between those who know everything
about computing and those who need to know enough, but not everything, to
be truly effective in the information-dominant world we've been careening
toward without nearly enough preparation of future generations.
I haven't worked with Snap! enough yet to know for sure whether it can be
used to develop itself, but I strongly suspect that is the case (it's
actually implemented in Javascript using an HTML5 canvas due to its
browser-based nature). It wouldn't be suitable for doing systems level
development, unless optimized C code (or equivalent) could be emitted, but
it could certainly be used to demonstrate the logic principles involved in
any level of software development that most people are ever likely to need
to understand. There's mention of Snap! programs being convertible to
mainstream programming languages such as Python, JavaScript, C, etc., but I
haven't traced to ground in documentation how that's supposed to happen,
yet.
We may be part-way there because Google's Blockly spin-off of Scratch can
already emit five scripting languages (Javascript, Python, PHP, Lua, and
Dart), and it uses a modular approach where emission of code in additional
languages could reportedly be added. That magic word, "optimized", is the
key to whether the code is fundamentally correct and would need oodles of
hand-rewriting to improve efficiency, or there are ways to automate at
least some of the optimization.
Snap! can be run off-line in a browser, as well as on the on-line primary
and mirror sites, and standalone applications can be generated. Scratch
has been extended to provide an easy way to control and sense physical
environments via typical robotics components, but I haven't looked to see
if Snap! has inherited those extensions.
For any doubters, note that Pacman was ported to Scratch years ago,
complete with the authentic sounds (including the "shrivel and
disappear-in-death" clip), so ... ;^)
All the Best,
Jim
2:27 p.m.
On 11/30/2018 02:33 PM, Jim Manley via cctalk wrote:
There's enough slack in the approved offerings
that electives can be
weighted more toward the technical direction (e.g., user interface and
experience) or the arts direction (e.g., psychology and history). The idea
was to close the severely-growing gap between those who know everything
about computing and those who need to know enough, but not everything, to
be truly effective in the information-dominant world we've been careening
toward without nearly enough preparation of future generations.
I kept thinking to myself that many of the people that are considered
pioneers in computers were actually something else by trade and learned
how to use computers and / or created what they needed for the computer
to be able to do their primary job.
--
Grant. . . .
unix || die
1 Dec
1 Dec
12:07 p.m.
On Fri, Nov 30, 2018 at 3:28 PM Grant Taylor via cctalk <
cctalk at classiccmp.org> wrote:
On 11/30/2018 02:33 PM, Jim Manley via cctalk wrote:
Most people know that Newton's motivation for developing calculus was
explaining the motions of the planets, but not many know that he served as
the Warden, and then Master, of the Royal Mint, as well as being fascinated
with optics and vision (to the point where he inserted a needle into one of
his eyes!) and a closet alchemist. His competitor, Leibniz, was motivated
to develop calculus by a strong desire to win more billiards bets from his
fellow wealthy buddies in Hanover, the financial capital of Germany at the
time, while developing the mathematics of the physics governing the
collisions of billiard balls. Babbage was motivated to develop calculating
and computing machines to eliminate the worldwide average of seven errors
per page in astronomical, navigational, and mathematical tables of the
1820s.
Shannon and Hamming (with whom I worked - the latter, not the former!) were
motivated to represent Boolean logic in digital circuits and improve
long-distance communications by formalizing how to predictably ferret more
signal out of noise. Turing was motivated to test his computing theories
to break the Nazi Enigma ciphers (character-oriented, vs. word-oriented
codes) and moved far beyond the mathematical underpinnings of his theories
into the engineering of Colossus and the bombes. Hollerith was motivated
by the requirement to complete the decennial census tabulations within 10
years (the 1890 census was going to take 13 years to tabulate using
traditional manual methods within the available budget). Mauchly and
Eckert were motivated to automate calculations for ballistics tables for
WW-II weapons systems that were being fielded faster than tables could be
produced manually.
Hopper developed the first compiler and the first programming language to
use English words, Flow-Matic, that led, in turn, to COBOL being created to
meet financial software needs. John Backus and the other developers of
FORTRAN were likewise motivated by scientific and engineering calculation
requirements. Kernigan, Ritchie, and Thompson were motivated by a desire
to perform an immense prank, in the form of Unix and A/B/BCPL/C, on an
unsuspecting and all-too-serious professional computing world (
http://www.stokely.com/lighter.side/unix.prank.html). Gates and Allen were
motivated by all of the money lying around on desks, in their drawers, and
in the drawers worn by the people sitting at said desks, to foist PC/MS-DOS
and Windows on the less serious computing public. Kildall was motivated by
the challenges of developing multi-pass compilation on systems with minimal
microcomputer hardware resources.
Meanwhile, the rest of the computing field was motivated to pursue the next
shinier pieces of higher-performance hardware, developing ever-more-bloated
programming languages, OSes, services, and applications that continue to
slow down even the latest-and-greatest systems. Berners-Lee was motivated
to help scientists and engineers at the European Organization for Nuclear
Research (CERN - the Conseil Europ?en pour la Recherche Nucl?aire) organize
and share their work without having to become expert software developers in
their own right. Yang, Filo, Brin, Page, Zuckerberg, et al, were motivated
by whatever money could be scrounged from sofas used by couch-surfing,
homeless Millenials (redundant syntax fully intended), and from local news
outlets' advertising accounts. Selling everyone's, but their own,
personally-identifiable information, probably including that of their own
mothers, has been a welcome additional cornucopia of revenue to them.
Computer science and engineering degrees weren't even offered yet when I
attended the heavily science and engineering oriented naval institution
where I earned my BS in engineering (70% of degrees awarded were in STEM
fields). The closest you could get were math and electrical engineering
degrees, taking the very few electives offered in CS and CE disciplines.
Granted, the computer I primarily had access to was a secondhand GE-265
with drum storage (we each got a whopping 32 KBs for all of our software
development ... yeah, that's with a K). There was also a PDP-8 in a rack
on wheels movable between the various engineering labs - we had to plug it
into a wall outlet for power, and a phone line for its modem to connect to
our accounts on the GE-265. My senior year, we received an Evans and
Sutherland Picture System 1 hardware-accelerated, 3-D vector wireframe
workstation, mind-melded to a dedicated PDP-11/70 via a three-foot cube on
its Mass Bus, containing 1 MB of dual-ported static RAM ... that alone cost
a million smackers (a buck a byte!).
I had to wait until I earned my MSCS 10 years later (taking care of my
WW-II D-Day in Normandy/Bastogne/Bulge/etc., 101st Airborne Division
paratrooper, POW, and vet Dad, and cancer-stricken Mom during that entire
period) to "officially" be considered a computer scientist and software
engineer (by HR weenies). That was despite being a full-time practitioner
of both that entire decade, developing systems with a majority of
components involving data, information, and knowledge processing. That
turned out to be a blessing in disguise, as I've routinely had to show even
some younger CS PhDs what discrete transistors look like (going all the way
back to Bell Labs' 1947 dual gold point-contact germanium prototype) and
how they work when presenting artifacts during tours at the Computer
History Museum in Silicon Valley. It's also been handy in jobs to be able
to accurately describe the real-world effects of bone-headed decisions
based purely on academic theoretical beliefs.
In short, Necessity and Invention are Mothers ...
There's enough slack in the approved
offerings that electives can be
weighted more toward the technical direction (e.g., user interface and
experience) or the arts direction (e.g., psychology and history). The
idea
was to close the severely-growing gap between
those who know everything
about computing and those who need to know enough, but not everything, to
be truly effective in the information-dominant world we've been careening
toward without nearly enough preparation of future generations.
I kept thinking to myself that many of the people that are considered
pioneers in computers were actually something else by trade and learned
how to use computers and / or created what they needed for the computer
to be able to do their primary job.
--
Grant. . . .
unix || die
30 Nov
30 Nov
2:22 p.m.
On 11/30/2018 11:34 AM, Keelan Lightfoot via cctalk wrote:
Thanks!
:-)
Both. In the beginning we were content, because the
keyboard was well
suited to the capabilities of the technology available at the time it was
invented. We didn't see a better way, because when compared to using a pen
and paper (for writing) or using toggle switches (to control a computer),
a keyboard was a significant improvement. It's the the explosive growth
and universal adoption of computers that has locked us in to the keyboard
as the standard.
*sigh* The Steve G. from Security Now's comments about passwords not
going away comes to mind and seems apropos for keyboards.
There are other, likely better, things out there. But keyboards
themselves aren't going to go away.
I disagree with this; from a usability standpoint,
control codes are
problematic. Either the user needs to memorize them, or software needs
to inject them at the appropriate times.
Okay.
There's technical problems too; when it comes to
playing back a stream
of characters, control characters mean that it is impossible to just
start listening. It is difficult to fast forward and rewind in a file,
because the only way to determine the current state is to replay the
file up to that point.
Now I'm wondering about something akin to the differences in upper case
and lower case. Functionally the same code, just a different value in
the 6th bit.
What if there were (functionally) additional bits that indicated various
other (what I was calling) stylings?
I think that something along those lines could help avoid a concern I
have. Namely how do search for an A, what ever ""style it's in. I
think I could hypothetically search for bytes ~> words (characters)
containing (xxxxxxxx xxxxxxxx) (xxxxxxxx) 01x00001 (assuming that the
proceeding don't cares are set appropriately) and find any format of A,
upper case, lower case, bold, italic, underline, strike through, etc.
The other think that the additional bit / flags could do is allow the
bytes (words / characters) to be read mid-stream.
Do you mean modal control codes? As in
"everything after here is bold"
and "the bold stops here"?
Yes. That's what I was thinking when I wrote that.
We've gone backwards sadly. For a brief while,
this kind of rich user
interface stuff was provided by the OS. A text box, regardless of
the application, would use the OS's text box control, and would have
a universal interface for rich text.
Indeed.
But the growth of the web has resulted in an atavism.
We're back to plain
text, and using markup to style our text.
I mostly agree. But I do wonder how true that actually is, at least on
a technical level. I think the text input box can be enhanced to allow
more than just plain text.
If I want bold text in Slack, I have to use markup.
Facebook Messages and
YouTube comments also support markup, but the syntax is slightly different
between them.
*sigh*
Back in 1991, If I wanted bold text in any application
that supported
rich text on my SE/30, I hit command-B and I got bold text. Sure, there
are Javascript rich text editors that can be bolted on, but they all
have their own UI concepts, and they're all a trainwreck.
I believe that we can do better.
In addition to crusty old computers, I also enjoy the
company of three
crusty old Linotypes. In fact, that's what got me thinking about this
stuff in the first place. The Linotype keyboard has 90 keys, which
directly map to the 90 glyphs a Linotype can "render". The keyboard is
laid out in three qual sized sections: lowercase letters on the left,
uppercase on the right, with numbers and punctuation in the middle.
Push the button, and what's marked on the button is what ultimately
ends up on the page. Each Linotype mat (matrix; letter mold) has two
positions, which can be selected by flipping a little lever when they're
being assembled into a line. The two positions are almost always used
to select between two versions of a font; roman/bold or roman/italic
are the most common pairings.
Intriguing. I have a vague mental image of what you're talking about
after watching Linotype: The Film (http://www.linotypefilm.com). I
found it quite entertaining and informative.
But what it means is that you can walk up to a machine
with a half-typed
line in the assembler and immediately determine its state. Any mats
set in the bold position are in a physically different position in
the assembler. The position of the switch tells you if you're typing
in bold or roman. When you push the 'A' key, you know an uppercase 'A'
in bold will be added to the line. Additionally, the position of that
switch can be verified without taking your eyes off of the copy. There
is no black magic, no spooky action at a distance. The capabilities of
the machine are immediately apparent.
I was not aware of the physically different positions. But either I
don't remember, pick up on, or they didn't go into that in the Linotype
film. Being able to determine the current position without removing
your eyes from copy does sound like a very good thing.
I agree. I think that they're normal enough that
they should exist
as their own code points in unicode. Our 'standard' coding treats
'formatting' as optional. IOW, I agree more!
:-)
Consciously omitted in the beginning, yes, otherwise
typewriters would
have never been affordable enough to become mainstream. But that has led
to "plain text" becoming the de-facto standard.
~nod~
It's 2018, and I can't type italic text in
this e-mail without
potentially causing some people problems, ??? ?'?
??????? ?? ???? ?? ?
???.
It came through for me. - It even made it through my clipboard, sed,
and fmt. :-)
Aside: I suspect that none of the (plain-text / non-MIME) digest
subscribers will see that properly. I've found out from Mark S.,
Mailman's maintainer, that UTF-8 isn't maintained in the plain-text /
non-MIME digest.
I agree. But if they're added as a touch screen,
shoot me now. "Haptics"
has mutated into "shakes when you touch it", instead of "you can feel
the button".
Don't get me started on how inferior a device shaking is compared to a
buckling spring.
I have no doubt that things will end up on a touch screen. I'm
confident that some are already there.
I have the little DigiStump Arduino thingy somewhere
that I bought to
use for exactly that purpose! My goal is to create a Linotype style
keyboard, the middle bank of 30 keys tailored to my application, as was
often done with the Linotype. I have one Linotype with dedicated E13B
keys for setting the magnetic ink characters at the bottom of cheques.
That sounds intriguing.
I find that having the extra glyphs readily available
means that I use
them more in everyday communication; I use the trademark symbol (which is
only slightly buried on a mac keyboard) quite often to convey a sense of
sarcasm (i.e. "sure, we could do that, but there is no One True Way?,
regardless of what the sales people told you...").
Yep. I find the same.
I also find that I want to use them more as I do use them. Or rather,
it seems as if I know that there is a solution (character) that is
appropriate in this situation, and I know how to use it, I'm going to
use it! Sort of like adding words to your vocabulary.
When my Linotype 2000 keyboard enters production,
I'll let you know ;)
That sounds a little bit tongue-in-cheek. But I think that you could
make something like that happen. I suspect that there are a number of
people that would be interested in that. Dare I say it... especially if
it was USB connected.
What if comment characters had their own unicode code
points? A bit silly,
yes, but that's the lines I'm thinking along. It would allow me to put
comments right inside my code if I found myself stricken with such a
desire to produce prodigiously incomprehensible programming!
Using the methodology I laid out above, where I could still search for
the base A character, sure.
I'm going to lavish on the unicode for this
example, so those of you
properly unequipped may not see this example:
foo := ???? ?? ? ??????
???? ?? ? ???????
printf(??? ?????? ?? ? ????
???? ????????, foo) if ????
?? ? ?????? ??????
??????? foo == ???? ??
???? ? ??????, ??? ???
??? ???? ??? { ???? ??
???? ? ??????? ...
It works for me. :-)
Aside: I tried to subscribe additional addresses to see both the MIME
and plain text digest. But I'm waiting on moderator approval. :-/
An atrocious example, but a good demonstration of my
point. If I had a
toggle switch on my keyboard to switch between code, comment and string,
it would have been much simpler to construct too!
Agreed.
I don't deny that they exist, but there are no
significant applications
being developed with them.
:-/
I'm not sure how VB puts things together behind
the scenes. The example
I am more familiar with is HyperCard, where instead of the UI existing
in the code, the code exists in the UI as you describe. This of course
violates all the religious tenets of Model-View-Controller design (for
the most part, dogmatic adherence to that pattern has mainly served to
give us government software projects that die as multi-trillion dollar
failures before seeing the light of day. I am of course being a bit
facetious, but not entirely). Back on topic, the tools exist, but they
are often seen as toys and not serious software development tools. Are
we at the point where the compiler for a visual programming language is
written in the visual programming language?
?\_(?)_/?
--
Grant. . . .
unix || die
1 Dec
1 Dec
10:46 a.m.
New subject: Text encoding Babel.
On 11/30/18 3:22 PM, Grant Taylor wrote:
Aside:? I suspect that none of the (plain-text /
non-MIME) digest
subscribers will see that properly.? I've found out from Mark S.,
Mailman's maintainer, that UTF-8 isn't maintained in the plain-text /
non-MIME digest.
If anyone cares (I did manage to get subscribed in time)?
The Unicode (and format=flowed line wrapping) survives the digesting
process for the MIME digest. The text digest corrupted Unicode (and
format=flowed).
I forgot how nice MIME digests could be. (Assuming your MUA understands
multipart/digest with message/rfc822 attachments.) ? I'm actually
replying to the digest attachment and it should get threaded with the
proper message.
--
Grant. . . .
unix || die
30 Nov
30 Nov
2:57 p.m.
It was thus said that the Great Keelan Lightfoot via cctalk once stated:
[ and further down the message ... ]
I see no
reason that we can't have new control codes to convey new
concepts if they are needed.
I disagree with this; from a usability standpoint, control codes are
problematic. Either the user needs to memorize them, or software needs
to inject them at the appropriate times. There's technical problems
too; when it comes to playing back a stream of characters, control
characters mean that it is impossible to just start listening. It is
difficult to fast forward and rewind in a file, because the only way
to determine the current state is to replay the file up to that point. I'm going to lavish on the unicode for this
example, so those of you
properly unequipped may not see this example:
foo := ???? ?? ? ?????? ???? ?? ? ???????
printf(??? ?????? ?? ? ???? ???? ????????, foo)
if ???? ?? ? ?????? ?????? ??????? foo ==
???? ?? ???? ? ??????, ??? ??? ??? ????
??? { ???? ?? ???? ? ???????
...
An atrocious example, but a good demonstration of my point. If I had a
toggle switch on my keyboard to switch between code, comment and
string, it would have been much simpler to construct too!
Somehow, the compiler will have to know that "???? ?? ? ??????" is a
string while "???? ?? ? ???????" is a comment to be ignored. You lamented
the lack of a toggle switch for the two, but existing langauges, like C,
already have them, '"' is the "toggle" for strings, while
'/*' and '*/' are
the toggles for comment (and now '//' if you are using C99). It's still
something you have to "type" (or "toggle" or "switch" or
somehow indicate
the mode).
The other issue is now such inforamtion is stored, and there, I only see
two solutions---in-band and out-of-band. In-band would be included with the
text. Something along the lines of (where <ESC> is the ASCII ESC character
27, and this is an example only):
foo := <ESC>_this is a string<ESC>\ <ESC>^this is a
comment<ESC>\
printf(<ESC>_the string is <ESC>[1p isn't that exciting<ESC>\,foo)
But this has a problem you noted above---it's a lot harder to seek through
the file to arbitrary positions. Grant Taylor stated another way of doing
this:
What if there were (functionally) additional bits that
indicated various
other (what I was calling) stylings?
I think that something along those lines could help avoid a concern I
have. Namely how do search for an A, what ever ""style it's in. I
think I could hypothetically search for bytes ~> words (characters)
containing (xxxxxxxx xxxxxxxx) (xxxxxxxx) 01x00001 (assuming that the
proceeding don't cares are set appropriately) and find any format of A,
upper case, lower case, bold, italic, underline, strike through, etc.
There are several problems with this. One, how many bits do you set aside
per character? 8? 16? There are potentially an open ended set of stylings
that one might use. Second problem---where do you store such bits? Not to
imply this is a bad idea, just that there are issues that need to be
resolved with how things are done today (how does this interact with UTF-8
for instance? Or UCS-4?).
Then there's out-of-band storage, which stores such information outside the
text (an example---I'm not saying this is the only way to store such
information out-of-band):
foo := this is a string this is a comment
printf(the string is 1 isn't that exciting,foo)
---
string 8-23
string 50-63
string 65-84
replacement 64
comment 25-41
This has its own problems---namely, how to you keep the two together. It
will either be a separate file, which could get separated, or part of the
text file but then you run into the problem of reading Microsoft Word files
cira 1986 with today's tools.
-spc (I like the ideas, but the implementations are harder than it first
appears ... )
3:11 p.m.
On 11/30/2018 03:57 PM, Sean Conner via cctalk wrote:
There are several problems with this. One, how many
bits do you set
aside per character? 8? 16? There are potentially an open ended set
of stylings that one might use.
I acknowledge that the idea I shared was incomplete and likely has
shortcomings. But I do think that it demonstrates a concept, which is
what I was after.
Second problem---where do you store such bits? Not to
imply this is a
bad idea, just that there are issues that need to be resolved with how
things are done today (how does this interact with UTF-8 for instance?
Or UCS-4?).
Ideally, I'd like to see UTF-8 / UTF-16 code points (?) for the
different styles of a letter. Not every letter (character ~> byte /
double) needs the styling. So I suspect that it would be better to
judiciously place code points in the UTF-8 / UTF-16 space.
Sadly, when I try to search for "this", the letters aren't found in
"???? ?? ? ??????" or "???? ?? ? ???????".
Something that I think should work.
Also, storage of these letters can work just like it is in this email. ;-)
--
Grant. . . .
unix || die
27 Nov
27 Nov
8:11 p.m.
It was thus said that the Great Keelan Lightfoot via cctalk once stated:
I'm a bit dense for weighing in on this as my
first post, but what the heck.
Our problem isn't ASCII or Unicode, our problem is how we use computers.
Going back in time a bit, the first keyboards only recorded letters
and spaces, even line breaks required manual intervention. As things
developed, we upgraded our input capabilities a little bit (return
keys! delete keys! arrow keys!), but then, some time before graphical
displays came along, we stopped upgrading. We stopped increasing the
capabilities of our input, and instead focused on kludges to make them
do more. We created markup languages, modifier keys, and page
description languages, all because our input devices and display
devices lacked the ability to comprehend anything more than letters.
Now we're in a position where we have computers with rich displays
bolted to a keyboard that has remained unchanged for 150 years.
Do you have anything in particular in mind?
Unpopular opinion time: Markup languages are a kludge,
relying on
plain text to describe higher level concepts. TeX has held us back.
It's a crutch so religiously embraced by the people that make our
software that the concept of markup has come to be accepted "the way".
I worked with some university students recently, who wasted a
ridiculous amount of time learning to use LaTeX to document their
projects. Many of them didn't even know that page layout software
existed, they thought there was this broad valley in capabilities with
TeX on one side, and Microsoft Word on the other. They didn't realize
that there is a whole world of purpose built tools in between. Rather
than working on developing and furthering our input capabilities,
we've been focused on keeping them the same. Markup languages aren't
the solution. They are a clumsy bridge between 150 year old input
technology and modern display capabilities.
Bold or italic or underlined text shouldn't be a second class concept,
they have meaning that can be lost when text is conveyed in
circa-1868-plain-text.
But I can still load and read circa-1968-plain-text files without issue,
on a computer that didn't even exist at the time, using tools that didn't
exist at the time. The same can't be said for a circa-1988-Microsoft-word
file. It requires either the software of the time, or specialized software
that understands the format.
I've read many letters that predate the
invention of the typewriter, emphasis is often conveyed using
underlines or darkened letters. We've drawn this arbitrary line in the
sand, where only letters that can be typed on a typewriter are "text",
Everything else is fluff that has been arbitrarily decided to convey
no meaning. I think it's a safe argument to make that the primary
reason we've painted ourselves into this unexpressive corner is
because of a dogged insistence that we cling to the keyboard.
There were conventions developed for typewriters to get around this.
Underlining text indicated italicized text (if the typewriter didn't have
the capability---some did).
In fact, typewriters have more flexibility than computers do even today.
Within the restriction of a typewriter (only characters and spaces) you
could use the back-space key (which did not erase the previous
character) and re-type the same character to get a bold effect. You could
back-space and hit the underscore to get underlined text. You could
back-space and hit the ` key to get a grave accent, and the ' to get an
acute accent. With a bit more fiddling with the back-space and adjusting
the paper via the platten, you could get umlauts (either via the . or '
keys).
I think the original intent of the BS control character in ASCII was to
facilitate this behavior, but alas, nothing ever did. Shame, it's a neat
concept.
I like the C comment example; Why do I need to call
out a comment with
a special sequence of letters? Why can't a comment exist as a comment?
The smart-ass answer is "because the compiler only looks at a stream of
text and needs a special marker" but I get the deeper question---is a plain
text file the only way to program?
No. There are other ways. There are many attempts at so-called "visual
languages" but none of them have been used to any real extent. Yes, there
are languages like Visual Basic or Smalltalk, but even with those, you still
type text for the computer to run.
The only really alternative programming language I know of is Excel.
Seriously. That's about the closest thing you get to a comment existing as
a comment without special markers, because you don't include those as part
of the program (specifically, you will exclude those cells from the
computation least you get an error).
Why is a comment a second class concept? When I take
notes in the
margin, I don't explicitly need to call them out as notes. This
extends to strings, why do I need to use quotes? I know it's a string
why can't the computer remember that too?
Actually, this reminds me of another "really out there" language---Color
Forth. Symbols, constants, codes, strings, don't have special characters to
designate them, but *color*. It's an interesting concept but that too, has
its downsides (especially relevant to color-blind or even the truly blind
programmers).
Why do I have to use the
capabilities of a typewriter to describe that to the computer? There
seems to be confusion that computers are inherently text based. They
are only that way because we program them and use them that way, and
because we've done it the same way since the day of the teletype, and
it's _how it's done._
"Classic" Macs are a great example of breaking this pattern. There was
no way to force the computer into a text mode of operating, it didn't
exist. Right down to the core the operating system was graphical. When
you click an icon, the computer doesn't issue a text command, it
doesn't call a function by name, it merely alters the flow of some
binary stuff flowing through the CPU in response to some other bits
changing. Yes, the program describing that was written in text, but
that text is not what the computer is interpreting.
The computer is still interpreting [1], but it's not text. It's
interpreting a spatial location with an action (mouse button press) to do
something (I cop to this being a semantic slight-of-hand---sorry).
I'm getting a bit philosophical, so I'll shut
up now, but it's an
interesting discussion.
-spc (I'll agree to that)
[1] In fact, it's interpreters all the way down. The CPU is
interpreting instructions from memory ...
8:27 p.m.
On Tue, 27 Nov 2018, Sean Conner via cctalk wrote:
It was thus said that the Great Keelan Lightfoot via
cctalk once stated:
In fact, typewriters have more flexibility than
computers do even today.
Within the restriction of a typewriter (only characters and spaces) you
could use the back-space key (which did not erase the previous
character) and re-type the same character to get a bold effect. You could
back-space and hit the underscore to get underlined text. You could
back-space and hit the ` key to get a grave accent, and the ' to get an
acute accent. With a bit more fiddling with the back-space and adjusting
the paper via the platten, you could get umlauts (either via the . or '
keys).
But, doing superscripts required a steady hand.
Hence, half a century ago, many physicists changed
6.02 x 10[superscript]23 into
6.02 E 23
I think the original intent of the BS control
character in ASCII was to
facilitate this behavior, but alas, nothing ever did. Shame, it's a neat
concept.
There was word processing software around 1980 that would do underlining
wither through backspacing, or through Carriage Return WITHOUT Linefeed.
also bold, overstrike, slashed zeroes, etc.
> I like the C comment example; Why do I need to call out a comment with
> a special sequence of letters? Why can't a comment exist as a comment?
Why not a language even more self-documenting than COBOL, wherein the main
body is text, and special markers to identify the CODE that corresponds?
9:50 p.m.
It was thus said that the Great Fred Cisin via cctalk once stated:
In the book _Programmers at Work_ there's a picture of a program Jef
Raskin [1] wrote that basically embeds BASIC into a word processor document.
-spc
[1] He started the Macintosh project at Apple. It was later taken over
by Steve Jobs and taken in a different direction.
>I like the C comment example; Why do I need to
call out a comment with
>a special sequence of letters? Why can't a comment exist as a comment?
Why not a language even more self-documenting than COBOL, wherein the main
body is text, and special markers to identify the CODE that corresponds?
11:04 p.m.
> Why not a language even more self-documenting than
COBOL, wherein the main
> body is text, and special markers to identify the CODE that corresponds?
On
Wed, 28 Nov 2018, Sean Conner wrote:
In the book _Programmers at Work_ there's a
picture of a program Jef
Raskin [1] wrote that basically embeds BASIC into a word processor document.
[1] He started the Macintosh project at Apple. It was later taken over
by Steve Jobs and taken in a different direction.
He also created the Canon Cat.
His idea of a user interface included that the program should KNOW
(assume) what the user wanted to do.
I showed him WHY the OS shouldn't go ahead (without asking for
confirmation!) and format a disk that it couldn't read. I do not know
whether that change got made before commercial release.
(The Cat, incidentally, was SS 512 bytes per sector, with 10 sectors per
track. Sometimes described as 256K (because use was primarily for
imaging 256K of RAM), but sometimes [more accurately] as 384K)
Before his death, I almost ended up with his electric van (Subaru 600
based). There was not enough computational capability in it for that to
be on-topic here.
28 Nov
28 Nov
3:58 a.m.
On Wed, 28 Nov 2018 at 08:05, Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
He also created the Canon Cat.
His idea of a user interface included that the program should KNOW
(assume) what the user wanted to do.
One of my heroes.
I've never used a Cat or his other software UIs, but the demos I've
seen are enough to make me wonder at how much we have lost already,
and secondarily, if it would be possible to code up a Raskin-style
editor in Emacs.
It's about the only editor I know that's smart enough and programmable
enough. Unfortunately, I also find it horrible to use and don't know
how to do this.
--
Liam Proven - Profile: https://about.me/liamproven
Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
1:34 p.m.
Some computing economics history:
I'm an engineer and scientist by both education and experience, and one
major difference between the disciplines is that engineers are required to
pass coursework and demonstrate proficiency in economics. That's because
we need to deliver things that actually do what customers think they paid
for within strict budgets and schedules, or we go hungry. Scientists, on
the other hand, if they can accurately predict what it will cost to prove a
theory, aren't practicing science, because they have to already know the
outcome and are taking no risk. A theoretically "superior" encoding may
not see practical use by a significant number of people because of legacy
inertia that often makes no sense, but is rooted in cultural, sociological,
emotional, and other factors, including economics.
Dvorak computer keyboards are allegedly far more efficient
speed/accuracy-wise than QWERTY computer keyboards, so they should rule the
computing world, but they don't. Keyboards that reduce the risk of
repetitive stress injuries (e.g., carpal tunnel syndrome) should dominate
the market for very sensible health reasons, but they don't, either.
Legacy inertia is a beyotch to overcome, especially when
international-level manufacturers and investors have a strong
interest making lots of money from the status quo. Logic and reasoning are
simply nowhere near enough to create the conditions necessary for
widespread adoption - sometimes it's just good luck in timing (or, bad
luck, as the case may be).
ASCII was developed in an age when Teletypes and similar devices were the
only textual I/O options, with fixed-width/size/style typefaces (font
family is an attribute of a typeface - there's no such thing as a "font").
By the late 1950s, there were around 250 computer manufacturers, and none
of their products were interoperable in any form. Until the IBM 360 was
released in 1965, IBM had 14 product _lines_ that were incompatible with
each other, despite having 20,000+ very capable scientists and engineers on
their payroll.
You can't blame the ASCII developers for lack of foresight when no one in
their right mind back then would have ever predicted we could have upwards
of a trillion bytes of memory in our pockets (e.g., the Samsung Note 9),
much less multi-megapixel touch displays with millions of colors, with
worldwide-reaching cellular/Internet access with milliseconds of round-trip
response, etc.
Someone thinking that they're going to make oodles of money from some
supposedly new-and-improved proprietary encoding "standard" that discards
five-plus decades of legacy intellectual and economic investment, is
pursuing a fool's errand. Even companies with resources at the level of
Apple, Google, Microsoft, etc., aren't that arrogant, and they've
demonstrated some pretty heavy-duty chutzpah over time. BTW, you won't be
able to patent what apparently amounts to a lookup table, and even if you
copyright it, it will be a simple matter of developing
functionally-equivalent code that performs a translation on-the-fly. See
also the clever schemes where DVD encryption keys, that had been left on an
unprotected server accessible via the Internet, were transformed into prime
numbers that didn't infringe on the copyrights associated with the keys.
True standards are open nowadays - the days of proprietary "standards" are
a couple of decades behind us - even Microsoft has been publishing the
binary structure of their Office document file formats. The specification
for Word, that includes everything going back to v 1.0, is humongous, and
even they were having fits trying to maintain the total spec, which is
reportedly why they went with XML to create the .docx, .xlsx, .pptx, etc.,
formats. That also happened to make it possible to placate governments
(not to mention customers) that are looking for any hint of
anti-competitive behavior, and thus also made it easier for projects such
as OpenOffice and LibreOffice to flourish.
Typographical bigots, who are more interested in style than content, were
safely fenced off in the back rooms of publishing houses and printing
plants until Apple released the hounds on an unsuspecting public. I'm
actually surprised that the style purists haven't forced Smell-o-Vision
technology on The Rest of Us to ensure that the musty smell of old books is
part of every reading "experience" (I can't stand the current common use of
that word). At least I have the software chops to transform the visual
trash that passes for "style" these days into something pleasing to _my_
eyes (see what I did there with "severely-flawed" ASCII? Here's how you
can do /italics/ and !bold! BTW.).
Nothing frosts me more than reading text that can't be resized and
auto-reflowed, especially on mobile devices with extremely limited display
real estate. I'm fully able-bodied and I'm perturbed by such bad design,
so, I'm pretty sure that pages that prevent pinch-zooming, and that don't
allow for direct on-display text resizing/auto-reflow, violate the spirit
completely, if not virtually all of the letters, of the Americans with
Disabilities Act (and similar legislation outside the U.S., I imagine).
Your mileage may vary, objects in mirror are closer than they appear, do
not spindle, fold, or mutilate, do not expose to fire or flame, batteries
not included, and all of the other legalese disclaimer garbage may
apply that lawyers produce, who aren't being kept busy enough looking out
for widows and orphans, which should be their full-time vocation.
Soapbox hereby happily relinquished to the next blowhard ...
27 Nov
27 Nov
9:59 p.m.
On 11/27/2018 9:11 PM, Sean Conner via cctalk wrote
But I can still load and read circa-1968-plain-text files without issue,
on a computer that didn't even exist at the time, using tools that didn't
exist at the time. The same can't be said for a circa-1988-Microsoft-word
file. It requires either the software of the time, or specialized software
that understands the format.
But where do find the 1968 plain text files?
Right now I am looking for free online books on computers
and computer science books in the 1971 to 1977 year range.
a fictional example "HAL 9000 programing" AI BOOTSTRAPPING WITH A LISP
1st edition. Useful knowledge for back then. "HAL 9000 programing"
HOW the AI BOOTSTRAPS windows 1000 in HOT JAVA 2001 edition. No so
useful for historic knowledge.
Looking to write a simple integer language as I have no floating point
yet on 1973-1974 ish paper computer design. And yes it is 18 bits and
TTL. Right now I am programing in C for what little quick and dirty
software I have written and digging around for ideas.
It would be nice if bitsavers could have the old 1st edition books.
The latest may sell but old knowledge is being lost.
Ben.
28 Nov
28 Nov
4:32 a.m.
On Tue, 27 Nov 2018 at 20:47, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
I don't think that HTML can reproduce fixed page layout like PostScript
and PDF can. It can make a close approximation. But I don't think HTML
can get there. Nor do I think it should.
There are a wider panoply of options to consider.
For instance, Display Postscript, and come to that, arguably, NeWS.
Also, modern document-specific markups. I work in DocBook XML, which I
dislike intensely.
There's also, at another extreme, AsciiDoc (and Markdown (in various
"flavours")), Restructured Text, and similar "lightweight" MLs:
http://hyperpolyglot.org/lightweight-markup
But there are, of course, rivals. DITA is also widely-used.
And of course there are things like LyX/LaTeX/TeX, which some find
readable. I am not one of them. But I get paid to do Docbook, I don't
get paid to do TeX.
Neal Stephenson's highly enjoyable novel /Seveneves/ contains some
interesting speculations on the future of the Roman alphabet and what
close contact with Cyrillic over a period will do to it.
Aside:
[[
I'm not personally aware of any cases where ASCII
limits programming
languages. But my ignorance does not preclude that situation from existing.
APL and ColorForth, as others have pointed out.
I have long wondered if there are computer languages
that aren't rooted
in English / ASCII.
https://en.wikipedia.org/wiki/Qalb_(programming_language)
More generally:
https://en.wikipedia.org/wiki/Non-English-based_programming_languages
Personally I am more interested in non-*textual* programming
languages. A trivial candidate is Scratch:
https://scratch.mit.edu/
But ones that entirely subvert the model of using linear files
containing characters that are sequentially interpreted are more
interesting to me. I blogged about one family I just discovered last
week:
https://liam-on-linux.livejournal.com/60054.html
The videos are more or less _necessary_ here, because trying to
describe this in text will fail _badly_. Well worth a couple of hours
of anyone's time.
]]
Anyway. To return to text encodings.
Again I wish to refer to a novel; to Kim Stanley Robinson's "Mars
trilogy", /Red Mars/, /Green Mars/ and /Blue Mars/. Or as a friend
called them, "RGB Mars" or even "Technicolor Mars".
A character presents an argument that if you try to summarise many
things on a scale -- e.g. for text encodings, from simplicity and
readability, to complexity and capability -- you can't encapsulate any
sophisticated system.
He urges a 4-cornered system, using the example of the "four humours":
phlegm, bile, choler and sang. The opposed corners of the diagram are
as important as the sides of the square; characteristics form the
corners, but the intersections between them are what defines us.
So. There is more than one scale here.
At one extreme, we could have the simplest possible text encoding.
Something like Morse code or Braille, which omits almost all "syntax"
-- almost no punctuation, no carriage returns or anything like that,
which are _metadata_, they are information about how to display the
content, not content themselves. Not even case is encoded: no
capitals, no minuscule letters. But of course a number of alphabets
don't have that distinction, and it's not essential in the Roman
alphabet.
Slightly richer, but littered with historical baggage from its origins
in teletypes: ASCII.
Much richer, but still not rich enough for all the
Roman-alphabet-using-languages: ANSI.
Insanely rich, but still not rich enough for all the written
languages: Unicode. (What plane? What encoding? What version, even?)
At the other extreme, markup languages that either weren't really
intended for humans but often are written by them -- e.g. the SGML/XML
family -- or are only usable by relatively few humans -- e.g. the TeX
family -- or that are almost never used by humans, e.g. PostScript, or
HP PCL.
And what I find a fairly happy medium -- AsciiDoc, say. Perfectly
readable by untrained people as plain ASCII, can be written with mere
hours of study, if that, but also can be processed and rendered into
something much prettier.
The richer the encoding, the harder it is for *humans* to read, and
the more complex the software to handle it needs to be.
So, yes, ASCII is perhaps too minimal. ANSI is just a superset.
But I'd argue that there _should_ be a separation between at least 2,
maybe 3 levels, and arguably more.
#1 Plain text encoding. Ideally able to handle all the characters in
all forms of the Latin alphabet, and single-byte based. Drop ASCII
legacy baggage such as backspace, bell, etc.
#2 Richer text, with simple markup, but human-readable and
human-writable without needing much skill or knowledge. Along the
lines of Markdown or *traditional* /email/ _formatting_ perhaps.
#3 Formatted text, with embedded control codes. The Oberon OS does this.
#4 Full 1980s word-processor-style document, with control codes,
formatting, font and page layout features, etc.
#5 Number 4, plus embedded objects, graphics. I'm thinking PDF or the
like as my model.
Try to collapse all these into one and you're doomed.
--
Liam Proven - Profile: https://about.me/liamproven
Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
1983
days inactive
1987
days old
29 comments
14 participants
participants (14)
-
bfranchuk＠jetnet.ab.ca -
captainkirk359＠gmail.com -
cclist＠sydex.com -
cctalk＠gtaylor.tnetconsulting.net -
cisin＠xenosoft.com -
guykd＠optusnet.com.au -
jim.manley＠gmail.com -
keelanlightfoot＠gmail.com -
lproven＠gmail.com -
paulkoning＠comcast.net -
spc＠conman.org -
spectre＠floodgap.com -
toby＠telegraphics.com.au -
wdonzelli＠gmail.com