<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
You know, I'm kind of surprised I've never seen a programming language
(that uses different fonts for different purposes. Something like
boldface for reserved words, italics for built-ins, so you could do
something like<br>
<br>
<b>foreach</b> index <b>in </b>mylist <b>do </b>item +=
<i>length</i>(mylist[index])<br>
<br>
or something like that. Then you could use things like "in" and "do" as
variable names as well. :-)<br>
<pre class="moz-signature" cols="72">-- 
Darren New / San Diego, CA, USA (PST)
</pre>
</body>
</html>

Post a reply to this message

On 17-Oct-08 21:06, Darren New wrote:
> You know, I'm kind of surprised I've never seen a programming language 
> (that uses different fonts for different purposes. Something like 
> boldface for reserved words, italics for built-ins, so you could do 
> something like
> 
> *foreach* index *in *mylist *do *item += /length/(mylist[index])
> 
> or something like that. Then you could use things like "in" and "do" as 
> variable names as well. :-)
> 

Yes, but that would imply that the set of reserved words is static. Hmm, 
am I suffering from deja vu?

Post a reply to this message

andrel wrote:
> Yes, but that would imply that the set of reserved words is static. 

No. It would imply anything in bold is a reserved word while anything in 
regular font isn't.  Kind of like using different alphabets/fonts in 
math to distinguish the variable "R" from the symbol meaning "Real numbers".

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New escreveu:
> You know, I'm kind of surprised I've never seen a programming language 
> (that uses different fonts for different purposes. Something like 
> boldface for reserved words, italics for built-ins, so you could do 
> something like
> 
> *foreach* index *in *mylist *do *item += /length/(mylist[index])
> 
> or something like that. Then you could use things like "in" and "do" as 
> variable names as well. :-)
> 
> -- 
> Darren New / San Diego, CA, USA (PST)
> 

That would utterly suck.  Programming languages should be about meaning 
and meaning is conveyed by words, not by how they are drawn or spelled.

Let external tools do any styling to the source text if you will.

Post a reply to this message

On 17-Oct-08 22:10, nemesis wrote:
> Darren New escreveu:
>> You know, I'm kind of surprised I've never seen a programming language 
>> (that uses different fonts for different purposes. Something like 
>> boldface for reserved words, italics for built-ins, so you could do 
>> something like
>>
>> *foreach* index *in *mylist *do *item += /length/(mylist[index])
>>
>> or something like that. Then you could use things like "in" and "do" 
>> as variable names as well. :-)
>>
>> -- 
>> Darren New / San Diego, CA, USA (PST)
>>
> 
> That would utterly suck.  Programming languages should be about meaning 
> and meaning is conveyed by words, not by how they are drawn or spelled.
> 
http://compsoc.dur.ac.uk/whitespace/
http://www.dangermouse.net/esoteric/piet.html
http://www.ni.com/labview/
.
.
.

> Let external tools do any styling to the source text if you will.

Post a reply to this message

andrel escreveu:
> On 17-Oct-08 22:10, nemesis wrote:
>> Darren New escreveu:
>>> You know, I'm kind of surprised I've never seen a programming 
>>> language (that uses different fonts for different purposes. Something 
>>> like boldface for reserved words, italics for built-ins, so you could 
>>> do something like
>>>
>>> *foreach* index *in *mylist *do *item += /length/(mylist[index])
>>>
>>> or something like that. Then you could use things like "in" and "do" 
>>> as variable names as well. :-)
>>>
>>> -- 
>>> Darren New / San Diego, CA, USA (PST)
>>>
>>
>> That would utterly suck.  Programming languages should be about 
>> meaning and meaning is conveyed by words, not by how they are drawn or 
>> spelled.
>>
> http://compsoc.dur.ac.uk/whitespace/
> http://www.dangermouse.net/esoteric/piet.html
> http://www.ni.com/labview/

Yeah, if you want a Turing Complete toy or brainfuck...

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> http://www.dangermouse.net/esoteric/piet.html

  Speaking of esoteric languages, I like the basic idea behind befunge, but
I hate its actual implementation.

  The execution of the program following the 2D arrangement of the command
characters is a clever idea, and could result in very interesting programming
challenges. However, the actual implementation of befunge sucks because it's
way too limited. It's almost impossibly hard to have actual *variables* and,
AFAIK, basically impossible to access anything but the value at the top of
the value stack. This makes writing even simple programs, such as for example
an ascii mandelbrot drawing program, incredibly difficult.

  IMO befunge's clever idea was ruined by a poor implementation, which has
a way too limited set of commands.

  Befunge's idea with a much more powerful and expressive set of commands
could be actually very interesting.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> andrel <a_l### [at] hotmailcom> wrote:
>> http://www.dangermouse.net/esoteric/piet.html
 >
> It's almost impossibly hard to have actual *variables* and,
> AFAIK, basically impossible to access anything but the value at the top of
> the value stack. This makes writing even simple programs, such as for example
> an ascii mandelbrot drawing program, incredibly difficult.

I thought the point of such languages was in overcoming such 
difficulties per se rather than actually writing useful programs...

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote in message
news:48f8f145$1@news.povray.org...

> That would utterly suck.  Programming languages should be about meaning
> and meaning is conveyed by words, not by how they are drawn or spelled.

Meaning is conveyed by anything that is meant to convey meaning, be it
words, grunts, connections between gears, flowcharts, hearldry symbols,
colours... etc. Pictorial representations will eventually assume a more
prominant role in general programming. Software audio synthesizers, CAD
histories, UML.. etc already use flowchart style, graphical representations
and are none the less rigorous for it.

Post a reply to this message

nemesis wrote:
> That would utterly suck.  Programming languages should be about meaning
 
> and meaning is conveyed by words, not by how they are drawn or spelled.


Meaning isn't conveyed by words in programming languages. It's conveyed 
by tokens and formal matches between tokens at different parts of the 
source.

{ int index = 23;
   cout << index;
}

The meaning there isn't conveyed by "int". In chinese, you might use 
something different than "int" (maybe 整數 or something) an
d it would be 
just as meaningful if not moreso to a native chinese speaker (assuming 
you fixed the compiler, of course).  The compiler doesn't care what 
token you use to mean what Warp means by "int" in his code.

The word "index" doesn't provide any meaning, and the program would work 

identically if both instances of the word "index" were changed to the 
word "age". The compiler doesn't care what you name your variables.

The text doesn't mean anything per se to the compiler. Only the 
relationship of one part of the text to other parts of the text.

> Let external tools do any styling to the source text if you will.

OK, so reserved words are in greek, and user-defined words are in latin 
characters, no matter what fonts you use. Better? If so, why? If not, 
why not?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> nemesis wrote:
>> That would utterly suck.  Programming languages should be about 
>> meaning and meaning is conveyed by words, not by how they are drawn or 
>> spelled.
> 
> Meaning isn't conveyed by words in programming languages. It's conveyed 
> by tokens and formal matches between tokens at different parts of the 
> source.
> 
> { int index = 23;
>   cout << index;
> }
> 
> The meaning there isn't conveyed by "int". In chinese, you might use 
> something different than "int" (maybe 整數 or something) and it would be 
> just as meaningful if not moreso to a native chinese speaker (assuming 
> you fixed the compiler, of course).  The compiler doesn't care what 
> token you use to mean what Warp means by "int" in his code.

Fine.  整數 is still a word with a meaning associated, which is my 
point:  words should convey meaning, not how 整數 is written or spelled.

I mean, surely 整數 can be written in italics or bold without altering 
its meaning.  And no, I'm not a fan of case-sensitive syntax either.

>> Let external tools do any styling to the source text if you will.
> 
> OK, so reserved words are in greek, and user-defined words are in latin 
> characters, no matter what fonts you use. Better?

Yes.  You may use whatever font you please, as long as it's Unicode and 
can correctly display the greek and latin words in the text or else the 
meaning is lost.  This is not the same as styling with bold or italics, 
nor as capitalizing words.

Post a reply to this message

somebody wrote:
> "nemesis" <nam### [at] gmailcom> wrote in message
> news:48f8f145$1@news.povray.org...
> 
>> That would utterly suck.  Programming languages should be about meaning
>> and meaning is conveyed by words, not by how they are drawn or spelled.
> 
> Meaning is conveyed by anything that is meant to convey meaning, be it
> words, grunts, connections between gears, flowcharts, hearldry symbols,
> colours... etc.

You know?  That's very true.  And I can even imagine a tokenizer to a 
compiler accepting italicized words to be different from non-italicized 
words if it was to internally apply some transform like:

*Foo* /foo/;

bold_foo -> italic_foo ->

etc.

To me, it just sucks, though.  It means, when I'm writing a program I 
have now to think not only of good identifier names, but also of 
correctly applying the right styling, besides also capitalization.

> Pictorial representations will eventually assume a more
> prominant role in general programming.

Sure, UML and company have been around for quite some time already.  And 
it all eventually gets converted to a stream of text in some language 
anyway, and that to a stream of bytes in machine language, so hey!, 
perhaps it's time we communicate using just jpgs and emoticons as well... :P

I for one find some things much easier to write about than to drag 
balloons, boxes and arrows around and apply meaning by combos, 
radiobuttons and so on, besides messing with a UI looking like that of a 
top aircraft...

BTW, perhaps you'd be interested in this nutjob and his take on the 
future of computers and programming:
http://rebelscience.blogspot.com/2008/09/cosa-new-kind-of-programming-part-i.html

I still find much simpler writing a textual while loop though... :P

Post a reply to this message

nemesis wrote:
> I mean, surely 整數 can be written in italics or bold wit
hout altering 
> its meaning.  

Again, it depends on the field of study.  "R" is a variable. Bold-face R 

means the set of real numbers, in mathematical notation.

> And no, I'm not a fan of case-sensitive syntax either. 

And capital delta and lower-case delta mean two different things in 
math, too.

> Yes.  You may use whatever font you please, 

You've yet to actually provide a reason for your disagreement.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > I mean, surely 整數 can be written in italics or bold wit
> hout altering
> > its meaning.
>
> Again, it depends on the field of study.  "R" is a variable. Bold-face R
>
> means the set of real numbers, in mathematical notation.

Nice try, but in one given program it means one and only one thing.

> > And no, I'm not a fan of case-sensitive syntax either.
>
> And capital delta and lower-case delta mean two different things in
> math, too.

We're not talking about math, we're talking about a program, possibly a domain
specific one with its own business rules and meanings.

> > Yes.  You may use whatever font you please,
>
> You've yet to actually provide a reason for your disagreement.

I thought I was clear enough.  I consider "foobar", *foobar*, /foobar/, Foobar,
FooBar, FOOBAR to be all the same.  It's still a foobar like any other...

yes, I know C++ users will say FOOBAR is a constant, Foobar or FooBar a class
and foobar an instance of such class.  Baloney...

Post a reply to this message

nemesis wrote:
>> Again, it depends on the field of study.  "R" is a variable. Bold-face
 R
>> means the set of real numbers, in mathematical notation.

> Nice try, but in one given program it means one and only one thing.

You assert this without justification.

>>> And no, I'm not a fan of case-sensitive syntax either.
>> And capital delta and lower-case delta mean two different things in
>> math, too.
> 
> We're not talking about math, we're talking about a program, possibly a
 domain
> specific one with its own business rules and meanings.

Yes? You don't understand hypotheticals?

>>> Yes.  You may use whatever font you please,
>> You've yet to actually provide a reason for your disagreement.
> 
> I thought I was clear enough.  I consider "foobar", *foobar*, /foobar/,
 Foobar,
> FooBar, FOOBAR to be all the same.  It's still a foobar like any other.
..

You assert this without justification.

Maybe you mean that you simply disagree with the merit of the idea. 
That's fine. But you phrase it as if there's actually a good reason why 
the idea needn't be considered other than your personal preference.

You say "surely 整數 can be written in italics or bold with
out altering 
its meaning."  I'm disagreeing that it is as sure as you say, but your 
justification seems to be "saying the same thing louder". :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > I thought I was clear enough.  I consider "foobar", *foobar*, /foobar/,
>  Foobar,
> > FooBar, FOOBAR to be all the same.  It's still a foobar like any other.
> ..
>
> You assert this without justification.
>
> Maybe you mean that you simply disagree with the merit of the idea.

Yes.  I can certainly see the value of having different identifiers binded to
the same word under different graphisms, from a practical standpoint, but still
do not agree with it.

> That's fine. But you phrase it as if there's actually a good reason why
> the idea needn't be considered other than your personal preference.

It's not mine alone.  The Pascal and Lisp languages have long supported this
notion.

Besides, case-sensitiveness is already bad enough, but at least most editors
support it.  I'm guessing your proposal would not play nice with notepad
folks...

Post a reply to this message

nemesis wrote:
> I'm guessing your proposal would not play nice with notepad folks...

Less a proposal than a thought thrown out to look over, yes.  And you'd 
definitely not be writing it in notepad, unless you used wordstar or 
html conventions or something. (I.e., embedded markers, like <b>int</b> 
or embedded control characters or something.)

APL, after all, used greek letters (mostly) for built-in functions 
(along with things like a proper division sign), and ascii for 
user-defined variables and functions, and with the appropriate 
infrastructure (such as keyboards with the characters printed on them) 
it really wasn't a problem as such. You couldn't read the program on a 
terminal that didn't have the right character sets, of course, but 
that's hardly a problem nowadays.

And of course 8-bit BASIC interpreters did something similar internally, 
but decoded it into text for display.

But yeah, it doesn't seem like there's a particular technological 
benefit to trying that.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

nemesis wrote:
> BTW, perhaps you'd be interested in this nutjob and his take on the 
> future of computers and programming:
> http://rebelscience.blogspot.com/2008/09/cosa-new-kind-of-programming-part-i.html 

I'd be much more interested in that if he'd actually written something 
larger than a quicksort. Or even a quicksort that would actually work in 
a generic sort of way, like with different types, or different size 
arrays, or whatever.

Too much handwaving while loudly proclaiming he's solved every problem.

He thinks hardware is very reliable, but he's clearly never worked at 
building hardware, where you ship off dozens of versions of chips, and 
when you're done, you use software to patch the bugs in the hardware 
design.  He also doesn't seem to realize that there are all kinds of 
timing problems in hardware, and that indeed solving the timing problems 
in "synchronous" hardware is a major part of the development effort.

He also thinks that hardware is more complex than software, but the 
reason people write software instead of building hardware is that much 
that software does is too complex to implement in hardware.

He also seems to think that the problems with making software work is 
problems with getting from detailed correct specs to software that 
implements those specs. Much more often, the specs on what a piece of 
software is to do is far more vague than what hardware is to do. Nobody 
starts building a chip before they decide what all the CPU instructions 
are going to be for sure. I'd also suspect it's pretty rare that 
hardware is designed in a way that's easy to upgrade - add-on floating 
point units would seem to be the most obvious example of what I mean, 
while every piece of software is meant to be "soft". Virtually nobody is 
happy with software that never changes once released, and for those who 
are (a la cell phones, microwave ovens, etc) it seems we manage a pretty 
good level of reliability.

He also seems to think that hardware doesn't have the same problems as 
software, yet http://www.opencores.org/ exists.

When he shows how you'd build an air traffic control system that's more 
reliable than what we have, or even a SQL RDBM server, using his system, 
I'll maybe start to worry about it. :-)



-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > BTW, perhaps you'd be interested in this nutjob and his take on the
> > future of computers and programming:
> > http://rebelscience.blogspot.com/2008/09/cosa-new-kind-of-programming-part-i.html
>
> I'd be much more interested in that if he'd actually written something
> larger than a quicksort. Or even a quicksort that would actually work in
> a generic sort of way, like with different types, or different size
> arrays, or whatever.
>
> Too much handwaving while loudly proclaiming he's solved every problem.

I think you devoted too much time to the guy's ideas.  He's a well-known,
long-time internet crackpot and he knows it:
http://rebelscience.blogspot.com/2007/10/who-am-i-what-are-my-credentials.html

Beware, he may be an online sentient being.  One day I innocently invoked his
name in comp.lang.lisp and he appeared all of a sudden!
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e0ee331cfe13f214/9f84e2cccc7c0269?lnk=gst&q=louis+sa
vain#9f84e2cccc7c0269

He may drop by here as well... :P

Post a reply to this message

nemesis wrote:
> I think you devoted too much time to the guy's ideas. 

It's hard to tell without looking. Anyway, he's just proposing "data 
flow" types of languages. Of course, he doesn't know that, since he 
never actually studied the field. :-)  They work great, until you need 
an algorithm.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > I think you devoted too much time to the guy's ideas.
>
> It's hard to tell without looking.

I specially enjoy reading him bashing physicists and astrophysics:
http://www.rebelscience.org/Crackpots/notorious.htm
http://groups.google.com/group/sci.physics/browse_thread/thread/2d91a6c420a0bcb0/3faf25bc7bdaa0de

I specially like this quote:
"It is a pity Dr. Sagan passed away because I liked him, crackpot or not."

fairly amusing. :)

Post a reply to this message

nemesis wrote:
> fairly amusing. :)

I didn't really look at anything beyond his computer stuff. I do like 
this one:

"This gem of pseudoscience comes from one of the most celebrated 
physicists of the twentieth century."

Um, and you, in calling him a crackpot, are obviously more celebrated? I 
mean, I'm not one of those who believes in Proof By Authority, but I'll 
take the word of "most celebrated physicists" over "never studied 
physics" any time. Especially when the celebrated results lead directly 
to the technology I have sitting in front of me.

"Second, dt/dt is always the same (1) regardless of the actual rate of 
velocity."  I'm pretty sure this isn't true, actually, is it?

Indeed, that whole page is silly. First he says you can't have a time 
dimension, because otherwise things wouldn't move. Then he says "people 
talk about time changing, but time doesn't change."  Well, yes. You're 
confusing two meanings of "time" there, and complaining that the popular 
meaning doesn't match the physics meaning. So?

Heh. "Time does not dilate (as if time could change!). On the contrary, 
it is the clocks that slow down (for whatever reason) resulting in 
longer measured intervals." Riiiight. He's another one of these 
crackpots who attempt proof by vigorous assertion.

""Time dilation" = process slowdown. There is no causal link between the 
two. They are equivalent."  Um, yes. Clearly he doesn't understand what 
is even meant by "time dialation".

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Heh. "Time does not dilate (as if time could change!). On the contrary, 
> it is the clocks that slow down (for whatever reason) resulting in 
> longer measured intervals." Riiiight. He's another one of these 
> crackpots who attempt proof by vigorous assertion.

A master troll indeed.  Such creatures are amusing in their natural 
habitat... :)

Post a reply to this message