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
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
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.
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
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.
"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.
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.
"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.
"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. ;)
"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
"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
↑ ↓ ←→ 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.
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.
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.
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.
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? ;)
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.
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
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
↑↓←→ 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.
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
↑ ↓ ←→ 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?
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
↑ ↓ ←→ "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-----
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.
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
↑ ↓ ←→ "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.
-----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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next