There are lots of whats that speciation could occur -- one obvious one is that the population gets split into two which then evolves away from each other. If you had 100 different high related species then they would likely compete with each other or interbred. The end result of either is that you end up with fewer populations -- one wipes out the other, or the two interbred till they become one.
Pizza is not that healthy, I am afraid. The problem is that most Italian pizza's have really significant amounts of salt in both the base and the topping. Of course, Italians tend to use rather too much salt to my taste anyway, but Pizza is where it is the biggest issue, because it doesn't taste really salty. The only reason you know is that you have to pee a lot afterwards.
It's not quite that misinformed. Emacs lisp is a special purpose language. It's implemented in the Emacs core and is not implemented any where else. It's in the same family as the 1958 lisp, but is none-the-less as different language from all the others.
It's actually quite a nice language; it has some nice data types good for editors. And being a lisp, you can layer anything you want on top of it.
Why not mercurial? Two main reasons, I can think of. Firstly, some of Emacs (ELPA) is already hosted on git. And, secondly, because Emacs support for git (magit) is way ahead of that for mercurial.
ESR gives a third reason, which is that git has won and mercurial is not in great health, and may end up in the same position as bzr. Maybe, maybe not, but it's a factor.
This is demand lead. Students want Java. Many of them think it's good, or that it's a "real" language or something. Even though, it's not actually very good for teaching, it's what people want.
Ant? Seriously, you have to be kidding!
The bottom line is that there is no replacement for Make; it still does what it was designed for very well. I use it when ever I have lots of small files with unix commands to convert them; python normally shows up there as well.
But make sucks for Java, hence ant, and then maven. And I use leiningen for Clojure. I'm not sure having one build tool per language is a great situation, but there you have it. But make fills its niche and it will be there in quite a few years time.
"Is the peer review process at open-access journals acceptable?"
It's a perfectly scientific question; you can address most questions, including those about values and personal preference, with a scientific methodology.
But it's a poor question, because open access has no bearing on the question -- Is the peer-review process acceptable.
All he has done is sub-select a biased, non-randomised group in the first place. To justify this, he should be comparing open access
to something else, otherwise, it has no role in the experiment.
Basically, he's taken a journalistic approach -- performed a test which gave him the answer he needed for the story -- and not a scientific
approach. It does raise a lot of questions about peer-review. In particular, it raises the question of what sort of peer review did this paper go
Well, the editor is really good. It's fast and light. It's works with pretty much every language every invented and several that haven't yet. It integrates fantastically with all the different version control systems out there. You can plug it into any command line tool that you want. It's got find and grep support. You can connect to remote machines via ssh. You can use it entirely without a mouse. It has some incredible buffer and file switching facilities that mean you can open the right file instantly. It's got org-mode, which is a work of insane genius. If you do lisp it has paredit which has been widely copied.
You can configure it however you like. I configure it so that it does different things on different machines but feels that same to me; I've also got a custom colour scheme for use on my laptop, when it's sunny, It works over X, so I can use my desktop while plugged into the wall; you can also have two people editing the same file in different places this way. When it doesn't have a mode for what every you are editing, it's not that hard to write one. You can release these and people will help to improve them for you.
it's not as polished at editing Java as Eclipse that's true. It's a jack of all trades. If I worked on one project, in one language, I would use eclipse (or whatever was best for that one language). Because I switch a lot I use emacs. Actually, at the moment, I am doing a lot of clojure, so I'd use Emacs anyway. But that's a side issue.
The different factions do different things. ELPA is server based, but works with a raw Emacs. el-get gets files in a number of ways, but I suspect that git checkouts are the most common. But you need git installed.
I suspect it will come together a bit more eventually though.
The problem with these is that they get out of date; more over, if you use emacs a lot, then having to use different package management systems on different operating systems is also a pain. Likewise, with tools like R.
So, it all depends on your application and your requirements. I a combination of ELPA style packages, and checkout git repositories for my Emacs package management. And, yes, version conflicts happen. But, the alternative of living with very old packages isn't always great either.
Some publishers do require exclusivity. Some do not. There is a free-to-submit equivalent. Ironically, it's licence is also a bit restrictive for this sort of thing.
Basically, we got ourselves tied up here. It all made sense 20 years ago. Now it doesn't. The social incentives to give away our value for free are still there.
And the publishers want to keep this also. Trying to make understand the situation now is pointless; you have to look at the history.
Hopefully, the future will be better than the present.
This is actually at the root of the problem. The general ideology is these days moving toward the idea that the private sector is the only plausible way to function. A marked change from the days when we a mixed economy with different kinds of entity were considered important; this is why we invented the legal frameworks for charities, not-for-profits and so forth. Perhaps all of this is pointless. Personally, I think not. There are some things that are worth achieving, could be achieved but for which is is hard to find a business model for.
One solution to this problem is hope that a few people earn pots of money, and then give it away in a fit of philanthropy. This can work, although there is a problem; generally these sort of entities are only willing to give money to things on which it is possible to attach an advert saying who bought it. This is, I think, the core problem here. Easy to stick a label on the side of a new van; much harder to do so with the diesel.
I think we will be, and are becoming, a poorer world for this. Perhaps the trend will turn back again.
The problem with type checking is that sooner or later you want to do something that is very hard to type check. So, then you have to reinvent and extend the type system. If you look, for example, at Java which had a nice simple type system, but one that was too simple; now we have upper bound, wild card types in the generics, which I still don't fully understand and have to look up every time I want to use. Complicated.
Finally, type checking tends to add syntax; Java, again, is an extreme example, Scala much less so. If you want to build a DSL, for example, then the added syntax of types is significant. What ends up happening is the developer produces a config file which the application parses. With a simpler syntax for the language, you can just use the language instead.
Type checking is a good thing, but it is one that comes at a cost. As with many areas of programming, it is a question of weighing the gains and the losses.
The GPL is hard to understand, because it is quite long. This is because it is written to have legal meaning. It's the legal system(s) that is at fault here, I think.
A generic license like that is basically pointless, because it has to define what "revenue" actually is. I bet that Google could prove that they make no profit if they wanted to. In fact, they do prove that they make no profit, which is why the poor souls don't have to pay tax.
If you want this form of license on software that is GPL, then write to the authors and ask them. This will involve a period of contract negotiation, and they will probably only be bothered if you can convince them that you are likely to turn a profit. And away you go.
The bottom line problem is not that GPL is bad. It's that you don't have any money. Over the last twenty to thirty 30 years, we have transformed our societies to one where the market rules us; you don't have any money, well, tough.