why ; ?

[Yigal Chripun]

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.