So where is the problem?
In your inability to to distinguish between simplistic reasoning and the real world. You're free to accept the wage or not, just as you're free to become destitute. So many choices in a "free" market. Bonus points if you can tell me who has the greater bargaining power in a situation with 10 buyers and 10,000 sellers.
It's the Republicans that want to make sure that engineers make as little money as possible.
Guess which party gets the largest donations from the tech industry.
So if you have invalid stolen plates
Big deal. Just use a white list instead of a black list.
the existing system has a near-infinite upgrade path
That's the point.
And if it were actually used for this purpose you could simply download a list of plates whose registrations have expired or been revoked into each scanner, and have the scanner report it when it saw one of those plates. In other words the LAPD's monitoring goes way beyond what is necessary to enforce the law, which is (or used to be) strongly frowned on by the courts.
It won't mean a thing that you have a car that can run.
Where did I say it did? I simply pointed out that "CME will fry your car" is a myth. CME will fry the electric grid is not a myth, and that's a monster of a problem. Many of the things you mention follow from that.
Instead of listening to your argument, they just dismiss you for being old (you know, early 30s) and not understanding the "new" technology.
You could point out that dynamic typing was introduced one year after static typing. Dynamic typing is state-of-the-art, circa 1958.
Otherwise, you'd have to run your program, and discover that type error at runtime.
Don't be absurd. Type problems don't show up during testing - they show up 3 weeks after the code has been released, and then only in situations that are practically impossible to reproduce. That makes debugging more interesting. Any idiot can find type problems when the compiler does it for you.
So do you rely on implicit or automagical type conversions? That doesn't do much for error checking. No, I don't do web programming, but I've worked on code that had to do a lot of string to whatever conversions. The biggest pain, but one of the most important things, is detecting errors in the string format. You need an explicit function to do that right, and a way to handle the errors. Once you have the explicit function, what's so hard about declaring that it returns an object of class ObiWan?
when I work with dynamically typed languages I tend to spend similar amounts of times if not more figuring out what really is and is not supported with this dynamic object in front me
Much worse than writing dynamically typed code is reading it. If I write function foo in a dynamically typed language, I know it's supposed to return an integer. If I'm reading somebody else's code, I often winding up guessing that an integer makes sense. Of course it may return a float or a string on odd Tuesdays when the moon is full. Much nicer for it to explicitly say it returns an integer, and have the compiler check that that's the truth.
Haskell's NIH version of SQL is tedious. Why didn't they just implement SQL?
I haven't tried SQL, but in general Haskell's libraries are one of its weaknesses.
Also, closures seem to me to violate the premise of static variables and fixed variable scoping. When you introduce closures into a language they are bound to cause all the same problems as global variables.
I don't agree. A closure should produce a new pure function (some languages allow otherwise, but not Haskell). With functions as first class objects, you can just pass and return them like data. There is nothing about that that suggests the evils of globals.
I get sick of spending half my time dicking around with static types, casts, etc and spinning my wheels chasing down type errors
If you spend half, or any appreciable part of your programming time dealing with static typing issues, then you're doing something seriously wrong. Occasionally the compiler will be a pain in the ass about it, but most of the time static typing should require nary a thought. If it's otherwise, you're not thinking about types clearly. The static typing is there to catch you when you screw up. It also serves as useful documentation for the next poor schmuck that has to look at your code, and for good measure the compiler enforces the accuracy of this type of "documentation". If you're really too lazy to type "int" or "double", try a language with type inference.
Then I tried Haskell and my mind was duly blown. Now I'm a huge proponent of static typing, even if I still can't stand Java and avoid C++ unless necessary.
While I have mixed feelings about Haskell as a whole, it's got the best damned type system I've ever seen. My advice to designers of new languages is just copy Haskell's type system.
Actually that sounds a lot like Haskell.
BTW, why is it called Ceylon instead of Sri Lanka?
the reason Scala is so sweet is that it does type inference
Haskell also does type inference.
Old and Modern cars will be unaffected by a CME.
Shhh. You'll ruin the fun - it makes a great urban legend. However, even survivalists don't think it will be a problem (that link also has links to serious studies).
However, if the CME trashes the power grid (a likely effect) you'll have a problem pumping gas for the car because the gas station pumps are electric. I experienced that problem first hand after Hurricane Sandy. IIRC there was talk of a law requiring at least some gas stations to have backup generators, but I don't know what happened to it. You could also just get a hand pump or something, but it'll be slow. There may also be problems with the rest of the delivery network (a problem after Sandy was that some of the fuel barge docks were trashed), and I don't think a loss of the power grid would help refineries, pipelines (they need pumping stations) or possibly even wells very much.
There are two ways to write error-free programs; only the third one works.
