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 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

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.
>> 
> Also known as the bikeshed problem
> (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.

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.
>>>
>> Also known as the bikeshed problem
>> (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? ;)

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.

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.
> 
> 
I'll be glad to here that sometime when there's time, if you care to
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

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.

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.

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.

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.
>> 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.

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?