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