Log in

No account? Create an account

Previous Entry | Next Entry

over. whelmed.

I was rambling in my thoughts on my way home from work today, not quite into the book I'm reading (I hate one of the main characters, and dislike the other two), but it's rare hard science and has to be appreciated for that, at least--I was thinking about my misbegotten attempt to teach java (aka computer science) at a local highschool many years ago. I'd really like another go at it. [[which reminds me of emails I'm ignoring and need to answer, I'm three thousand deep now--many of them of significant social importance at the very least, though by now many can be deleted as ignorable--but none of that is spam, and all of it is stuff I meant to attend to at the time, or even in my wisdom meant to attend to at some later time, which is still probably long past. sigh?]] But I'd really like another go at it. And then I thought about the book on java I started writing back in ... 2k, or maybe even '99. And then I started ranting in my mind about things I wanted to say and remember, and knew as they were happening that I was losing them--and I wanted to get home sooner to write them down and say something interesting that perhaps could start some intelligent discourse, which would then brighten my day. intelligent discourse that I don't feel too tired or stupid to participate in never fails to brighten my day.

the (less than intelligent) ramblings I have left, after returning home, checking email, catching up on LJ ((I told myself I would write first, and do these later, and ... well, such is the price, same as telling myself I'll write a dream down "later")).

    A problem with introduction to computer science is that students don't have a clue what they're being introduced to, and often--they're not introduced to it at all; they're led blind to its curves and told to feel it, to ponder it as it squishes under their fingers. Then, still blind, they're told to take the goo and make little structures out of it--a small pot, a vase, a mug.

    They have no clue what any of this means or why they're doing it. They don't know if their creation is ugly or bad, and it's insubstantial so even a proud parent can't look at it and treasure it for them.

    And that's _not_ computer science. What they're learning, or what they would be learning if they understood it, is software development--a trade, not a science. It is a good trade, and the trade must be understood to a large degree before any science can be put into practice... and as for science without practice, you'll just have to watch two mathematicians argue 'pure' math versus 'applied' math. It's an interesting sight, and different every time.

    Software development is two things, mainly, interwoven--it is creation, and integration. Creation can be for its own sake, for the sake of learning how to create, or for the sake of learning with the creation. Integration is communication. A project will be bits of both. In the idealized class room, you're almost only ever dealt the creation task--you're given simple projects that you can start and finish, and handed (or pointed to) a single api to use. In 'real' software development, you often have to integrate across many boundaries, some of which are more ready to be integrated than others.

    Some boundaries give you a human-like api, where you simply write to it in a manner that makes sense, and it works--remote procedure calls, or just libraries of procedures created by a third party, in the language you yourself are using.

    Then there are libraries written in common languages that you are not using, and you have to figure out how to wrap those libraries, or hook yourself into them; or decide that you can't, and move to something more compatible, or write what you need from more primitive parts.

    Then there's the embedded systems, essentially, where you embed another language inside your own code; it's simple enough, if potentially confusing, and often other people have already made wrappers (likely dozens of competing ones that are confusing in their clamor to be the one true wrapper).

    Next is the holy data massage, the translation from what one system likes to another, which can be as simple as flipping bits around, or padding columns of data, as hackish as attempting babel conversions, or as obstruse as doing multiple lookups, or even requiring (_gasp_) human intervention.

    This is what software development is. Once you can do these things in a span that keeps the attention of a human being, then you can move on to the science of it.

    Computer science is essentially applied math. It's knowing your time and memory constraints, and devising (or picking out of a cookbook) what data structures are optimal to your task at hand, what methods will return a good enough answer fastest. Computer science is tightly intertwined with software architecture, but tends to be more theoretical still. Software architecture takes these data structures and abstract methods, and (optionally) software development paradigms, and rolls them into something that is good, and can be made better without having to demolish the entire building. A proper software architect can design any building, and design it to last lifetimes, to grow and replace itself entirely, without ever 'from scratch' being a quicker way of moving forward.

And that's all I have to say for now. Any questions? Comments? I'm sure I say some mistruths in there, I know I meander, ... it's a rant, and one I hope to improve and to build on, perhaps to even evolve into, if not a book, a curriculum.

Though... shit, yeah. This then meandered into robotics--and where robotics comes into all this, and then from there where mechanics, and physics, and all that enter in. The robotics was going to take a look at merging two things--one is to extend computers into the real world, and the other is to extend mechanics into the digital world. There are reasons for both, of course, but those are (in my head) certain mindsets that people have, and when two people communicate with different mindsets and without the understanding of different mindsets, often no proper communication takes place.

more later, I hope. Posted the above rant to two groups I hope will have something interesting to say, which makes three including this livejournal. :)


( 12 comments — Leave a comment )
May. 5th, 2004 09:16 pm (UTC)
im very interested in computer science. any books on the subject you could recommend?
May. 5th, 2004 10:02 pm (UTC)
hard to say, really.

in what sense are you interested in it? :)

for the true beginner, the only books I know of are 'learn a language', and their claim to 'for the novice' is they explain terms about what a language is, and what a computer is, but not the why's of either.
May. 6th, 2004 01:21 am (UTC)
ack! i dont know. i wanna learn the linux.
May. 6th, 2004 08:01 am (UTC)
that's a different thing entirely.

the most painless way to learn a bit about that is to play with 'co-operative linux' -- http://colinux.org
May. 6th, 2004 06:35 am (UTC)
Thoughts in response to your thoughts
I love your thoughts and agree with them whole heartedly. But as a code-hack, I find the presentation a bit daunting.
I know that I am far from a computer scientist. Hell, my brother who was at University for years doing a co-op and is the smartest guy I know, couldn't hack the Science side and switched to Engineering. So I get that in it's largest scope Comp Sci is hard.

But having studied a lot of the broader concepts in abstract terms, and a dozen languages, and getting an overview of several OE's and API's, I also see a value of comp sci to me. I once spent an afternoon reading the tech specs of .jpg and a day on the W3's files re Email handling. I find it interesting and useful, but I don't have enough sci to understand how a .jpg compacts it's data or blows it back up again. I don't understand bit manipulation.

So I read this thinking, yes, Sci is good, yes, this is exactly what Sci is, but it's scarey and this doesn't address that. Which I think is only a neccesary tweak for certain audiences. But one to take into consideration.

Hope these thoughts are usefull,
May. 6th, 2004 08:07 am (UTC)
Re: Thoughts in response to your thoughts
yes indeed, quite useful -- definitely an avenue to approach. :)
May. 6th, 2004 10:33 am (UTC)
from stephen

Two things:

1. In every educational environment there is a tug of war between theory and
application; it's not exclusive to computer science. Though, I think
computer science has leaned farthest toward application of any of the major
disciplines. Even as an EE (a very practical discipline) at most schools you
are required to understand the science and the theory of electrons flowing
through wires.

2. Obviously you have never taken a computer science course at Harvey Mudd
College. "Computer Science" is tought as exactly that: using machines to
solve computational problems and all the theory of computation that goes
along with it. In the one intro-level course I took we worked on the theory
of solving mathematical problems with machines. No Java, no C++, no machine
code. Instead, we used clunky, proprietary languages designed from the
outset to help illustrate computational theory.

May. 6th, 2004 10:34 am (UTC)
from Kage
this is probably among the weakest of all possible comments, but:

i'd also like to see you address the recent trend in (commercial)
thinking, in which software development has come to be viewed as a sort of
straight-forward, low-brow, easily replicable process - not a true science
or (dare i say it!?) art which requires real intelligence, creativity,
ingenuity, application of experience, and appreciation of elegance. bring
some respect back to the goddamn discipline! ;)
May. 6th, 2004 12:04 pm (UTC)
from Brian
On May 6, 2004, at 11:54 AM, Brian Denny wrote:

Most of the rant is criticism of the status quo, so i am interested in
hearing more about your alternative ideas, ie your curriculum-to-be.

At Berkeley I learned about parsing, about concurrency, about data
structures and algorithms, architecture and memory. All the fruits of
computer science research. Granted, that's a lot different from
learning how to *do* computer science, if by that you mean the actual
technological innovation. But that's the nature of the undergraduate
curriculum. It's no different in a field like psychology -- as an
undergrad you learn what others have discovered, then if you're so
inclined you move on to grad school and start doing some actual

As far as the difference between CS and "software development":
Whether the subjects taught in undergrad CS are "computer science" or
not, they are certainly technical in nature. Whereas, to my mind,
software development has more to do with humans than with technology.
In some sense, writing code that does what you want is the easy part.
Writing code that does what the *customer* wants is somewhat harder.
Writing code that another programmer is going to be able to pick up and
understand and work with once you've left the scene -- IMO that's the
real challenge of software development, and one in which I feel I
received very little training, except in the School of Hard Knocks.

All based on my own limited experience, of course. :)

May. 6th, 2004 12:05 pm (UTC)
Re: from Brian
All very good points, thanks.

And yes, I actually am hoping to propose a curriculum as part of these rants.

I hope to leave part of the human equation out of it, but it does have to be mentioned, with further reading suggested at the very least. There I think it will be harder to be general and useful at the same time--an investigation of project management tools would be good, and code management, and all that. I don't know project management tools at all. But definitely something that a curriculum would need to address. Berkeley gave a platform for doing such, but like many things at berkeley, they either didn't care or wanted you to figure it out yourself, (or something).

I think a series of case studies will be necessary, towards that, and I'm largely not qualified, but I'll do what I can.

mentions of design patterns and anti-patterns would also fall in there.

a thought:
hello world, the guessing game... good stepping stones. that need to explain why they're being taught, while they teach.
May. 6th, 2004 01:27 pm (UTC)
from Tobin
61A was excellent at the "computer science" side of things. It used an
easy language that people could mess around with at home and do powerful
things with, and it exposes students to a host of very cool things. It's
the sort of class I'd take again for amusement.

61B was taught using Java and served as an introduction to algorithms and
data structures.

61C was taught using C and assembly language and shows students how the
computer works, down to the "bare metal" (a final assignment in 61C now is
to produce a basic MIPS processor in VHDL).

It seems to me that this follows *exactly* your manifesto for having a
balance of "theory" and "practice," and "teaching with languages people
are likely to use and have easy access to at home for playing around

How do you think these courses should have been improved?

My only complaint is that there was no honors sequence.
May. 6th, 2004 01:29 pm (UTC)
Re: from Tobin
An honors sequence would have been really nice.

Where this falls down is the context for practice. People take computer science and don't know why it is, why they're taking it, and why they're learning what they're learning.

Where this also falls down (cribbing from other comments), is the whole 'social' aspect--code does not develop in a vacuum, typically. And you don't get to work on it in any way you please. And you're _not_ handed a project on a platter. And you generally don't get to just drop a project after it's done. Hell, often you have to take something that someone else made, that's pure crap, and extend it to be something else, or fix an obscure bug.

I'm not focusing very well right now. More later, most definitely. I'm trying to archive comments from a few lists on the livejournal post.
( 12 comments — Leave a comment )

Latest Month

February 2016


Powered by LiveJournal.com
Designed by chasethestars