[opensource] RESOLVE

Shaun Rowland rowland at cse.ohio-state.edu
Mon Feb 9 12:38:19 EST 2009


On Feb 9, 2009, at 4:29 AM, Aaron Joseph wrote:
>
> 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++.

This is not my position at all. I am not claiming it is like C++.
I said that they have built something using C++, and that arguing
that a Java change is simple would mean that it would probably
already be more like C++ right now. I am saying their use of
C++ is a means to an end. I'm saying its not a practical experience
in using C++ because it's more about concepts than practical
experience - and that this reality indicates as much.

I am also not arguing that it is impossible to do it in Java.
I have no love of C++. You could view my statements as a weird
way of just putting out some points to which you could successfully
counter and have more of a chance of attaining the "sometimes
undergraduate holy grail quest" of changing Resolve's implementation,
without really even investing the time to get into specifics of
what they are trying to do on the conceptual side. I have to
worry about my day job and don't have time for that. This is more
of a high level logic exercise to me.

I did not speak up at the UG forum because I didn't think the
arguments you were making were beyond the superficial, and I
really have no strong interest in changing or not changing
Resolve as long as the core goals are met.

> 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.

Bruce's research happens to be software engineering. Real world
development could use some more thinking about the things the
class does cover. A tool used for learning concepts often does
not reflect what you would do in the real world. This is a
university, not a technical training school. If you think it
is a huge waste of time to learn what his research is about,
that makes me think that you are less interested in the fundamental
concepts and just interested in technical training. If that's
your main goal (since you used "huge waste of time"), then
that's more than arguing to change the language for practical
concerns. I assert that the debate will eventually really come
down to this, and this will detract from demonstrating how
Java could be used as a replacement while still being as good
at enforcing the same ideas because what you want to do is
strip out anything that's not practical but currently used
to teach those ideas.

The idea is not to learn the Resolve language. It is a CSE course
for CSE goals, where there are places to get the technical
training aspect you're looking for. You can argue that you
are an ECE major and it's not part of your sequence. That's not
an invalid argument, but your goal is to change a CSE core
course sequence for your benefit - so you have to argue against
that too.

Requires and ensure clauses are not useful in that in various
other languages you don't have to use them, but they are useful
in teaching you to think about the concept. To me your argument
boils down to not wanting to do these things because they have
no practical visibility in the languages you know and that
these courses would be better for you because what you need
is something that teaches you to use language <X>. That's so
not the point of these courses.

You can attack Resolve to death too, but if this is where you
are going, you will not succeed.

> 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).

So you want to ditch the things that are important in teaching
the concepts they feel are necessary as researchers in software
engineering and concentrate on the other things they happen to
also cover. That would seem contrary to the goals of the course.
This is an old and tired argument for those who have heard it
before and seen it debated.

> 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.

OO is not missing to my knowledge, and the rest of the items are
a secondary concern to the bigger goal. You can debate all day
about how those things are important, others can debate that you
can get them in plenty of other places, but they have nothing
fundamental in countering the use of the things you want to
have removed from the course.

> 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.


You just want to pick up practical knowledge on using a tool
that you would use as a software engineer. Their research is
in software engineering. It's relevant to teach that if you
are trying to enforce concepts. I find not understanding the
logic used in what is taught to in the course as an indication
the argument is weak. People argue that the things you want
to remove from the course are important, even if you don't
directly use them in real world development because you are
not required to... because they are important. Your view on
software engineering is not the same as mine, apparently.
-- 
Shaun Rowland
rowland at cse.ohio-state.edu





More information about the Opensource mailing list