and no, the answer is not exactly 20 year ago (ignoring leap years) because timezone changes means that not all days are 24 hours
Time zones have nothing to do with how long a day is. Every time zone has 24 hour days. Unless you live in some weird alternate universe where some days are longer than others...
The changes in daylight savings time may impact exactly what time it is now but the only thing you have to deal with is whether you're currently in daylight savings time. Because within a year, switching to DST and back cancels itself out. A given year will have one day that acts like a 23 hour day and another that acts like a 25 hour day.
The only real thing that would make 20*365*24*60*60 (ignoring leap years) not exactly 20 years ago is if the standard for daylight savings time had changed between then and now. If daylight savings time was in effect then but not now (or not then but in effect now), you'd only be off by one hour.
The law may be settled but that doesn't stop people from filing suit anyway. They may either think they have a notable enough exception or they're just working with a lawyer who knows he's going to lose but is getting paid to do what the client tells him to do (after doing his due diligence of informing them of the probable outcome).
I suppose there are a few that don't have cameras. But a lot of them do. Initially, it let them take the staff out of the booth (saving money) while still allowing for enforcement. But, as with any other tool of convenience, it only takes time for someone to want to misuse the system.
So manually paying the tolls is more expensive, takes you longer and doesn't do anything to improve your privacy. Sounds like the decision is a no-brainer to me.
They photograph your license plate at all manual toll collection points too. The police can get those records just as easily. Dropping the pass in favor of dropping coins in the slot doesn't help.
Sure. But I can do that in a procedural language too. In fact, that's one of the points of OOD. You abstract away your layers with a proper design and your code is small and concise. Of course, it's rare to find that type of design done well but it's possible.
To me, functional languages are actually more intuitive.
I know a lot of academic types for whom that is the case. But I've met far more people who have enough trouble understanding basic procedural language concepts. I don't even want to think of trying to teach them a language that requires a solid understanding of advanced math just to be able to use.
And that's my point. Functional languages have their place, but they will never reach the mainstream because the mainstream just doesn't have the desire (or ability in many cases) to understand the underlying theory that makes it work.
Sounds to me like you're in a situation where a language like that is a viable tool with which to implement a solution. But only because the nature of the problem lends itself to being solved with that specific tool. And when it's the right tool to use, I'm sure it's a fantastic language. But that's just it. How often are people working on problems where it's the best tool? I don't often run into situations where a functional language is the best choice. I'm glad I have it in my tool box along with so many other languages and tools for the few times I need it. But I, and so many other people in the world, just don't work on the kinds of problems where functional languages are really the best tool to apply.
I don't know if you've ever tried teaching functional languages to novices with no math background. To say it's not easy is a colossal understatement. What is far easier is getting them up and running with procedural languages. The concepts are just far easier for the average layman to grasp than the concepts of functional languages. Protest all you want but that's just the way it is.
I have, and my point still stands. A minimalist Lisp language may have a simpler syntax but that's not what I'm referring to when I call the languages simpler. The point is that the concepts behind building software with procedural languages are far more simple than using functional languages. The average office worker can cobble together enough thought process to write basic macros in a spreadsheet. Try getting those same people to use a functional language to do the same thing and then tell me how "simple" those functional languages are.
Agreed. In fact, just about everywhere I work has a coding standard that says you shouldn't cram a whole lot of stuff into one line of code specifically because it's hard to write correctly, not to mention difficult to read and maintain. Perhaps that's a symptom of the chosen languages but I suspect it goes deeper than that. It's been my experience that one needs to be able to strike a balance between complexity/elegance and readability. I've been known to write code so clever and elegant I have no idea what it does just months after I write it.
'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'
But there's the rub. Other things are not equal. Functional languages require the developer to approach problems with an entirely different mindset. There is a steep learning curve to really understand how they work. And I'm not talking about just the syntax. Functional languages are fundamentally different than procedural languages. Truly understanding how they work requires a lot more brainpower than procedural languages.
While it's admirable to espouse what you see to be a more elegant and "better" solution, you need to be pragmatic. Getting the millions of software developers in the world to put the effort to completely change their way of thinking just isn't going to happen. The cost/benefit ratio is questionable at best, given that a lot of people could train for a long time and still have difficulty with the basic concepts of functional languages.
Procedural languages are the norm because they're a lot simpler. Procedural languages (including "C with classes" and the like that masquerade for OOP/OOD) are useful to many more people simply because there is less to understand about how they work. It's easier for people to approach problem solution in a procedural way than it is for them to think about it functionally. And that's why functional languages, no matter how elegant or "great" they may be, will never really break into the mainstream.
That's not unlike people who sleep around and are surprised when they get herpegonasyphalide.
However, even the most cautious net user is still vulnerable. There are just too many vectors of attack. I too am cautious when I surf. I never open the attachment of the picture of cute cats that my aunt refuses to stop sending me. I don't follow links people think are hilarious. I run not-windows and not-IE. I have an ad blocker and script blocker.
The thing is, even with all that there are plenty of ways I can get infected. Legitimate websites can themselves get hacked and serve up malware. Places that were fine yesterday may attack my computer today. Virus scanners and firewalls don't always catch the attack. You can even get infected if you never connect to the internet, as we have seen malware find its way onto software distribution CDs. Don't delude yourself. You can only reduce your risk. It is impossible to guarantee that you are 100% virus free unless you never turn your computer on. Ever.
Slashdot Mirror
Anonymously admit you were wrong? Big stretch there...
I know stories like this generate a lot of traffic but what does this have to do with tech news?
I see where the terminology confusion came about. A lack of precision in the original statement left it open to misinterpretation
That makes sense. But it still holds true that the time zones aren't responsible for this change in the length of a day.
and no, the answer is not exactly 20 year ago (ignoring leap years) because timezone changes means that not all days are 24 hours
Time zones have nothing to do with how long a day is. Every time zone has 24 hour days. Unless you live in some weird alternate universe where some days are longer than others...
The changes in daylight savings time may impact exactly what time it is now but the only thing you have to deal with is whether you're currently in daylight savings time. Because within a year, switching to DST and back cancels itself out. A given year will have one day that acts like a 23 hour day and another that acts like a 25 hour day.
The only real thing that would make 20*365*24*60*60 (ignoring leap years) not exactly 20 years ago is if the standard for daylight savings time had changed between then and now. If daylight savings time was in effect then but not now (or not then but in effect now), you'd only be off by one hour.
Cut him a little slack. He may still be suffering from one of the other head injuries he had a while ago...
Yes, that too.
The law may be settled but that doesn't stop people from filing suit anyway. They may either think they have a notable enough exception or they're just working with a lawyer who knows he's going to lose but is getting paid to do what the client tells him to do (after doing his due diligence of informing them of the probable outcome).
Depends on the jurisdiction. Deliberately obscuring your plate from law enforcement cameras is illegal in some states.
I suppose there are a few that don't have cameras. But a lot of them do. Initially, it let them take the staff out of the booth (saving money) while still allowing for enforcement. But, as with any other tool of convenience, it only takes time for someone to want to misuse the system.
So manually paying the tolls is more expensive, takes you longer and doesn't do anything to improve your privacy. Sounds like the decision is a no-brainer to me.
They photograph your license plate at all manual toll collection points too. The police can get those records just as easily. Dropping the pass in favor of dropping coins in the slot doesn't help.
We didn't cover Scheme in my CS class. We did straight LISP (Lost (In (Superfluous (Parenthesis)))).
Sure. But I can do that in a procedural language too. In fact, that's one of the points of OOD. You abstract away your layers with a proper design and your code is small and concise. Of course, it's rare to find that type of design done well but it's possible.
To me, functional languages are actually more intuitive.
I know a lot of academic types for whom that is the case. But I've met far more people who have enough trouble understanding basic procedural language concepts. I don't even want to think of trying to teach them a language that requires a solid understanding of advanced math just to be able to use.
And that's my point. Functional languages have their place, but they will never reach the mainstream because the mainstream just doesn't have the desire (or ability in many cases) to understand the underlying theory that makes it work.
Sounds to me like you're in a situation where a language like that is a viable tool with which to implement a solution. But only because the nature of the problem lends itself to being solved with that specific tool. And when it's the right tool to use, I'm sure it's a fantastic language. But that's just it. How often are people working on problems where it's the best tool? I don't often run into situations where a functional language is the best choice. I'm glad I have it in my tool box along with so many other languages and tools for the few times I need it. But I, and so many other people in the world, just don't work on the kinds of problems where functional languages are really the best tool to apply.
I don't know if you've ever tried teaching functional languages to novices with no math background. To say it's not easy is a colossal understatement. What is far easier is getting them up and running with procedural languages. The concepts are just far easier for the average layman to grasp than the concepts of functional languages. Protest all you want but that's just the way it is.
I have, and my point still stands. A minimalist Lisp language may have a simpler syntax but that's not what I'm referring to when I call the languages simpler. The point is that the concepts behind building software with procedural languages are far more simple than using functional languages. The average office worker can cobble together enough thought process to write basic macros in a spreadsheet. Try getting those same people to use a functional language to do the same thing and then tell me how "simple" those functional languages are.
You really shouldn't insult Geek Squad like that.
Agreed. In fact, just about everywhere I work has a coding standard that says you shouldn't cram a whole lot of stuff into one line of code specifically because it's hard to write correctly, not to mention difficult to read and maintain. Perhaps that's a symptom of the chosen languages but I suspect it goes deeper than that. It's been my experience that one needs to be able to strike a balance between complexity/elegance and readability. I've been known to write code so clever and elegant I have no idea what it does just months after I write it.
Seriously?
What kind of knuckle dragging moron can't figure out how to encrypt the data stream they're backing up?
'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'
But there's the rub. Other things are not equal. Functional languages require the developer to approach problems with an entirely different mindset. There is a steep learning curve to really understand how they work. And I'm not talking about just the syntax. Functional languages are fundamentally different than procedural languages. Truly understanding how they work requires a lot more brainpower than procedural languages.
While it's admirable to espouse what you see to be a more elegant and "better" solution, you need to be pragmatic. Getting the millions of software developers in the world to put the effort to completely change their way of thinking just isn't going to happen. The cost/benefit ratio is questionable at best, given that a lot of people could train for a long time and still have difficulty with the basic concepts of functional languages.
Procedural languages are the norm because they're a lot simpler. Procedural languages (including "C with classes" and the like that masquerade for OOP/OOD) are useful to many more people simply because there is less to understand about how they work. It's easier for people to approach problem solution in a procedural way than it is for them to think about it functionally. And that's why functional languages, no matter how elegant or "great" they may be, will never really break into the mainstream.
The world is only run on emotion. Logic always gets shouted down by people who don't like it or, worse, don't understand it.
Not always. They've driven competitors out of business by building in incompatibilities that break existing functionality. More than once.
That's not unlike people who sleep around and are surprised when they get herpegonasyphalide.
However, even the most cautious net user is still vulnerable. There are just too many vectors of attack. I too am cautious when I surf. I never open the attachment of the picture of cute cats that my aunt refuses to stop sending me. I don't follow links people think are hilarious. I run not-windows and not-IE. I have an ad blocker and script blocker.
The thing is, even with all that there are plenty of ways I can get infected. Legitimate websites can themselves get hacked and serve up malware. Places that were fine yesterday may attack my computer today. Virus scanners and firewalls don't always catch the attack. You can even get infected if you never connect to the internet, as we have seen malware find its way onto software distribution CDs. Don't delude yourself. You can only reduce your risk. It is impossible to guarantee that you are 100% virus free unless you never turn your computer on. Ever.