Gregory Benford published a novel in 1980 about a more toxic algae bloom http://en.wikipedia.org/wiki/Timescape
It got the Nebula award so some of you might have read it.
Go look at the desktop version of this site with Firefox 22 for Android and you'll see why Mozilla is going to have a hard time with their OS. It's a mix of Mozilla's poor technical choices (look at the same site with Dolphin HD or the stock browser) and sites caring only about Webkit mobile browsers.
Re:"the web's most popular scripting language"?!?
on
PHP 5.5.0 Released
·
· Score: 1
Actually phpunit runs scripts from the command line but yes, usually they are tests for code that eventually runs in a webserver. Anyway a large and well done PHP project has much more code in models, controllers and libraries that in HTML views so it's not easy to say that it's just a templating language.
About being the most popular, it probably is. It's either it or Java or some.NET language. Python and Ruby are following at a distance. Given all the free or cheap PHP hosting servers my bet are on PHP. But being popular doesn't mean being good.
CakePHP 1 was really difficult to read. I had to work with it and all I remember is that the signal was so obscured by tons of array() and strings with the names of models that the meaning of the code was difficult to understand (I was used to Rails). I remember that Symfony was cleaner, but still not so good. Hopefully CakePHP 2 got better but I never had to work with it so I can't compare it with Rails. Laravel looks like something that can be used, notwistanding the limits of PHP.
No, it's not. Dynamic typing let's you save a lot of time because when you use one of those languages there is rarely need to explicitly state the type of a variable and everything keeps working just fine. Furthermore, thinking of Ruby, if you try to mix different types without an explicit coercion it reminds you that you are doing a mistake and kills your program. I don't know why but it never happened in production. Only in development mode. It's tests, which one should do anyway, or just that we don't mix different types unless into very specific situations like printing output as String?
Then after a couple of years you go back to Java and you don't understand why all of a sudden you have to write all those String, int, BigComplexType annotations before variable names. I was raised with them but I discovered that they add very little value. I'm not sure (there must be some theorem to prove or disprove my claim) but a compiler could statically analyze a program without type annotations and tell us if it can run safely, but dynamically generated code need an runtime for doing that.
I read the Laravel page and it's great to see how closely they managed to mimic Ruby and Rails (I used "and" on purpose). However it also exposes the limits of the language.
This PHP
$tasks = User::find(1)->tasks;
$author = Task::find(5)->user()->username;
$task = new Task([ title: 'Go to store.' ]);
User::find(1)->tasks()->insert($task);
would be this Ruby
tasks = User.find(1).tasks
author = Task.find(5).user.username
task = new Task({title: 'Go to store.'}) # but the {} are idiomatically removed in this case because there are no ambiguities
User.find(1).tasks.insert(task)
Count the keyboard hits and shift saved. Think about the signal to noise ratio of the two pieces of code.
Ruby has its share of oddities but PHP is an easy target for critics. Using $ for variables was a terrible decision, worse than Ruby's @ and @@ for instance and class variables. Using -> to access methods and attributes was a bad trade with the ability to use . for string concatenation. Mandatory () for function call and around if (conditions) are useless as well as the semicolon at the end of lines. Compilers and interpreters can be made smart enough to understand when a statement is complete without forcing the programmer to do part of their job. And think of the mandatory $this->. Argh!
Yeah, let's hope for a wised up PHP x.0. A first step has been allowing [ ] in place of array( )
Yes I know his argument. I just don't buy and I could build counterarguments but it doesn't matter. At the end even programming languages are not completely rational and our tastes are even less so.To me Python looks similar to C and tastes of '80s, with all those unnecessary double underscores (Guido should have uses a keyword for that). Maybe that is why it is getting successful as a system language. But there is the inconvenience of paying attention to spaces when copy pasting code around, which is a pain and a source of disasters waiting to happen.
All the closed source software for customers of mine (usually web apps and related services) was already on git when I took over the projects or has been migrated afterward (usually not my call). The only exception was a 1 GB svn repository of binary files that we don't really need to work much with and didn't make sense to convert. Anyway the two of us are too small a number to make a statistics. Just my two cents anecdote.
But in some environments git has become a de facto standard. Almost any Ruby gem is on github, which makes it easier to install, fork and modify. That means that many people and companies also use it for their private projects because they're accustomed to the tool. They also have desktop clients for Mac and Windows but I have no idea of what they do. I see customers hosting they remote git repositories on bitbucket too and somebody run their own server.
After years of git I can't think of using a pure centralized system anymore. Too limited.
Why not? Experimentation is useful and gives many languages that die quickly but also ideas that spread and end up in languages that stick. Just imagine saying use the classic languages at the time of Cobol and Fortran, or at the time of C later on. No C, no Perl, no Python, no Ruby, no Java, no PHP (oh well...), no JavaScript. All of them got ideas from other languages and spread their ideas into newer languages or into contemporary ones (PHP has traits nowadays).
As for really using Lobster in production, let's wait and see how it compares to its competitors. Chances that it will go anywhere are little as for every other new language.
I agree that the meaning of this one liner is not easy to guess but there are other more fundamental things that bother me in Lobster. One is why they should make a difference between = to assign and:= to define & assign. The first assignment should define. Most languages just do that and everybody is happy. The second rant is about the pythonish end of line colon. The : is ugly. It still hits me as a bad taste when writing Python: if a statement looks complete at the end of the line, then it's should be assumed to be complete. It doesn't sound difficult even with semantic spaces which IMHO are a Bad Choice but I won't spend words on that.
Rants ended, this language has some merits. The optional type declaration should make everybody happy. Immutable objects should be great for parallel and functional processing. Native vector operations are great. But there is one final rant: please don't mix objects and functions. It should be class.max and not max(objects). Two paradigms into one language are not a nice thing to look at (even if there are plenty of examples of this kind of languages).
Overall my first look opinion of Lobster is: a little too much on the ugly side of aesthetics but promising. It's always nice to see a new language even if the chances it will survive a couple of years are slim (that's true for every new language). Ideas spread so keep inventing.
I'm not a proponent of DRM and I didn't buy any DRMized item because I want to be sure to able to use what I bought on any future device I'll happen to use. That said, this DRM doesn't seem to lower the value of the text much. It's probably just watermarking, which I'm fine with because I'm not interested in buying something and pirating it.
Nevertheless I see potential problems with this technology. Files are files, got backup, move to physical media that get lost and sometimes end up in somebody's else hands. Even if I (and you, reader) can say "it will never happen to me", it will happen to somebody, probably many people along the years. Maybe even me (and you) and the guy who got his files distributed could be in more troubles than he deserves for losing a USB key. So watermarking is better than DRM, but no watermarking is even better.
Finally, I believe that reconstructing the non watermarked original file won't be as trivial as many other slashdotters think. It looks like one of those bioinformatics problems with reconstructing a DNA sequence from a bunch of different versions of it (don't assume the texts will be aligned). Plus, there is a noise introduced on purpose and if an arms race starts they'll do their best to make it difficult to remove without having really many different versions of the file.
No, it doesn't but I'm not much interested in that. I don't have that many programs and I know what I need to run to burn a CD/DVD (brasero, if my memory serves me well). If I didn't, clicking Applications, Sound and Video and reading the menu is pretty fast. Luckily Linux menus are not the anarchy the Windows folks have to live with. Actually DVDs are bad example for me because it has been a long time since I mastered an optical media, but I understand what you mean and I'm sure an internal search engine for applications discovery can be useful. Different people, different needs, different shells. Everybody's happy.
What you do with meta I'm doing it with ALT-F2 usually not more than a couple of times per week. Not that I open my Applications menu much more often. Firefox, Thunderbird, Skype, Emacs, Terminal are all open since boot time and Nautilus can be opened from the desktop. I'm opening the Places menu more often because I have bookmarks stored in there. Gnome 3 doesn't give me advantages, only disruption to my workflow so I stay on classic mode without the top bar. I merged in the bottom one the few things I cared about.
Only if the customer is willing to pay for the extra development time. If it's a fixed cost project the developers and the customer should have a contract to protect each others. if it's not, even for "pay as you go" projects usually customers compromise between what they wish and what they can afford both as cost and as delivery time.
False analogy, yes. But not for that reason. The real analogy would be: I ordered a car and working with the engineering team I slowly discover I needed a camper van. That's what I get home with and end up much happier because I got the right product. Obviously that analogy applies to custom designed software and is seldom appropriate with cars. If I buy something off the shelf, think about a car or about Word, I usually know what I need because I already used it. But Word as seen from inside MS is custom designed software. I don't know if they use Agile to build it but they could.
In a project I've been working on for part of the last year the general direction didn't change much but we made many discoveries along the way. We started with some high level documents and some more detailed ones. The only ones that survived the first three months of development were the high level ones, which we kept adapting as they provide a good orientation map to the project. The detailed ones were superseded by what we wrote as the development team worked on the code. We could have spared us the trouble (and time and costs) of writing them. Lesson learned for the next time.
One reason might be that investors feel that Apple can't grow at the same rate as in the past. The ones interested in just the stock price sell Apple and buy other companies, possibly in totally different markets, that have a chance of growing faster. The company they invest on is not important to them, only the growth rate of the stock price is.
Whatever it is, the stock price is an indicator of how people feel about the future of a company.
I'm back from a trip on my time machine. I was in the 60's and I heard someone at Bell Labs arguing "why would someone want to use this C language instead of what we already have?" Don't worry, I didn't tell him what was about to happen.
On a less funny note, people experiment and throw languages at us. Java, JavaScript, Perl, Python, Ruby were not established 20 years ago. Actually only two of them already existed at that time. Countless other languages came and died but nobody was able to predict which ones would form a community and be the winners. IMHO it's not only a matter of technical merit but also how it is marketed (even for non proprietary not for profit languages).
Yes, modest was an understatement:-) but my line of thought was along the lines of "if my dog bites you I pay damages" or "if somebody uses my gun to rob you, I pay consequences". And yes, I believe that I should pay consequences if the gun design I created is used to kill. Weapons creation and distribution are regulated in many countries and manufacturers are waived with the responsibility for their use. A license is required in my country (Italy). The USA are quite liberal about weapons for well understood historical reasons but even there there is a thing called Federal Firearms License. I better have one if I have the copyright (or copyleft) on a 3D printed weapon.
A modest suggestion: if the virus which is of your property kills someone you go to jail. Discounts granted if you own only a few genes. Let's see how long intellectual property lasts once it faces responsibility.
There are "hard" bugs (let's call them so) as in "a +=2 instead of a += 3" and there are "soft" bugs as in "neither the customer nor us thought about that (possibly very complicated) combination of inputs and internal state, and our code doesn't yield the right result". That's the "what do we do when..." question that many times developers ask to designers. Unfortunately hard bugs are relatively easy to find with test suites and code reviews but soft bugs can accumulate unnoticed until the end of the project. Some become apparent only after it goes to production and the real world finally hits the code. Then the development team starts feeling like they're not their bugs (probably fair) and like they're working for free so they ask for more money just when the customer is least happy with them. There are technical and contractual ways to protect both parties against this kind of problems but they increase the costs and are not always appreciated by customers, not even after bad thing happened in production.
Gregory Benford published a novel in 1980 about a more toxic algae bloom http://en.wikipedia.org/wiki/Timescape
It got the Nebula award so some of you might have read it.
Go look at the desktop version of this site with Firefox 22 for Android and you'll see why Mozilla is going to have a hard time with their OS. It's a mix of Mozilla's poor technical choices (look at the same site with Dolphin HD or the stock browser) and sites caring only about Webkit mobile browsers.
Actually phpunit runs scripts from the command line but yes, usually they are tests for code that eventually runs in a webserver. Anyway a large and well done PHP project has much more code in models, controllers and libraries that in HTML views so it's not easy to say that it's just a templating language.
About being the most popular, it probably is. It's either it or Java or some .NET language. Python and Ruby are following at a distance. Given all the free or cheap PHP hosting servers my bet are on PHP. But being popular doesn't mean being good.
CakePHP 1 was really difficult to read. I had to work with it and all I remember is that the signal was so obscured by tons of array() and strings with the names of models that the meaning of the code was difficult to understand (I was used to Rails). I remember that Symfony was cleaner, but still not so good. Hopefully CakePHP 2 got better but I never had to work with it so I can't compare it with Rails. Laravel looks like something that can be used, notwistanding the limits of PHP.
No, it's not. Dynamic typing let's you save a lot of time because when you use one of those languages there is rarely need to explicitly state the type of a variable and everything keeps working just fine. Furthermore, thinking of Ruby, if you try to mix different types without an explicit coercion it reminds you that you are doing a mistake and kills your program. I don't know why but it never happened in production. Only in development mode. It's tests, which one should do anyway, or just that we don't mix different types unless into very specific situations like printing output as String?
Then after a couple of years you go back to Java and you don't understand why all of a sudden you have to write all those String, int, BigComplexType annotations before variable names. I was raised with them but I discovered that they add very little value. I'm not sure (there must be some theorem to prove or disprove my claim) but a compiler could statically analyze a program without type annotations and tell us if it can run safely, but dynamically generated code need an runtime for doing that.
I read the Laravel page and it's great to see how closely they managed to mimic Ruby and Rails (I used "and" on purpose). However it also exposes the limits of the language.
This PHP
$tasks = User::find(1)->tasks;
$author = Task::find(5)->user()->username;
$task = new Task([ title: 'Go to store.' ]);
User::find(1)->tasks()->insert($task);
would be this Ruby
tasks = User.find(1).tasks
author = Task.find(5).user.username
task = new Task({title: 'Go to store.'}) # but the {} are idiomatically removed in this case because there are no ambiguities
User.find(1).tasks.insert(task)
Count the keyboard hits and shift saved. Think about the signal to noise ratio of the two pieces of code.
Ruby has its share of oddities but PHP is an easy target for critics. Using $ for variables was a terrible decision, worse than Ruby's @ and @@ for instance and class variables. Using -> to access methods and attributes was a bad trade with the ability to use . for string concatenation. Mandatory () for function call and around if (conditions) are useless as well as the semicolon at the end of lines. Compilers and interpreters can be made smart enough to understand when a statement is complete without forcing the programmer to do part of their job. And think of the mandatory $this->. Argh!
Yeah, let's hope for a wised up PHP x.0. A first step has been allowing [ ] in place of array( )
Yes I know his argument. I just don't buy and I could build counterarguments but it doesn't matter. At the end even programming languages are not completely rational and our tastes are even less so.To me Python looks similar to C and tastes of '80s, with all those unnecessary double underscores (Guido should have uses a keyword for that). Maybe that is why it is getting successful as a system language. But there is the inconvenience of paying attention to spaces when copy pasting code around, which is a pain and a source of disasters waiting to happen.
All the closed source software for customers of mine (usually web apps and related services) was already on git when I took over the projects or has been migrated afterward (usually not my call). The only exception was a 1 GB svn repository of binary files that we don't really need to work much with and didn't make sense to convert. Anyway the two of us are too small a number to make a statistics. Just my two cents anecdote.
But in some environments git has become a de facto standard. Almost any Ruby gem is on github, which makes it easier to install, fork and modify. That means that many people and companies also use it for their private projects because they're accustomed to the tool. They also have desktop clients for Mac and Windows but I have no idea of what they do. I see customers hosting they remote git repositories on bitbucket too and somebody run their own server.
After years of git I can't think of using a pure centralized system anymore. Too limited.
Oh now I see. I woosh myself.
Why not? Experimentation is useful and gives many languages that die quickly but also ideas that spread and end up in languages that stick. Just imagine saying use the classic languages at the time of Cobol and Fortran, or at the time of C later on. No C, no Perl, no Python, no Ruby, no Java, no PHP (oh well...), no JavaScript. All of them got ideas from other languages and spread their ideas into newer languages or into contemporary ones (PHP has traits nowadays).
As for really using Lobster in production, let's wait and see how it compares to its competitors. Chances that it will go anywhere are little as for every other new language.
I agree that the meaning of this one liner is not easy to guess but there are other more fundamental things that bother me in Lobster. One is why they should make a difference between = to assign and := to define & assign. The first assignment should define. Most languages just do that and everybody is happy. The second rant is about the pythonish end of line colon. The : is ugly. It still hits me as a bad taste when writing Python: if a statement looks complete at the end of the line, then it's should be assumed to be complete. It doesn't sound difficult even with semantic spaces which IMHO are a Bad Choice but I won't spend words on that.
Rants ended, this language has some merits. The optional type declaration should make everybody happy. Immutable objects should be great for parallel and functional processing. Native vector operations are great. But there is one final rant: please don't mix objects and functions. It should be class.max and not max(objects). Two paradigms into one language are not a nice thing to look at (even if there are plenty of examples of this kind of languages).
Overall my first look opinion of Lobster is: a little too much on the ugly side of aesthetics but promising. It's always nice to see a new language even if the chances it will survive a couple of years are slim (that's true for every new language). Ideas spread so keep inventing.
I'm not a proponent of DRM and I didn't buy any DRMized item because I want to be sure to able to use what I bought on any future device I'll happen to use. That said, this DRM doesn't seem to lower the value of the text much. It's probably just watermarking, which I'm fine with because I'm not interested in buying something and pirating it.
Nevertheless I see potential problems with this technology. Files are files, got backup, move to physical media that get lost and sometimes end up in somebody's else hands. Even if I (and you, reader) can say "it will never happen to me", it will happen to somebody, probably many people along the years. Maybe even me (and you) and the guy who got his files distributed could be in more troubles than he deserves for losing a USB key. So watermarking is better than DRM, but no watermarking is even better.
Finally, I believe that reconstructing the non watermarked original file won't be as trivial as many other slashdotters think. It looks like one of those bioinformatics problems with reconstructing a DNA sequence from a bunch of different versions of it (don't assume the texts will be aligned). Plus, there is a noise introduced on purpose and if an arms race starts they'll do their best to make it difficult to remove without having really many different versions of the file.
No, it doesn't but I'm not much interested in that. I don't have that many programs and I know what I need to run to burn a CD/DVD (brasero, if my memory serves me well). If I didn't, clicking Applications, Sound and Video and reading the menu is pretty fast. Luckily Linux menus are not the anarchy the Windows folks have to live with. Actually DVDs are bad example for me because it has been a long time since I mastered an optical media, but I understand what you mean and I'm sure an internal search engine for applications discovery can be useful. Different people, different needs, different shells. Everybody's happy.
What you do with meta I'm doing it with ALT-F2 usually not more than a couple of times per week. Not that I open my Applications menu much more often. Firefox, Thunderbird, Skype, Emacs, Terminal are all open since boot time and Nautilus can be opened from the desktop. I'm opening the Places menu more often because I have bookmarks stored in there. Gnome 3 doesn't give me advantages, only disruption to my workflow so I stay on classic mode without the top bar. I merged in the bottom one the few things I cared about.
Only if the customer is willing to pay for the extra development time. If it's a fixed cost project the developers and the customer should have a contract to protect each others. if it's not, even for "pay as you go" projects usually customers compromise between what they wish and what they can afford both as cost and as delivery time.
False analogy, yes. But not for that reason. The real analogy would be: I ordered a car and working with the engineering team I slowly discover I needed a camper van. That's what I get home with and end up much happier because I got the right product. Obviously that analogy applies to custom designed software and is seldom appropriate with cars. If I buy something off the shelf, think about a car or about Word, I usually know what I need because I already used it. But Word as seen from inside MS is custom designed software. I don't know if they use Agile to build it but they could.
In a project I've been working on for part of the last year the general direction didn't change much but we made many discoveries along the way. We started with some high level documents and some more detailed ones. The only ones that survived the first three months of development were the high level ones, which we kept adapting as they provide a good orientation map to the project. The detailed ones were superseded by what we wrote as the development team worked on the code. We could have spared us the trouble (and time and costs) of writing them. Lesson learned for the next time.
Actually Donna Noble became a sort of Doctor in Journey's End.
One reason might be that investors feel that Apple can't grow at the same rate as in the past. The ones interested in just the stock price sell Apple and buy other companies, possibly in totally different markets, that have a chance of growing faster. The company they invest on is not important to them, only the growth rate of the stock price is.
Whatever it is, the stock price is an indicator of how people feel about the future of a company.
Me too. They are great novels in a great setup. http://en.wikipedia.org/wiki/Demon_Princes
I'm back from a trip on my time machine. I was in the 60's and I heard someone at Bell Labs arguing "why would someone want to use this C language instead of what we already have?" Don't worry, I didn't tell him what was about to happen.
On a less funny note, people experiment and throw languages at us. Java, JavaScript, Perl, Python, Ruby were not established 20 years ago. Actually only two of them already existed at that time. Countless other languages came and died but nobody was able to predict which ones would form a community and be the winners. IMHO it's not only a matter of technical merit but also how it is marketed (even for non proprietary not for profit languages).
Same problem here in Italy and same solution.
Yes, modest was an understatement :-) but my line of thought was along the lines of "if my dog bites you I pay damages" or "if somebody uses my gun to rob you, I pay consequences". And yes, I believe that I should pay consequences if the gun design I created is used to kill. Weapons creation and distribution are regulated in many countries and manufacturers are waived with the responsibility for their use. A license is required in my country (Italy). The USA are quite liberal about weapons for well understood historical reasons but even there there is a thing called Federal Firearms License. I better have one if I have the copyright (or copyleft) on a 3D printed weapon.
A modest suggestion: if the virus which is of your property kills someone you go to jail. Discounts granted if you own only a few genes. Let's see how long intellectual property lasts once it faces responsibility.
Sourceforge has software downloads. You might consider moving your project there.
There are "hard" bugs (let's call them so) as in "a +=2 instead of a += 3" and there are "soft" bugs as in "neither the customer nor us thought about that (possibly very complicated) combination of inputs and internal state, and our code doesn't yield the right result". That's the "what do we do when..." question that many times developers ask to designers. Unfortunately hard bugs are relatively easy to find with test suites and code reviews but soft bugs can accumulate unnoticed until the end of the project. Some become apparent only after it goes to production and the real world finally hits the code. Then the development team starts feeling like they're not their bugs (probably fair) and like they're working for free so they ask for more money just when the customer is least happy with them. There are technical and contractual ways to protect both parties against this kind of problems but they increase the costs and are not always appreciated by customers, not even after bad thing happened in production.