... reimplementing jQuery (which is 31K, btw) badly in uncacheable custom ways without being able to draw on the years of expertise of the developers of jQuery would be a great alternative.
Performance doesn't matter any more. Correctness and quick development does. FP provides that in abundance. (Of course, correctness is just another way to say "quick development" nowadays, but whatever...)
To adress some of your points:
1) Two words: undefined behavior. You'll find it around every corner in C or C++ (two very different languages, of course) -- this leads to unreasonably hard-to-find bugs. In C++ it's also extremely hard to avoid such behavior consistently -- compilers are happy exploit it for optimizations, but somehow can't provide warnings for all cases where you are (unwittingly) relying on UB.
2) Really? Haskell or Ocaml do not rely on any of those things you mentioned. Difficult? Perhaps, but see my point #1. Besides, who would you like making your software... someone who's just "learned java" or someone who knows what the fuck they're doing?
3) So all FP languages which don't perform as well as C (or order-of-magnitude at least) don't perform as well as C. What an insight. Btw, Haskell is also within OoM of C. Also, see the top of this post.
4) How hardware works is fucking irrelevant. If compiler for language X can optimize "fib N" to a constant expression it doesn't matter if your C compiler can generate code which executes a million iterations of a fib-computing loop per second. Certainly, we're not quite there yet, but in the C world there's no hope of doing this beyond *really* simple examples (aka not fib), but FP could conceivably get further. (TC is a barrier, but you can still do useful computation even without TC.) See also: top of this reply.
... and the rest of your comment is personal preference. That's fine, but stop pretending you have anything of value to contribute wrt. the relative value of various programming paradigms, mkay? I don't either, but I know bullshit when I see it.
It's a distortion to suggest that the model doesn't work when clearly it does.
It sort of works (see all the issues mentoined already) -- that doesn't mean that it can't be improved upon, nor that this partiuclar idea is a bad one.
The major problem with the UNIX philosophy in this area is that lots and lots of programs now contain informally specified (i.e. specified by implementation), badly written ad-hoc parsers for the output of other programs. This leads to lots of minor, but amazingly annoying issues(*). (The output format itself is often also often badly specified.)
(*) Trying to parse out stack traces from JVM application servers is my particular favorie. It can certainly be done, but it requires code which should be unnecessary (and [b]is[/b] unnecessary if logging to a DB, for example) and it isn't particularly reliable.
Also, I definitely do not believe in SmartPtrs, because they can always be eliminated by looking more closely at the problem.
You're missing the point of why people use smart pointers. Hint: It's not because the job couldn't be done in any other way. (... though, actually, I seem to remeber there being some dynamic programming algorithms which are fiendishly difficult to implement without garbage collection... or at least implementing your own version of garbage collection.)
Closed-over variables are more private than Java's "private" modifier. In Java, you can actually get access to an object's privates by reflection and using setAccessible(true)... so much for privacy.
To be a good JavaScript programmer, all you really have to understand are the concepts related to objects and scope.
I don't think that's true. There are lots of non-obvious things in Javascript which are really required to make coding in JS tolerable, the "private through closure" pattern is just one of them.
Working with Objects seems particularly primitive to me. I believe someone else pointed out the lack of strong typing and inheritance, among other things
Prototypal object models are just different from class-based object models. Neither is particularly better/worse than the other, just different. If you want to you can even implement "classical" object orientation in Javascript if you want.
You can almost get strong typing (not static) in Javascript if you always use the "===" and "!==" operators instead of "==" and "!=". (See "JavaScript: The Good Parts" by Crockford and JSLint.com.)
I wish that hardware manufacturers, browser develoeprs, and web standards groups, etc. would normalize and standardize languages and hardware access so that it [...]
This was more or less what happened with the DOM... one the (rightly) most maligned APIs of all. You may think you want an API designed by a committee, but you really don't. If DOM isn't example enough, I don't know what would be.
The goal obviously isn't to catch terrorists, so it can't be that. Maybe it's just "who fucks you over the cheapest?"... but then we could just get rid of the TSA (or any corporate TSA-like entities.)
Check out Clever Hans and then ask yourself why people demand extraordinary evidence.
Personally, I don't think humans are all that special. We're ruled much more by our lower/base instincts than we like to admit. Most of what appears to ourselves like free will appears (from research) to be post-hoc rationalization rather than actual free will.
The first is subjective... there are plenty of good things about dynamic weak typing.
Note that "dynamic" (as opposed to "static") and "weak" (as opposed to "strong") are orthogonal in this context. Dynamic type checking can be a good thing. Weak typing... not so much.
I haven't been bit by scoping rules too many times, I think that's mostly because I don't write JS like it's C or Java.
The point is that the current JS scoping rules have no easily discernible advantage over normal lexical block scopes. It's a "feature" which leads to hard-to-find bugs for no advantage.
Sure, we have JSLint and/or strict mode, but that's not really a full solution.
(I realize JS is its own languge, but the mere fact that the syntax is so close to C/Java should be taken into account when departing from "normal" semantics in C-like langauges. Especially if it doesn't actually have any noticable advantages.)
The === vs == operator thing is dumb, but hardly as dumb as PHP's situation, and honestly in all the lines of JS I've written, I've never had to use ===.
Read "JavaScript: The Good Parts" (or just watch this) for why you should NEVER EVER use "==" in any capacity.
Because, I don't see the similarity... Last time I tried it, Debian stable was years out of date wrt. common "non-base" packages (Firefox/Iceweasel). Also, Debian unstable was far too 'loose' with various system packages (udev, xorg, glibc, kernel) and yet various packages were still lagging far behind what we're used to. This was especially noticable with Firefox/Iceweasel and Thunderbird/Icedove. (I don't see how a simple rebranding can lag so much behind, but I digress...)
If only it were possible to have the best of both worlds, a stable "base" and new/recent applications. I think e.g. PBI-9 from PC-BSD may have a chance of doing that, but none of the currently popular package systems offer anything like it. (Yeah, I read the paper, so kill me.)
Personally, I think it would be interesting if the base (kernel, glibc, that kind of thing) were updated every 6-12 months, but applications were rolling release.
Ubuntu is kind of close with PPAs, but it's a bit of a crapshoot if your particular application has a (high-quality) PPA.
but apparently I hadn't read it thoroughly enough:). Good to know that it's a least technically possible.
Still, even if it is technically permissible to throw in destructors, it seems too fraught with danger to actually contemplate seriously. I wonder if the standard fstream classes do something like this if running in "exception mode"...
The new Java 7 resource statement does something more useful here. It catches the exception and attaches the stack trace to the original exception (if there was one). If there wasn't a pending exception when the close failed, it actually throws.
That's not something which can be done in C++ because destructors (as you say, and of course, I knew before asking:)) cannot throw.... but this also means that if a file fails to close() during normal RAII (perhaps because of a failing flush), there is absolutely no way to tell the user code. So you end up with subtly broken behavior.
In Java (7 or earlier) your code WILL get an exception and won't fail silently.... and that is why RAII is broken (in C++ at least).
Slashdot Mirror
... reimplementing jQuery (which is 31K, btw) badly in uncacheable custom ways without being able to draw on the years of expertise of the developers of jQuery would be a great alternative.
You're definitely getting an internet for Christmas.
What... astroturfing?
No it wont.
Performance doesn't matter any more. Correctness and quick development does. FP provides that in abundance. (Of course, correctness is just another way to say "quick development" nowadays, but whatever...)
To adress some of your points:
1) Two words: undefined behavior. You'll find it around every corner in C or C++ (two very different languages, of course) -- this leads to unreasonably hard-to-find bugs. In C++ it's also extremely hard to avoid such behavior consistently -- compilers are happy exploit it for optimizations, but somehow can't provide warnings for all cases where you are (unwittingly) relying on UB.
2) Really? Haskell or Ocaml do not rely on any of those things you mentioned. Difficult? Perhaps, but see my point #1. Besides, who would you like making your software... someone who's just "learned java" or someone who knows what the fuck they're doing?
3) So all FP languages which don't perform as well as C (or order-of-magnitude at least) don't perform as well as C. What an insight. Btw, Haskell is also within OoM of C. Also, see the top of this post.
4) How hardware works is fucking irrelevant. If compiler for language X can optimize "fib N" to a constant expression it doesn't matter if your C compiler can generate code which executes a million iterations of a fib-computing loop per second. Certainly, we're not quite there yet, but in the C world there's no hope of doing this beyond *really* simple examples (aka not fib), but FP could conceivably get further. (TC is a barrier, but you can still do useful computation even without TC.) See also: top of this reply.
I'm sure there are billions and billions of moon rocks out there.
- False Dichotomy, this is metamatic.
- metamatic, this is False Dichotomy.
It sort of works (see all the issues mentoined already) -- that doesn't mean that it can't be improved upon, nor that this partiuclar idea is a bad one.
The major problem with the UNIX philosophy in this area is that lots and lots of programs now contain informally specified (i.e. specified by implementation), badly written ad-hoc parsers for the output of other programs. This leads to lots of minor, but amazingly annoying issues(*). (The output format itself is often also often badly specified.)
(*) Trying to parse out stack traces from JVM application servers is my particular favorie. It can certainly be done, but it requires code which should be unnecessary (and [b]is[/b] unnecessary if logging to a DB, for example) and it isn't particularly reliable.
Never mind that rampant objectification, it's the fucking spelling of her name that really gets my goat.
No, it's just that you're completely incoherent.
You're missing the point of why people use smart pointers. Hint: It's not because the job couldn't be done in any other way. (... though, actually, I seem to remeber there being some dynamic programming algorithms which are fiendishly difficult to implement without garbage collection... or at least implementing your own version of garbage collection.)
or maybe Slashdot is fucking dying. Seriously, what the fuck are the "editors" actually doing?
Closed-over variables are more private than Java's "private" modifier. In Java, you can actually get access to an object's privates by reflection and using setAccessible(true)... so much for privacy.
I don't think that's true. There are lots of non-obvious things in Javascript which are really required to make coding in JS tolerable, the "private through closure" pattern is just one of them.
Prototypal object models are just different from class-based object models. Neither is particularly better/worse than the other, just different. If you want to you can even implement "classical" object orientation in Javascript if you want.
You can almost get strong typing (not static) in Javascript if you always use the "===" and "!==" operators instead of "==" and "!=". (See "JavaScript: The Good Parts" by Crockford and JSLint.com.)
This was more or less what happened with the DOM... one the (rightly) most maligned APIs of all. You may think you want an API designed by a committee, but you really don't. If DOM isn't example enough, I don't know what would be.
Traditional economic 'theory' assumes that people act as entirely rational selfish entities. Unfortunately that isn't how people actually work.
Seriously? What criteria would they compete on?
The goal obviously isn't to catch terrorists, so it can't be that. Maybe it's just "who fucks you over the cheapest?"... but then we could just get rid of the TSA (or any corporate TSA-like entities.)
Check out Clever Hans and then ask yourself why people demand extraordinary evidence.
Personally, I don't think humans are all that special. We're ruled much more by our lower/base instincts than we like to admit. Most of what appears to ourselves like free will appears (from research) to be post-hoc rationalization rather than actual free will.
Note that "dynamic" (as opposed to "static") and "weak" (as opposed to "strong") are orthogonal in this context. Dynamic type checking can be a good thing. Weak typing... not so much.
The point is that the current JS scoping rules have no easily discernible advantage over normal lexical block scopes. It's a "feature" which leads to hard-to-find bugs for no advantage.
Sure, we have JSLint and/or strict mode, but that's not really a full solution.
(I realize JS is its own languge, but the mere fact that the syntax is so close to C/Java should be taken into account when departing from "normal" semantics in C-like langauges. Especially if it doesn't actually have any noticable advantages.)
Read "JavaScript: The Good Parts" (or just watch this) for why you should NEVER EVER use "==" in any capacity.
Did you read the paper?
Because, I don't see the similarity... Last time I tried it, Debian stable was years out of date wrt. common "non-base" packages (Firefox/Iceweasel). Also, Debian unstable was far too 'loose' with various system packages (udev, xorg, glibc, kernel) and yet various packages were still lagging far behind what we're used to. This was especially noticable with Firefox/Iceweasel and Thunderbird/Icedove. (I don't see how a simple rebranding can lag so much behind, but I digress...)
If only it were possible to have the best of both worlds, a stable "base" and new/recent applications. I think e.g. PBI-9 from PC-BSD may have a chance of doing that, but none of the currently popular package systems offer anything like it. (Yeah, I read the paper, so kill me.)
Personally, I think it would be interesting if the base (kernel, glibc, that kind of thing) were updated every 6-12 months, but applications were rolling release.
Ubuntu is kind of close with PPAs, but it's a bit of a crapshoot if your particular application has a (high-quality) PPA.
I was basing my information on this:
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9
but apparently I hadn't read it thoroughly enough :). Good to know that it's a least technically possible.
Still, even if it is technically permissible to throw in destructors, it seems too fraught with danger to actually contemplate seriously. I wonder if the standard fstream classes do something like this if running in "exception mode"...
The new Java 7 resource statement does something more useful here. It catches the exception and attaches the stack trace to the original exception (if there was one). If there wasn't a pending exception when the close failed, it actually throws.
That's not something which can be done in C++ because destructors (as you say, and of course, I knew before asking :)) cannot throw. ... but this also means that if a file fails to close() during normal RAII (perhaps because of a failing flush), there is absolutely no way to tell the user code. So you end up with subtly broken behavior.
In Java (7 or earlier) your code WILL get an exception and won't fail silently. ... and that is why RAII is broken (in C++ at least).
Lazy evaluation has nothing to do with it.
Not even lambdas are needed, nor anonymous classes. All you need is the ability to instantiate objects (with state) dynamically (aka. "new").
Of course anonymous classes and (especially) lambdas make such an API much nicer to use.
simply scoped resources that is.
An intermediate representation is being interpreted.