realizing your old code is crap means you are improving. if you have less than 10 years experience with a language, chances are in 5 years you will think what you write now is crap too. Agreed wholeheartedly. Now, there's probably nothing that a junior programmer can do to stop projects drifting (heck, even the gurus struggle with that!) and they probably don't have the influence to change the entire development culture, but they can do the Right Thing with their own code. Always consider in what circumstances it's legitimate for a piece of code to be invoked, and document it. Consider what it should do in other circumstances, and document it. Consider how it should react if it can't do what it's supposed to, and document it. Try to double guess which requirements are stable, and which are likely to change, and design to make likely changes easy. (I'm assuming here that the customer can't tell you anything useful about those things -- if they can then you can do better still). And when you get it wrong, think about why you got it wrong, and see whether you can learn how to do better next time. Just remember that getting it wrong doesn't just mean failing to anticipate changes, it includes over-engineering the code to account for changes that were never likely.
Yeah, but they probably aren't the low end, now, are they? But if the low end wants to do business with the high end they may have to stay with MS for a while yet. I have customers that insist I deliver using MS Office templates that use macros, so OO.o is not an option. I keep thinking "Oh, I'll use OO.o for my own stuff", but what's the point since I have to have MS Office anyway and I have to be familiar with it?
Your "income coming in" is an important factor to you, yet irrelevant for the definition of a high level language. As is the question of whether it's my favourite OS, which you brought up.
For your definition of "high level" I suggest you go the gcc route. Or Python. Or OCAML. Or even C# if I could trust MS not to stomp on Mono.
So Ruby apparently isn't high level then, because it seems that it can't be fully adapted to the OS I have to work with if I want to keep my income coming in. Actually, I'd suggest that your definition of high level is too restrictive, because I do think Ruby is a high level language, but with some unfortunate design choices for anybody wanting to develop cross-platform apps. Fair enough: all languages have compromises, and that's one that Ruby has chosen.
Yes, I'd agree that it's perfectly reasonable for a solution to be specialised. I'm a strong opponent of the "I have a hammer so every problem is a nail" type development mentality, and believe that any competent developer needs a wide range of tools. Rails might be just the thing for lots of jobs, but it's also going to be a poor solution for other jobs. The good developer will pick the tool that's right for the job -- not, as some seem to have been doing, argue that if their pet tool isn't right then it must be the job that's wrong.
You're a real jerk. Why, thank you. It's good to see we can keep to the real issues.
First, the linked article said that surrogate keys are always the better choice, not that natural/composite keys aren't always best. It presents some good arguments, too. I couldn't find a single general argument in there; just an argument that surrogate keys were better in one specific case.
Second, the parent wasn't distinguishing between normalizing and not normalizing I know, which is why I kept pointing out that I was agreeing with the parent.
he was pointing out that implementing 'extreme' normalization (like going all the way to sixth normal form) is usually counterproductive. I don't know about you, but I rarely go beyond third, and any references I've read about normalization agree that anything beyond that is rarely useful. I'd never consider stopping short of BCNF unless there was a really strong reason to enforce consistency another way (I can't imagine a situation in which I wouldn't care about consistency). I'd consider higher forms, but they're certainly less automatic.
Way to keep up the./ tradition of loudly disagreeing with something you didn't read properly, or at all. So I see -- because if you'd properly read what I wrote you'd see that I was agreeing with the parent, just qualifying it.
I am suggesting that composite keys may sometimes be the best solution (and so should be supported) and may sometimes not be the best solution. Referencing an article that gives an example of a case where they're not the best solution doesn't actually say anything at all to that debate.
Sure, but that's because Ruby is a real VHLL. Hmm. And is there a full version for MS Windows yet? [checks] Nope. Because OS dependency is hard wired into the language. Which I suppose is one way a language can be high level.
People have discussed this over and over and over again. I presume you're talking about support for composite primary keys. They aren't necessarily a good thing. Go read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html Wow, a composite key isn't always the best solution? No sh*t, Sherlock!
I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Indeed it is a compromise, and it's not even always possible. But most people who dismiss it aren't actually aware of what it actually gives them, so I've seen some truly terrible tradeoffs. The main thing it gives you is data consistency. If you don't care whether your data is consistent then you can throw normalisation away quite happily. If you do care about data consistency, well, the alternatives to normalisation usually (not always) end up more complicated than normalisation would have been. As you say, lack of normalisation isn't proof that a database is broken, but it's very good reason to be suspicious -- it's far more than just an ivory tower ideal.
That is true for four wheelers in most parts of the USA it is taught that way. It is also true according to the "Federal Motor Carrier Safety Regulations" that we (semi's) can run red lights under certain circumstances. a.) We do not have the ability to stop, b.) we are carrying a high value load through an extremely high crime area or c.) we are in a low traffic area (usually late at night). However, we are required to blow our air horn continuously from before we get to the intersection until we are completely clear of the intersection. Interesting, but I can't find any of that in the regulations. I don't suppose you could point me to the actual clauses in the regulations, could you?
We would have to drive 10 mph all the way through town in order to achieve such a feat and to be absolutely certain we could stop at every light. Not only would that cost us significant lost revenue, especially for local (city drivers) but it would also result in daily tickets for "impeding the flow of traffic". Firstly, I don't care a bit about your revenue if you can't earn it safely. Secondly, do local (city drivers) really drive big rigs? I thought they would be for long distance haulage. Thirdly, are you really telling me that it's illegal in the USA to drive at a safe speed?
Why not just stick radar on them? Or beam them radar images?
Problem solved. No stupidly advanced image recognition system needed. And then make the automatic collision avoidance sufficiently safe for all the other users of the airspace.
Well, I don't know how it is in your jurisdiction, but when I was learning to drive I was taught that when approaching traffic lights I should slow to such as speed that I could safely stop if they change against me. That seems sufficiently general to account for anything I might drive.
Wrong way round. Just because the speed limit is 35 mph doesn't mean that it's always safe to drive at 35 mph. It's probably not safe to drive at 35 mph if it's thick fog. It's probably not safe to drive at 35 mph if it's icy. It's probably not safe to drive at 35 mph if there are small kids playing ball on the sidewalk. It's probably not safe to drive at 35 mph if you're at the wheel of an 80,000 pound rig.
Although I agree with most of your post, motorways are the exception, not the rule. There are loads of antiquated laws about what you can take down 99.9% of the roads in the UK. I'm think, for example, that if someone _really_ wanted to drive a flock of sheep through London, they probably could. Under road traffic legislation, almost certainly. But I bet the police would consider it a breach of the peace or a terrorist act, stop it on those grounds, and fight it out in court after the event.
The north circular, probably the largest road in London still has cattle grids in places. Still? Where's that?
I do know you're allowed to ride a horse _anywhere_ except for motorways.... Not on footpaths or pavements (sidewalks). It happens, and it's not so bad -- no worse than any other slow-moving vehicle. The rider needs a lot of confidence in the horse, though.
1.) Late at night traffic lights are on a faster cycle than in the daytime. By the time we notice a light is yellow we usually do not have time to stop (safely) before it turns red. This is due to the 80,000 lb weight of our loaded trucks and we just can't stop that damn fast....period. No, as I think any judge would inform you if you caused an accident by jumping the red light, it is due to you approaching the traffic lights to fast to stop in time if they change.
Where do you get that information? My understanding is that there is no such thing in British law as a "right of way over traffic" -- in law, a "right of way" is essentially somewhere the public have a right to go, and says nothing about who has priority. And although we have no offence of jaywalking, it certainly is an offence to walk on the motorway (except obvious exceptions such as along the hard shoulder to reach an emergency telephone).
As far as I can see, all the relevant roadsigns are the same in Poland as they are in the UK, except Poland uses a yellow background on prohibition signs whereas we use white.
Most UK warning and prohibition signs are purely iconic and use no language at all [1] except to provide additional information. It's the information signs that are being put up in Polish.
[1] Ok, to a semiologist, icons/are/ a language, but you know what I mean.
Look at http://www.direct.gov.uk/en/TravelAndTransport/Highwaycode/Signsandmarkings/index.htm under "Signs giving orders". It shows the standard international signs, as used throughout the UK, which prohibit vehicles above a certain height, length, width or weight, all without using a single word of English. If there is a plate with English on it, it will almost certainly be showing an exception to the prohibition.
Slashdot Mirror
Because then we'd be overrun by destitute lawyers?
So Ruby apparently isn't high level then, because it seems that it can't be fully adapted to the OS I have to work with if I want to keep my income coming in. Actually, I'd suggest that your definition of high level is too restrictive, because I do think Ruby is a high level language, but with some unfortunate design choices for anybody wanting to develop cross-platform apps. Fair enough: all languages have compromises, and that's one that Ruby has chosen.
Yes, I'd agree that it's perfectly reasonable for a solution to be specialised. I'm a strong opponent of the "I have a hammer so every problem is a nail" type development mentality, and believe that any competent developer needs a wide range of tools. Rails might be just the thing for lots of jobs, but it's also going to be a poor solution for other jobs. The good developer will pick the tool that's right for the job -- not, as some seem to have been doing, argue that if their pet tool isn't right then it must be the job that's wrong.
I am suggesting that composite keys may sometimes be the best solution (and so should be supported) and may sometimes not be the best solution. Referencing an article that gives an example of a case where they're not the best solution doesn't actually say anything at all to that debate.
Wow, a composite key isn't always the best solution? No sh*t, Sherlock! I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Indeed it is a compromise, and it's not even always possible. But most people who dismiss it aren't actually aware of what it actually gives them, so I've seen some truly terrible tradeoffs. The main thing it gives you is data consistency. If you don't care whether your data is consistent then you can throw normalisation away quite happily. If you do care about data consistency, well, the alternatives to normalisation usually (not always) end up more complicated than normalisation would have been. As you say, lack of normalisation isn't proof that a database is broken, but it's very good reason to be suspicious -- it's far more than just an ivory tower ideal.
Problem solved. No stupidly advanced image recognition system needed. And then make the automatic collision avoidance sufficiently safe for all the other users of the airspace.
Well, I don't know how it is in your jurisdiction, but when I was learning to drive I was taught that when approaching traffic lights I should slow to such as speed that I could safely stop if they change against me. That seems sufficiently general to account for anything I might drive.
Wrong way round. Just because the speed limit is 35 mph doesn't mean that it's always safe to drive at 35 mph. It's probably not safe to drive at 35 mph if it's thick fog. It's probably not safe to drive at 35 mph if it's icy. It's probably not safe to drive at 35 mph if there are small kids playing ball on the sidewalk. It's probably not safe to drive at 35 mph if you're at the wheel of an 80,000 pound rig.
And if you knock down /all/ buildings that are in /somebody's/ way, there won't be any A or B left to go between -- problem solved!
Where do you get that information? My understanding is that there is no such thing in British law as a "right of way over traffic" -- in law, a "right of way" is essentially somewhere the public have a right to go, and says nothing about who has priority. And although we have no offence of jaywalking, it certainly is an offence to walk on the motorway (except obvious exceptions such as along the hard shoulder to reach an emergency telephone).
Mainly at beer festivals, for the barley wines.
I think the average lorry/truck finds itself driving on both sides of the road.
As far as I can see, all the relevant roadsigns are the same in Poland as they are in the UK, except Poland uses a yellow background on prohibition signs whereas we use white.
Most UK warning and prohibition signs are purely iconic and use no language at all [1] except to provide additional information. It's the information signs that are being put up in Polish.
[1] Ok, to a semiologist, icons /are/ a language, but you know what I mean.
I never see police stop cyclists for slaloming through pedestrians on the sidewalk
Come to London and you'll see it, particularly in Westminster. Except they're not sidewalks, of course.Look at http://www.direct.gov.uk/en/TravelAndTransport/Highwaycode/Signsandmarkings/index.htm under "Signs giving orders". It shows the standard international signs, as used throughout the UK, which prohibit vehicles above a certain height, length, width or weight, all without using a single word of English. If there is a plate with English on it, it will almost certainly be showing an exception to the prohibition.