Implementing one high-level language (CoffeeScript, TypeScript, etc.) via translation to another high-level language (JavaScript) does not make the target language an "assembly language" in any sense.
885 karma · joined December 29, 2013
It's one of those things that sounds good on the surface, but upon further inspection by those who know assembly language it's quite clear that it just isn't true. Yet this doesn't matter when in a crowd that consists of people who, as a whole, don't know assembly language. The claim can be parroted repeatedly, without anyone really questioning it properly.
(I'm not directing this at resu_nimda, by the way. I see his comment more as a reference to the idea, rather than necessarily in support of it.)
I just don't think that there's any significant demand for this product, realized or unrealized. People know about it, and people could choose to use it, but doing so would likely not make them sufficiently better off.
Maybe that's not ideal, from an ideological standpoint or when it comes to "openness". But I think it is the, perhaps unfortunate, reality. It really doesn't make sense to endlessly waste resources on a product that has been proven to be unwanted, or at least not valuable enough to use.
I think if there truly was a pressing need for Persona, we would have seen it get adopted rapidly and quickly. That's exactly what happened with Firefox. That's also what happened with Thunderbird, although to a lesser extent.
Openness is ideal, but it also requires some demand for that openness. Open systems that aren't adopted are really quite useless.
The "if timeval:" case may contain fewer characters, but it's less explicit. Being less explicit opens it up to greater ambiguity. Ambiguity is a form of complexity. Complexity is the opposite of simplicity.
The explicit "is not None" check may require more typing, but it's far more explicit and exact. That means it's much less ambiguous, and thus less complex, and thus exhibits greater simplicity.
I think it's more likely just a bad habit that some people may have picked up when using PHP or JavaScript, and mistakenly continued using after moving to Python.
PEP 8 (http://legacy.python.org/dev/peps/pep-0008/#programming-reco...) is quite clear about this:
"Comparisons to singletons like None should always be done with is or is not, never the equality operators.
Also, beware of writing if x when you really mean if x is not None -- e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!"
PEP 8 is more representative of the actual Python community's views than the mistakes of some programmers who are more accustomed to certain languages that are not Python.
The "Youtube of Flipbooks" tagline makes no sense. It's not really clear what this is trying to express.
The term "flipbooks" also seems to be misused. That term already refers to printed books with pictures that differ slightly from one page to the next. Rapidly flipping through the pages ends up rendering a crude animation. The term "flipbook" is also sometimes used to describe books aimed at children where there's a flap of paper or cardboard that can be flipped up to reveal some image or text underneath. Trying to add a new meaning only leads to confusion.
And while I understand it's still a work in progress, the experience is not very good. Even with a large desktop monitor and a fullscreen browser window, scrolling is required to view the complete pages. The page flipping is also rather distracting. And the content available so far is not very enticing, I'm afraid to say. The low-quality images used in some of the books does not help.
So I have a hard time seeing what value this site provides. The freely available content isn't very appealing, and the reading experience itself is very poor. If the experience won't attract and keep users, then it's unlikely that publishers will be interested. If publishers aren't interested, then users will additionally not be interested. And both of those factors will, of course, directly impact the potential profitability of such a venture.
I think that every aspect of this offering needs to be reworked, unfortunately. Which leads me back to the original question, "What exactly are you trying to achieve with this product?"
What ends up mattering most is how productive you are once you're familiar with it. This is where a language like Python, and most other widely used languages, tend to be much better than Scheme for most programmers.
Scheme may be easier to learn initially, but it's generally much less useful in the long run in most cases.
It also doesn't help to refer to that very legitimate feature request as "childish", especially when it involves core functionality that's very critical to many users.
While events like this do have significance, without a doubt, there is already ample coverage in a very wide variety of general news outlets. Many of the ones that are online allow for discussion, as well.
So there's little need or reason for news sites focusing on rather specific topics like technology, science, mathematics and entrepreneurship to devote page space to rather unrelated political topics. The focus and the depth of coverage is what makes such sites appealing in the first place. Diluting them with news that can be found elsewhere is counterproductive.
Just because somebody points out serious flaws or problems with one technology does not automatically mean that he or she thinks that other, unrelated-yet-similar technologies aren't flawed or are somehow perfect.
Even if the Perl 5 community has generally admitted that Perl 6 was a failure and has moved on, a lot of people first think about how disastrous Perl 6 was well before they think about anything positive involving Perl 5.
I think it has become more of an issue in general as the discussion of software projects has moved away from mailing lists and newsgroups to blogs and other more centralized discussion forums.
I recently saw similar censorship happen at Opera's blogs. I would read some of the comments one evening, and there'd be some good discussion about features that the newer versions of Opera's desktop browsers are still missing. They weren't always positive comments, but they'd be relevant and remarkably civilized given the circumstances. Then I'd read the same blog post a day or two later, and entire discussion threads full of useful content would be gone.
Criticism and negative discussion is often the most valuable that there is. It often highlights real problems that need to be solved. To delete such commentary is not at all helpful, and actually probably quite harmful.
It's pretty clear that Perl does not hold the prominence it once held in the 1990s. So, yes, it is clearly becoming a less-enticing option for a lot of people, whether you're willing to admit this or not.
And the same holds true for "variable". It's a very common term for things that change their state of being, including stuff that isn't directly related to programming or mathematics. Stuff like the weather, somebody's mood, and so on.
"Monoid" just doesn't have any everyday meaning like those terms do, especially a meaning that so closely resembles the programming concept like in the case of "function" and "variable".
Some of those words are very likely non-mathematical words that were adopted and re-purposed by mathematicians. "Tree" is inspired by how the data structure's shape is very similar to that of trees (that is, the plants), for example.
For most C++ terminology, you don't need to give a single-line description. The keyword or concept name alone generally embodies that information very well. To use your example, at a basic level a C++ "template" is quite similar to a form letter, stencil or other real-world "templates". It's a predefined mold that you inject your specific information/material into to get a final product with minimal effort.
There just isn't a direct relation back to the real world with a term like "monoid". You end up with people who are confused at best, or more likely they're thinking of some other word that sounds similar but is totally unrelated.
An "object" is something specific that exists (implying it can likely also be created and destroyed), and can be distinguished from other objects. This applies equally well to a combination of a data structure and some related code as it does to a tennis ball, or to a car, or to a book.
A "method" is a systematic way of doing something. That "something" could be the operations described by some source code, or it could be tying a shoe, or even brushing one's teeth.
"Monoid" has no good real-world parallel. It has no related or relevant meaning outside of very, very specific contexts. That's what makes it "detached". It's off on its own, with an isolated and non-obvious meaning.
Most people are inherently familiar with the concept of a "container", in the sense of something that holds other things, regardless of whether it's a physical container or a data structure.
"Iterator" might not be as clear as "container", but at least most people are familiar with the concept of doing something repeatedly, whether it's some physical action or executing some chunk of source code.
"Monoid" just isn't like that. It may be concrete when constrained to the context of mathematics or programming, but it's quite meaningless outside of those very specific contexts.
However, I would like to think that there's somebody out there who could come up with a name that describes the concept sufficiently, while still using pragmatic C++-style terminology.
All I'm saying is that "monoid" is terminology of a style that's very different from basically all other C++ terminology. To many C++ programmers, even those with a background in mathematics, it's no better than gibberish.
At least the existing C++ keywords and terminology tend to be far more descriptive of what they're referring to, even if there is ambiguity in some cases. This is true even for the more abstract concepts in C++.