|
|
I was looking at the catalog from my old State U, and I noticed that it has a minor in CS that requires:
- intro programming (2)
- data structures
- computer organization / assembly
- discrete math
- upper level electives
While I certainly agree with the other 4 lower-level stuff, I have to question the need to do computer organization & assembly. Yes, it is important in some realms of CS, but I think that the study of CS has by now completely abstracted out that part of the body of knowledge of CS so that someone could consider himself well-prepared to do CS work (including the fancy-shmancy stuff at the graduate level) without knowing this. Sure, there are some folks studying CS as a minor that might want to learn this, but I don't think it's essential anymore. I could even make the argument that it should be an elective for a CS major.
|
|
|
|
|
What's in the "computer organization / assembly" course ? hardware stuff ?
I'd rather be phishing!
|
|
|
|
|
|
looks like a nice course.
I'd take it.
I'd rather be phishing!
|
|
|
|
|
I reckon it's important. I've worked with developers who had studied courses centered around web development - they get stuck not being able to think below a certain layer of abstraction.
Anything not in the accepted high level formats is horrible unreadable gobbledygook.
Sure you don't want to always operate at that level of thinking but it's infuriating to work in an environment where everything has to be serialized and sent over HTTP otherwise they can't understand/troubleshoot configuration of some infrastructure that operates at the TCP/IP level.
|
|
|
|
|
swampwiz wrote: I think that the study of CS has by now completely abstracted out that part of the body of knowledge of CS so that someone could consider himself well-prepared to do CS work (including the fancy-shmancy stuff at the graduate level) without knowing this.
Sure. Perhaps we can abstract away some more and hand out the degrees in every corn flakes package.
So go ahead. Let's produce more fools who can't write a simple one line method or property to set or check some flag bits. I can show you a nice, idiotic error that exists since .Net 1.0 that probably has been built in by someone who could not grasp the concept of enumerating bit flags. It will never be fixed to keep compatibility and makes an otherwise very practical thing almost useless to me because I constantly have to work around this tiny mistake.
And let's invent something that manages memory for those that would be thrown out of every library because they can't understand the simple concept of bringing back what you have borrowed. Let's make them believe that even thinking about managing memory is a very bad thing. This way we can produce idiots who can't understand the absolutely simple concept of a pointer and give me job security forever. Let's make a religion out of it and put it on the list of sins they will have to confess and atone for in code reviews.
Don't you dare to take away the joy of finding out that someone programmed an instant server crash with this simple line:
ds.Fill();
No error checking or exception handling, just a setup to let the server's memory hop out of their sockets instantly. And the idiot insists on having done everything 'as required' and absolutely unable to imagine that memory is not available in unlimited amounts. Nor was he able to estimate the memory requirements of what he did or understand why it's better to make such an estimate in the code before executing that one simple line.
Abstracting something away does not help those who are still learning. You only deny them any chance to understand what's happening and only few ever become aware that there is a little more to all they know or ever get around to learn about these things. Indeed, they are discouraged to do so by people who mindlessly repeat what they have been preached. Teaching students to rely on abstractions and not equipping them to understand them simply sets them up to fail.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 13-Sep-18 4:07am.
|
|
|
|
|
CodeWraith wrote: And let's invent something that manages memory for those that would be thrown out of every library because they can't understand the simple concept of bringing back what you have borrowed.
This is an amazing metaphor.
|
|
|
|
|
You proven again why you're the CP Member I respect the most.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
assembly language should definitely be there and people need to know whats going on at the lower level rather that just suck it up to javascript
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Absolutely yes!
Remember, this is a computer science course.
Computer science is not necessarily about programming computers although programming and development skills will form part of it.
I remember recruiting a young chap who had just come off some IT course who had a 2.1 and he looked at me with a blank face when I mentioned how understanding the basic mechanics of how a hard disc works and how data is stored on it will make you a better DBA.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It is vital, now more than ever. Embedded computing as everywhere, high performance low consumption low cost systems are spreading like butter under the Sun... and being able of tracing faults down to the hw level and fixing one's own tool (aka the workstation) is a skill that never lost value. In fact it is only gaining, due to the usage of industrial PCs in most applications in places of the traditional built-in systems.
Heh, I had a large international company pestering me for almost a year and offering me an amount usually reserved to managers just because I'm one of the few under-40 that has this kind of experience and knowledge. I'll be moving to them in 10 days.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
They should change it to
- intro programming (2)
- data structures
- googling for the solution
- discrete math
- upper level electives
|
|
|
|
|
googling for the solution Ask Siri/Cortana
FTFY
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
So....you think it's a good idea to write code without understanding what a CPU or memory are...
On second thought, there is a degree that basically does what you're talking about: CIS. That's the people that learn to write horribly hacky things in VBA.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
swampwiz wrote: computer organization / assembly
I first read this as meaning the kids are taught the discrete parts of the hardware, and assembling a computer, but after reading other people's comments, I'm not so sure anymore. "Assembler" (if that's what was meant), rather than "assembly", would've removed all doubt.
In any case - assuming my first guess was right:
Yes, I'd like them to know this stuff. But based on what I've seen IRL, I would NOT want most people anywhere near the insides of a computer.
|
|
|
|
|
This first bullet item is key to everything!!! However, many software _geniuses_ don't want to admit it.
John Gall, Systemantics + A complex system that works is invariably found to have evolved from a simple system that worked
+ A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system
+ In setting up a system, tread softly. You may be disturbing another system that is actually working
+ A system can fail in an infinite number of ways
+ In complex systems, malfunction and even total nonfunction may not be detectable for a long period, if ever
John Gall: • In general, systems work poorly or not at all.
• New system means new problems.
• Complex systems usually operate in failure mode
Finally I give you the explanation for people arguing about what Agile Methodology is:
John Gall A system represents someone's solution to a problem. The system doesn't solve the problem.
But, managers often believe the system (Agile) is the solution. No, it is a possible path to a solution.
Read more at: John Gall - Wikiquote[^]
Now that I've stirred the pot...have a nice evening. 
|
|
|
|
|
they all boil down to : sh*t happens if you let it happen.
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: they all boil down to : sh*t happens if you let it happen.
Nice! That's a very good summary.
I could just put that on a bumpersticker and call it my Software Development Architecture Warning. 
|
|
|
|
|
I'd say: S#!t happens. Period.
If you try to prevent s#!t from happening by holding it back, you'll eventually end up with a terrible mess.
It's better to let s#!t happen in a controlled manner.
BREAKING FAKE NEWS: Trump told the truth!
|
|
|
|
|
For a moment I thought that you were referring to John Galt... 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
That's really funny, because I stumbled upon the quote by John Gall in a book I was reading and I thought the exact same thing. I was like, "Is this that Ayn Rand guy?"
|
|
|
|
|
Please note that Systemantics does NOT promote "Use agile methods when building large systems". It promotes "Don't build large systems! If at all possible, do not build 'systems' at all!"
So, I think that your first quote is somewhat misleading for the main spirit of the book. The main spirit is "Don't do it". KISS and blackboxing comes much closer to the spirit of Systemantics than agile methods. But even though three out of four software developers cheer enthusiastically (whether wearing a plaid shirt or not...) when hearing a speech promoting KISS, it is all forgotten when they return to their keyboards half an hour later. Knowing a principle doesn't imply that you live by it.
This is actually the first time for the last 25 years that I have seen anyone but myself refer to Systemantics - the book was a cult text when I was a student, but more or less forgotten ten years later. That's a pity. (Maybe it is different across the pond.)
I just happens that today I am wearing a T-shirt with a Systemantics quote: Fail safe systems fail by failing to fail fail safe.
|
|
|
|
|
Member 7989122 wrote: It promotes "Don't build large systems! If at all possible, do not build 'systems' at all!"
It's funny, because one of my own quotes is..."As a dev, writing code may be the last thing you want to do." Devs so often hear a user describe a problem and then start writing code in their heads. I'm more like, "wait a second, I don't think you even need to do that thing. Just stop doing that and your problem is solved." People need to examine the work process they are following before even thinking about solving things with code.
Member 7989122 wrote: just happens that today I am wearing a T-shirt with a Systemantics quote: Fail safe systems fail by failing to fail fail safe.
Uh...are you John Gall?
|
|
|
|
|
raddevus wrote: People need to examine the work process they are following before even thinking about solving things with code.
Reminds me of a project I worked on, quite a few years ago (1980s), when computers/networks were still something new: We worked through all the work processes of the city administration (a 200.000 people town), from civil enigneering to health services, making a total Entity-Relationship model of the information handled. This was a pure analysis project - only in a few selected sectors could we draw a closed curve around a set of entitie that were to be automated.
You wouldn't believe the praise and acclaim we received for telling them how they were doing their job  I think we had people from every department telling us than now I see the dependencies between the cases I handle and the rest of the infrastucutre! Now I see where the bottleneck is in the document flow! Now I see...
Obviously, we did a little more than just describing: The data modelling did identify bottlenecks, unclear responsibilities, dependencies that should be avoided... We did support the guys in the administration find areas for improvement, but essentially, they came up with a lot of improvements themselves, from studying the data model. And they cleaned up a lot, in the non-automated procedures. When computerized tools were introduced several years later, the manual procedures were already cleaned up and streamlined, so that the computerization went very smoothly.
I know that ER modelling is considered outdated today, which I think is a pity, because I have seen it used successfully in both this project and others - much because it is quite well separated from program code, but done at a conceptual level. In the 1990s, several efforts was made to change ER into a way of defining C++ data structures - lots of coding related, not concepts related, facilites were added to ER models, and they lost their simplicity and transparency: You no longer could discuss an ER model with a non-technical customer without intimidating him with technical details. So we kicked out both ER and the customer from the modelling process, which I consider a major loss. Designers/developers today have very few tools suitable for having a dialog with non-techical customer, where the customer directly contributes to the model, and understanding what he is doing.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
