What ifs are great; may be Zope corp could've created Zope in a statically typed language in the same amount of time. Maybe not. I honestly can't say. Zope, like most other well built systems (whether statically or dynamically typed), relies on the loose coupling of smaller, well developed, separate components. What Zope did well was their component oriented architecture. It makes integrating all the different components, and writing new ones, very easy. That said, they did this by building a stronger type system on top of Python (without getting in the way too much). However, this kind of flexibility is what makes dynamic languages so great.
Clearly dynamic languages' biggest flaw is that they have no compile time type checking. However, since this is the big demarcation line between static & dynamic languages, I can't really fault dynamic languages here. As always, the right tool for the right job is the best credo for most professions.
I'd suggest you take a look at Zope if you want to see a good example of a complex application developed in a dynamic language (Python). Zope is built on a rather nice component-oriented architecture which helps with most issues you'd have, I think.
I guess it wasn't obvious, but I was comparing JS to other dynamically typed scripting languages. I'm also talking in respect to tasks that scripting languages usually tackle. If JS is painfully slow for you, I'm just assuming you are using it for something you probably shouldn't be using ANY scripting language for.
I'm not sure what the "module" and "require" patterns have to do with prototypical inheritance. Ruby, Python, and Groovy (for example, there are many others) are all class based and allow metaprogramming and/or "monkey patching," so "dirty object decoration" is not a trait only found with JS.
Web workers are very restricted. They run in a completely different scope and can merely pass messages to the main UI thread.
I wasn't peeing on JS. I love Javascript. The only negative thing I mentioned was that prototypical inheritance isn't something people usually fawn over. However, I also mentioned that it IS in keeping with Javascript's simplicity. For note, I LIKE simple. Simple is good. Simple and powerful are not mutually exclusive.
My favourite language, by far, is Scala, so don't think I don't know where you are coming from. And, honestly, my favourite dynamic language is Python, though I am using JS on occasion now.
The difference is that JS can appear to be multi-threaded. For instance, I can set a function to run after a set amount of time (setTimeout). In the browser, this function will be run in the same thread as all the other code and it will be atomic. The same goes for all the UI events and the like. If I wanted to set a timeout in C that would run a function after 1 seconds, while doing some other stuff in the mean time, threads would be what I'd grab for first. However, JS promises to be single threaded, so you never have to worry about the underlying implementation.
Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.
Undefined vs. null is nuanced? Hardly. And == vs. ===? Pretty much every language defines a difference between equivalence and object identity, whether its Python (== vs. is), Java (equals vs. ==), or Javascript (== vs. ===). What I meant by simple is that there aren't a whole lot of "extras" in the language. Every language is nuanced to the extent you are describing.
Well played, sir. Pretend that an inherent limitation is somehow a feature. As if, if I were to choose another language, I would be forced to write multithreaded code.
It's a design decision, there is no reason they couldn't have allowed threads. Also, it is a design decision that isn't always immediately apparent when dealing with event driven UI code. This includes setTimeout/Interval. The functions that run on this timer are atomic. Again, this is not immediately apparent if you aren't familiar with JS. And, yes, this is a nice feature, as having all even driven UI code, timers, etc. run in the same thread is not as easy as it seems.
Prototypical inheritance didn't make JS cool, and JS wasn't the reason we hated JS 10 years ago.
The reason JS was hated so much 10 years ago was because of the DOM. That's it. Every browser had close enough implementations that you thought mucking about with the DOM would be simple... but they were different enough to cause endless headaches and hardcoded hacks to work around all sorts of quirks. Making a simple drop-down menu meant coding everything from scratch, maintaining essentially 3 different versions of the same code for different browsers.
JS is cool today because of many things.
The convergence of browser features and DOM implementations towards the standard. Coding JS to work cross browser has definitely gotten easier.
The proliferation of browser libraries that abstract the browser away from us developers and handle all the little DOM implementation differences for us.
There is a solid (and growing) set of best practices for client-side programming (eg. progressive enhancement, event-driven programming, etc.). This has dramatically cut down on the amount of time spent (re)writing JS and let's people create better abstractions that work well with JS.
The functional aspect of JS is definitely nice, and allows for some very concise code (considering) to be written. However, it can also be eschewed for those that are not comfortable with functional programming.
JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.
However, I don't think people think prototypical inheritance is really all the grand. It's simple, is what it is and that fits well with JS (simple). When most the original crop of modern JS frameworks came out, the first order of business was to build a more traditional class-based inheritance approach. I know it doesn't fit well with your "renegade" theory, but it's true. People now seem to be getting comfortable with prototypical inheritance, but I don't think you'll find many people willing to extol its virtues.
Also, JS has first class functions, yes, but so do LOTS of other languages. I'm not sure why you're picking on JS developers for liking some aspects of functional programming.
Except that JavaScript, today, is not a slow dynamic scripting language. The latest JS engines in IE 9, FF 4, and Chrome are lightning fast. You'll be hard pressed to find a faster dynamically typed scripting language today. Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS. Also Rhino IS slow (compared to most other JS interpreters) and has been included with Java by default since Java 6.
Sandvine, who did this research, actually supplies Comcast with the devices they use to throttle traffic (especially of the P2P variety). So I'd take this article with a grain of salt.
Seriously. If I could just diff old-eula.txt new-eula.txt I'd be as happy as a pig in poop. Instead, I'm supposed to re-read the mammoth PSN EULA every other month.
Desalination is far from solved (as an economically viable technology). Yes, it works well for cruise ships and the like, but providing clean water to 10s of millions of people living in poverty? Not really. The best method for desert dwellers is to tap into fossil water supplies. Gadhafi (yes, that Gadhafi) put $30b into a water distribution and supply system that tapped into fossil water wells in the main desert and supply it all over the country. The only problem is that fossil water wells do not regenerate as fast as we use them and suffer the same fate as oil; cost goes up as more water comes out because the levels go down and it becomes harder to pump. These sources are not a permanent fix and $30b is a LOT of money for a lot of countries. Importing water isn't easy either. Water weighs a lot and costs a lot to import and, remember, we are talking about countries with millions of people with next to no GDP. Unfortunately, you are using a very wealthy nation as your example, but I'm talking about the Chads, Sudans, Nigers of the world, not the Dubais and Saudi Arabias.
The problem is that the origin story usually has fairly little to do with the main plot (at least after the first movie or whatever). The show "Heroes" actually suffered from this. The producers thought that people liked origin stories, so in Season 3 (I think) they introduced a LOT of new characters with new origins. The story suffered greatly (lots of little threads, but with very little happening each episode). The season tanked as people didn't want to watch Season 1 again. The producers back tracked for the next 2 seasons, they scaled down to a much smaller base cast (about the size of season 1's), and stopped introducing new people with origin stories. Season 4 and 5 were much better as a result.
I use rdio.com (Canada & US) for $5/m. On demand music is fantastic. Seriously, its great for general listening (listen at work a lot), but it really shines when you have friends over. Just leave the laptop open and anyone can just go and play whatever song they feel like. Definitely worth it for $5/m.
I use rdio.com, which is available in Canada and the U.S. No free service, but $5/m gives you on-demand music. I'm always worried the labels are going to get greedy and start imposing stupid restrictions, even on paying customers, which would force me to drop the service.
It is not a percentage of cost of the laptop, but electricity saved vs. cost of retrofitting their manufacturing plant. The retrofitting process will probably involve a lot of western engineers and involve a high fixed cost that is less variable per country.
That said, in Canada we may even pay you to use electricity. If a manufacturing plant can keep the majority of their work in off-peak times, they can save a bundle in Western countries. The point is, for a large company, electricity is an important cost, but they have lots of options to reduce this cost. Most importantly, there are a lot easier ways to save some $$$ in your electricity bill than investing in the latest and greatest green tech. It sucks but it is true.
Sounds like he is an "idea" guy (he is not a programmer). "Oh, I have a great idea. Now the easy part; implementing it!" Apparently Ted Nelson was considered the King of Vaporware back in 1995... just to give you some background.
Basing your identity on what you don't base your identity on is probably childish too then. However, what I do and my identity are definitely linked. Seriously, I stare at a computer and program for about half my waking life. If you think that I can somehow completely separate that part of myself from the other half, you have to be nuts.
Well, it is nice to see that the math section has more or less remained relevant. Aside from finding cubic roots by hand, everything in there is still taught in high school today. In fact, the arithmetic section seemed quite easy by today's standards and there was no calculus at all, which most high school students going into post-sec get at least 1 year of, if not 2. Only the trig & geom part would be tricky, as I remember only about 1/4 of my graduating year taking trig & geom in the last year. I guess even math has its fashions, though it seems to be the most stable.
Or you can use public key cryptography to solve the problem. Store a padded version of the password in the DB encrypted with a public key (verification just involves re-encrypting the plaintext password submitted by the user), and store the private key in some super secure location. The only time you'd ever need to access the private key is at law enforcement's request (so it can be stored in a vault or something).... No hacker can crack the passwords by getting access to the machine and the company can always get the data back in plaintext if absolutely necessary. The biggest implication is the overhead cost involved, but that will still probably be less than the revenue generated from continued business in France.
What ifs are great; may be Zope corp could've created Zope in a statically typed language in the same amount of time. Maybe not. I honestly can't say. Zope, like most other well built systems (whether statically or dynamically typed), relies on the loose coupling of smaller, well developed, separate components. What Zope did well was their component oriented architecture. It makes integrating all the different components, and writing new ones, very easy. That said, they did this by building a stronger type system on top of Python (without getting in the way too much). However, this kind of flexibility is what makes dynamic languages so great.
Clearly dynamic languages' biggest flaw is that they have no compile time type checking. However, since this is the big demarcation line between static & dynamic languages, I can't really fault dynamic languages here. As always, the right tool for the right job is the best credo for most professions.
I'd suggest you take a look at Zope if you want to see a good example of a complex application developed in a dynamic language (Python). Zope is built on a rather nice component-oriented architecture which helps with most issues you'd have, I think.
I guess it wasn't obvious, but I was comparing JS to other dynamically typed scripting languages. I'm also talking in respect to tasks that scripting languages usually tackle. If JS is painfully slow for you, I'm just assuming you are using it for something you probably shouldn't be using ANY scripting language for.
I'm not sure what the "module" and "require" patterns have to do with prototypical inheritance. Ruby, Python, and Groovy (for example, there are many others) are all class based and allow metaprogramming and/or "monkey patching," so "dirty object decoration" is not a trait only found with JS.
Web workers are very restricted. They run in a completely different scope and can merely pass messages to the main UI thread.
I wasn't peeing on JS. I love Javascript. The only negative thing I mentioned was that prototypical inheritance isn't something people usually fawn over. However, I also mentioned that it IS in keeping with Javascript's simplicity. For note, I LIKE simple. Simple is good. Simple and powerful are not mutually exclusive.
My favourite language, by far, is Scala, so don't think I don't know where you are coming from. And, honestly, my favourite dynamic language is Python, though I am using JS on occasion now.
The difference is that JS can appear to be multi-threaded. For instance, I can set a function to run after a set amount of time (setTimeout). In the browser, this function will be run in the same thread as all the other code and it will be atomic. The same goes for all the UI events and the like. If I wanted to set a timeout in C that would run a function after 1 seconds, while doing some other stuff in the mean time, threads would be what I'd grab for first. However, JS promises to be single threaded, so you never have to worry about the underlying implementation.
Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.
Undefined vs. null is nuanced? Hardly. And == vs. ===? Pretty much every language defines a difference between equivalence and object identity, whether its Python (== vs. is), Java (equals vs. ==), or Javascript (== vs. ===). What I meant by simple is that there aren't a whole lot of "extras" in the language. Every language is nuanced to the extent you are describing.
Well played, sir. Pretend that an inherent limitation is somehow a feature. As if, if I were to choose another language, I would be forced to write multithreaded code.
It's a design decision, there is no reason they couldn't have allowed threads. Also, it is a design decision that isn't always immediately apparent when dealing with event driven UI code. This includes setTimeout/Interval. The functions that run on this timer are atomic. Again, this is not immediately apparent if you aren't familiar with JS. And, yes, this is a nice feature, as having all even driven UI code, timers, etc. run in the same thread is not as easy as it seems.
Prototypical inheritance didn't make JS cool, and JS wasn't the reason we hated JS 10 years ago.
The reason JS was hated so much 10 years ago was because of the DOM. That's it. Every browser had close enough implementations that you thought mucking about with the DOM would be simple... but they were different enough to cause endless headaches and hardcoded hacks to work around all sorts of quirks. Making a simple drop-down menu meant coding everything from scratch, maintaining essentially 3 different versions of the same code for different browsers.
JS is cool today because of many things.
The convergence of browser features and DOM implementations towards the standard. Coding JS to work cross browser has definitely gotten easier.
The proliferation of browser libraries that abstract the browser away from us developers and handle all the little DOM implementation differences for us.
There is a solid (and growing) set of best practices for client-side programming (eg. progressive enhancement, event-driven programming, etc.). This has dramatically cut down on the amount of time spent (re)writing JS and let's people create better abstractions that work well with JS.
The functional aspect of JS is definitely nice, and allows for some very concise code (considering) to be written. However, it can also be eschewed for those that are not comfortable with functional programming.
JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.
However, I don't think people think prototypical inheritance is really all the grand. It's simple, is what it is and that fits well with JS (simple). When most the original crop of modern JS frameworks came out, the first order of business was to build a more traditional class-based inheritance approach. I know it doesn't fit well with your "renegade" theory, but it's true. People now seem to be getting comfortable with prototypical inheritance, but I don't think you'll find many people willing to extol its virtues.
Also, JS has first class functions, yes, but so do LOTS of other languages. I'm not sure why you're picking on JS developers for liking some aspects of functional programming.
Except that JavaScript, today, is not a slow dynamic scripting language. The latest JS engines in IE 9, FF 4, and Chrome are lightning fast. You'll be hard pressed to find a faster dynamically typed scripting language today. Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS. Also Rhino IS slow (compared to most other JS interpreters) and has been included with Java by default since Java 6.
Sandvine, who did this research, actually supplies Comcast with the devices they use to throttle traffic (especially of the P2P variety). So I'd take this article with a grain of salt.
Yep. Health care is a big no-no. I mean, roads, water, police, education, etc, that's perfectly fine, but health care!? That's absurd.
Seriously. If I could just diff old-eula.txt new-eula.txt I'd be as happy as a pig in poop. Instead, I'm supposed to re-read the mammoth PSN EULA every other month.
Desalination is far from solved (as an economically viable technology). Yes, it works well for cruise ships and the like, but providing clean water to 10s of millions of people living in poverty? Not really. The best method for desert dwellers is to tap into fossil water supplies. Gadhafi (yes, that Gadhafi) put $30b into a water distribution and supply system that tapped into fossil water wells in the main desert and supply it all over the country. The only problem is that fossil water wells do not regenerate as fast as we use them and suffer the same fate as oil; cost goes up as more water comes out because the levels go down and it becomes harder to pump. These sources are not a permanent fix and $30b is a LOT of money for a lot of countries. Importing water isn't easy either. Water weighs a lot and costs a lot to import and, remember, we are talking about countries with millions of people with next to no GDP. Unfortunately, you are using a very wealthy nation as your example, but I'm talking about the Chads, Sudans, Nigers of the world, not the Dubais and Saudi Arabias.
I'm sorry, but how?
The problem is that the origin story usually has fairly little to do with the main plot (at least after the first movie or whatever). The show "Heroes" actually suffered from this. The producers thought that people liked origin stories, so in Season 3 (I think) they introduced a LOT of new characters with new origins. The story suffered greatly (lots of little threads, but with very little happening each episode). The season tanked as people didn't want to watch Season 1 again. The producers back tracked for the next 2 seasons, they scaled down to a much smaller base cast (about the size of season 1's), and stopped introducing new people with origin stories. Season 4 and 5 were much better as a result.
Compiz delegates pretty much all standard WM tasks to plug-ins... including "theming".
I use rdio.com (Canada & US) for $5/m. On demand music is fantastic. Seriously, its great for general listening (listen at work a lot), but it really shines when you have friends over. Just leave the laptop open and anyone can just go and play whatever song they feel like. Definitely worth it for $5/m.
I use rdio.com, which is available in Canada and the U.S. No free service, but $5/m gives you on-demand music. I'm always worried the labels are going to get greedy and start imposing stupid restrictions, even on paying customers, which would force me to drop the service.
It is not a percentage of cost of the laptop, but electricity saved vs. cost of retrofitting their manufacturing plant. The retrofitting process will probably involve a lot of western engineers and involve a high fixed cost that is less variable per country.
That said, in Canada we may even pay you to use electricity. If a manufacturing plant can keep the majority of their work in off-peak times, they can save a bundle in Western countries. The point is, for a large company, electricity is an important cost, but they have lots of options to reduce this cost. Most importantly, there are a lot easier ways to save some $$$ in your electricity bill than investing in the latest and greatest green tech. It sucks but it is true.
Sounds like he is an "idea" guy (he is not a programmer). "Oh, I have a great idea. Now the easy part; implementing it!" Apparently Ted Nelson was considered the King of Vaporware back in 1995... just to give you some background.
Unfortunately, most laptops are not manufactured in Britain, but in countries with much cheaper (and dirtier) electricity.
Lots of robots do use 2 eyes (cameras) for 3D vision. http://opencv.willowgarage.com/documentation/camera_calibration_and_3d_reconstruction.html
Basing your identity on what you don't base your identity on is probably childish too then. However, what I do and my identity are definitely linked. Seriously, I stare at a computer and program for about half my waking life. If you think that I can somehow completely separate that part of myself from the other half, you have to be nuts.
Well, it is nice to see that the math section has more or less remained relevant. Aside from finding cubic roots by hand, everything in there is still taught in high school today. In fact, the arithmetic section seemed quite easy by today's standards and there was no calculus at all, which most high school students going into post-sec get at least 1 year of, if not 2. Only the trig & geom part would be tricky, as I remember only about 1/4 of my graduating year taking trig & geom in the last year. I guess even math has its fashions, though it seems to be the most stable.
Or you can use public key cryptography to solve the problem. Store a padded version of the password in the DB encrypted with a public key (verification just involves re-encrypting the plaintext password submitted by the user), and store the private key in some super secure location. The only time you'd ever need to access the private key is at law enforcement's request (so it can be stored in a vault or something).... No hacker can crack the passwords by getting access to the machine and the company can always get the data back in plaintext if absolutely necessary. The biggest implication is the overhead cost involved, but that will still probably be less than the revenue generated from continued business in France.