[opensource] RESOLVE

Wyatt trent.arms at gmail.com
Mon Feb 9 07:27:46 EST 2009

Hoo boy, this one got pretty lengthy.... :/

Some observations I will make.  They don't have any great ordering, and they
may not all mesh well, but they're here.  For the full disclosure, I don't
particularly like Resolve in its current state, but I appreciate the intent.

It's interesting to bring the natural language argument into this; it's a
similar one that I use frequently when explaining what it is to be a
programmer.  I disagree entirely that "natural language" is, in itself, a
discipline in quite the way you describe (English shares a lot with the West
Germanics and Italics, sure, but what of the Indics, Slavics, northern
Germanics, Baltics, or Celtics?  Things further outside the scope of PIE,
such as the Altaics, Niger-Congo, Sino-Tibetans, or sign languages?  ;) )
but you are correct that programming (as a whole) can be treated as just
another language (I somewhat consider assembly to be yet another,
incidentally).  The individual "programming language" is best thought of as
vocabulary and, as you'll hear any accomplished polyglot say, vocabulary is
cheap.  From this we can take away that knowing your discipline is key.  The
language is immaterial to the argument at hand, at some level, and we seem
to accept this as undeniably true.

Learning how to order water at a restaurant or receive directions to the
bathroom shouldn't also involve discourse on astrophysics.  This is one
mistake in particular that I feel Resolve/C++ could afford to rectify in its
specification style: it has neither the advantage of clarity that natural
languages have nor the mathematical rigour of a formal language.  It doesn't
help that it's also inconsistent with the combined canon of mathematical and
programmatic idiom, either.  This is a purely cosmetic change that could
very well serve to make Resolve much more palatable to those who have
programming experience (which really should be everyone.  Is not CSE201 or
equivalent still a requirement?) while sacrificing nothing for those who
have never written code.

I think we can all agree that using a language even a small amount will
expose one to its strengths and weaknesses in a manner that its use and
relevance is apparent enough.  Not all languages are created equal for all
tasks.  Except, beginners don't know that.  Considering we seem to assume a
zero-exposure scenario (I've personally always thought it strange that
someone would go to school to be a programmer and yet never have had the
gumption to at least actually do some reading about it beforehand) I've
always felt that a beginner's survey class that introduces the concepts as
truly language independent rather than simply making that claim would be
highly beneficial.

Start with C for a few weeks so they'll understand better how the machine
interprets things and get a grounding in debugging, checking their own work,
and (hopefully) using comments.  Move to Python and they see how high-level
languages aid the programmer with high-level constructs and other niceties,
but also the performance penalty (Python has the added bonus of indentation
as a syntactic element, thus reinforcing consistent code style that was
voluntary before).  Have them deal with different languages and scenarios,
do some problems over in a different language, use to read documentation
early on, etc.  Programmers should understand things like type systems, the
exitence of programming disciplines, and the perks and drawbacks of
interpreted verus static languages.  These kids should at least have heard
about these things before encountering Resolve (though they'll be
disappointed greatly by the documentation they find when they get there...)

Knowing a little vocabulary is hardly enough to get by, and certainly not
enough to be anything more than crude.  I see this as where using a
different language could be a compelling benefit to the student, moreso than
attempting to so firmly reinforce concepts that become more and more obvious
as one progesses into the field of programming as a whole.  Having
experience using a language matters.  Switching from something that you've
used for ten years in day-to-day work to a new language will cause a
productivity penalty, possibly for a significant duration.  Whether it has a
smaller standard library or a larger one, the body of knowledge concerning
performance pitfalls and gotchas is simply not there in your head.  And thus
you encounter that adage that 70% of programming is reading.  Four quarters
(because realistically, if you don't know anything else, and no one else
knows anything else, why would you NOT use Resolve for 560?) is quite a bit
when compared to "nothing;" that's a full 44 weeks of using a language
almost every day.

A language switch might not be strictly necessary, but as Patrick Lauer
always tells me, "You can only use it if you can explain why it's bad."
Words to live by.

Students, as a whole, are loathe to entertain lessons that are irrelevant.
Argue all you want about how they need to know the concepts, if you can't
make it immediately relevant to them, it's breeding discontent.  Hello world
should ideally give way to very few problems that have only one solution.
The multitude of solutions will, in and of itself, provide plenty of content
for lectures on what went right and wrong.  Engage the student with useful
discourse that can be applied immediately and universally and they will
thank you for it later.

Never in any of my lectures was the purpose of Resolve stated outright in
clear language.  "Resolve exists as part of an ongoing body of research
intended to provide a meanse to prove that code does what you think it
does." I believe this is more-or-less what I was told when I actually
bothered to ask.  But why did I have to ask?  Even saying "Contract
programming is a discipline for verifying the design of your code." with an
accompanying description of what that means in a practical sense would be
more useful than resounding silence.  Thank god for Wikipedia and Google,

Incidentally, the writing of the Resolve docs could be improved.  If you
must expose them to tedium, at least show them what docs SHOULD be before
forcing them to write docs in 560.

Why is a single class spread across four directories and four files?  What
purpose does having two directories of files that do nothing serve?  To my
recollection, those files are replicated verbatim in the other diretories'
files. Re: students and BS busywork.

Maybe this is too obvious, but why teach Resolve/C++?  What criteria does it
meet that no other language does?  The contract programming paradigm has its
merits, but not piled onto C++ like this.  Languages like D that actually
have contracts built in already would seem a much better fit.  What ever
happened to Resolve/Ada?  The only novel thing I can really see that doesn't
seem to be replicated elsewhere is the swapping.  But what is the benefit of
that?  No, really, what's the actual lesson to be learned in making it
difficult to perform non-destructive operations on your variables?  Whatever
it is, considering that it's not applied especially consistently (e.g.
Resolve "pointers," initialisation of variables), I feel like it must be
losing something for it.


On Mon, Feb 9, 2009 at 04:29, Aaron Joseph <bonesawosu at gmail.com> wrote:

> I think Tyler's analogy was very good. If you only spoke German (only knew
> resolve) and wanted to go to a English (java [or any other "real" language)
> speaking school (internship/other cse class) then you would have a harder
> time keeping up. You would spend the whole time learning English (java) and
> would have less time to work on the actual task at hand (actual
> programming). I don't think that the languages (English and German) really
> have anything to do with the overall concept he's trying to explain.... so
> you should focus more on what is metaphorically being said.
> Have you looked at the 221,222,321 sequence syllabus/notes lately? Resolve
> C++ is definitely meant to seem like it is it's own language. That class
> couldn't be any further from C++. They call 'classes' 'components' they use
> 'INTEGER' instead of 'int'... they pointers are checked pointers so they
> aren't as cool as real pointers. You mention that it's a C++ class, but it
> just isn't even close to being C++.
> The class is based around Bruce Weide's research. They try to make it seem
> like in software design you use 'requires' and 'ensures' clauses for
> everything, and those clauses are based on these cryptic math definitions.
> But in real-world development you don't do that. So why focus so much on
> that? It's just not focused on the right thing. It's a huge waste of time to
> force students to put Bruce's research into practice. Resolve is an idea
> better left for research. You may still think resolve is a good language to
> use.... but do you think it's a good idea to teach students practices that
> aren't actually used in the real world? Concepts like recursion are
> useful... but requires and ensure clauses aren't. If software design should
> be taught with a language like resolve then why does MIT use Java in their
> introductory software course? Why does Stanford use Java? It seems like
> school that are producing the type of talent they do would know what to
> teach. So why don't they teach resolve [or some other language that one of
> their CS faculty happen to be researching] ? It's not like I'm suggesting
> anything more than to switch to doing things the way other colleges do it so
> that OSU students won't be behind in terms of skill/knowledge/exposure. You
> can defend resolve to the death... but I just don't think resolve it worth
> learning.
> This might also be a good time to ensure we are all on the same page in
> terms of what we are arguing. I consider resolve to include the 'requires'
> and 'ensures' clauses... the parameter modes... the math definitions... and
> the different syntax (INTEGER instead of int, TEXT instead of string,
> COMPONENT instead of class, etc.).  That's what I want to ditch. The part
> that can be transferred over to a java based course would be things like
> recursion, trees, linked lists, sorting, pointers (please don't respond with
> comments about java not having pointers because you could easily implement a
> pointer class that is equivalent to what they use in resolve since they do
> zero pointery things with the pointers they use in resolve). And java would
> be able to add in things like Object Orientation, IDEs, source control (MIT
> gives every student a repo to use during their entire school career),
> libraries, private/public/protected, and sooo much more if they wanted.
> It seems like it should be a simple argument... a SOFTWARE ENGINEERING
> course should focus on teach students real-world SOFTWARE ENGINEERING. But
> for some reason everyone want to argue why we should learn about Bruce
> Weide's research during our software engineering course and then just learn
> actual software engineering on our own. I don't think I'll ever understand
> the logic behind that argument. I think they should at least change the
> title of the course to "Introduction to Bruce Weide's Research". That way I
> couldn't complain as much about them not teaching much actual software
> engineering in our "software engineering" course.
> --Aaron Joseph
> On Mon, Feb 9, 2009 at 3:32 AM, Shaun Rowland <rowland at cse.ohio-state.edu>wrote:
>> On Feb 8, 2009, at 12:34 PM, Tyler Sampson wrote:
>>  However, I ultimately find the method to be flawed. Let's go back to our
>>> natural language analogy. Let's pretend that we're parents of a newborn
>>> child (a freshman!). We want to teach our child how to communicate
>>> effectively, and good concepts behind language. Unfortunately for Junior,
>>> English (read: C++) is a really terrible language for this. There's lots of
>>> confusing syntax and inconsistent rules. So, rather than teach Junior
>>> English, we decide to teach him German (read: Resolve). It's sort of like
>>> English, but the rules are a little more predictable. (Note: I'm not a
>>> linguist so I don't know if German is actually less complicated than
>>> English...just assume for argument's sake that it is.) So, we spend the
>>> first 5 years (read: 221/222/321) of Junior's life only speaking German to
>>> him. Then, we send Junior off to Kindergarten (read: internship search, or
>>> CSE 560). Uh-oh! It's an English speaking Kindergarten (he understands
>>> Kindergarten, since it's a German word, but that's about it). Junior fails
>>> and gets put into the remedial class. Of course, since he has such a great
>>> understand of natural language concepts now, he flies through the remedial
>>> class and is soon speaking English pretty well. However, he is now far
>>> behind the other children, because he failed Kindergarten.
>> The analogy seems about as flawed as you find the method in my
>> view. I'll use the same terms. Kindergarten in this case does
>> not require that you speak German. If you don't know English,
>> you can speak German. This is true if kindergarten is CSE 560.
>> You can take English classes before kindergarten as well (in
>> both cases if you are a CSE major). I don't know where this falls
>> in the ECE sequence exactly, but to me that's ECE's problem to
>> figure out. These are core CSE courses. That's just a view on
>> how best to serve the students of the CSE department. Maybe if
>> an ECE major is depending on a language so much, they should be a
>> CSE major instead? It seems a little odd that the languages
>> an ECE major knows would be so critical to their job prospects.
>> If this is so important in getting a job that requires an
>> in-depth level of experience using Java, C++, or whatever
>> then it seems to be something geared toward software development.
>> If what I said is true, and it seems it would be for at
>> least most cases, then this seems more like complaining
>> about the whole method because it was found to be annoying.
>> If the language used is more important and I just don't
>> see it, then perhaps ECE should make an adjustment to better
>> serve their goals. I realize there is the possibility for
>> a grey area here too, and then again - the world is not
>> perfect either.
>> Additionally, thought I realize this is just an analogy, the
>> differences between English and German aren't the same as between
>> C++ and Java in my view. I am not a linguist either, but that
>> seems accurate to me. Since I am not a linguist, I am just
>> offering that as an opinion which has no strong background
>> (except how it is easier for me to learn a new programming
>> language as opposed to a spoken language - so practical
>> experience).
>>  Maybe the situation I have provided above is a bit contrived, so let me
>>> explain my point straightforwardly: there is no reason not to teach a "real"
>>> (i.e. industrially used) programming language for teaching concepts. Now, as
>>> I have said, C++ would be a bad way to do this. It's clunky, got terrible
>>> syntax, etc. I have not seen one good reason anywhere on the Resolve website
>>> that explains why Java cannot be used. The only thing I see is that they
>>> want to hide reference/value semantics until the second half of the
>>> sequence. I had no experience with Java coming into 421 (which I took last
>>> quarter). I was shocked at how similar many of the things that exist in Java
>>> were so similar to Resolve, such as interfaces, extends, abstract, etc.
>>> (that basically are represented by virtual void or =0 in C++).
>>> I get the argument of using an easier to understand language to teach
>>> concepts. Java is that language. The way  the sequence is taught now
>>> accomplishes its objective of teaching concepts of CS. But if it is possible
>>> to do the same thing, while giving students experience with a programming
>>> language that is functional outside the Ivory Tower, then why not do it?
>> Perhaps because we've moved on from changing the language to making
>> fundamental changes to the method used to teach the concepts. If
>> anyone can answer how changing the method used to teach the concepts
>> now in such a way that it offers more practical Java experience, then
>> they might have a shot at changing things. This goes way beyond these
>> analogies. That is something best discussed with the implementors.
>> The view supporting changing the language seems to be geared toward
>> this idea that it'd just be a simple thing to do. If it were so
>> simple, then one could argue that the course would already be
>> a practical C++ learning experience. It certainly is not seem
>> that anyone has that view.
>> --
>> Shaun Rowland
>> rowland at cse.ohio-state.edu
>> _______________________________________________
>> Opensource mailing list
>> Opensource at cse.ohio-state.edu
>> http://mail.cse.ohio-state.edu/mailman/listinfo/opensource
> _______________________________________________
> Opensource mailing list
> Opensource at cse.ohio-state.edu
> http://mail.cse.ohio-state.edu/mailman/listinfo/opensource
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.cse.ohio-state.edu/mailman/private/opensource/attachments/20090209/c22ec559/attachment-0001.html

More information about the Opensource mailing list