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