Half of all the CS classes I've taken were at a 2 year community college and I still learned things on a more physical level. Not to mention physics and such were prereqs for some of the classes, and most definitely for transferring to a 4 year program. These same community colleges offered courses on assembly and logic and circuits and more. 2 year. I'm not even talking about universities at this point (which, also, I've attended and I don't see any variation from the above either).
Us CS majors with our heads stuck in code and theory may have never reached the depths of inner workings as you may have in a full 4+ year CE program, but that doesn't mean you get to demean an entire field of study thinking that people don't learn these concepts that apparently make you and other CE majors gods. And yes, no matter what your intent, you are definitely coming off as someone that is being incredibly snobby to say the least.
I have learned and I know at least a good smattering of basics on a physical level and have seen such curricula at all kinds of schools of higher learning. I would hope that anyone that intends on using their knowledge somewhere would care to understand just as much if not more regardless of their major or education. People that think it's acceptable to store phone numbers as integers clearly didn't.
I study CS and the first year we learned about digital logic, how to build memory, clocks, ALUs, etc. in parallel with learning about loop invariants, operational and denotational semantics, computational complexity, algorithms and data structures, algebra, real logic, how to prove things formally, and emacs.
There were some boring courses as well, mathematical analysis etc.
Where do you go to school? Where I went, denotational semantics and code proofs were taught in a senior level class (I went to a public university though). I think you might be the exception rather than the rule.
Still, you're correct to say that engineers are taught the things the grandparent mentions in CS courses.
How do you understand that a quicksort is faster than a selection sort at the core level without theory? I mean, I see what you're getting at. That does help you understand how to speed things up at a very low level and might be useful for embedded systems programming or kernel hacking. But most programmers work on a much higher level and need to understand a lot more concepts than that.
For instance, it takes a lot more to build a scalable and reliable system (especially one that must scale to multiple systems) than simply knowing how the circuits are designed. You need to understand network protocols, how things are stored on disk by databases, a bit of graph theory, how caching works, and a whole slew of other things.
Would it be beneficial to learn this all from the ground up? Probably. But I doubt many college students would be thrilled by the idea of spending 20 years finishing their degree.
And what I'm trying to get at is that there are about zero CS graduates that do not know that integers usually are limited to the word size of the architecture you are working on.
If you're talking about really crappy schools and crappy students, then I agree, but what is there to debate then? There are no crappy engineering schools or stupid engineers?
The kind of people who write a program that stores telephone numbers as primitive ints are not CS graduates.
I'm not trying to compete with you. Nor am I trying to imply that CE majors can't build scalable web systems.
I'm just trying to explain that the interesting problems in CS are different than the interesting problems in CE, and therefore benefit from a different approach. My experience has been that the difference is simply that CS majors get told "This is how you create programs" while CE majors get told "This is how you create hardware that can run programs". No more, no less.
The way you're phrasing things is inviting a pissing contest where it's unwarranted. A proper CS degree and a proper CE degree do not differ that much in their mental rigor. The former is higher level than the latter, but for the most part it's turtles all the way down. CE certainly gets messier where physics get involved, but it's not fundamentally a different kind of thinking from software engineering, you're just operating at different level of abstraction where the constraints are different.
Saying that CS is about "this is the best way to code this type of algorithm" is insulting. CS is not about coding at all actually. It's more about "these are the best known algorithms for solving such and such mathematical problems". The coding part is what you figure out on your own in the labs. There is a significant machine architecture component as well, where you learn how the mathematical models map to physical hardware, and what your constraints are.
> I feel it's that very ability to piece all of that knowledge together on our own while forming highly complex (and scalable ;)) systems that separates C.E. from C.S. Note that separation does not imply one is better than the other, only different.
So what is it that you think software engineers do? Retype BASIC programs out of Byte Magazine? You disingenuously state that you're not making a value comparison, yet that can be the only purpose of such a god-like description of the field of CE "in comparison to" but without a description of CS.
> And another personal example, I've designed a web-based multidimensional database application framework that allows me to create nearly any web app within minutes to days (depending on the scope)... highly scalable... and the database is entirely of my own design, works flawlessly, and benchmarks put it ahead of mysql. Again, this isn't a competition... I'm just proving a point that I didn't need 20 years of education... just needed a mental map of a computer's internals. Because specific theories have not been ingrained into my head (just cold hard facts)... I'm able to think outside of the box and sometimes (definitely not every time!) design a better system with a little more effort (because I have to make it up as I go, based on the knowledge I have).
Wow. This is the height of hubris. Did you proof this? I have news for you; you are not making world-changing breakthrough software based on your intimate knowledge of hardware (if you are, by all means show us the code!). There is plenty to think about anywhere along the abstraction ladder, and the point where you hope to make a dent will get diminishing returns the further you move up or down the ladder—just ask the assembly programmer who got replaced by a web developer when the ROI for bit-flipping optimizations crossed over the very low threshold of having read Javascript for Dummies.
I dunno, maybe I just got trolled, in which case well-played. But if you really think this way you need to meet some world-class programmers and get some of your code reviewed to get some perspective on how "flawless" it really is.
If there's a salient point trying to claw its way out of your post, I think it's that there are more crap CS programs than crap CE programs simply because there's a market for crap programmers whereas hardware has to be reasonably well-engineered from the get-go since it's more expensive, rarer, and is created pretty much exclusively by companies for whom hardware is their core competency.
"this is the best way to code this type of algorithm" is insulting. CS is not about coding at all actually. It's more about "these are the best known algorithms for solving such and such mathematical problems"
These two are essentially the same, just worded differently. I shouldn't have said "best way to code"... you're completely right about that... been awake for way too long.
I think the fact that you think these two are essentially the same is where the problem is. VERY different statements. I won't blame your CE education for this, but any CS major would see the difference :-)
I went to University in Sweden, this was the first year in an undergraduate program. A public university of course, we're dirty socialists after all ;)
We learned denotational and operational semantics but only used operational semantics in the exam.
I can't imagine private universities being of higher quality. It's not true of private primary schools or private high schools here.
I can vouch for the majority if not all universities in my country and all of Scandinavia. I don't dare speak for europe as a whole, mostly because the UK does things more like in the US, see Dijkstras commments on the difference between continental and anlgo-saxon engineers.
Yes, we covered the electrical bit of computers briefly, because the chemistry bit is not very interesting when writing software. Two's complement and IEEE 754 etc. are interesting, so we learned that.
My physics and chemistry are on high school level only, so energy levels, S,P,D,F clouds is what I remember from chemistry. The last physics I recall was special relativity, general relativity, time and space dilation, quantum mechanics, the copenhagen interpretation etc. I was not really into those subjects and this was years ago now.
I don't see what physics have to do with how integers are represented other than the fact that one way to do it is to use eletricity and transistors. Another way of looking at it is to see the registers as tuples of ones and zeroes. In reality, errors happen on levels below the bit, but the best we can do about that is to use checksums etc. or so you use your chemistry skills when writing software storing phone numbers?
When I say we learned how to build memory, I mean how to build gates out of transistors, how to use them to build latches and flip flops, building registers and larger circuits of read/write memory. No, I'm not interested in the strings to fermions to hadrons to semi conductors to transistors bit, but knock yourself out ,I will not write down instructions for you how to build a latch out of quarks.
We read Structured Computer Organization by Tanenbaum.
> Thanks for the downvote(s) by the way! Glad I'm allowed to have a real, intellectual conversation on HN.
Thanks for making HN look like reddit. I have no idea who's downvoting, I did not know you could downvote on HN.
Another difference between Sweden and the US is that in Sweden if you're studying CS then you spend 4 years taking basically nothing but CS and Math classes. Sure you can take classes outside of those departments, but it's neither necessary nor actively encourages.
In the US it seems that most people take a far wider variety of courses. So even people who major in CS have dabbled in some Humanities, Languages and/or other sciences.
I got worked up because your comments are just like any of the other millions of Computer-Scientists-don't-know-anything-about-anything-and-are-only-in-it-for-the-money comments you see everywhere. You could have spent two minutes googling looking at curriculums.
As a Swede, I could have included more EE courses in my CS masters degree than you have in your engineering degree, had I wanted to.
>I'm guessing whoever has downvoted me is pretty young and/or still in school. […] I guess those early days seem to be a bit touchy because you feel like you have to prove yourself or something. :)
I don't think you're helping yourself…
You don't have to be young to find the following patronising:
>No cheating! :)
>If you don't know how to do this then I'm actually right about my assumption.
> There's nothing wrong with me proving my initial theory (and falsifying fabjan's hasty "you're wrong" post) that C.S. majors don't know as much about the inner workings of computers as C.E. majors.
Your initial comment was about the representation of integers, not all the inner workings of a computer. Or course I don't know all the details.
Computer Scientists are Formula One drivers, Electrical Engineers are the guys who change tires and fills the tank up in 4 seconds, which is awesome. I only speak the truth.
You offend anyone with a brain when you write blatantly wrong assumptions about how only the EE master race learn about how integers are represented.
Just where did you get the idea that an Elecrit Engineer knows more about the types in MySQL than a CS graduate does? You're also the one who brought up the whole education thing, as if the morons who programmed these silly systems that store telephone numbers as integers have any education.
Almost all universities in the US teach in CS what is needed to know how to deal with this issue.
Not many universities go from electron to semi-conductors. But you don't need that to understand overflow/underflow.
For example, as an undergrad I had a year of architecture and a quarter of digital circuits. So we study how to build an 8bit CPU from the digital logic level. And then we study assembly language. Then microcode (have to implement 68K support for VM), microinstructions, controllers, DMA, RAM, ROM, registers, caches, TLBs, up the foodchain, etc...
Again we don't understand this at the analog circuit level or lower, but I'm unclear at how solid state physics knowledge would help prevent this bug? If you understand what I've described, you shouldn't have any problem seeing where this issue came from.
> "It's safe to say that whoever is storing phone numbers as integers either didn't study or didn't receive a proper education on the inner workings of a computer."
...or that they didn't absorb it. A lot of the comments on this post are indignantly claiming that "anyone who has taken a CS class...", as if every lesson of every class is perfectly absorbed by every student. As someone who teaches CS, I assure you that we discuss appropriate data representation right from the start, but I can attest to the fact that even students who did understand the general lessons about strings vs. ints (vs. other things) sometimes aren't great at applying it.
And while decent testing should have caught this, sure, test-driven design and effective regression testing was long an on-the-job training sort of thing; good testing as an integral part of the programming process was not a widespread part of the ugrad CS curriculum until fairly recently (and is far from universal even now).
I'm a CompE and I interview countless CS and CompE's for entry-level programming jobs and they consistently fail horribly at business-logic decisions. More than 50% of the time, people with 3.5+/4 undergrad and 3.5+/4 masters can barely write a function and discuss the design decisions (e.g., recursive vs. iterative, caching) behind problems as simple as returning the Nth number from the fibonacci sequence.
I've seen over and over again that knowing the physics (well enough to get A's in class) behind a computer and how it stores integers is NOT enough information to deduce good patterns and practices.
A C.S. major would at the minimum learn to test against boundary conditions. In the case of a U.S. phone number, one would test against 000-000-0000, 999-999-9999, and also check what happens if someone puts in garbage / international numbers / parenthesis / other things like that. The 999-999-9999 test would catch this immediately.
I'd go further to say that anyone who hasn't been bitten by an integer overflow bug in the past cannot have written enough software to qualify for a CS degree, unless of course they write all their software in languages that insulate you from it. I might be biased on that one, though, since I was first bitten by this bug on 16-bit systems: you can multiply two not-especially-large numbers and overflow a 16-bit integer.
For what it's worth, many of the best programmers I know majored in electrical engineering. On the other hand, many of the best programmers I know majored in math. They are likely to know even less about the inner workings of a computer.
Where I went to school(in the US) the first two years of CS and CE where the same, except in the class that covered digital logic. Then the CEs had an accompanying lab where they had to wire stuff up and CS majors didn't. All of the physics, math, and programming background were the same. After that CEs degrees were more EE than CS.
I'm hoping that at least half of C.E.'s would be able to make that logical deduction given their knowledge on ints and the possible lengths of a phone number. :)
Disregarding the fact that all CS graduates know how integers are represented, You don't need to know anything about that to know that you should not store phone numbers as ints.
You will typically normalize telephone numbers when storing them, that means prefixing them with their national code and two leading zeroes or a plus sign if you want to be fancy. Neither a plus sign, nor double leading zeroes lend to storing as an integer. Even if you're not fancy and normalize your number, there are numbers that have leading zeroes.
Well yeah, they explain how numbers are stored in a computer and whatnot. It's just that for most software programming, it isn't a terribly interesting or difficult to solve problem. I suppose after so long working with graph algorithms and Turing theory, people might forget these things, but it doesn't take a great deal of training to remember that numbers have limits in computers. I think this is more a case of simple stupidity than lack of education.
The people in question likely haven't had any formal education at all, they're self-taught.
I took CS, and my second class involved assembly (starting with JVM bytecode and then 8088) and my third was C++. CS majors know what integer overflow is.
