www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: why ; ?

reply bearophile <bearophileHUGS lycos.com> writes:
Janice Caron Wrote:

 Besides which, how would that work with statements like
     if (a == b) { ++i; ++j } else { --i; --j }
 If newlines were to take over the role of semicolons, then that would turn into
     if (a == b) { ++i
     ++j } else { --i
     --j }



You may want to take a look at Scala.
Your statement can be written like this, that is readable but needs many lines:

if (a == b) {
    ++i
    ++j
} else {
    --i
    --j
}

Or like this:

if (a == b) { ++i; ++j; } else { --i; --j; }

(Plus various other ways you can use today).
Both versions are okay, because ; becomes optional when it's at the end of the
line. And the symbols for line continuations are part of this proposal, I
presume.

If you want to remove the brackets too, you may end with:

if a == b:
    ++i
    ++j
else:
    --i
    --j

Bye,
bearophile
May 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
IMO, this whole thread is ridiculous since you're arguing about
something that amounts to just personal style. D was created by Walter
to be part of the C family of languages therefore D should continue to
use the style Walter chose.
Personally I prefer to use ; in my code but I won't join the argument
since it's just a matter of style and personal taste.

for all the python fans here - my suggestion would be to add a switch to
the compiler to parse D files written with a Python style. D would
officially use the current style but if someone wants he could use a
python style in his own code via the proposed switch. Official code
(standard library, code on digital mars, etc) will remain in the current
style.
This extension is very low priority IMHO.

--Yigal
May 08 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 08/05/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  but I won't join the argument



You just did. :-) The only way not to join the argument is not to post
your opinion, but alas you gave in to the temptation. :-)

You did hold out for a long time though.
May 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Janice Caron wrote:

 On 08/05/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  but I won't join the argument



 You just did. :-) The only way not to join the argument is not to post
 your opinion, but alas you gave in to the temptation. :-)
 
 You did hold out for a long time though.



All I stated is my preferred style without getting into the whole
argument which style is technically better. So you see, technically I
_didn't_ post my opinion so I didn't join the argument after all.

My firm belief on the subject is that you should always choose the best
tool for the job and that there are no absolutes. People who go for such
absolutes confirm the phrase: "When all you got is a hammer, everything
becomes a nail", which is to say that I don't think any one style is
absolutely always better than all the other alternatives.
Another factor to this debate is this -
http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis

--Yigal
May 08 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 08 May 2008 21:06:30 +0100, Yigal Chripun <yigal100 gmail.com>  
wrote:


 Janice Caron wrote:

 On 08/05/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  but I won't join the argument



 You just did. :-) The only way not to join the argument is not to post
 your opinion, but alas you gave in to the temptation. :-)

 You did hold out for a long time though.



 All I stated is my preferred style without getting into the whole
 argument which style is technically better. So you see, technically I
 _didn't_ post my opinion so I didn't join the argument after all.

 My firm belief on the subject is that you should always choose the best
 tool for the job and that there are no absolutes. People who go for such
 absolutes confirm the phrase: "When all you got is a hammer, everything
 becomes a nail", which is to say that I don't think any one style is
 absolutely always better than all the other alternatives.
 Another factor to this debate is this -
 http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis

 --Yigal



Maybe you just joined a different argument?
Anyway, times up! That will be five pounds please.
May 09 2008
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:fvvk5j$k56$1 digitalmars.com...

 IMO, this whole thread is ridiculous since you're arguing about
 something that amounts to just personal style.



I think it's been a very interesting discussion.

Yes, there is a lot that comes down to preference in the end, and yes, we 
have come up with some such things in this thread. But we can't just go 
around assuming that all opposing viewpoints are always equally valid, 
because a lot of times they just simply aren't.  Sometimes a clear "best 
practice" does emerge. Not by unanimous vote though, but by merit of the 
argument itself. For instance, everyone could agree 2+2=5, but that doesn't 
make it so, and by the same token, one rouge diehard "2+2=5" person doesn't 
turn "2+2=4" from a fact into an opinion or a preference.

And on the things that do turn out to be matters of preference, it's still 
interesting (my opinion) and potentially helpful/productive (which I submit 
as fact, but open for debate, of course) to see the pros and cons of each 
actually laid out for all to see.
May 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Nick Sabalausky wrote:

 I think it's been a very interesting discussion.
 
 Yes, there is a lot that comes down to preference in the end, and yes, we 
 have come up with some such things in this thread. But we can't just go 
 around assuming that all opposing viewpoints are always equally valid, 
 because a lot of times they just simply aren't.  Sometimes a clear "best 
 practice" does emerge. Not by unanimous vote though, but by merit of the 
 argument itself. For instance, everyone could agree 2+2=5, but that doesn't 
 make it so, and by the same token, one rouge diehard "2+2=5" person doesn't 
 turn "2+2=4" from a fact into an opinion or a preference.
 
 And on the things that do turn out to be matters of preference, it's still 
 interesting (my opinion) and potentially helpful/productive (which I submit 
 as fact, but open for debate, of course) to see the pros and cons of each 
 actually laid out for all to see. 
 



Where in my post did you read that I said "[we should] go around
assuming that all opposing viewpoints are always equally valid"? I know
what I wrote and that ain't it.

I said that this specific argument which I'm replying to is about
personal preferences/style only and is not a technical discussion
related to D and have stated my opinion that arguing about
_this_specific_subject_ is ridiculous. In the same way you could argue
that you prefer you code to be shown with red color and someone else
would argue that green is better. Colors do have pros and cons regarding
eye-sight but they don't make your red if statement any better than
Janice's green one from a code POV. Both will compile to the same
assembly code. therefore, unless you discuss the pros and cons of colors
to a programmer's sight, arguing whether red code is better than green
code is indeed ridiculous.

If you decide to discuss next which editor is better: vi[m] or emacs
(since as you say, this is "potentially helpful/productive" in your
opinion) than count me out since yet again this comes down to personal
preference.

--Yigal

PS: it's amazing how such smart people can waste so much time and energy
debating such unimportant issues as the semicolon at the end of
statements with such a passion.
May 08 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.



Where in my post did you read that I said "You said that we should go around 
assuming that all opposing viewpoints are always equally valid"? ;)

But you did say "this whole thread is ridiculous", even though we discussed 
other issues besides "semicolon-oriented language" vs. "newline-oriented 
language". If you really meant just the particular branch of the thread you 
replied to and not actually the whole thread, then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.



Sure. After all, nobody would say that you were obligated to participate. 
Feel free to pick and choose which discussions you wish to participate in. I 
do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.



One could make the same claim about meta-debates, such as this. (I'm not 
actually making that claim though. I don't personally mind the occasional 
meta-debate.)

Besides, I think it's good to periodically challenge, and be challenged by, 
each others viewpoints. This way we don't stagnate, isolated in the world of 
our own preferences, possibly even blind to the occasional mistaken 
assumption. For all I know, someone might say something that makes me think 
of Python in a new way and I decide "Wow, this is my new preference. I like 
Python better than D. If I had just agreed to disagree then my eyes never 
would have been opened to this."

As real-world examples, when I first started reading about Python, I had a 
knee-jerk reaction and decided "this is garbage, I'm not going near it", and 
that was that. But a couple weeks ago I was talking to a friend who liked 
Python, we disagreed, but still discussed, and I realized that Python did 
have some good functional-ish features - things that even my favorite 
language, D, could use to borrow. And I also came to the conclusion that it 
really wouldn't kill me, at the very least, to write a quck little 
prototype, script, etc., in Python every now and then. All this even though 
I still consider, for example, the rationale behind Python's indentation to 
be logically flawed and inappropriate for large projects. In much the same 
way, my friend ended up getting interested in D (To paraphrase: "Wow, a 
static typed, non-VM language without the muss and fuss of C/C++, who 
knew?").

If we had just decided "these are matters of preference, discussing it is 
ridiculous", and avoided what seemed like a pointless discussion, then where 
would we both be right now? Sitting in our own happy ignorance.
May 08 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:g003u3$1g02$1 digitalmars.com...

 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.



 Where in my post did you read that I said "You said that we should go 
 around assuming that all opposing viewpoints are always equally valid"? ;)

 But you did say "this whole thread is ridiculous", even though we 
 discussed other issues besides "semicolon-oriented language" vs. 
 "newline-oriented language". If you really meant just the particular 
 branch of the thread you replied to and not actually the whole thread, 
 then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.



 Sure. After all, nobody would say that you were obligated to participate. 
 Feel free to pick and choose which discussions you wish to participate in. 
 I do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.



 One could make the same claim about meta-debates, such as this. (I'm not 
 actually making that claim though. I don't personally mind the occasional 
 meta-debate.)

 Besides, I think it's good to periodically challenge, and be challenged 
 by, each others viewpoints. This way we don't stagnate, isolated in the 
 world of our own preferences, possibly even blind to the occasional 
 mistaken assumption. For all I know, someone might say something that 
 makes me think of Python in a new way and I decide "Wow, this is my new 
 preference. I like Python better than D. If I had just agreed to disagree 
 then my eyes never would have been opened to this."

 As real-world examples, when I first started reading about Python, I had a 
 knee-jerk reaction and decided "this is garbage, I'm not going near it", 
 and that was that. But a couple weeks ago I was talking to a friend who 
 liked Python, we disagreed, but still discussed, and I realized that 
 Python did have some good functional-ish features - things that even my 
 favorite language, D, could use to borrow. And I also came to the 
 conclusion that it really wouldn't kill me, at the very least, to write a 
 quck little prototype, script, etc., in Python every now and then. All 
 this even though I still consider, for example, the rationale behind 
 Python's indentation to be logically flawed and inappropriate for large 
 projects. In much the same way, my friend ended up getting interested in D 
 (To paraphrase: "Wow, a static typed, non-VM language without the muss and 
 fuss of C/C++, who knew?").

 If we had just decided "these are matters of preference, discussing it is 
 ridiculous", and avoided what seemed like a pointless discussion, then 
 where would we both be right now? Sitting in our own happy ignorance.



I just re-read what I wrote here and realized it came across a little bit 
hippy-ish. Anybody: feel free to sprinkle in a few "fuck"s or "damnit"s as 
you read it. ;)
May 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:g003u3$1g02$1 digitalmars.com...

 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.



 around assuming that all opposing viewpoints are always equally valid"? ;)

 But you did say "this whole thread is ridiculous", even though we 
 discussed other issues besides "semicolon-oriented language" vs. 
 "newline-oriented language". If you really meant just the particular 
 branch of the thread you replied to and not actually the whole thread, 
 then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.



 Feel free to pick and choose which discussions you wish to participate in. 
 I do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.



 actually making that claim though. I don't personally mind the occasional 
 meta-debate.)

 Besides, I think it's good to periodically challenge, and be challenged 
 by, each others viewpoints. This way we don't stagnate, isolated in the 
 world of our own preferences, possibly even blind to the occasional 
 mistaken assumption. For all I know, someone might say something that 
 makes me think of Python in a new way and I decide "Wow, this is my new 
 preference. I like Python better than D. If I had just agreed to disagree 
 then my eyes never would have been opened to this."

 As real-world examples, when I first started reading about Python, I had a 
 knee-jerk reaction and decided "this is garbage, I'm not going near it", 
 and that was that. But a couple weeks ago I was talking to a friend who 
 liked Python, we disagreed, but still discussed, and I realized that 
 Python did have some good functional-ish features - things that even my 
 favorite language, D, could use to borrow. And I also came to the 
 conclusion that it really wouldn't kill me, at the very least, to write a 
 quck little prototype, script, etc., in Python every now and then. All 
 this even though I still consider, for example, the rationale behind 
 Python's indentation to be logically flawed and inappropriate for large 
 projects. In much the same way, my friend ended up getting interested in D 
 (To paraphrase: "Wow, a static typed, non-VM language without the muss and 
 fuss of C/C++, who knew?").

 If we had just decided "these are matters of preference, discussing it is 
 ridiculous", and avoided what seemed like a pointless discussion, then 
 where would we both be right now? Sitting in our own happy ignorance.



 I just re-read what I wrote here and realized it came across a little bit 
 hippy-ish. Anybody: feel free to sprinkle in a few "fuck"s or "damnit"s as 
 you read it. ;) 
 
 



I'm glad that you realize that I was talking about "semicolon-oriented
language" vs. "newline-oriented language". I never said we shouldn't
discuss python vs. D which (again) was not discussed in this thread.
this very long discussion was about the semicolon and you already know
what I think of such discussions.

Your post actually proves my original post. If you read it again you
would realize that I said that I prefer to use the right tool for the
job, be it D, python or even VB (ok, I would probably would never use VB
if I can help it ;) ). Also, there's was link to a wiki page about the
Sapir hypothesis in there. Sapir is a linguist and he noticed that the
language used by a people affects their way of thinking. Applying this
to our discussion means that a C/C++ programmer "thinks" in a C/C++ way
and it would be harder for him to understand python vs D. Hence your
knee jerk reaction to Python as you stated above. so you see, you've
just proved my point.

--Yigal
May 09 2008
parent "Nick Sabalausky" <a a.a> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:g0156n$lj6$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:g003u3$1g02$1 digitalmars.com...

 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.



 around assuming that all opposing viewpoints are always equally valid"? 
 ;)

 But you did say "this whole thread is ridiculous", even though we
 discussed other issues besides "semicolon-oriented language" vs.
 "newline-oriented language". If you really meant just the particular
 branch of the thread you replied to and not actually the whole thread,
 then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.



 participate.
 Feel free to pick and choose which discussions you wish to participate 
 in.
 I do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and 
 energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.



 actually making that claim though. I don't personally mind the 
 occasional
 meta-debate.)

 Besides, I think it's good to periodically challenge, and be challenged
 by, each others viewpoints. This way we don't stagnate, isolated in the
 world of our own preferences, possibly even blind to the occasional
 mistaken assumption. For all I know, someone might say something that
 makes me think of Python in a new way and I decide "Wow, this is my new
 preference. I like Python better than D. If I had just agreed to 
 disagree
 then my eyes never would have been opened to this."

 As real-world examples, when I first started reading about Python, I had 
 a
 knee-jerk reaction and decided "this is garbage, I'm not going near it",
 and that was that. But a couple weeks ago I was talking to a friend who
 liked Python, we disagreed, but still discussed, and I realized that
 Python did have some good functional-ish features - things that even my
 favorite language, D, could use to borrow. And I also came to the
 conclusion that it really wouldn't kill me, at the very least, to write 
 a
 quck little prototype, script, etc., in Python every now and then. All
 this even though I still consider, for example, the rationale behind
 Python's indentation to be logically flawed and inappropriate for large
 projects. In much the same way, my friend ended up getting interested in 
 D
 (To paraphrase: "Wow, a static typed, non-VM language without the muss 
 and
 fuss of C/C++, who knew?").

 If we had just decided "these are matters of preference, discussing it 
 is
 ridiculous", and avoided what seemed like a pointless discussion, then
 where would we both be right now? Sitting in our own happy ignorance.



 I just re-read what I wrote here and realized it came across a little bit
 hippy-ish. Anybody: feel free to sprinkle in a few "fuck"s or "damnit"s 
 as
 you read it. ;)



 I'm glad that you realize that I was talking about "semicolon-oriented
 language" vs. "newline-oriented language". I never said we shouldn't
 discuss python vs. D which (again) was not discussed in this thread.
 this very long discussion was about the semicolon and you already know
 what I think of such discussions.

 Your post actually proves my original post. If you read it again you
 would realize that I said that I prefer to use the right tool for the
 job, be it D, python or even VB (ok, I would probably would never use VB
 if I can help it ;) ).



Agreed on VB ;)

Not everyone always agrees what the right tool for a given job is. But the 
problem is: even when preference plays a large part, it isn't always due 
100% to preference. For instance, sometimes a mistaken assumption may have 
slipped in, or an oversight. We don't know if it really is purely 
preference, or if faulty reasoning has managed to slip in until 
it's...discussed.


 Also, there's was link to a wiki page about the
 Sapir hypothesis in there. Sapir is a linguist and he noticed that the
 language used by a people affects their way of thinking. Applying this
 to our discussion means that a C/C++ programmer "thinks" in a C/C++ way
 and it would be harder for him to understand python vs D. Hence your
 knee jerk reaction to Python as you stated above.



A knee-jerk reaction which I then (at least partially) overcame 
through...discussion. The Sapir hypothesis doesn't mean that we should just 
stick to our native language and avoid comparing/contrasting languages. But 
what it does mean that we're naturally blind to the pros/cons of that which 
we are unfamiliar with. Avoiding discussion allows this natural ignorance to 
persist, while participating in discussion helps to dispell it.
May 09 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Yigal Chripun wrote:

 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.



Also known as the bikeshed problem 
(http://en.wikipedia.org/wiki/Color_of_the_bikeshed)
:)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 13 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Bruno,


 Yigal Chripun wrote:
 

 PS: it's amazing how such smart people can waste so much time and
 energy debating such unimportant issues as the semicolon at the end
 of statements with such a passion.
 



 (http://en.wikipedia.org/wiki/Color_of_the_bikeshed) :)
 



The only usable solution is the define the language is such a way that there 
is exactly one correct way to format code. That way must be so bad that
absolutely 
no one will even try to edit it without a pretty printer (and an ugly printer 
to go back the other way) That way everyone is unhappy with the actual files 
but no one cares because then never see it.
May 13 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:

 Reply to Bruno,
 

 Yigal Chripun wrote:


 PS: it's amazing how such smart people can waste so much time and
 energy debating such unimportant issues as the semicolon at the end
 of statements with such a passion.



 (http://en.wikipedia.org/wiki/Color_of_the_bikeshed) :)



 The only usable solution is the define the language is such a way that
 there is exactly one correct way to format code. That way must be so bad
 that absolutely no one will even try to edit it without a pretty printer
 (and an ugly printer to go back the other way) That way everyone is
 unhappy with the actual files but no one cares because then never see it.
 



personally I don't understand why we still use text files to represent
code. that's just so silly. data in a computer is stored in binary form
not text, so you don't get to see your "real" code anyway, but rather a
specific interpretation of it. and this encoding is very old and very
simplistic. this is identical to word for example only difference is the
format used by word is a different binary encoding.

there is a programming language where you use pixels and colors to
program and you can actually create pretty code. imagine your source
code looks like a butterfly, for example. there are some mostly academic
languages that use math extensivly and thus rely on latex for syntax.
I'm sure that there are endless possibilities of richer representations
of code than just text.

in star-trek when they need to "program" the holo-deck or the machine
that creates food (darn, I forgot the name of it) they simply explain to
the computer what they actually want. no need for a formal language at
all. there's an episode in star-trek TNG where they unfreeze someone in
a space shuttle which was frozen since the 20th century. since in the
Utopian earth in the future they don't have alcohol nor anything
unhealthy like coca-cola, he tries to program that machine to create
coke, and it takes a while since he didn't know how to explain what a
coke is. (he had much better luck with whiskey, though ;) )

and with all those endless possibilities, we still spend time arguing
the semi-colon?! doesn't it look silly, in comparison?

D is already years ahead of many other languages, simple by using
Unicode instead of ASCII. wouldn't it be cool to have a voice
recognition compiler for D too? ;)
May 13 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Yigal,


 personally I don't understand why we still use text files to represent
 code.
 



I's to long a story to post here, but my day job is working on a new
programming 
language. For several years it was a non text based language. Suffice to 
say, it just couldn't be made to work.
May 13 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:

 Reply to Yigal,
 

 personally I don't understand why we still use text files to represent
 code.



 I's to long a story to post here, but my day job is working on a new
 programming language. For several years it was a non text based
 language. Suffice to say, it just couldn't be made to work.
 
 



tell it.
anyway, that doesn't mean anything. this just shows that your particular
 language couldn't be made to work by your company. that's not a proof
in any way.
the little theorem of Fermat was calculated by super computers for a
huge set of numbers, but until it was formally proved it wasn't formally
true. the story of the light bulb shows also how despite hundreds of
failures Edison continued his work until he did manage to create a
light-bulb.
on the other hand, as I said in the original post, there are already
available programming languages that are not text based. even those math
(latex) languages are included in this. You can even include UML in this
if you use a weaker definition, since there are (many) tools that
generate code from UML diagrams.
GUI is a prime candidate for a visual language. most people already use
tools like eclipse's visual editor to draw the GUI and have the IDE
generate the code for them. I don't think there are any Java programmers
left (outside the educational system) that actually hand code their GUI
code. Eclipse does a better job of it and the development is faster.
this is just evolution taking it's course.
once upon a time humans used assembly. I think the last assembly
language designed to be used by humans was that of the PDF-11. today the
compiler generates it for you. you still can use assembly directly of
course, but the current design is driven by the needs of compiler
writers and the assembly language is no longer built to accommodate mere
humans.

http://en.wikipedia.org/wiki/Visual_programming_language
May 13 2008
parent BCS <ao pathlink.com> writes:
Reply to Yigal,


 I'll be glad to here that sometime when there's time, if you care to
 tell it.



I'll show up here sooner or later (don't expect sooner)


 anyway, that doesn't mean anything. this just shows that your
 particular
 language couldn't be made to work by your company. that's not a proof
 in any way.



The issue didn't forbid general purpose non-text languages, but they don't 
make me thinking it's going to happen any time soon. To put it concisely, 
visual systems are fine for a well defined, static domains, but are to rigid 
for anything else.
May 13 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.



I've used Lingo, a proprietary programming language that uses a binary 
format for code. Of course, the code is largely textual, so it's the 
worst of both worlds.

The largest issue is finding an efficient means of recording intent that 
is Turing-complete (and can easily be translated to machine code). Text 
fulfills that wonderfully. Human languages do not, for a variety of 
reasons. You could come up with a pixelmap solution that is reasonable, 
but it would be compilable to text without significant difficulty, and 
text is probably easier to read and write.

The second largest issue is editors. Once you have your visual 
programming language, everyone needs an editor that can display it in 
order to program for it, which is a considerable barrier to entry. I 
tried learning Lingo recently, and though most of the code involved is 
text, it's in a binary format along with images and other data, so you 
can't hope to learn it without shelling out $800 for Adobe Director. 
Even if the editor were free, even if it were available for all 
platforms, it would still require everyone to use that editor, no matter 
its quality. And there are wars over editors, so this is no trivial matter.
May 13 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Christopher Wright wrote:

 Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.



 I've used Lingo, a proprietary programming language that uses a binary
 format for code. Of course, the code is largely textual, so it's the
 worst of both worlds.
 
 The largest issue is finding an efficient means of recording intent that
 is Turing-complete (and can easily be translated to machine code). Text
 fulfills that wonderfully. Human languages do not, for a variety of
 reasons. You could come up with a pixelmap solution that is reasonable,
 but it would be compilable to text without significant difficulty, and
 text is probably easier to read and write.
 
 The second largest issue is editors. Once you have your visual
 programming language, everyone needs an editor that can display it in
 order to program for it, which is a considerable barrier to entry. I
 tried learning Lingo recently, and though most of the code involved is
 text, it's in a binary format along with images and other data, so you
 can't hope to learn it without shelling out $800 for Adobe Director.
 Even if the editor were free, even if it were available for all
 platforms, it would still require everyone to use that editor, no matter
 its quality. And there are wars over editors, so this is no trivial matter.



while that's true, it doesn't really prevent us from having a language
that has a more rich representation. also note, I didn't say we should
ban the use of text, merely that we shouldn't be limited by text.
text is a binary format too as I said earlier, the only difference is
that you already have many free editors for it. that's a bit of an egg
and a chicken problem. but that shouldn't force us to limit ourselves to
only text. look at Java for instance, it already is used almost
exclusively with IDEs, you can use a text editor with Java of course,
but in practice, nobody does that. the next step would be to write a
language with a rich representation and provide an eclipse plugin for it.

the point of this is not to find something easier for the computer to
understand, but to find something more easy for humans to use. finding a
way to generate code from human languages is probably hard, I agree. the
benefit would be that you will not need to be a programmer to create a
program. you could just describe your problem to the PC and it'll
understand it and generate a solution. (maybe this needs AI for that.)

another line of thinking is this: why do we need a general purpose
Turing-complete language anyway? programmers deal with abstractions,
right? we are constantly trying to raise the level of those abstractions
to make them closer to the domain of the problem. otherwise we would
still be using assembly since all the Turing complete languages have
equal power. so everything you can do with D (for instance) is possible
to do in assembly as well (it'll be harder to program, though).

what's the next level of abstraction, than? let's define a DSL (domain
specific language) that describes our problem domain and use that
language to solve the problem. SQL for example is very good at DBs and
it isn't even Turing complete. so instead of using one general purpose
language (which internally has to have design trade-offs) you can choose
the language for the job or create a new one. (there's an interesting
article about this idea by the jetbrains developers with their MPL
system, you can google it up - highly recommended to read)

by doing this we have just added another level of abstraction. now your
code is written in a a set of specific DSLs suitable for your problem.
those are translated to a general purpose language like D or Java, which
then is compiled and linked to a binary.
this way you can use graphics to design the GUI, SQL for DB access, and
other languages for other stuff.
May 13 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Yigal Chripun wrote:

 Christopher Wright wrote:

 Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.



 format for code. Of course, the code is largely textual, so it's the
 worst of both worlds.

 The largest issue is finding an efficient means of recording intent that
 is Turing-complete (and can easily be translated to machine code). Text
 fulfills that wonderfully. Human languages do not, for a variety of
 reasons. You could come up with a pixelmap solution that is reasonable,
 but it would be compilable to text without significant difficulty, and
 text is probably easier to read and write.

 The second largest issue is editors. Once you have your visual
 programming language, everyone needs an editor that can display it in
 order to program for it, which is a considerable barrier to entry. I
 tried learning Lingo recently, and though most of the code involved is
 text, it's in a binary format along with images and other data, so you
 can't hope to learn it without shelling out $800 for Adobe Director.
 Even if the editor were free, even if it were available for all
 platforms, it would still require everyone to use that editor, no matter
 its quality. And there are wars over editors, so this is no trivial matter.



 while that's true, it doesn't really prevent us from having a language
 that has a more rich representation. also note, I didn't say we should
 ban the use of text, merely that we shouldn't be limited by text.
 text is a binary format too as I said earlier, the only difference is
 that you already have many free editors for it. that's a bit of an egg
 and a chicken problem. but that shouldn't force us to limit ourselves to
 only text. look at Java for instance, it already is used almost
 exclusively with IDEs, you can use a text editor with Java of course,
 but in practice, nobody does that. the next step would be to write a
 language with a rich representation and provide an eclipse plugin for it.



I have regularly written Java with vim. It's only annoying because the 
Java stdlib is hueg, and every class has so many methods, and a lot of 
the identifier names are quite long. If you're primarily working with 
your own code and keep the identifiers and classes managably sized, and 
are working on a small project, it's quite reasonable.

But I'm just uncertain that there is a visual representation of computer 
programs that is useful aside from code. I mean, GUI designers work 
because they're concerned about layout and not function. But actual code?

Perhaps editing assembly would be easier if you could view your program 
as a set of still images or a video that's showing what is happening 
with which registers. But I'm sure that it would be slower than just 
using your text editor of choice.


 another line of thinking is this: why do we need a general purpose
 Turing-complete language anyway? programmers deal with abstractions,
 right? we are constantly trying to raise the level of those abstractions
 to make them closer to the domain of the problem. otherwise we would
 still be using assembly since all the Turing complete languages have
 equal power. so everything you can do with D (for instance) is possible
 to do in assembly as well (it'll be harder to program, though).
 
 what's the next level of abstraction, than? let's define a DSL (domain
 specific language) that describes our problem domain and use that
 language to solve the problem. SQL for example is very good at DBs and
 it isn't even Turing complete. so instead of using one general purpose
 language (which internally has to have design trade-offs) you can choose
 the language for the job or create a new one. (there's an interesting
 article about this idea by the jetbrains developers with their MPL
 system, you can google it up - highly recommended to read)



If I design a DSL, it's easier to start with an existing language. For 
instance, at work I use Castle Windsor for dependency injection, 
configured with Bindsor, a DSL based on Boo. Bindsor is pretty small, 
since it doesn't have to contain a lexer or a parser or do any code 
generation.

It would have been harder to make Bindsor without Boo, and it may well 
have been impossible to get any gains over the original XML 
configuration without making the language Turing-complete. (In fact, 
since looping and conditional execution are pretty much sufficient to 
make a language Turing-complete, Bindsor would be useless if it were not 
Turing-complete. And it's primarily a declarative language!)

At the very least, arbitrary DSLs branched off an existing language 
would be extremely difficult to create if the existing language were not 
Turing complete. At that point, why not make the DSLs into libraries and 
just use the original language for your application? Or why not add each 
of the compiler interceptors for these DSLs to the compiler so you can 
use each of the DSLs at once?
May 14 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Christopher Wright wrote:

 I have regularly written Java with vim. It's only annoying because the
 Java stdlib is huge, and every class has so many methods, and a lot of
 the identifier names are quite long. If you're primarily working with
 your own code and keep the identifiers and classes managably sized, and
 are working on a small project, it's quite reasonable.



of course you can use vim to program in Java, you also can use assembly
if you want, you can even use a hex editor and write the binary OP codes
directly. The question is, should you do this?
Java is indeed annoying when used in a text editor. In a way you can say
that Java is designed to be used with an IDE.  Java uses long
descriptive names for everything. this is a non issue since the IDE
auto-completes Identifiers. in fact the IDE *knows* Java and it can
write code and transform code for you. there are literally hundreds of
refactoring operations it can perform. in view of that, you can say that
Java is designed such that an IDE is considered integral part of the
language. Writing Java without an IDE is almost like programming D
without a compiler.
a similar example is smalltalk. when smalltalk was designed, its IDE was
designed with it. it's not an optional part but rather an important
integral part of the language implementation.

 
 But I'm just uncertain that there is a visual representation of computer
 programs that is useful aside from code. I mean, GUI designers work
 because they're concerned about layout and not function. But actual code?



I'm uncertain that only textual free context grammars can be used for
programming. we both do not the answer to this question yet, but it's
still fun exploring the possibilities.

 
 Perhaps editing assembly would be easier if you could view your program
 as a set of still images or a video that's showing what is happening
 with which registers. But I'm sure that it would be slower than just
 using your text editor of choice.
 
 
 If I design a DSL, it's easier to start with an existing language. For
 instance, at work I use Castle Windsor for dependency injection,
 configured with Bindsor, a DSL based on Boo. Bindsor is pretty small,
 since it doesn't have to contain a lexer or a parser or do any code
 generation.
 
 It would have been harder to make Bindsor without Boo, and it may well
 have been impossible to get any gains over the original XML
 configuration without making the language Turing-complete. (In fact,
 since looping and conditional execution are pretty much sufficient to
 make a language Turing-complete, Bindsor would be useless if it were not
 Turing-complete. And it's primarily a declarative language!)
 
 At the very least, arbitrary DSLs branched off an existing language
 would be extremely difficult to create if the existing language were not
 Turing complete. At that point, why not make the DSLs into libraries and
 just use the original language for your application? Or why not add each
 of the compiler interceptors for these DSLs to the compiler so you can
 use each of the DSLs at once?



there are two issues here.
a) Turing-completeness: if we are discussing DSLs than the best thing is
to look at the problem domain and try to create the most suitable
abstraction. sometimes that requires Turing completeness, and sometimes
it doesn't. SQL is an example where this is not required. I don't know
the statistics for this but I think that if you want to abstract as
close as possible to the problem domain the more specialized the DSL
will become and it'll be less likely you'll need Turing-completeness.
b) the point of the MPL and similar tools is to provide a way to easily
define a language, it's tools (IDE, compiler, etc..) and define a
translation to some general purpose language. the idea is to add to the
stack of abstractions another level. with this scheme you'll get:
My Specific Language -> general purpose language -> assembly -> binary.
it's the reverse of inner DSLs common to lisp. to answer your question
of: "why not make the DSLs into libraries and just use the original
language?"
let's compare the two by looking at Java's swing library:
swing is very complex and has a lot of code in it in order to provide
maximum flexibility. but it's just a library with API. a DSL based on
that API will add specific language support and an IDE that understands
swing. for example it can provide compile time checks and rules that a
regular Java cannot check/enforce.  for example swing might define rules
 about layout for accessibility [certain combinations of colors and
fonts are forbidden].
a DSL is like a library API with it's own compiler/IDE that know how to
highlight the syntax/check correctness/etc..
all of this can be implemented manually too of course, but the end user
which just wants to create a window and a bunch of buttons can be just a
graphic designer instead of a C++ expert when using a DSL.
also nothing should prevent you to from using any combination of DSLs to
create your product. most developers today already use some sort of a
DSL, this is just the next step in evolution. not only can you use a
visual designer for you GUI (just an example, of course) but you'll also
get an automatic check to make sure your widgets do not overlap,
colors/fonts are accessible, etc, etc.
the editor will also point to errors in the design, and suggest some
solutions to common issues.

I highly recommend to google for MPL and Language Oriented Programming
for better explanations.
May 14 2008
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.



 Bjarne Stroustrup had some hopes that the particular textual form of
C++ he’d developed could be replaced with other forms that were
conceptually identical but different syntactically. Turns out that isn’t
quite so doable. (Though when D exposes the syntax-tree form it’s a step
in that direction.)

—Joel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIKwaWzLx4GzBL9dYRAtz0AKCjA7WFMZRXjRRZ/Dt0QLLSu0Z/YQCfduXQ
mp5Tu7CtjLOOgRq+7H6DZNg=
=zqUy
-----END PGP SIGNATURE-----
May 14 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Joel C. Salomon wrote:

 Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.



  Bjarne Stroustrup had some hopes that the particular textual form of
 C++ he’d developed could be replaced with other forms that were
 conceptually identical but different syntactically. Turns out that isn’t
 quite so doable. (Though when D exposes the syntax-tree form it’s a step
 in that direction.)
 
 —Joel



on the contrary, I've seen an article online of two people that did
exactly that. they defined an alternative syntax for C++ which is both
consistent and preserves the semantics of c++. it was their Thesis or
something like that. just stumbled on it via google.
May 14 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 15 May 2008 00:56:49 +0200, Yigal Chripun <yigal100 gmail.com>  
wrote:


 Joel C. Salomon wrote:
  > Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is  
 the
 format used by word is a different binary encoding.



  Bjarne Stroustrup had some hopes that the particular textual form of
 C++ he’d developed could be replaced with other forms that were
 conceptually identical but different syntactically. Turns out that isn’t
 quite so doable. (Though when D exposes the syntax-tree form it’s a step
 in that direction.)

 —Joel



 on the contrary, I've seen an article online of two people that did
 exactly that. they defined an alternative syntax for C++ which is both
 consistent and preserves the semantics of c++. it was their Thesis or
 something like that. just stumbled on it via google.



Link?
May 15 2008
parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simen Kjaeraas wrote:

 Yigal Chripun wrote:

 on the contrary, I've seen an article online of two people that did
 exactly that. they defined an alternative syntax for C++ which is both
 consistent and preserves the semantics of c++. it was their Thesis or
 something like that. just stumbled on it via google.



 Link?



<http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C++_Syntax>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILD6UzLx4GzBL9dYRAjMrAJ9WiMCBA5qUswzHBhtypOwSjfdxrgCgzIbN
vln72iicI3pFCgpDIyD4th8=
=BGPP
-----END PGP SIGNATURE-----
May 15 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Joel C. Salomon wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Simen Kjaeraas wrote:

 Yigal Chripun wrote:

 on the contrary, I've seen an article online of two people that did
 exactly that. they defined an alternative syntax for C++ which is both
 consistent and preserves the semantics of c++. it was their Thesis or
 something like that. just stumbled on it via google.






 <http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C++_Syntax>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (GNU/Linux)
 
 iD8DBQFILD6UzLx4GzBL9dYRAjMrAJ9WiMCBA5qUswzHBhtypOwSjfdxrgCgzIbN
 vln72iicI3pFCgpDIyD4th8=
 =BGPP
 -----END PGP SIGNATURE-----



Yeah, this is exactly what I was talking about :)
thanks Joel. you saved me the need to go look it up myself.
May 15 2008