why ; ?

[Christopher Wright]

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?