[opensource] RESOLVE

Tyler Sampson tdsampson at gmail.com
Mon Feb 9 10:10:00 EST 2009


Again, don't focus on the German/English thing. I wasn't trying to get into
a debate about Indo-European languages :)

My argument also didn't have anything to do with ECE/CSE majors. It focused
entirely on the content of the series, for all students. Let me restate my
point (new line for emphasis):

The Resolve sequence works fine to introduce programming concepts, but if it
is possible to do the same thing using a "real" programming language, why
not do it?

I still have yet to see a compelling argument explaining this. I'm not
arguing that the entire method should be changed, or that switching from the
current sequence to one taught in Java would be an easy transition. What I'm
arguing is simply what I stated above.

Also, while I agree with Aaron that the formal math specs are a little
overkill, I don't agree that design by contract should be done away with. In
fact, it's a very useful concept and a great way to think about programming.
The problem is that, as Aaron pointed out, very, very few places would ever
think about going into that amount of mathematical rigor when designing
software. It takes way too much time in real-world situations. I have read
the research papers posted about how a company did use Resolve's formal math
contracts and thereafter had very few problems with bugs. That's all well
and great, but the problem is that simply nobody does that. Until that
practice is more widely accepted, it is pointless to force students to do
that. Well, not pointless. It might be a good exercise to make students do
this for a quarter (221) to get them thinking in these terms, but to force
it for 3 quarters is a little harsh.

Finally, I do agree with Wyatt that on day 1, the 221 instructor should
present an explanation of why Resolve is taught. Does this happen? If it did
when I was in there I don't remember.

-- Tyler Sampson



On Mon, Feb 9, 2009 at 7:27 AM, Wyatt <trent.arms at gmail.com> wrote:

> 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,
> right?
>
> 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.
>
> Cheers,
> Wyatt
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/149e6db9/attachment-0001.html


More information about the Opensource mailing list