Allergic to *plants*? What? That's the saddest first world problem I've ever heard of. How the hell do keep yourself in a plant-free environment anyway?
How do you account for the large number of Dutch articles on Wikipedia then?
I think it might be possible that a good understanding of English within a population actually boosts the number of articles in their local language. You can't deny the fact that most of the content on the internet is written in English, so being fluent in that language makes the internet as a whole more accessibility and attractive. I think this results in a higher internet penetration in countries where citizens are more fluent in English. I think there's a good chance this higher internet-saviness will in turn result in a higher awareness of the local internet and a richer local Wikipedia as a result of that. Just theorizing though, I obviously have no proof or evidence of this at all.
The ratio between articles in Danish and speakers of the Danish language is still much, much higher than that of equally obscure languages in southern and eastern Europe.
That does explain the relative high number of articles in western/northern Europe, but it doesn't account for the lack of articles in equally obscure languages, such as Hungarian or Greek. I still think the ratio between articles in a language on Wikipedia and number of speakers of that language is a good way to measure internet penetration in countries.
It obviously fails for languages without a strong connection to a specific country, such as English or Spanish. But even so, it's interesting to see that the English Wikipedia has over 4 times the number of articles, while the number of speakers worldwide is roughly equal. Maybe more people speak English than Spanish, I don't know, but it certainly isn't 4 times as much. So I still think this is a pretty good way to say something about how many people are using the internet in certain language areas.
Even so, Denmark has only about 6 million citizens, yet they've written almost 160.000 articles in Danish on Wikipedia. That's a *way* better ratio than most southern/eastern European countries. The Romanian Wikipedia for example only includes 10.000 more articles than the Danish one, yet their population is more than three times as large as Denmark. And even a relatively wealthy and modern country like Italy has a ratio which is far worse (almost 900.000 articles with a population of 60 million.)
I'm always amazed when I see the number of articles on Wikipedia in different languages. The German Wikipedia for example has about 1.3 million articles, while the number of German-speaking people is about 100 million. There are *a lot* more people speaking Spanish around the world (Mexico alone has more than 100 million citizens), yet there are only about 850.000 articles in Spanish on Wikipedia.
I think the number of articles says a lot about internet penetration in European countries, because most of them have their own language. The Dutch Wikipedia for example has almost a million articles, while only about 30 million or so people actually speak the language. You see the same sort of ratio between articles to speakers in other nordic and western European countries. This ratio drops sharply as you move towards the east and south of Europe. People seem to be a lot less interested to add content to the internet in those countries. You could argue a poor country has other more important preoccupations, but people in countries such as Spain or Italy aren't all that poor, yet they don't seem to be adding a lot of articles to Wikipedia either.
Looking through PHP's changelog makes it clear that adding new stuff is not exactly a priority. Sure there is a handful of new stuff, but it's taking them ages to do tiny steps forward. So it took them three years to add four new features. You think that's rapid enough to keep up with the ever changing needs of the web as an application platform? I don't.
I understand it may be a hassle to wait for an updated framework. But that's what you get with updates. Of course I'm not going to tell you to modify a framework yourself, but it shouldn't take the maintainers of those frameworks years to update either. (If it does, you might want to consider changing frameworks.) And you don't run a cutting edge version of PHP on a production server anyway, so it's fine if you wait for the updated framework before actually updating the server itself, right?
Things like mcrypt happen. It's annoying, but it will be resolved. It doesn't mean the whole PHP project shouldn't keep moving forward. All in all I think the number of major incompatibilities are really small and most things are announced years in advance through warnings. The documentation also does a great job of keeping people posted on changes in the way things are handled by PHP and what the best practices are regarding different subjects.
Erm... what? Have you actually looked at the changelog in the past few years? It's all bug fixes, there's absolutely nothing interesting going on there! Development in PHP has completely stagnated for years now. PHP 5.2 was released in 2006 (!!!) and still not everybody has caught on. Then 5.3 came out 3 years later, but it's even rarer to encounter that in the wild. The differences are totally marginal and the stuff they're deprecating is mainly bad stuff from PHP3 and PHP4 that you shouldn't have been using in anything for the last couple of years anyway.
There's a lot wrong with PHP and there's a lot of bad stuff in there, but in my opinion the worst thing about PHP is the lack of progress to improve things. So no, I don't agree the language changes too rapidly, I think it's changing not nearly rapid enough.
I've already countered that argument in this post. Am I in Groundhog Day or something?
By making yourself sit next to an outlet all the time, you take away the portability and with that the benefit of a notebook. Having 2 hours between full charges doesn't fix this problem, because two hours is too short of a period to do any meaningful work. It also creates a very restless state of being, because two hours fly by very quickly when you're engaged in your work, so you have to watch your battery status all the time. And then, when your battery is depleted after these two hours, you don't magically get a full charge when you find an outlet. You are required to sit next to that outlet for at least another hour to get your battery full again, during which you have no mobility and thus no advantage of working on a portable computer.
I'm sure for some situations or some people, two hours of battery life is fine. And if you don't mind to work near an outlet most of the time, that's your choice. But to me it makes no sense at all to have a notebook with such short battery life. I use my notebook to go to meetings, where I want to show stuff and write down annotations. It's a nuisance to plug in during such events, which I rather prevent. I also hate it to bother a client with the question of where an outlet is I can use when I go visit one. And when I'm home, I like to sit on the couch with my notebook without having to worry about a stupid cable across the room. I've used different notebooks for about 8 years now, but never owned one that had less than 5 hours of juice. I just don't see the point of having a notebook when I can't use it on the go for a solid couple of hours. But that's me.
You're completely entitled to that opinion and I for one try my best to make sure every web application I develop is completely functional without the need of client-side scripting. But you can't ignore the added benefits in user experience of a scripted application. You may not like it, but Javascript profoundly enhances the web. If it weren't for Javascript, the web would have been replaced by now.
Without NoScript who cares? It isnt a functional browser.
I don't like NoScript. I understand the dangers of JS, but in my opinion NoScript is just too much. Every single website out there relies on having functional Javascript. So you just end up enabling it on every site you visit. Which in my view kind of defies the purpose of having the plugin at all.
I'm more than happy with ClickToFlash, AdBlock and Ghostery and I've disabled the support of Java. But Javascript to me is just an essential part of the web and I wouldn't want to use websites without it.
I'm sorry, you are right, I've been a bit sloppy in laying down my argument. And I also agree Chrome's model works quite well, especially for home users, because Google keeps the UI and API very consistent between major versions and nobody is bothered by dialogs and restarts in order to get the latest version.
But you see, I do believe there is a meaning to a version number. It's not just a label nobody cares about. In controlled environments, such as the workplace, system administrators do care about software versions. And plugin developers also care about software versions. A major version number is a very good way to communicate a set of coherent features of a software product. It's something you can depend on. And it makes a lot of sense to everybody if something works in "Browsers 4 and up", both to geeks and the technically less inclined.
I think we shouldn't throw that system away, there is some value there. That's why I think both Firefox and Chrome, even though Chrome is handling itself very well, are eventually on the wrong track.
So what do you guys enter for a comment when checking in a bunch of files? I imagine something along the lines of "added feature X, hope this works! *fingers crossed*" and then 10 subsequent versions to fix feature X because of some unanticipated bugs. And hopefully in the meantime some of the other team members aren't held up by the buggy feature X, because since your development server automatically rolls out the latest version from your subversion repository, that is broken too the moment someone checks in buggy code. Better roll it back quickly before starting on your fix!
Clearly a lot better than a single commit with feature X, tested locally by the developer before entering his files into the repository. I'm sorry for being so dense.
I'm not against file versioning, how can you even suggest that? I'm just against committing too much bullshit. Because files that you know are broken will clutter up the repo and I truly believe it makes everyone's life harder if the repo doesn't contain mostly working code. It doesn't have to be finished or useful, but if I check out the latest version on monday morning and it doesn't even compile, I'm off to a very bad start of the week.
You clearly disagree. And you've found a team of people who are also fine with that. So that's great. I wouldn't wan't to be working on an application of which most of the committed code isn't tested locally first, but I guess that's my quirk.
It's not evil to stop giving money to someone else. It was very kind of Google that they helped Mozilla to get started. By now, Mozilla should be able to stand on its own legs.
Giving away money doesn't mean you are tied to keep doing it.
Firefox' recent accelerated release cycle and Chrome's ludicrous version (it's out for 3 years now and already at version 15 or something, wtf?) show that frequently updating the entire browser is not a sustainable path into the future. You can't seriously ask from people to update their browser every couple of weeks to a new major version and if Chrome keeps up this pace, they will be at version 30 in 2014 and version 45 in 2017. That doesn't make any sense. Already nobody knows the difference between Chrome 6 and 7 or 11 and 12, let alone people will know the difference between Chrome 38 and 39. It's crazy.
But the corporate browser strategy of a more traditional life cycle doesn't make a lot of sense either. Safari 5 has been out for more than a year now, IE's latest stable release is 8 months old. That's just too much. The web changes rapidly and the only way developers can make use of that progress if browsers are updated frequently. Browsers need to keep up, it's in everybody's best interest.
So what I'm proposing is a new browser that separates updates to the rendering engine and the application itself. Not a lot of people really want frequent updates to the browser application. I think most people are perfectly happy with an address bar on top, some tabs and a space to show the actual web page. The code to produce that doesn't need to change very often. The browser application should provide a solid base framework for displaying web pages and hosting plugins. Nothing fancy, nothing cutting edge and certainly nothing rapidly changing all the time. The added benefit of a stable and slowly progressing browser application, is that plugins get a chance to really thrive. Instead of keeping up with the browser versions, plugin developers can focus on polishing their algorithms and user experience. Updates to the browser application should be released sparsely and users should only be able to update manually, so they can decide for themselves when they want to change their browsing experience and possibly break some of their plugins.
But the rendering engine however, that is where rapid updates are very much welcome. Web standards are constantly evolving and as new features are implemented, they should be released quickly to the world so developers can benefit from them. Javascript interpreters are also continuously improving and there's no reason why anyone should miss out on that. Updates to those kinds of "background" systems should be handed out frequently, because it will make everyones experience better. Ideally, this should be a automatic self updating thing, like how Chrome works, without of course ever breaking the browser application. That way, everybody is exposed to the best techniques the web has to offer all the time.
I would very much welcome a browser with such a philosophy. I wonder if there are projects out there like this.
The point is not that the place you work at is equipped with outlets. The point is that by tying your device to a mandatory outlet all of the time, you take away the mobility of the device.
I'm not in the camp of people who believe tablets make great primary computers. But I do recognize the need for portability and so for me, a 2-hour battery life is simply not acceptable. Luckily there are lots of notebooks out there with much better battery life which does fulfill my needs without having to resort to a lesser device, like a tablet.
I guess we don't agree on what a version is then. To me, a file you are in the middle of creating or modifying isn't a version. First you finish it, then you test it locally and then after a few rounds of modifying and testing, when you end up with a file that is satisfactory for the moment, you have created a file which could be considered a version adequate for committing to the repository.
The reason why I think you should test locally before committing, is simply to prevent clutter on the repository. I understand you can label things, but why would you burden your team mates with the tasking of filtering through the crappy stuff, if you can prevent the crappy stuff from hitting the repository to begin with? Keeping things simple is the key in any programming environment. Managing complexity is what software development is all about. So in order to keep things simple, avoid clutter and don't commit code you know is crappy and doesn't work if you can prevent it.
You say you have pointed out several reasons why the way you work is better, but I have really only read one and that is that committing everything fixes the problem of mobility. The developer can resume work on a different device in the middle of his progress if everything he does is stored in a central location. I get that. But I find it rarely needed myself. I generally know when I have to leave and don't start major reworking of a file if the time remaining is too short to finish it. And because I don't work on a tablet, but on a notebook that is connected to a screen, keyboard and mouse when I'm sitting down at a desk, I simply have all my files with me when I'm on the go to begin with. I don't need network for that. But that's just me, I understand that other people might prefer working differently. I just think you shouldn't make it harder for other people to do their job by messing up the repo.
Slashdot Mirror
Allergic to *plants*? What? That's the saddest first world problem I've ever heard of. How the hell do keep yourself in a plant-free environment anyway?
How do you account for the large number of Dutch articles on Wikipedia then?
I think it might be possible that a good understanding of English within a population actually boosts the number of articles in their local language. You can't deny the fact that most of the content on the internet is written in English, so being fluent in that language makes the internet as a whole more accessibility and attractive. I think this results in a higher internet penetration in countries where citizens are more fluent in English. I think there's a good chance this higher internet-saviness will in turn result in a higher awareness of the local internet and a richer local Wikipedia as a result of that. Just theorizing though, I obviously have no proof or evidence of this at all.
The ratio between articles in Danish and speakers of the Danish language is still much, much higher than that of equally obscure languages in southern and eastern Europe.
That does explain the relative high number of articles in western/northern Europe, but it doesn't account for the lack of articles in equally obscure languages, such as Hungarian or Greek. I still think the ratio between articles in a language on Wikipedia and number of speakers of that language is a good way to measure internet penetration in countries.
It obviously fails for languages without a strong connection to a specific country, such as English or Spanish. But even so, it's interesting to see that the English Wikipedia has over 4 times the number of articles, while the number of speakers worldwide is roughly equal. Maybe more people speak English than Spanish, I don't know, but it certainly isn't 4 times as much. So I still think this is a pretty good way to say something about how many people are using the internet in certain language areas.
Even so, Denmark has only about 6 million citizens, yet they've written almost 160.000 articles in Danish on Wikipedia. That's a *way* better ratio than most southern/eastern European countries. The Romanian Wikipedia for example only includes 10.000 more articles than the Danish one, yet their population is more than three times as large as Denmark. And even a relatively wealthy and modern country like Italy has a ratio which is far worse (almost 900.000 articles with a population of 60 million.)
I'm always amazed when I see the number of articles on Wikipedia in different languages. The German Wikipedia for example has about 1.3 million articles, while the number of German-speaking people is about 100 million. There are *a lot* more people speaking Spanish around the world (Mexico alone has more than 100 million citizens), yet there are only about 850.000 articles in Spanish on Wikipedia.
I think the number of articles says a lot about internet penetration in European countries, because most of them have their own language. The Dutch Wikipedia for example has almost a million articles, while only about 30 million or so people actually speak the language. You see the same sort of ratio between articles to speakers in other nordic and western European countries. This ratio drops sharply as you move towards the east and south of Europe. People seem to be a lot less interested to add content to the internet in those countries. You could argue a poor country has other more important preoccupations, but people in countries such as Spain or Italy aren't all that poor, yet they don't seem to be adding a lot of articles to Wikipedia either.
And even then they've been around for 30 years.
Looking through PHP's changelog makes it clear that adding new stuff is not exactly a priority. Sure there is a handful of new stuff, but it's taking them ages to do tiny steps forward. So it took them three years to add four new features. You think that's rapid enough to keep up with the ever changing needs of the web as an application platform? I don't.
I understand it may be a hassle to wait for an updated framework. But that's what you get with updates. Of course I'm not going to tell you to modify a framework yourself, but it shouldn't take the maintainers of those frameworks years to update either. (If it does, you might want to consider changing frameworks.) And you don't run a cutting edge version of PHP on a production server anyway, so it's fine if you wait for the updated framework before actually updating the server itself, right?
Things like mcrypt happen. It's annoying, but it will be resolved. It doesn't mean the whole PHP project shouldn't keep moving forward. All in all I think the number of major incompatibilities are really small and most things are announced years in advance through warnings. The documentation also does a great job of keeping people posted on changes in the way things are handled by PHP and what the best practices are regarding different subjects.
The language changes too rapidly
Erm... what? Have you actually looked at the changelog in the past few years? It's all bug fixes, there's absolutely nothing interesting going on there! Development in PHP has completely stagnated for years now. PHP 5.2 was released in 2006 (!!!) and still not everybody has caught on. Then 5.3 came out 3 years later, but it's even rarer to encounter that in the wild. The differences are totally marginal and the stuff they're deprecating is mainly bad stuff from PHP3 and PHP4 that you shouldn't have been using in anything for the last couple of years anyway.
There's a lot wrong with PHP and there's a lot of bad stuff in there, but in my opinion the worst thing about PHP is the lack of progress to improve things. So no, I don't agree the language changes too rapidly, I think it's changing not nearly rapid enough.
What's really sad is regarding some crappy Asian pulp movie as a source of culture and history.
If your primary job in life is developing iPad apps, then a Linux machine isn't a very good choice for a primary computer.
I sticky piece of rubber wont make me buy a tablet either.
I've already countered that argument in this post. Am I in Groundhog Day or something?
By making yourself sit next to an outlet all the time, you take away the portability and with that the benefit of a notebook. Having 2 hours between full charges doesn't fix this problem, because two hours is too short of a period to do any meaningful work. It also creates a very restless state of being, because two hours fly by very quickly when you're engaged in your work, so you have to watch your battery status all the time. And then, when your battery is depleted after these two hours, you don't magically get a full charge when you find an outlet. You are required to sit next to that outlet for at least another hour to get your battery full again, during which you have no mobility and thus no advantage of working on a portable computer.
I'm sure for some situations or some people, two hours of battery life is fine. And if you don't mind to work near an outlet most of the time, that's your choice. But to me it makes no sense at all to have a notebook with such short battery life. I use my notebook to go to meetings, where I want to show stuff and write down annotations. It's a nuisance to plug in during such events, which I rather prevent. I also hate it to bother a client with the question of where an outlet is I can use when I go visit one. And when I'm home, I like to sit on the couch with my notebook without having to worry about a stupid cable across the room. I've used different notebooks for about 8 years now, but never owned one that had less than 5 hours of juice. I just don't see the point of having a notebook when I can't use it on the go for a solid couple of hours. But that's me.
You're completely entitled to that opinion and I for one try my best to make sure every web application I develop is completely functional without the need of client-side scripting. But you can't ignore the added benefits in user experience of a scripted application. You may not like it, but Javascript profoundly enhances the web. If it weren't for Javascript, the web would have been replaced by now.
Without NoScript who cares? It isnt a functional browser.
I don't like NoScript. I understand the dangers of JS, but in my opinion NoScript is just too much. Every single website out there relies on having functional Javascript. So you just end up enabling it on every site you visit. Which in my view kind of defies the purpose of having the plugin at all.
I'm more than happy with ClickToFlash, AdBlock and Ghostery and I've disabled the support of Java. But Javascript to me is just an essential part of the web and I wouldn't want to use websites without it.
I'm sorry, you are right, I've been a bit sloppy in laying down my argument. And I also agree Chrome's model works quite well, especially for home users, because Google keeps the UI and API very consistent between major versions and nobody is bothered by dialogs and restarts in order to get the latest version.
But you see, I do believe there is a meaning to a version number. It's not just a label nobody cares about. In controlled environments, such as the workplace, system administrators do care about software versions. And plugin developers also care about software versions. A major version number is a very good way to communicate a set of coherent features of a software product. It's something you can depend on. And it makes a lot of sense to everybody if something works in "Browsers 4 and up", both to geeks and the technically less inclined.
I think we shouldn't throw that system away, there is some value there. That's why I think both Firefox and Chrome, even though Chrome is handling itself very well, are eventually on the wrong track.
Well I hope you feel superior, my friend.
So what do you guys enter for a comment when checking in a bunch of files? I imagine something along the lines of "added feature X, hope this works! *fingers crossed*" and then 10 subsequent versions to fix feature X because of some unanticipated bugs. And hopefully in the meantime some of the other team members aren't held up by the buggy feature X, because since your development server automatically rolls out the latest version from your subversion repository, that is broken too the moment someone checks in buggy code. Better roll it back quickly before starting on your fix!
Clearly a lot better than a single commit with feature X, tested locally by the developer before entering his files into the repository. I'm sorry for being so dense.
I'm not against file versioning, how can you even suggest that? I'm just against committing too much bullshit. Because files that you know are broken will clutter up the repo and I truly believe it makes everyone's life harder if the repo doesn't contain mostly working code. It doesn't have to be finished or useful, but if I check out the latest version on monday morning and it doesn't even compile, I'm off to a very bad start of the week.
You clearly disagree. And you've found a team of people who are also fine with that. So that's great. I wouldn't wan't to be working on an application of which most of the committed code isn't tested locally first, but I guess that's my quirk.
I mainly browse with Safari, probably the browser with the weakest plugin culture out there, yet even I have most of these plugins (or an equivalent).
It's not evil to stop giving money to someone else. It was very kind of Google that they helped Mozilla to get started. By now, Mozilla should be able to stand on its own legs.
Giving away money doesn't mean you are tied to keep doing it.
In my opinion, 2 hours is too short of a time to do anything useful.
Firefox' recent accelerated release cycle and Chrome's ludicrous version (it's out for 3 years now and already at version 15 or something, wtf?) show that frequently updating the entire browser is not a sustainable path into the future. You can't seriously ask from people to update their browser every couple of weeks to a new major version and if Chrome keeps up this pace, they will be at version 30 in 2014 and version 45 in 2017. That doesn't make any sense. Already nobody knows the difference between Chrome 6 and 7 or 11 and 12, let alone people will know the difference between Chrome 38 and 39. It's crazy.
But the corporate browser strategy of a more traditional life cycle doesn't make a lot of sense either. Safari 5 has been out for more than a year now, IE's latest stable release is 8 months old. That's just too much. The web changes rapidly and the only way developers can make use of that progress if browsers are updated frequently. Browsers need to keep up, it's in everybody's best interest.
So what I'm proposing is a new browser that separates updates to the rendering engine and the application itself. Not a lot of people really want frequent updates to the browser application. I think most people are perfectly happy with an address bar on top, some tabs and a space to show the actual web page. The code to produce that doesn't need to change very often. The browser application should provide a solid base framework for displaying web pages and hosting plugins. Nothing fancy, nothing cutting edge and certainly nothing rapidly changing all the time. The added benefit of a stable and slowly progressing browser application, is that plugins get a chance to really thrive. Instead of keeping up with the browser versions, plugin developers can focus on polishing their algorithms and user experience. Updates to the browser application should be released sparsely and users should only be able to update manually, so they can decide for themselves when they want to change their browsing experience and possibly break some of their plugins.
But the rendering engine however, that is where rapid updates are very much welcome. Web standards are constantly evolving and as new features are implemented, they should be released quickly to the world so developers can benefit from them. Javascript interpreters are also continuously improving and there's no reason why anyone should miss out on that. Updates to those kinds of "background" systems should be handed out frequently, because it will make everyones experience better. Ideally, this should be a automatic self updating thing, like how Chrome works, without of course ever breaking the browser application. That way, everybody is exposed to the best techniques the web has to offer all the time.
I would very much welcome a browser with such a philosophy. I wonder if there are projects out there like this.
The point is not that the place you work at is equipped with outlets. The point is that by tying your device to a mandatory outlet all of the time, you take away the mobility of the device.
I'm not in the camp of people who believe tablets make great primary computers. But I do recognize the need for portability and so for me, a 2-hour battery life is simply not acceptable. Luckily there are lots of notebooks out there with much better battery life which does fulfill my needs without having to resort to a lesser device, like a tablet.
I guess we don't agree on what a version is then. To me, a file you are in the middle of creating or modifying isn't a version. First you finish it, then you test it locally and then after a few rounds of modifying and testing, when you end up with a file that is satisfactory for the moment, you have created a file which could be considered a version adequate for committing to the repository.
The reason why I think you should test locally before committing, is simply to prevent clutter on the repository. I understand you can label things, but why would you burden your team mates with the tasking of filtering through the crappy stuff, if you can prevent the crappy stuff from hitting the repository to begin with? Keeping things simple is the key in any programming environment. Managing complexity is what software development is all about. So in order to keep things simple, avoid clutter and don't commit code you know is crappy and doesn't work if you can prevent it.
You say you have pointed out several reasons why the way you work is better, but I have really only read one and that is that committing everything fixes the problem of mobility. The developer can resume work on a different device in the middle of his progress if everything he does is stored in a central location. I get that. But I find it rarely needed myself. I generally know when I have to leave and don't start major reworking of a file if the time remaining is too short to finish it. And because I don't work on a tablet, but on a notebook that is connected to a screen, keyboard and mouse when I'm sitting down at a desk, I simply have all my files with me when I'm on the go to begin with. I don't need network for that. But that's just me, I understand that other people might prefer working differently. I just think you shouldn't make it harder for other people to do their job by messing up the repo.
throws away 30 years of office app development
I was skeptical about the usage of a tablet as primary computer, but now that you mention it, this is indeed pretty awesome!