Any current preprocessor/Ruby language add-ons?

[C. Dagnon]

This is kind of a wide-ranging question but for some fairly specific
purposes.

I'm curious what project people are working on with respect to the Ruby
language, compiler, or any preprocessors. Specifically I want to use
file- or project-wide directives (as in VB where new variables require
explicit declarations), and I want to add preconditions, postconditions,
type checking, side effects, and tests/behaviour assertions within the
code files along with associated automated analysis. I am open to
annotation styles, eg. # @directive..., or others so ideally the code
files are actual Ruby code files, but can be assured when desired.

In a brief search I found RPP (http://rubyforge.org/projects/ruby-rpp/)
which adds some ability to type-check variables. Unfortunately it looks
like it is alpha with no progress in the last 2-3 years and I don't
think I can contact the author (or I need a login). It also requires
editing all files and placing the modified Ruby code after __END__, both
of which I would like to avoid. So I'm curious to find active projects
which align more directly with my goals.

Generally Ruby seems flexible and pretty powerful and concise but unruly
and, well, unreliable. All the benefits but detriments of a scripting
language when mixed with (at least my) human fallibility. But if
someone isn't already working on these things it may be more prudent for
me to move to a different language or platform. Anyone have a
suggestion? More directly, is there a computer language group which I
should start shadowing as comp.lang seems more off topic than
discussion...


Curious,

-Chris

 

[Robert Klemme]

This is kind of a wide-ranging question but for some fairly specific
purposes.

I'm curious what project people are working on with respect to the Ruby
language, compiler, or any preprocessors. =A0Specifically I want to use
file- or project-wide directives (as in VB where new variables require
explicit declarations), and I want to add preconditions, postconditions,
type checking, side effects, and tests/behaviour assertions within the
code files along with associated automated analysis. =A0I am open to
annotation styles, eg. # @directive..., or others so ideally the code
files are actual Ruby code files, but can be assured when desired.

In a brief search I found RPP (http://rubyforge.org/projects/ruby-rpp/)

There are also
http://www.cse.dmu.ac.uk/~hgs/projects/ruby_dbc.html
http://rubyforge.org/projects/rdbc/
http://www.rubyinside.com/handshake-design-by-contract-504.html

Jim also has an interesting article
http://onestepback.org/index.cgi/Tech/Programming/DbcAndTesting.html

which adds some ability to type-check variables. =A0Unfortunately it look= s
like it is alpha with no progress in the last 2-3 years and I don't
think I can contact the author (or I need a login). =A0It also requires
editing all files and placing the modified Ruby code after __END__, both
of which I would like to avoid. =A0So I'm curious to find active projects
which align more directly with my goals.

Generally Ruby seems flexible and pretty powerful and concise but unruly
and, well, unreliable.

For me it is not unreliable at all.

=A0All the benefits but detriments of a scripting
language when mixed with (at least my) human fallibility. =A0But if
someone isn't already working on these things it may be more prudent for
me to move to a different language or platform. =A0Anyone have a
suggestion? =A0More directly, is there a computer language group which I
should start shadowing as comp.lang seems more off topic than
discussion...

Frankly, with that set of features you want to add to Ruby I am
wondering why you still want to use Ruby? I mean, there are languages
out there that have it all (or most of it) already so why invest
efforts in bending Ruby in that direction? Ruby's dynamism is one of
the core features - and as far as I can see your suggestion ultimately
targets at making a script language variant of Eiffel. Why then not
use Eiffel directly?

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[C. Dagnon]

Thanks for those links - it is interesting to me that they wanted to
start design by contract for Ruby in 2001 but never got anywhere. Even
their resources link to some DBC page instead forwards to buying one of
their books (not about DBC). And the RubyForge project is by all
accounts empty and inactive though it was founded in 2007.

However the 2 articles you list last are definitely interesting. The
second one especially gives me several ideas to mull over. Thank you!

Why not move to Eiffel? Well if Eiffel is the only or best language
using contracts I should be trying it if only to learn it's limitations.
However I'd rather do incremental upgrades of all the existing
Ruby/Rails products I've made than switch to a completely new language
and web framework all at once. I would also like to bring this new
level of reliability to new companies and projects who have finally
started taking Ruby seriously or are willing to use it on the JRuby or
related platforms. I've also never seen a job posting for Eiffel, but I
haven't explored much.

I also love the dynamic abilities of Ruby, and I want to keep them.
However I want to be sure the code does what I want it to without
needing me to exercise all the code separately. From the last article
you gave, it sounds like Eiffel doesn't provide that feature - that the
contracts are only enforced when the code is run, which would not meet
my needs. It seems like if the contracts are defined the
compiler/preprocessor should be able to guarantee all (at least
small-scale) code interactions without writing any tests. Effectively
swat all Unit and Functional tests without writing external, dependent
code needing triggered updates. Except if that could be done, someone
would have already done it, right?

Which is partly why I was asking about other groups, meta-computer
language groups in particular because I'm pretty fed up with limitations
I've experienced in each of the existing languages I've tried. But I'm
not experienced with the vernacular enough to know what the N-axis(es?)
are of possible language/environment features. Wikipedia doesn't quite
help either - their comparison has several useful points, yet doesn't
quite compare their gestalts as I would like to. Perhaps because they
want it to fit in thin tables?
http://en.wikipedia.org/wiki/Comparison_of_programming_languages

Lastly, I would love to see the assurance flexibility within the Ruby
platform. Sometimes you need a script (easy with any Ruby), sometimes
you need a 20+ person team working on a complex application (I don't see
this as possible without major, strict development practices). The
ability to tighten up an application from free-form script to
(Eiffel-ness?) seems like a great growth vector for my usage patterns.
We get both the immediate usefulness and the long-term maintainability.


Thank you for continuing the conversation!

-Chris

 

[Caleb Clausen]

This is kind of a wide-ranging question but for some fairly specific
purposes.

I'm curious what project people are working on with respect to the Ruby
language, compiler, or any preprocessors. Specifically I want to use
file- or project-wide directives (as in VB where new variables require
explicit declarations), and I want to add preconditions, postconditions,
type checking, side effects, and tests/behaviour assertions within the
code files along with associated automated analysis.

You may want to look at RubyMacros, a preprocessor I wrote to add
syntax tree based macros to ruby. I've got a simple assert macro in my
examples; maybe that helps you...

http://www.rubyforge.org/projects/rubymacros
http://github.org/coatl/rubymacros

There have been a number of efforts to add static typing (-ish)
features to ruby. The most recent is Diamondback Ruby; an announcement
for it was posted here a couple weeks ago. It has some kind of method
annotation special comment for declaring types of arguments, like you
wanted.

 

[Robert Klemme]

However the 2 articles you list last are definitely interesting. The
second one especially gives me several ideas to mull over. Thank you!

You're welcome!

Why not move to Eiffel? Well if Eiffel is the only or best language
using contracts I should be trying it if only to learn it's limitations.

I always keep recommending Bertrand Meyer's excellent book on OO in
general and Eiffel in particular:

http://archive.eiffel.com/doc/oosc/page.html

However I'd rather do incremental upgrades of all the existing
Ruby/Rails products I've made than switch to a completely new language
and web framework all at once.

Did you consider whether these upgrades will retain the functionality of
those frameworks? Chances are that they are highly dependent on Ruby's
dynamics and won't play well together with the kinds of changes you want
to do to the language.

I've also never seen a job posting for Eiffel, but I
haven't explored much.

Economic success and technical quality are two orthogonal concepts with
only loose coupling.

I also love the dynamic abilities of Ruby, and I want to keep them.

But you do see a certain level of contradiction there, do you?

However I want to be sure the code does what I want it to without
needing me to exercise all the code separately. From the last article
you gave, it sounds like Eiffel doesn't provide that feature - that the
contracts are only enforced when the code is run, which would not meet
my needs.

I would assume that what can be checked at compile time is already
checked then. Eiffel has a quite elaborate type system with more
options of inheritance than any other language I am aware of. So that
buys you quite a bit of added safety.

It seems like if the contracts are defined the
compiler/preprocessor should be able to guarantee all (at least
small-scale) code interactions without writing any tests. Effectively
swat all Unit and Functional tests without writing external, dependent
code needing triggered updates. Except if that could be done, someone
would have already done it, right?

.... which brings us to the halting problem:

http://en.wikipedia.org/wiki/Halting_problem

Which is partly why I was asking about other groups, meta-computer
language groups in particular because I'm pretty fed up with limitations
I've experienced in each of the existing languages I've tried. But I'm
not experienced with the vernacular enough to know what the N-axis(es?)
are of possible language/environment features. Wikipedia doesn't quite
help either - their comparison has several useful points, yet doesn't
quite compare their gestalts as I would like to. Perhaps because they
want it to fit in thin tables?
http://en.wikipedia.org/wiki/Comparison_of_programming_languages

Maybe you get yourself a textbook about computer languages and one on
computational theory.

http://en.wikipedia.org/wiki/Computational_theory

Lastly, I would love to see the assurance flexibility within the Ruby
platform. Sometimes you need a script (easy with any Ruby), sometimes
you need a 20+ person team working on a complex application (I don't see
this as possible without major, strict development practices). The
ability to tighten up an application from free-form script to
(Eiffel-ness?) seems like a great growth vector for my usage patterns.
We get both the immediate usefulness and the long-term maintainability.

I am not so sure whether this works our. Sure, in practice we often
seen things that start out as mini applications and grow into large and
complex things over time. I am just not sure whether it is realistic to
expect a single language to cover the whole range. After all, the rule
should be to pick the right tool for the job. Put it differently:
assuming all your extensions could be incorporated into Ruby then the
Ruby you would use for small scale scripting and the Ruby you use for
large applications would not have much in common, so you *are*
effectively using two different languages. The step towards something
completely different does not seem to big.

Kind regards

robert

 

[C. Dagnon]

I don't have time for a full reply, but I definitely wanted to say some
more 8)

Economic success and technical quality are two orthogonal concepts with
only loose coupling.

Unfortunately, but only for now!

But you do see a certain level of contradiction there, do you?

Nope, I don't 8) Partially I would say I am not looking for a
compile-time (singly-) statically-typed language. I want it to be
adaptable and further, *useful* by others without requiring source-code
changes in existing libraries.

But my old gripe is that Ruby isn't Duck-Typed, it is explicitly
No-Typed but implicitly Strong-Typed (except for method-missing). But
that makes no sense for a language since any method I write requires (at
most) a certain set of functionality from the parameters. So there are
interface dependencies, just never declared or, in Ruby, declarable.

checked then. Eiffel has a quite elaborate type system with more
options of inheritance than any other language I am aware of. So that
buys you quite a bit of added safety.

I will have to check out the book, though I'll try the homepage/FAQ to
try to build my interest up for a whole book.

... which brings us to the halting problem:

http://en.wikipedia.org/wiki/Halting_problem

I'm not convinced yet that it does, but I'm also not yet concerned that
it does bring up the halting problem.

Maybe you get yourself a textbook about computer languages and one on
computational theory.

http://en.wikipedia.org/wiki/Computational_theory

Yeah, I passed the senior-year language and computer theory classes...
It may have been too long ago, but that didn't impart knowledge of all
existing (and at that time, future) computer languages, nor give
meaningful ways to compare them if I did have all that knowledge. But
as with many things our lives seem built upon, if no one else is going
to do it maybe it is time someone competent did. Or I could try.

I am not so sure whether this works our. Sure, in practice we often
seen things that start out as mini applications and grow into large and
complex things over time. I am just not sure whether it is realistic to
expect a single language to cover the whole range. After all, the rule
should be to pick the right tool for the job. Put it differently:
assuming all your extensions could be incorporated into Ruby then the
Ruby you would use for small scale scripting and the Ruby you use for
large applications would not have much in common, so you *are*
effectively using two different languages. The step towards something
completely different does not seem to big.

Two different languages... not quite, but I'm unsure how else to
differentiate it from the C to C++ transition. Adding objects and
abstractions created a superset for the original language, allowing more
powerful concepts to be expressed directly rather than requiring
everyone to create them every time they're needed. Here I'm trying to
verbalize how to better incorporate the tests and other implicit code
requirements into explicit structures the (compiler/preprocessor) can
utilize and the developers can understand. I'm not changing the
functionality of Ruby, nor limiting but rather trying to expand it's
expressiveness...

I would love to see it work out, but it may be too hopeful for our
current world. Hmm, the more I try describing this it does sound more
and more like a different use case for utilizing Ruby, and I am
certainly talking about adding syntax (even if within comments) so
depending on how much is necessary it could be/become an adjunct
language.

But can you tell me that a Ruby script and a large app are going to be
created in the same way? Don't they already have differing use cases?

And it is fine to pick the right tool for the job, but you can't be
serious that I should do my draft in Ruby and Rails, intermediate
requirements in Java, then do all production work in ...?
Eiffel/Ada/Prolog? If there are transitioning scripts that make it a
zero-time operation to upgrade, I would say: you've got the tool I've
been looking for! (Though having to learn completely new languages at
each level sounds like a consultant's creation, not a developer's.)
Otherwise I am still looking for those gradual transitions and
flexibility as Agile, Extreme, and (all?) other programming paradigms
promote.

Kind regards

robert

Thanks for playing devil's advocate,

-Chris

 

[Robert Klemme]

I don't have time for a full reply, but I definitely wanted to say some
more 8)

Oha, what might a full reply have looked like?

Unfortunately, but only for now!

Note, that I did not state that quality products cannot be successful!
But I don't see how the loose coupling is going to change anytime soon.

Nope, I don't 8) Partially I would say I am not looking for a
compile-time (singly-) statically-typed language. I want it to be
adaptable and further, *useful* by others without requiring source-code
changes in existing libraries.

But as long as those changes aren't done, you won't benefit from the
additional safety. You would then likely have to live with a hybrid
situation and I am not sure whether that is less safe because people's
expectations might go into the wrong direction.

I'm not convinced yet that it does, but I'm also not yet concerned that
it does bring up the halting problem.

I am not sure I understand that sentence properly. Your wording seemed
pretty ambitious:

It seems like if the contracts are defined the compiler/preprocessor should be able to guarantee all (at least small-scale) code interactions without writing any tests.

I would love to see it work out, but it may be too hopeful for our
current world. Hmm, the more I try describing this it does sound more
and more like a different use case for utilizing Ruby, and I am
certainly talking about adding syntax (even if within comments) so
depending on how much is necessary it could be/become an adjunct
language.

Maybe you start by writing up what your requirements are, i.e. what
kinds of checks you want to see. That might serve as a good basis for
discussion and will help you clarify your ideas.

But can you tell me that a Ruby script and a large app are going to be
created in the same way? Don't they already have differing use cases?
Exactly!

And it is fine to pick the right tool for the job, but you can't be
serious that I should do my draft in Ruby and Rails, intermediate
requirements in Java, then do all production work in ...?

Why not? If it works better?

Thanks for playing devil's advocate,

Playing? Who's playing?



Cheers

robert

 

[Jörg W Mittag]

There have been a number of efforts to add static typing (-ish)
features to ruby. The most recent is Diamondback Ruby; an announcement
for it was posted here a couple weeks ago. It has some kind of method
annotation special comment for declaring types of arguments, like you
wanted.

AFAIU, that's not the primary use case for Diamondback Ruby, though.
The intention is that, ideally, DRuby should be able to typecheck
*any* existing Ruby code without modifications. The type annotations
were primarily added because while DRuby can typecheck Ruby code, it
is based on MRI, in which many "Ruby" classes and methods are
implemented in C. Since DRuby cannot typecheck those, it needs type
annotations. Ironically, type annotations are also needed for Ruby
code that implements "static-ish" features by hand, because DRuby
cannot statically figure those out. The main examples are methods that
just take an *args array and then implement method overloading by hand
(e.g. String#[]).

But I *think* you can also use type annotations the way you describe,
by basically using a "double-entry bookkeeping" scheme similar to
Haskell: DRuby infers the types from the code, but then it compares
them to the annotation and checks if they match.

A nice property of DRuby type annotations is that their syntax is
derived from the semi-formal unofficial type syntax that is *already*
widely used inside the core and stdlib RDocs.

jwm

 

[Jörg W Mittag]

You might be interested in structural typing:
http://en.wikipedia.org/wiki/Structural_type_system

Of the languages I've looked at, scala is likely to come closest to
what you want. (i.e. a flexibly but statically typed language that
scales both down to small scripts and up to large systems).

Interesting trivia: Scala is actually short for "scalable language".

jwm

 

[Jörg W Mittag]

Generally Ruby seems flexible and pretty powerful and concise but unruly
and, well, unreliable. All the benefits but detriments of a scripting
language when mixed with (at least my) human fallibility. But if
someone isn't already working on these things it may be more prudent for
me to move to a different language or platform. Anyone have a
suggestion? More directly, is there a computer language group which I
should start shadowing as comp.lang seems more off topic than
discussion...

Maybe you are interested in the Cobra Programming Language
(<http://Cobra-Language.Com/>)? The main feature of Cobra is that it
is designed with a "no holy cows" attitude: if there is a feature that
makes sense, it is added. Period. No flamewars allowed. And so, while
other language communities engage in the umpteenth flamewar about
whether static or dynamic typing is better, Cobra simply has both.

Chuck Esterbrook (<http://CobraLang.BlogSpot.Com/>), the designer of
Cobra, has a very simple guiding principle: a programming language
should help a programmer to achieve her goals. And those goals are:
productivity and quality. There are a number of language features that
help with productivity (dynamic typing, implicit typing, expressive,
concise, lightweight syntax, high-level abstractions) and there are
features that help with quality (static typing, explicit typing,
language-integrated documentation, language-integrated testing, design
by contract). There are some languages that have all the features in
one list (Ruby, Python, Perl, Smalltalk, Lisp), some have all from the
other list (Eiffel, D), some have some from both lists (Objective-C,
Perl6 have static and dynamic typing, Haskell has static and implicit
typing plus expressive syntax and high-level abstractions). But none
have all of them. Well, until Cobra.

First two caveats: Cobra is a CLI language, and it is still in
development. However, Chuck Esterbrook has used Cobra commercially in
production systems for many years now.

Cobra achieves this by starting with the syntax of Python, but
massively cleaned up (no gratuitous self, no __underscores__, no
colons). Then you add the object model of C# and the contracts of
Spec#. Whenever there is a C# concept that cannot be expressed with
Pythonic syntax, steal from VB.NET. Add unit tests analogous to
contracts and docstrings. Throw in streams from Cù, for good measure.
Make static typing the default, but implicit.

Well, you get the idea.

jwm

 

[Jörg W Mittag]

I also love the dynamic abilities of Ruby, and I want to keep them.
However I want to be sure the code does what I want it to without
needing me to exercise all the code separately. From the last article
you gave, it sounds like Eiffel doesn't provide that feature - that the
contracts are only enforced when the code is run, which would not meet
my needs. It seems like if the contracts are defined the
compiler/preprocessor should be able to guarantee all (at least
small-scale) code interactions without writing any tests. Effectively
swat all Unit and Functional tests without writing external, dependent
code needing triggered updates. Except if that could be done, someone
would have already done it, right?

AFAIK, Eiffel only enforces contracts at runtime. But Micosoft
Research has a very powerful static analysis tool (Boogie), based on
an *insanely* powerful theorem prover (Z3, wins pretty much every
benchmark), both built as part of the Spec# project, which was a
superset of C# 2.0 with contracts and null-tracking. Spec# is now
defunct, but the team is now building the Code Contracts.NET library,
which is part of .NET 4.0. The bad part about Code Contracts being a
library: no nice syntax for contracts. The good part: because it is
"just a library", it works with *any* .NET language. And it just so
happens, that Ruby *is* a .NET language!

Code Contracts/Spec#/Boogie/Z3 can do some pretty amazing static
analysis. You can still have your contracts enforced at runtime, but
if Z3 can prove statically that the contract can never be violated,
the check can be omitted and when it can prove that the contract can
never be fulfilled, then your project won't even compile to begin
with. Also, there is a Visual Studio Plugin that is tightly integrated
with Code Contracts and can analyze your program at design time,
giving you things like squiggly lines for unfulfilled contracts or
displaying the contracts of a method in the code completion popup
window.

Lastly, I would love to see the assurance flexibility within the Ruby
platform. Sometimes you need a script (easy with any Ruby), sometimes
you need a 20+ person team working on a complex application (I don't see
this as possible without major, strict development practices). The
ability to tighten up an application from free-form script to
(Eiffel-ness?) seems like a great growth vector for my usage patterns.
We get both the immediate usefulness and the long-term maintainability.

You will be very pleased to hear that this kind of scalability is one
of the major design goals for Ruby 2.0. Scalability in problem size,
project size, team size, program size, from a single developer coding
up a 3 line script in a couple of seconds to a 100 person team
developing a 100 million line financial trading system over the course
of years.

Please note that Ruby 2.0 is still very far into the future, and so no
actual features have been set in stone to actually achieve these
goals. Some that have been talked about are selector namespaces,
method combinators/aspects, traits, static typing and contracts.

(Other types of scalability that are also in the sights are community
size and machine size (in both directions(!), i.e. modularizing the
language for embedded systems, but also adding better concurrency
support for massively parallel many-core systems).)

jwm

 

[Marc Heiler]

Cobra sounds interesting.

And the syntax is - for my eyes - clean.

However there is one thing I worry - isnt adding many features
problematic?

Like, I get to decide downright to the basic level to use only a subset
of this feature, to keep complexity down?

I am already struggling with this on ruby, but I found that - for me -
restricting myself to the shortest route possible to a solution works in
general very very fine.

Less has become more for me that way.

Ah well, guess I should try out Cobra - dont intend to steal the focus
of this discussion

 

[Jörg W Mittag]

Economic success and technical quality are two orthogonal concepts with
only loose coupling.

I would say it depends on where you are. While certainly far from
being anything even close to "mainstream", Eiffel is much more popular
in Western Europe than say in America or Asia. Bertrand Meyer is in
charge of the entire programming education at ETH Zürich both for CS
students and others, and, naturally, he uses Eiffel. He also runs his
University department in a very industry-focused manner, teaching
classes to programmers, collaborating with industry partners on
projects and so on.

I would assume that what can be checked at compile time is already
checked then. Eiffel has a quite elaborate type system with more
options of inheritance than any other language I am aware of. So that
buys you quite a bit of added safety.

Actually, AFAIK, Eiffel does *not* do any static analysis based on
contracts. The only contract systems I know of that do that, are
Microsoft Research's Spec# and its productized successor Code
Contracts.NET.

I think you are actually mixing up three different things there:
Eiffel's elaborate type system, the flexible object system and
contracts. Eiffel *does* have a very powerful type system that can
catch a lot of errors that other, more "C++-ish" type systems can't.
Eiffel also has a very powerful and flexible notion of inheritance,
including actual working multiple inheritance without all the
stupidity from C++.

And thirdly, contracts. Those are tightly integrated with the object
system and inheritance, but not, AFAIK, with the type system.
(Interestingly, there is a paper that proves that every contract can
also be expressed as a type, but that paper says nothing about the
practicality of such types. In particular, the types that correspond
to even pretty simple contracts are *ginormous* and require an
insanely complex type system that makes Haskell and Scala look like
BASIC in comparison. OTOH, some type system can easily express
restrictions for which you would need very complicated or even
infinitely large contracts.)

... which brings us to the halting problem:

http://en.wikipedia.org/wiki/Halting_problem

Yes, this is indeed a problem. More specifically, Rice's Theorem which
is based on the Halting Problem, which basically says that proving any
interesting static propertiy about a program is in general equivalent
to solving the Halting Problem.

This is one of the reasons why Spec#/Code Contracts can only check
some contracts at compile time. That being said ... Spec# *does* do
exactly that!

Maybe you get yourself a textbook about computer languages and one on
computational theory.

http://en.wikipedia.org/wiki/Computational_theory

When it comes to programming languages and programming paradigms you
certainly can't go wrong with

Concepts, Techniques, and Models of Computer Programming
Peter van Roy and Seif Haridi
ISBN: 978-0262220699
<http://MITPress.MIT.Edu/0262220695/>
<http://Info.UCL.Ac.Be/~pvr/book>
<http://CodePoetics.Com/wiki/>

or

Programming Languages: Application and Interpretation
Shriram Krishnamurthi
<http://WWW.PLAI.Org/>

jwm

 

[Jörg W Mittag]

Cobra sounds interesting.

And the syntax is - for my eyes - clean.

However there is one thing I worry - isnt adding many features
problematic?

Well, this is a very philosophic question that goes to the very heart
of programming language design. There are basically three different
schools of thought:

1) A programming language should have a very small kernel of very few,
very simple abstractions, plus powerful ways of combining these
abstractions. The prototypical example of this is Scheme ... I mean,
it doesn't even have *syntax*! Everything else can be built *on top*
of these abstractions. Take the famous book Structure and
Interpretation of Computer Programs as example: it teaches you how to
implement object-orientation, lazy evaluation, garbage collection, an
interpreter, a compiler, logic programming, heck, even a CPU(!) in
Scheme.

2) A programming language should provide many powerful abstractions
and paradigms. One of the most extreme examples of this is Oz/Mozart.
This programming language takes the word "multi-paradigm" to a whole
new level: it is declarative, imperative, functional, procedural,
object-oriented, lazy, strict, you name it. It even supports logic
programming, dataflow programming. For concurrent programming it
supports futures, actors, threads, ... Its approach is best
exemplified by the book Concepts, Techniques, and Models of Computer
Programming, which *also* teaches you OO, logic programming, lazy
evaluation and so on. But, unlike, SICP, it doesn't teach you how to
*implement* them (after all, Oz already supports them), but how to
*use* them. (A more mainstream example of a multi-paradigm language is
C#. Originally basically a clone of Modula-2 with a Java object system
and C++ syntax, it has since grown functional features, monads (in the
form of LINQ) and most recently dynamic typing.)

3) A programming language should play nice with other languages, so
that you can mix and match paradigms by mixing and matching languages.
This is of course the idea that Parrot and .NET are built on and what
the JVM is moving towards. And, of course, this approach is also
exemplified in a book: Programming Languages: Application and
Interpretation. This book teaches you again the same things that SICP
and CTM teach you, but this time it uses *different* languages for
each concept. Well, mostly Scheme, but lazy evaluation is shown in
Haskell and logic programming in Prolog. In my education at the
University of Karlsruhe, Germany, we were taught different concepts
using, among others, Java, Pizza, Gofer, Python, MIPS Assembly, C,
Prolog, SQL, OQL, XSLT, plus a whole range of very specific teaching
"languages", like lambda calculus, universal Turing machine,
µ-recursive functions, Semi-Thue sytems, Markov systems, the FOR
language, the WHILE language (whose only control structure is FOR and
WHILE, respectively), a hypothetical assembly language for which we
had to build a hypothetical CPU, just with pen and paper and so on.

Like, I get to decide downright to the basic level to use only a subset
of this feature, to keep complexity down?

Well, if you don't want to use contracts or tests, then don't write
them

Cobra even helps you out with that:

def m(p as int) as dynamic
"""
doc
"""
require
...
ensure
...
test
...
body
...

is the normal form of a method definition. If you leave off the
contracts and tests, it would be:

def m(p as int) as dynamic
"""
doc
"""
body
...

But if you *only* provide the method body, you don't need to
explicitly say that:

def m(p as int) as dynamic
"""
doc
"""
...

jwm

 

[Jörg W Mittag]

When it comes to programming languages and programming paradigms you
certainly can't go wrong with

Concepts, Techniques, and Models of Computer Programming
Peter van Roy and Seif Haridi
ISBN: 978-0262220699
<http://MITPress.MIT.Edu/0262220695/>
<http://Info.UCL.Ac.Be/~pvr/book>
<http://CodePoetics.Com/wiki/>

or

Programming Languages: Application and Interpretation
Shriram Krishnamurthi
<http://WWW.PLAI.Org/>

I *knew* I forgot one:

Essentials of Programming Languages
Daniel P. Friedman and Mitchell Wand
ISBN: 978-0-262-06279-4
<http://MITPress.MIT.Edu/0262062798/>
<http://WWW.EoPL3.Com/>

Also, Lambda the Ultimate (<http://Lambda-the-Ultimate.Org/>), or LtU
as it's known among its members (named after the famous and
groundbreaking "LAMBDA papers" series of papers by the inventors of
Scheme, with titles such as "LAMBDA: The Ultimate GOTO" or "LAMBDA:
The Ultimate Opcode"), is *the* online community for discussing all
aspects of Programming Language Theory (or PLT, as they commonly call
it).

jwm