Around the turn of the century, electric cars had a range of about forty miles... the same as the Chevy Volt.
For very large values of "forty":
Honda EV+ (1997-1999): Range ~100mi. Toyota RAV4 EV (1997-2003): Range ~100mi. General Motors EV1 (1996-1999): Range ~160mi.
The Chevy Volt is not, contrary to Chevy's marketing-speak, an "electric car", it is a series hybrid that, like many hybrids, can run pure-electric for a limited range.
Some modern electric cars (like the TH!NK city, range: 110mi) have similar ranges to the much more expensive 1990s EVs, while some more expensive modern electric cars have much better ranges (Tesla Roadster, ~200mi). And of course, both in the 1990s and now, there are less expensive low- and city-speed EVs with shorter ranges that are intended just for commuting, and not for expressway use.
I remember hearing that there actually was a normal-looking hybrid that preceeded the prius.
The original Honda Insight (2000-2006) preceded the Prius, but it was much smaller and less normal looking (as subcompacts go, IMO, not unattractive, but certainly rather distinctive). The earlier (compact) Prius was less distinctive (and, IMO, less attractive) than the current (midsize) Prius.
Frankly, aside from very expensive exotics, I can't think of a better-looking, generally available car on the road, to my tastes, than the current Prius, but degustibus non est disputandum, I suppose.
Is it safe to assume that some competitor has just released a working toolkit for developing cloud applications that works pretty well?
Its not so much a dedicated toolkit, but Amazon has just announced that Windows Server and SQL Server are in private beta on EC2 and will be generally available on that platform by the end of the year, meaning that Windows software not developed for the cloud can nonetheless be moved into Amazon's version of the cloud soon. So, yeah, there is something for them to be heading off.
He's saying that in a month they're going to announce (not ship) something, but he can't talk about it now? So he's telling us that he's not telling us something, but sometime later he will? Why doesn't he just, like, not say anything?
Because Amazon, knowing that Microsoft has been working in this direction, actually announced (not just pre-announced) that Windows Server and SQL Server are now running on EC2 in private beta, and will be generally available by the end of the year.
This pre-announcement is to scare people off of Windows Server on EC2 and get them to wait for MS's offering, because once people have their apps on Windows Server on EC2, it will be harder for MS to convince them to migrate to MS's cloud. (And, conversely, once people have apps running on EC2, Windows Server or otherwise, they'll be more likely to purchase more, platform neutral, Amazon services to go with them, rather than existing or planned competing MS services.)
My best guess is it will use SilverLight instead of AJAX. So you may see something like Office and Money written in SilverLight that you can run in your Browser as long as you are running on Windows.
And, probably, very soon that's the only way you'll get Office or Money, and if you don't want to host your own server and buy server licenses (which will be pricey), you'll just rent the software which will run from Microsoft's servers.
Microsoft's been looking to switch from selling software to Software-as-a-Service for quite a while.
except that MS Office Home and Student is legit to use if you're not a student.
"Home and Student" is really "non-commercial"; for all kinds of serious analysis, its inappropriate for the exact same reasons and student-licensed software, though the particular licensing boundary may be a little different.
Which has bugger-all to do with the standard held-up, which is quick to bang-out a usable GUI for Windows users..Net is not necessary (and, arguably, is often not desirable) for that.
I've used both, and although I usually advocate the B&D of the Pascal family of languages, I'm with the GP -- C# is a really easy language for knocking out a medium-sized, non-mission-critical GUI-intensive program for the.NET platform
The platform referred to was Windows, not.Net: "C# is not the best language for all sorts of problems, but when it comes to banging out a GUI.exe for windows users to use quickly, I don't think there are better choices.". Windows and.Net are two different things, though recent versions of Windows include.Net.
Re:a bunch of questions
on
C# In-Depth
·
· Score: 1
Could it be that C# is one of the most widely used simply because of the installed base of windoze machines all over the world and not because of any technical merit?
Close, but I think the real reason is lots of development shops, particularly corporate/government "in house" shops, standardize on "whatever Microsoft is currently pushing", which is currently.Net & C#.
Getting disbarred is really highly unusual, absent some kind of criminal conviction (like President Clinton's perjury charges).
President Clinton was never charged with, much less convicted of, perjury.
(He also wasn't disbarred from any state bar -- his Arkansas license was suspended for five years; he probably would have been disbarred from the US Supreme Court bar had he not resigned from it.)
well, he could apply to any of the other 49 state's bar, and, if admitted, pass the bar exam there.
The moral character portion of the bar application in most (I would assume all) US jurisdictions would require disclosing a current or past disciplinary action in any other jurisdiction, and a current (and permanent is always current) disbarment would, I suspect, weigh pretty darned heavily against the applicant, and that is especially true in this case, given the basis of the disbarment.
If an app is delivered to end users, then it's not beta.
Yeah, but the whole "public beta" abuse was being used by a lot of people (even large companies) long before Google started its perpetual-beta web apps. The term "beta" has lost its meaning, but Google didn't start it; the meaning was already dead when Google got its hands on it and tore the carcass limb-from-limb.
Is that supposed to imply that what's good for the economy is good for America?
No, its supposed to imply that there are powerful interests supporting the side of less draconian copyright laws offsetting those supporting more draconian laws; its speaking, with a very thin covering of "common interest", to narrowly self-interested politicians that only look to where powerful interests are in the language they understand.
If you aren't that kind of politician, they were talking past you, not to you.
Can anyone say DRM? Consumers do not like DRM and thus are not buying Blu-Ray. The poor economy is also a factor.
The poor economy is most likely several orders of magnitude larger a factor than DRM. Most consumers aren't aware of DRM, but consumers are aware both of the broad economic uncertainty and their own financial position, and the fact is that Blu-ray is a luxury that is looking to gain mass-market, not mere niche, acceptance in a time when people are being squeezed financially.
A few deployed applications doesn't make a programming language "real world"; there have been far more successful functional programming languages than Erlang, and they are still not considered mainstream.
"Mainstream" and "real world" are two very different terms. I would argue that a language (like Erlang) that is well-established in a particular industry niche has hit the "real world", whether or not it is "mainstream". There are certainly more widely used functional languages than Erlang, though most of them are not pure functional languages, and that raises the question of where you draw the line between non-pure functional languages and languages that have functional features but aren't primarily functional (does Ruby count as "functional" language?).
The distinction between lazy and non-lazy functional programming languages is also not as clearcut as you seem to think;
You seem to have missed (hard to do in such a small post, I would have thought) where I pointed out that the distinction is not particularly crisp since laziness is easily implemented in language that aren't inherently "lazy" in the sense that Haskell is, including (but not limited to) other functional languages. In fact, since that's the only thing I said about the distinction, I have no idea where you got the idea that I think the distinction is "clearcut".
Perhaps, but I would argue that computation by definition is not, as a general case, intuitive.
And I would argue that you are right, only because nothing is, as a general case, intuitive. What is intuitive is a function of personal experience and background. As in many other areas, one size does not fit all.
If others can act on your behalf without actually logging in as you, what proof is there that e-mails allegedly sent by you were actually sent by you?
If others can be delegated permissions to act on your behalf in specifically designated manners without logging in to your account, then, if the system logs who did what under what account, there will be accountability.
OTOH, if others can't act on your behalf without logging in as you, and you have a business need them to act on your behalf, you have no choice but to give them your access credentials (dongle, password, whatever) and then there really is no accountability, and no control over the manner in which they can act on your behalf.
So, rather than destroying accountability, supporting delegation enhances accountability (and security).
No matter how much time you invest, you cannot get Haskell code to run as fast as well-written C code; not even close.
The problem with languages like Haskell is that they make easy things easier, and the stuff that actually takes development time in real-world systems hard or impossible.
The stuff that actually takes development time is often getting correctly functioning code in place (and then doing that again when requirements change); expressiveness in functional languages can help that.
Now, in some cases, lots of development time goes in to speed optimization, and in those cases your criticism would seem to be on point, but that doesn't seem to be the main place that development time gets consumed in most projects.
You said it yourself, SQL is declarative, not functional.
The two are not opposed.
But more importantly, people can think of SQL in procedural terms, which is why it's easy to understand.
You can think of any set of instructions, in any model, that can be interpreted to produce a result in any paradigm in which one can design a Turing-complete language.
But, again, I don't see any support for your assertion that SQL is easy to understand because it can be thought of in procedural terms; in fact, I'd argue that SQL is useful precisely because it is easier to understand on its own than it would be to understand the necessary procedural steps to operate on the data to produce the same results, not because it can be translated into those steps.
See, people understand steps. They understand the idea that a computer executes instructions one after the other, and the aggregate of those steps is a software program. It's intuitive because it maps to how people think of algorithms in the real world.
Yes, procedural programming has a close relation to step-by-step instructions, just as functional programming has a close relation to definitions. Both are things that people commonly understand and work with in the real world.
Functional programming, on the other hand, has no analogy in human experience.
As noted above, I think this overlooks quite a lot of human experience.
That really seems like splitting hairs to me, but maybe there's a flash of light that hasn't hit me. In both cases, you're describing the steps required to calculate something; the difference is that Haskell looks like it lets you assume or not bother with things you might have to worry about if the same thing was being written in something like C++.
That's pretty much exactly the advantage of programming in a more declarative style, which is one of the big draws of functional programming (not the only one, but one of them.) I mean, really, in Turing-complete languages, the only possible meaningful distinctions are: (1) Expressiveness, (2) Library support, and (3) Performance.
Enabling more declarative programming is an advantage in #1.
I've always been fascinated with the ideas behind functional programming, but every time I try to learn it, I'm immediately struck by the complete mental disconnect needed to stop thinking about problems from an imperative or OO-based perspective. I've learned enough Python to use it for quick prototyping and testing, and I managed to get far enough into Lisp to realize it wasn't made for humans, but my one foray into Haskell was roughly equivalent to having the math team from my high school kick me repeatedly in the head while shouting, "WHY DON'T YOU GET THIS? THIS IS EASY! YOU MUST BE A RETARD!"
Something about Haskell's syntax, or maybe just the presentation of the tutorials I've found, gets in my way, too.
But no sane person would believe that pure functional programming languages will every really leave their niches.
When one of your niches is "large, distributed, fault tolerant systems", you don't need to leave your niche to become more popular.
(Now, whether lazy functional programming languages will ever find niches outside of academia, much less leave their niches, remains, I think, to be seen; pure functional programming languages, OTOH, can do quite well without leaving their niches.)
Functional programming will become ever more important in the future, but it won't look anything like Haskell when it meets the real world.
Functional, even purely functional, programming languages have already "hit the real world". Erlang is purely functional, and came out of industry.
Lazy functional languages haven't, that I'm aware of, hit their stride in much serious application, but explicit laziness is often easy to add, where it is useful, to other languages, so the big question is whether universal laziness (or even just laziness-by-default) brings enough benefit to make it superior to explicit laziness.
Functional languages follow this pattern: side-effects are only permitted if there is no other way. Examples are Lisp and Scheme, but also Matlab, Mathematica and Scala.
Lisp, per se, is pretty clearly not an example of this, though Scheme is an example of a Lisp-family language that, while not purely functional, at least leans more strongly than many Lisps toward avoiding side effects.
So, if you can show me that you can't have mutable variables in Javascript, we can call it functional.
You can have mutable variables in Lisp, which is usually described as functional. You seem to be saying that functional languages include only pure functional languages, which is pretty clearly not the way the term has traditionally been used (which is why we have the widely used term "purely functional" to refer to purely functional languages.)
JavaScript and Lisp are functional languages. They are not, like Erlang and Haskell, pure functional languages. Similar Java and C++ are OO languages, but are not, like Smalltalk or Ruby, pure OO languages.
The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.
Well, part of the reason for that is that the "current crop of popular languages" are mostly multiparadigm languages with substantial influence from functional languages as well as OO and procedural languages, and whenever something that functional (or any other paradigm) languages do better becomes important in the marketplace, more and more features get moved over into popular languages, or newer languages become more popular.
Slashdot Mirror
For very large values of "forty":
Honda EV+ (1997-1999): Range ~100mi.
Toyota RAV4 EV (1997-2003): Range ~100mi.
General Motors EV1 (1996-1999): Range ~160mi.
The Chevy Volt is not, contrary to Chevy's marketing-speak, an "electric car", it is a series hybrid that, like many hybrids, can run pure-electric for a limited range.
Some modern electric cars (like the TH!NK city, range: 110mi) have similar ranges to the much more expensive 1990s EVs, while some more expensive modern electric cars have much better ranges (Tesla Roadster, ~200mi). And of course, both in the 1990s and now, there are less expensive low- and city-speed EVs with shorter ranges that are intended just for commuting, and not for expressway use.
The original Honda Insight (2000-2006) preceded the Prius, but it was much smaller and less normal looking (as subcompacts go, IMO, not unattractive, but certainly rather distinctive). The earlier (compact) Prius was less distinctive (and, IMO, less attractive) than the current (midsize) Prius.
Frankly, aside from very expensive exotics, I can't think of a better-looking, generally available car on the road, to my tastes, than the current Prius, but degustibus non est disputandum, I suppose.
Its not so much a dedicated toolkit, but Amazon has just announced that Windows Server and SQL Server are in private beta on EC2 and will be generally available on that platform by the end of the year, meaning that Windows software not developed for the cloud can nonetheless be moved into Amazon's version of the cloud soon. So, yeah, there is something for them to be heading off.
Because Amazon, knowing that Microsoft has been working in this direction, actually announced (not just pre-announced) that Windows Server and SQL Server are now running on EC2 in private beta, and will be generally available by the end of the year.
This pre-announcement is to scare people off of Windows Server on EC2 and get them to wait for MS's offering, because once people have their apps on Windows Server on EC2, it will be harder for MS to convince them to migrate to MS's cloud. (And, conversely, once people have apps running on EC2, Windows Server or otherwise, they'll be more likely to purchase more, platform neutral, Amazon services to go with them, rather than existing or planned competing MS services.)
And, probably, very soon that's the only way you'll get Office or Money, and if you don't want to host your own server and buy server licenses (which will be pricey), you'll just rent the software which will run from Microsoft's servers.
Microsoft's been looking to switch from selling software to Software-as-a-Service for quite a while.
"Home and Student" is really "non-commercial"; for all kinds of serious analysis, its inappropriate for the exact same reasons and student-licensed software, though the particular licensing boundary may be a little different.
Which has bugger-all to do with the standard held-up, which is quick to bang-out a usable GUI for Windows users. .Net is not necessary (and, arguably, is often not desirable) for that.
The platform referred to was Windows, not .Net: "C# is not the best language for all sorts of problems, but when it comes to banging out a GUI .exe for windows users to use quickly, I don't think there are better choices.". Windows and .Net are two different things, though recent versions of Windows include .Net.
Close, but I think the real reason is lots of development shops, particularly corporate/government "in house" shops, standardize on "whatever Microsoft is currently pushing", which is currently .Net & C#.
They follow the radial corridors.
Since ships aren't waves, they presumably have little trouble following them.
Unless you live in a place where peak energy demand is driven by air conditioning usage.
President Clinton was never charged with, much less convicted of, perjury.
(He also wasn't disbarred from any state bar -- his Arkansas license was suspended for five years; he probably would have been disbarred from the US Supreme Court bar had he not resigned from it.)
The moral character portion of the bar application in most (I would assume all) US jurisdictions would require disclosing a current or past disciplinary action in any other jurisdiction, and a current (and permanent is always current) disbarment would, I suspect, weigh pretty darned heavily against the applicant, and that is especially true in this case, given the basis of the disbarment.
Yeah, but the whole "public beta" abuse was being used by a lot of people (even large companies) long before Google started its perpetual-beta web apps. The term "beta" has lost its meaning, but Google didn't start it; the meaning was already dead when Google got its hands on it and tore the carcass limb-from-limb.
No, its supposed to imply that there are powerful interests supporting the side of less draconian copyright laws offsetting those supporting more draconian laws; its speaking, with a very thin covering of "common interest", to narrowly self-interested politicians that only look to where powerful interests are in the language they understand.
If you aren't that kind of politician, they were talking past you, not to you.
The poor economy is most likely several orders of magnitude larger a factor than DRM. Most consumers aren't aware of DRM, but consumers are aware both of the broad economic uncertainty and their own financial position, and the fact is that Blu-ray is a luxury that is looking to gain mass-market, not mere niche, acceptance in a time when people are being squeezed financially.
"Mainstream" and "real world" are two very different terms. I would argue that a language (like Erlang) that is well-established in a particular industry niche has hit the "real world", whether or not it is "mainstream". There are certainly more widely used functional languages than Erlang, though most of them are not pure functional languages, and that raises the question of where you draw the line between non-pure functional languages and languages that have functional features but aren't primarily functional (does Ruby count as "functional" language?).
You seem to have missed (hard to do in such a small post, I would have thought) where I pointed out that the distinction is not particularly crisp since laziness is easily implemented in language that aren't inherently "lazy" in the sense that Haskell is, including (but not limited to) other functional languages. In fact, since that's the only thing I said about the distinction, I have no idea where you got the idea that I think the distinction is "clearcut".
And I would argue that you are right, only because nothing is, as a general case, intuitive. What is intuitive is a function of personal experience and background. As in many other areas, one size does not fit all.
If others can be delegated permissions to act on your behalf in specifically designated manners without logging in to your account, then, if the system logs who did what under what account, there will be accountability.
OTOH, if others can't act on your behalf without logging in as you, and you have a business need them to act on your behalf, you have no choice but to give them your access credentials (dongle, password, whatever) and then there really is no accountability, and no control over the manner in which they can act on your behalf.
So, rather than destroying accountability, supporting delegation enhances accountability (and security).
The stuff that actually takes development time is often getting correctly functioning code in place (and then doing that again when requirements change); expressiveness in functional languages can help that.
Now, in some cases, lots of development time goes in to speed optimization, and in those cases your criticism would seem to be on point, but that doesn't seem to be the main place that development time gets consumed in most projects.
The two are not opposed.
You can think of any set of instructions, in any model, that can be interpreted to produce a result in any paradigm in which one can design a Turing-complete language.
But, again, I don't see any support for your assertion that SQL is easy to understand because it can be thought of in procedural terms; in fact, I'd argue that SQL is useful precisely because it is easier to understand on its own than it would be to understand the necessary procedural steps to operate on the data to produce the same results, not because it can be translated into those steps.
Yes, procedural programming has a close relation to step-by-step instructions, just as functional programming has a close relation to definitions. Both are things that people commonly understand and work with in the real world.
As noted above, I think this overlooks quite a lot of human experience.
That's pretty much exactly the advantage of programming in a more declarative style, which is one of the big draws of functional programming (not the only one, but one of them.) I mean, really, in Turing-complete languages, the only possible meaningful distinctions are:
(1) Expressiveness,
(2) Library support, and
(3) Performance.
Enabling more declarative programming is an advantage in #1.
Something about Haskell's syntax, or maybe just the presentation of the tutorials I've found, gets in my way, too.
When one of your niches is "large, distributed, fault tolerant systems", you don't need to leave your niche to become more popular.
(Now, whether lazy functional programming languages will ever find niches outside of academia, much less leave their niches, remains, I think, to be seen; pure functional programming languages, OTOH, can do quite well without leaving their niches.)
Functional, even purely functional, programming languages have already "hit the real world". Erlang is purely functional, and came out of industry.
Lazy functional languages haven't, that I'm aware of, hit their stride in much serious application, but explicit laziness is often easy to add, where it is useful, to other languages, so the big question is whether universal laziness (or even just laziness-by-default) brings enough benefit to make it superior to explicit laziness.
Lisp, per se, is pretty clearly not an example of this, though Scheme is an example of a Lisp-family language that, while not purely functional, at least leans more strongly than many Lisps toward avoiding side effects.
You can have mutable variables in Lisp, which is usually described as functional. You seem to be saying that functional languages include only pure functional languages, which is pretty clearly not the way the term has traditionally been used (which is why we have the widely used term "purely functional" to refer to purely functional languages.)
JavaScript and Lisp are functional languages. They are not, like Erlang and Haskell, pure functional languages. Similar Java and C++ are OO languages, but are not, like Smalltalk or Ruby, pure OO languages.
Well, part of the reason for that is that the "current crop of popular languages" are mostly multiparadigm languages with substantial influence from functional languages as well as OO and procedural languages, and whenever something that functional (or any other paradigm) languages do better becomes important in the marketplace, more and more features get moved over into popular languages, or newer languages become more popular.