This sounds apocryphal to me. I mean, how would anyone build a system where no number above 2147483647 can be stored and not notice it? I mean, that excludes the vast majority of phone numbers.
The fascinating thing is that there are significantly sized urban areas with area codes < 214 (such as much of NY,NJ, Washington DC). Do these business survive off of customers just in those areas and they never pay attention to the fact that their systems are horribly broken?
This goes well beyond simply not having good testing though. It requires not testing and disconnecting the phone line and email so you can't get customers' bug reports. And never using the thing yourself.
Saturation is standard behavior of C's atoi() and friends. Over/underflow is signalled by returning largest/smallest possible value and setting errno to ERANGE. Many applications dont check for this (as it is not exactly straightforward) and thus get saturation.
MySQL does this too. I once found a bunch of Facebook User IDs that were all 2147483647 after someone missed the memo that Facebook was transitioning to BigInts.
"A string of characters acting as numbers? Hell no. People could put in anything. '234-fake-num' isn't a real phone number! This way we'll be sure the numbers are real. Besides, look how much space we'll be saving."
My google voice number is 786-J-Finnie... I really hate that I can't enter that on a vaild phone number on many websites! Since I specificially looked for that as a phone number, I haven't memorized the actual numers of JFINNIE, so I just put in a fake number.
I don't think zck was arguing for phone numbers as integers. I think he was just dissecting the broken thinking that would cause someone to make that decision.
I know next to nothing about the phone system, but in some countries there are legitimate numbers starting with 0. So among the many problems with this practice, it puts an arbitrary technical limit on your market.
Converting the phone number to hex and then storing them as character bytes as opposed to long integers, might save even more space on disk at the cost of hex-decimal conversion :)
hexadecimal is used, because the conversion is almost free (as oposed to decimal)
Also, phone numbers (for last 50 years or so) actually are hexadecimal strings (with extra characters - denoted ABCD*# - reserved for various special purposes).
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.
Y2K was such a little deal because so much effort went into fixing it. It's hard to say how big the problem would have been but considering that many financial systems would have been affected it probably would have been fairly significant.
It seems like if this explanation were to make sense, whoever implemented the string-to-number conversion was careful enough to implement saturating addition, but careless enough to not use a numerical type large enough to hold every possible phone number. I don't know if I buy that.
"Please press 1 now." Then, after a while: "Press press one now. If it is a person and not a computer calling, press 1 now.". Then, again after a while: "Press one of it will disconnect."
Integer overflow behavior varies a lot between languages; it can be undefined, some wrap around, others promote to a larger integer type, others convert the type to something else, and some clamp to the largest (or smallest) value.
For example, if you're using PHP, an integer will turn into a float when it overflows; if you then push the value into a MySQL databse, it'll be clamped.
Scary thought: this bug is nice and obvious when the data gets "clamped" to max_int, but what about when it doesn't and overflows to some value in the middle? No way to tell how many systems suffer from that flavor.
i'd say, not to store phone numbers in integer field require just one advice of an experienced colleague, no need in 5 years course (assuming a guy doesnt put boots on his head in other parts of his work)
EDIT: Maybe I give mankind too much credit. Search for a non-Dallas city here: http://24hourplaces.com/search.php