 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<!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] hotmail com> 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
|
|
| |
| |
|
|
|
|
| |
