We talked about the Therac-25 in Engineering I. What you said is likely true, but there were two additional faults we discussed:
UI fault: it regularly put up a lot of error dialogs which looked the same. They could range from "invalid data; reenter the field" to "if you hit radiate now, your patient will die". Technicians used to the first kind would learn to ignore the dialogs...so they'd miss the second also.
There was a metal plate that was supposed to be in place when using one kind of radiation but not the other. It depended on software to ensure that this plate was in place. There should have been a hardware interlock for a precaution so simple and so important.
If you make a commercial product yourself under a BSD licence, and try to make money selling boxed software, you're not going to sell very much,
You missed point #2: the BSD license is not "viral", and the GPL is. Imagine if both Qt and GTK+ were available only under the GPL. Then essentially all graphical software for Linux would have to be GPLed. (And you wouldn't have the option of making another license available.) Thus, the two ways I mentioned would be the only ways to make money off graphical software for Linux.
I said: The GPL grants the right to redistribute with source code to anyone who has the software. Thus, while the GPL does not forbid you from selling software, it makes Microsoft's business model impossible.
An AC said: This is not antagonistic to those who want to make money selling software. This makes it challenging for people to sell other people's software, if that software is GPL'd.
No. It makes it impossible to sell your own software more than once. Once you sell it to someone, they have exactly what you have: the executable, the source code, and the right to resell them. Thus, you can't realistically sell it to someone else because you'll be undercut by your own customers.
Planesdragon said: The headaches start because GPL'd "Free Software" is rather antagonistic to those that want to make a living selling software. It's hard to profit when anyone can copy your product and sell it for half price.
An AC replied: I challenge you to 1) offer proof for this ridiculous statement, and 2) demonstrate how "open source" software differs.
That's easy enough:
The GPL grants the right to redistribute with source code to anyone who has the software. Thus, while the GPL does not forbid you from selling software, it makes Microsoft's business model impossible. You can't keep selling the same software at the same price, because an existing user will undercut you. They have the same right to sell it as you do, and they'll use it.
It's not "viral". You can use BSD-licensed libraries without allowing redistribution of your own work. If we ever reached a point where virtually all software depended on GPL-licensed libraries (and we have reached a stage where virtually all software depends on some sort of library), the Microsoft business model would be gone.
There are still a couple ways to make money off GPLed software, but they're not as lucrative as selling many, many copies of the same software. Here they are:
Supporting mass market GPLed software. (Red Hat's business model)
contract development. You make all of your money off the first copy sold.
Which brings me to question, is there anywhere one can actually look up the rated/average/expected power consumption of various PC components?
Yup. AMD has a good guide to power consumption here. It has, among other things, a formula for computing the power usage of the processor, taking into account the expected inefficiency of the voltage regulator. Combined with spec sheets available from the manufacturers of various parts, it can tell you if a power supply will work.
I did all the math for a server I was thinking of building, and I was quite surprised by the outcome. Despite the fact that my server should only use about 140 W of total power, some of the 300 W supplies were inadequate. They didn't supply enough on the 12 V line. It looks like the maximum current draw on the 12 V line is a better indicator of the quality of a power supply than its total maximum power.
I recommend the PSUs from PC Power & Cooling. The Silencer units really are near-silent, and you can pump a lot of amps through the 12 V lead on all of their supplies. (An improvement they made since I bought mine, unfortunately.)
i guarantee you that a person will be better understood if they learn to speak through immersion classroom techniques (and lets say, for example, the teacher never bothered much with irregular verbs) than someone that can just spout out words and tables but not hold a conversation.
You're missing the point: this isn't an either/or. Memorization is valuable, and it takes a lot of time. It's better if that's not classroom time, and it's better if computers are used to keep it interesting. Conversations are valuable, but they take two people, which is harder to arrange outside of class. And they aren't so valuable that they eliminate the need for vocabulary practice.
Dont waste your money on computer stuff for a LANGUAGE class.
I totally disagree. This is one of the best types of classes for computer-based learning. A lot of the time in languages is just memorization or applying simple algorithms over and over and over (such as conjugation in Latin-based languages). That's very tedious to do. But it's also something a computer can check easily. I've seen simple, surprisingly addictive computer games that improve your vocabulary and conjugation.
In other words, computers can take on the tedious, repetitive jobs. They free the instructor to teach the interesting stuff, with more confidence that students have gotten the needed practice.
They're also quite simple: no 3D acceleration needed, no Internet access needed, not a lot of hard disk space required, no fast processor. Just a decent display.
Re:Cool! Just like form AutoComplete
on
Google Suggest
·
· Score: 1
The O(n) in best case...:
This is marketing speak. The alg. possibly is O(n) on some well-defined (hopefully) subset which (hopefully) represents in some way the typical inputs in practical use.
Ahh, that makes sense. Now that I think about it, this isn't even that uncommon. In a class, we determined that quicksort is "O(n log n) in the common case" or some such. In fact, I might even have seen something similar (but more rigorous) in the Knuth books.
Re:Cool! Just like form AutoComplete
on
Google Suggest
·
· Score: 1
If it makes you feel any better about Slashdot, there are plenty of people who knew exactly what you're asking and haven't responded because they know enough to know that they don't know the answer. Thus you're only getting responses from people who didn't understand the question.
A little. But my God, there are so many of these people, and they are so arrogant in their ignorance. They think the variable doesn't matter, and that anyone who believes otherwise doesn't understand asymptotic notation. They're completely backwards: the variable matters, and anyone who believes otherwise doesn't understand asymptotic notation.
Really, they seem to be missing the distinction between the meaning of n and its numeric value. Saying "it's O(n) with n = 50,000" is indeed the same as saying "it's O(1)". But saying "O(n) with n being the number of indexed pages" is necessary for the O(n) to have meaning.
(I don't actually know that it is with the number of indexed pages, by the way. I'm interested in the answer to this question also.)
By the way, saying "O(n) in the best case" isn't strictly correct, either. Big-Oh, by definition, measures the worst case. It's more correct to say "Omega(n) (best case) and O(n^2) (worst case)". (And more correct still to actually use the Greek letter capital-omega, but slashdot doesn't seem to like that.)
Re:Why Ruby?
on
RAD with Ruby
·
· Score: 3, Interesting
From where I stand (don't know Ruby, rarely use SQL) the Ruby example is easy to understand, and the SQL example is far from obvious.
To someone who uses SQL frequently, the code I gave is obvious. (It'd be even more so if slashdot allowed me to indent it properly.) And most people making code to access a RDBMS will have used SQL recently, because they just designed a schema to access. The tool doesn't do that for you.
With object-relational tools, you need to know more than you did before. There's much more complexity and bloat in the system. And the resulting SQL is crap. There's no benefit.
"Premature optimisation is the root of all evil"
More accurately, "premature micro-optimization is the root of all evil". You will save a lot of effort by choosing an efficient high-level design right away. Passing around objects that tie you to an object-relational tool like this one is not an efficient high-level design.
The point is that unless some analysis shows that that particular piece of Ruby code causes an unacceptable bottleneck within the context of the application (from the point of view of the user), then stick with the code that is shorter, simpler, easier to write and easier to maintain.
Yes, that particular piece of Ruby code would cause an unacceptable bottleneck. In many organizations (including mine), the database server and the webserver are not the same. Imagine every round trip taking 50ms and you'll begin to understand. The number of round trips must be O(1) for acceptable performance, and the closer to 1, the better. That's not true for the Ruby code. It makes m + n round trips, where m is the number of roles for that user, and n is the number of permissions for that user. So if that's 20 (depending on how granular permissions are, that's not unlikely), that will add a second per hit. Ugh.
I guess part of what you are saying is that there are existing (old) technologies that are better in some sense if only people would take the time and effort to learn about them, rather than chasing the flavour of the month. If that is part of your message then I whole-heartedly agree. I like fvwm!
In part. But mostly, it doesn't make sense to add on layers of complexity unless they accomplish something for you. This layer does not, and it does take away your performance.
Re:Why Ruby?
on
RAD with Ruby
·
· Score: 2, Interesting
That example really shows off why I hate object-relational mappings (Ruby's or any other). It looks like each of those lines of code requires a round trip to the database. In fact, this one requires three:
If you put some actual thought into the queries you make, you can do much better. For example, what you'd really like to do is see what permissions the user has. So:
select distinct perm.id, perm.name, perm.serial from user_roles user_role join roles role on (user_role.role_id = role.id) join permissions_roles perm_role on (perm_role.role_id = role.id) join permissions perm on (perm_role.permission_id = perm.id) where user_role.user_id =:p_user_id
That query allows you to go straight from the user ID to the actual useful information about permissions in a single database round trip. Notice that I used joins. These are things that object-relational mappings seem to neglect. And the foundation of the relational model.
SQL is not hard. Why must everything be an object? I love object-oriented programming, but this isn't a good use of it.
Ignoring exceptions completely is almost always a bad idea (though what do you do to handle, say, the InterruptedException that can be thrown by Thread.sleep(), or a CloneNotSupportedException from one of your own classes that you know is cloneable?)
When a seemingly-impossible thing happens, I wrap it in a RuntimeException. Something like this:
File f = blah;
try { ....InputSource src = new InputSource(f.toURL().toString());
} catch (MalformedURLException e) { ....throw new RuntimeException("java.io.File gave malformed URL.", e);// Unlikely.
}
I keep the whole stack trace (including the MalformedURLException's section; JDK 1.4's exception wrapping functionality is nice for this). I describe the impossible thing that appears to have just happened. And I do it in a RuntimeException so I don't have to have throws clauses all the way down the stack for every bizarre thing that could theoretically happen.
This method is pretty easy, and it puts you in a fairly good situation for debugging things, should the (nearly) impossible happen.
There's no doubt in my mind that if they were still working with Andreeson's hacked pile of crap, Firefox wouldn't have happened, IE would be the only web browser for Windows and the rest of us would be using Konqueror.
Dude, you've got to read the whole article. Particularly this paragraph:
First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without
throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code.
He is most certainly not saying that once you've made a poor architectural decision, you are stuck with it for the lifetime of the project. Instead, he's saying that it is possible to change these things without discarding everything. (Throwing the baby out with the bathwater.)
There are also lessons here for when you are writing the first version. Here's one: if your code to open a window needs a lot of new workaround code, add a comment, for the love of God. Version control logs are often enough for fixing existing code, but a big block of code that only is important on one platform really should have a comment in front of it. And, if you have a test machine of the type needing the workaround, add a unit test. (And if you don't, maybe you should get one.) You should never get into that situation where you have that two-page long function for a tiny task and no idea what all that code does. If you do, someone will inevitably rip it out without realizing they've introduced a bug on a platform they're not using.
I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.
In which you're afraid to touch those 5,000 lines of code because there are so many odd situations. If you have tests for them, this isn't a problem. Can you get ahold of all 60 types of server? Maybe, maybe not. But you can at least get a good chunk of them for integration tests. And you can certainly write mocks for the behavior noted as problematic for the others.
If you want to get a job programming (software engineering minus an engineering certification; writing code to the latest trendy language and APIs, using available tools, source code management, writing maintainable code, gathering requirements, making scheduling estimates, testing your code, etc.), I don't think it matters. Not only that, but you probably don't even need the degree you're getting now. A degree is helpful, but it doesn't necessarily even need to be a CS degree. You do need experience. If you don't have a programming-related student job now, you should think about getting one right away. Doing open-source work would also help you a lot.
If you want to get a job doing computer science (the more rare abstract work - designing algorithms, researching their efficiency, writing papers, etc.) - then your father may be right. If this is what you want, you want a degree from the best university you can find, and you may want more than a B.S.
And if you want to do a job that combines both, you need the qualifications of both. So...get busy.
I'm surprised nobody has mentioned that Spanish has two past tenses: the imperfect and the preterite. It's somewhat similiar to what's being mentioned about Choktaw, only you're more likely to encounter someone who speaks the language.
No, I wouldn't say it's close at all. The trait of the Choktaw tenses that the article mentioned is the distinction between first-hand, definite observations and second-hand ones. The Spanish distinction is something like this:
Cuando era niño, robé un banco.
When I was young, I robbed a bank.
Cuando era niño, robaba bancos.
When I was young, I used to rob banks.
The preterite refers to a specific time; the imperfect refers to habitual actions.
So Spanish has two past tenses, yes, but not similar to Choktaw's. In fact, Spanish has more past tenses than that. The past subjunctive comes to mind.
You probably even use more English tenses than you realize; look at a good grammar book. Ever said "I wish I were rich?" Then you've used the subjunctive tense. Roughly, it's used to talk about unlikely things. "I wish I was rich" might convey a sense that it's more likely to happen (or simply that you're not aware of this tense; it's less common nowadays).
Interesting. I'd never seen that "with cube" syntax before. I have some queries that I might be able to simplify with that operator, so thanks for the pointer. Looks like both Microsoft SQL Server and Oracle 8i or later have that syntax, and SQL-99 has a similar "group by cube" thing. (And, thus, PostgreSQL will have it soon if it doesn't already. I saw patches but haven't seen yet if they've been accepted.)
What you are saying is that "a multi-dimensional array isn't really multi-dimensional, because it's mapped to a linear memory space".
I'm more talking about its presentation to you, actually. When I say "view", I mean its appearance; I'm not describing a SQL view. A relation (SQL table, query, view) can certainly hold N-dimensional data, and in such a way that you can select whatever dimension(s) you want. The only real difficulty is presenting it to the user properly; just listing out the query results is presenting it in a one-dimensional fashion. That's the point I was trying to make, and it doesn't sound like you're disputing it.
Well then hotshot, why don't you take a few moments to bless us with your obviously Herculean knowledge of pivot tables, and post a nice example for the Slashdot readers?
Please note that I was responding to a question about what pivot tables were so I answered with the simplest possible example. There are obviously MANY more sophisticated things that can be done.
But that's an example of something that can be done without using a pivot table; a simple query could produce that list. Thus, it is a poor example of what they're for.
A traditional relational database has two dimensions - rows and columns.
I don't think that's a good way to look at it.
A relation (a single SQL table, view, query) has rows and columns, yes. But the column headings are fixed. So it's only one-dimensional.
However, this one-dimensional structure is adequate to represent N-dimensional data. (By having a table with a composite primary key of N columns.) It's pointless to "take a table and make a copy of it to separate records by year"; the relational way is to simply introduce a new column called "year". And you can have different tables to represent data of different arities. (One table to store stuff independent of year, one table to store stuff that is dependent on year and whatever else, one table to store stuff that is dependent only on year. However many tables it takes to properly normalize your data.)
One dimensional may not be adequate to understand N-dimensional data, though. If you make a query, you get a one-dimensional list. If you want to view a two-dimensional matrix, you need to use a matrix report/pivot table. This can make things much easier to look at and get a feel for.
That's one-dimensional data. "Country" is a single-column primary key of that data. Each country exists in only one continent. Each country has only one population.
Here's a way to spot a one-dimensional list: if the number of columns is fixed, it's one-dimensional. ("Continent, Country, Population" is fixed; it's not dependent on your data.)
If you introduced a "year" column, then it would be two-dimensional data. China's population in 2003 was different than in 2002. And China's population in 2002 was different than Japan's. You need to specify both columns to fully identify a row.
You could then view it with country down the left and year along the top. If you add a country, the number of rows grows. If you add a year, the number of columns grows. Producing this two-dimensional view from one-dimensional list would require a matrix report/pivot table.
Notice that I'm making a distinction between two-dimensional data and a two-dimensional view. SQL tables can be considered a one-dimensional view of N-dimensional data. You can, through the right query, produce a view based on any or or two of those N dimensions. Only the two-dimensional ones report a pivot table/matrix report.
There's a single-column primary key to that data (name), so it's one-dimensional. Your second view (average height by age) can be produced without a matrix report/pivot table. Where you do need pivot tables is where your data are more complex:
Name Age Height (cm) --------------------- Jane 22 174 Jane 21 174 Jane 20 174 Jane 19 173 Jane 18 171 ... Dick 22 212 Dick 22 212 ... Dick 9 105 Mary 24 150 Greg 24 198 Dave 23 244
The above data points describe height by age and person. It's two-dimensional data, but you're showing it with only one dimension. (As it would be stored in a RDBMS.) You could make it easier to read by instead showing their ages horizontally and the people vertically (or vice versa) with a matrix of columns for their height at that age. That's what pivot tables are for.
I'd really like to know what the hell a pivot table is.
First, you've got to have some data to describe. Here's one I'm looking at right now: I've got a table in my Oracle database that lists services doctors performed on given dates, and how much they charged for them.
A conventional report would describe that data one-dimensionally. Total amount of money each doctor charged or total amount of money charged in each date range.
A pivot table (or matrix report, as Oracle Reports calls them) shows the same data two-dimensionally. Down the left is a list of doctors. Across the top is a list of months. Cells in the middle show how much each doctor billed in a given month. There are monthly totals at the bottom, doctor totals on the right, and a grand total in the lower right.
So essentially, a pivot table is just a tool for putting data from a RDBMS into the spreadsheet form you know and love.
Yeah, I think it misplaced me, too. (I expected to be in the center, and ended up basically around the Green Party.) I'm more impressed with their scale and their placement of world leaders than their test of where you stand.
The Democratic philosophy is as different from the Libertarian one as it is from the Republican -- so much so that I find myself more or less half-libertarian and half-Republican, but nowhere near Democratic.
You may as well say they should help the Republican campaign; the two seem to me ideologically closer, Bush himself notwithstanding.
Have you seen the political compass? It's great - they plot ideologies on two dimensions rather than one. If you've ever been confused about what's a left vs. right point, it's probably because compressing everything into one dimension makes no sense. This site uses two dimensions, which is better. (Still imperfect, but a third dimension would probably be more confusing than beneficial.) The horizontal axis is economic; the vertical is social.
Going back to what you were saying, Democrats are left of Republicans, as always. But both Democrats and Republicans are in the upper right quadrant. Libertarians are in the lower right; the Green Party is in the lower left. They have Democrats and Republicans roughly equidistant from the Libertarians. But I think the social axis (libertarian vs. authoritarian) is more central to the Libertarian's beliefs (thus the name), so I'd consider Democrats closer than Republicans.
Slashdot Mirror
Dude, when I say "imagine if..." I'm stating a hypothetical.
You missed point #2: the BSD license is not "viral", and the GPL is. Imagine if both Qt and GTK+ were available only under the GPL. Then essentially all graphical software for Linux would have to be GPLed. (And you wouldn't have the option of making another license available.) Thus, the two ways I mentioned would be the only ways to make money off graphical software for Linux.
An AC said: This is not antagonistic to those who want to make money selling software. This makes it challenging for people to sell other people's software, if that software is GPL'd.
No. It makes it impossible to sell your own software more than once. Once you sell it to someone, they have exactly what you have: the executable, the source code, and the right to resell them. Thus, you can't realistically sell it to someone else because you'll be undercut by your own customers.
An AC replied: I challenge you to 1) offer proof for this ridiculous statement, and 2) demonstrate how "open source" software differs.
That's easy enough:
There are still a couple ways to make money off GPLed software, but they're not as lucrative as selling many, many copies of the same software. Here they are:
Yup. AMD has a good guide to power consumption here. It has, among other things, a formula for computing the power usage of the processor, taking into account the expected inefficiency of the voltage regulator. Combined with spec sheets available from the manufacturers of various parts, it can tell you if a power supply will work.
I did all the math for a server I was thinking of building, and I was quite surprised by the outcome. Despite the fact that my server should only use about 140 W of total power, some of the 300 W supplies were inadequate. They didn't supply enough on the 12 V line. It looks like the maximum current draw on the 12 V line is a better indicator of the quality of a power supply than its total maximum power.
I recommend the PSUs from PC Power & Cooling. The Silencer units really are near-silent, and you can pump a lot of amps through the 12 V lead on all of their supplies. (An improvement they made since I bought mine, unfortunately.)
You're missing the point: this isn't an either/or. Memorization is valuable, and it takes a lot of time. It's better if that's not classroom time, and it's better if computers are used to keep it interesting. Conversations are valuable, but they take two people, which is harder to arrange outside of class. And they aren't so valuable that they eliminate the need for vocabulary practice.
I totally disagree. This is one of the best types of classes for computer-based learning. A lot of the time in languages is just memorization or applying simple algorithms over and over and over (such as conjugation in Latin-based languages). That's very tedious to do. But it's also something a computer can check easily. I've seen simple, surprisingly addictive computer games that improve your vocabulary and conjugation.
In other words, computers can take on the tedious, repetitive jobs. They free the instructor to teach the interesting stuff, with more confidence that students have gotten the needed practice.
They're also quite simple: no 3D acceleration needed, no Internet access needed, not a lot of hard disk space required, no fast processor. Just a decent display.
Ahh, that makes sense. Now that I think about it, this isn't even that uncommon. In a class, we determined that quicksort is "O(n log n) in the common case" or some such. In fact, I might even have seen something similar (but more rigorous) in the Knuth books.
A little. But my God, there are so many of these people, and they are so arrogant in their ignorance. They think the variable doesn't matter, and that anyone who believes otherwise doesn't understand asymptotic notation. They're completely backwards: the variable matters, and anyone who believes otherwise doesn't understand asymptotic notation.
Really, they seem to be missing the distinction between the meaning of n and its numeric value. Saying "it's O(n) with n = 50,000" is indeed the same as saying "it's O(1)". But saying "O(n) with n being the number of indexed pages" is necessary for the O(n) to have meaning.
(I don't actually know that it is with the number of indexed pages, by the way. I'm interested in the answer to this question also.)
By the way, saying "O(n) in the best case" isn't strictly correct, either. Big-Oh, by definition, measures the worst case. It's more correct to say "Omega(n) (best case) and O(n^2) (worst case)". (And more correct still to actually use the Greek letter capital-omega, but slashdot doesn't seem to like that.)
To someone who uses SQL frequently, the code I gave is obvious. (It'd be even more so if slashdot allowed me to indent it properly.) And most people making code to access a RDBMS will have used SQL recently, because they just designed a schema to access. The tool doesn't do that for you.
With object-relational tools, you need to know more than you did before. There's much more complexity and bloat in the system. And the resulting SQL is crap. There's no benefit.
More accurately, "premature micro-optimization is the root of all evil". You will save a lot of effort by choosing an efficient high-level design right away. Passing around objects that tie you to an object-relational tool like this one is not an efficient high-level design.
Yes, that particular piece of Ruby code would cause an unacceptable bottleneck. In many organizations (including mine), the database server and the webserver are not the same. Imagine every round trip taking 50ms and you'll begin to understand. The number of round trips must be O(1) for acceptable performance, and the closer to 1, the better. That's not true for the Ruby code. It makes m + n round trips, where m is the number of roles for that user, and n is the number of permissions for that user. So if that's 20 (depending on how granular permissions are, that's not unlikely), that will add a second per hit. Ugh.
In part. But mostly, it doesn't make sense to add on layers of complexity unless they accomplish something for you. This layer does not, and it does take away your performance.
If you put some actual thought into the queries you make, you can do much better. For example, what you'd really like to do is see what permissions the user has. So:
That query allows you to go straight from the user ID to the actual useful information about permissions in a single database round trip. Notice that I used joins. These are things that object-relational mappings seem to neglect. And the foundation of the relational model.
SQL is not hard. Why must everything be an object? I love object-oriented programming, but this isn't a good use of it.
When a seemingly-impossible thing happens, I wrap it in a RuntimeException. Something like this:
I keep the whole stack trace (including the MalformedURLException's section; JDK 1.4's exception wrapping functionality is nice for this). I describe the impossible thing that appears to have just happened. And I do it in a RuntimeException so I don't have to have throws clauses all the way down the stack for every bizarre thing that could theoretically happen.
This method is pretty easy, and it puts you in a fairly good situation for debugging things, should the (nearly) impossible happen.
Dude, you've got to read the whole article. Particularly this paragraph:
He is most certainly not saying that once you've made a poor architectural decision, you are stuck with it for the lifetime of the project. Instead, he's saying that it is possible to change these things without discarding everything. (Throwing the baby out with the bathwater.)
There are also lessons here for when you are writing the first version. Here's one: if your code to open a window needs a lot of new workaround code, add a comment, for the love of God. Version control logs are often enough for fixing existing code, but a big block of code that only is important on one platform really should have a comment in front of it. And, if you have a test machine of the type needing the workaround, add a unit test. (And if you don't, maybe you should get one.) You should never get into that situation where you have that two-page long function for a tiny task and no idea what all that code does. If you do, someone will inevitably rip it out without realizing they've introduced a bug on a platform they're not using.
Then you can avoid problems like this one:
In which you're afraid to touch those 5,000 lines of code because there are so many odd situations. If you have tests for them, this isn't a problem. Can you get ahold of all 60 types of server? Maybe, maybe not. But you can at least get a good chunk of them for integration tests. And you can certainly write mocks for the behavior noted as problematic for the others.
If you want to get a job doing computer science (the more rare abstract work - designing algorithms, researching their efficiency, writing papers, etc.) - then your father may be right. If this is what you want, you want a degree from the best university you can find, and you may want more than a B.S.
And if you want to do a job that combines both, you need the qualifications of both. So...get busy.
No, I wouldn't say it's close at all. The trait of the Choktaw tenses that the article mentioned is the distinction between first-hand, definite observations and second-hand ones. The Spanish distinction is something like this:
The preterite refers to a specific time; the imperfect refers to habitual actions.
So Spanish has two past tenses, yes, but not similar to Choktaw's. In fact, Spanish has more past tenses than that. The past subjunctive comes to mind.
You probably even use more English tenses than you realize; look at a good grammar book. Ever said "I wish I were rich?" Then you've used the subjunctive tense. Roughly, it's used to talk about unlikely things. "I wish I was rich" might convey a sense that it's more likely to happen (or simply that you're not aware of this tense; it's less common nowadays).
What you are saying is that "a multi-dimensional array isn't really multi-dimensional, because it's mapped to a linear memory space".
I'm more talking about its presentation to you, actually. When I say "view", I mean its appearance; I'm not describing a SQL view. A relation (SQL table, query, view) can certainly hold N-dimensional data, and in such a way that you can select whatever dimension(s) you want. The only real difficulty is presenting it to the user properly; just listing out the query results is presenting it in a one-dimensional fashion. That's the point I was trying to make, and it doesn't sound like you're disputing it.
Umm, I posted three of them.
We're waiting with baited breath...
It's "bated breath".
But that's an example of something that can be done without using a pivot table; a simple query could produce that list. Thus, it is a poor example of what they're for.
I don't think that's a good way to look at it.
A relation (a single SQL table, view, query) has rows and columns, yes. But the column headings are fixed. So it's only one-dimensional.
However, this one-dimensional structure is adequate to represent N-dimensional data. (By having a table with a composite primary key of N columns.) It's pointless to "take a table and make a copy of it to separate records by year"; the relational way is to simply introduce a new column called "year". And you can have different tables to represent data of different arities. (One table to store stuff independent of year, one table to store stuff that is dependent on year and whatever else, one table to store stuff that is dependent only on year. However many tables it takes to properly normalize your data.)
One dimensional may not be adequate to understand N-dimensional data, though. If you make a query, you get a one-dimensional list. If you want to view a two-dimensional matrix, you need to use a matrix report/pivot table. This can make things much easier to look at and get a feel for.
Here's a way to spot a one-dimensional list: if the number of columns is fixed, it's one-dimensional. ("Continent, Country, Population" is fixed; it's not dependent on your data.)
If you introduced a "year" column, then it would be two-dimensional data. China's population in 2003 was different than in 2002. And China's population in 2002 was different than Japan's. You need to specify both columns to fully identify a row.
You could then view it with country down the left and year along the top. If you add a country, the number of rows grows. If you add a year, the number of columns grows. Producing this two-dimensional view from one-dimensional list would require a matrix report/pivot table.
Notice that I'm making a distinction between two-dimensional data and a two-dimensional view. SQL tables can be considered a one-dimensional view of N-dimensional data. You can, through the right query, produce a view based on any or or two of those N dimensions. Only the two-dimensional ones report a pivot table/matrix report.
The above data points describe height by age and person. It's two-dimensional data, but you're showing it with only one dimension. (As it would be stored in a RDBMS.) You could make it easier to read by instead showing their ages horizontally and the people vertically (or vice versa) with a matrix of columns for their height at that age. That's what pivot tables are for.
First, you've got to have some data to describe. Here's one I'm looking at right now: I've got a table in my Oracle database that lists services doctors performed on given dates, and how much they charged for them.
A conventional report would describe that data one-dimensionally. Total amount of money each doctor charged or total amount of money charged in each date range.
A pivot table (or matrix report, as Oracle Reports calls them) shows the same data two-dimensionally. Down the left is a list of doctors. Across the top is a list of months. Cells in the middle show how much each doctor billed in a given month. There are monthly totals at the bottom, doctor totals on the right, and a grand total in the lower right.
So essentially, a pivot table is just a tool for putting data from a RDBMS into the spreadsheet form you know and love.
Yeah, I think it misplaced me, too. (I expected to be in the center, and ended up basically around the Green Party.) I'm more impressed with their scale and their placement of world leaders than their test of where you stand.
Have you seen the political compass? It's great - they plot ideologies on two dimensions rather than one. If you've ever been confused about what's a left vs. right point, it's probably because compressing everything into one dimension makes no sense. This site uses two dimensions, which is better. (Still imperfect, but a third dimension would probably be more confusing than beneficial.) The horizontal axis is economic; the vertical is social.
Going back to what you were saying, Democrats are left of Republicans, as always. But both Democrats and Republicans are in the upper right quadrant. Libertarians are in the lower right; the Green Party is in the lower left. They have Democrats and Republicans roughly equidistant from the Libertarians. But I think the social axis (libertarian vs. authoritarian) is more central to the Libertarian's beliefs (thus the name), so I'd consider Democrats closer than Republicans.