While I agree with the journalist story telling discussions here, scientists should always approach the universe with wonder, surprise, and openness.
Just because we don't believe in magical ideologies, doesn't mean you should let egos replace imagination. Lack of wonder and imagination risks the very foundation of the furtherment of science.
For several years now Safari has outpaced Chrome nearly across the board in javascript and DOM operations.
I've been tracking it as a web app developer because it has serious implications for UX on mobile devices. The DOM operations can easily be 3-4X faster in safari, when combined with the iPhones processing advantages stacks up a 10X difference in performance between the average iPhone and the average android phone. Its a big problem for javascript app developers. examples: https://bugs.chromium.org/p/ch... https://discuss.emberjs.com/t/...
The fact the Safari is left out of these comparisons puts a reality distortion field on the market, and keeps Google from getting their act together.
The problem with your data is that selling lots of $50 android phones, and cheap windows boxes doesn't mean people use them. Also, given the professional, corporate, and tech industries strong leaning toward Macs over Windows (even the Microsoft office I was in recently was all iMacs) - they will use the web 10X more than joe average.
As programmer it makes no sense to me. Are you saying that the only code protected by copy-write is the code inside the function curly braces, and not the code outside (i.e. the functions, parameters, returns). This seems like an arbitrarily grey line. What about expressive languages that blur the lines between function declarations and executable code? What if significant code is all written in a macros, where there is no difference? This also dismisses code architecture as uncopywriteable, and yet architecture may be one of the hardest to do right, and thus most valuable things in code.
Citations are easily had by taking statement and plugging into google. I gave you pointers.
No energy industry is separate from government subsidies. Good luck separating the two. And in fairness, should they be totally seperate? As energy is a core driver of economics, security, independence and growth.
But least of which is nuclear, which is the most subsidized industry in history.
Those are international numbers led by developing countries installed capacity like China and India who could care less about regulation.
This very plant we are talking about required 3/4th of its costs to be underwritten by government
You mean like the $100 Billion (time.com) that has gone into every single nuclear pant ever built since the beginning of the DOE? You mean like the current nuclear research, loan guarantees and insurance coverage? All for an industry that collapsed under its own economic weight, and only exists today cause Obama boosted the government research subsidies for nuclear?
This is pure Econ 101. If a $1billion solar plant has the same CapEx as nuclear plant, but I can put a panel in service every 10 seconds for $150 each, versus wait 10 years for a monolithic nuclear plant with all the safety and infrastructure to be built... by the time the nuclear pant is built I've already paid down my CapEx, and essentially have no OpEx. Solar wins every time.
We used to test nuclear weapons in Nevada's desert and other remote places in the US proper before. Certainly, building a nuclear power-plant in the same (or similar) locations would've been acceptably risky
You're are kidding right? We spend $6B/Year on cleanup. Untold billions on health lawsuits. Still haven't found a long term storage solution. And leave it up to the government to figure it out for industry. Oh, and right... it doesn't matter cause it isn't economical.
The plant cost $2.2B and has a gross capacity of 392 megawatts, therefore the build capacity cost were $5.6/W. The DOE EIA shows coal averages $4.4/W but can be as high as $6.6/W for cleaner plants, and nuclear built costs at a similar $5.5/W. So it was built for a very conventional cost.
But that is just build cost. Then comes the fixed and variable O & M costs for which solar is very low. Half of coal, and a third of nuclear. And that is with coat and nuclear getting all sorts of governmental freebees on the external costs of environmental, health & security impact.
We describe the combination of capital and O&M as LCOE (levelized cost of energy). For which the plant it is a quoted at a LCOE of $0.146/kWh. NOT $200/kWh. Which is competitive which a number of conventional fuel sources like natural gas (wikipedia). PV still ranks cheaper, but there have been few bigger thermal projects to drive down these costs. You might notice that the DOE only quotes the LCOE of theoretical nuclear projects to be delivered in 10 years or fully capitalized 40 year old plants, because the last nuclear plants to be built in the USA had terrifyingly bad economics, and even then don't include their obvious myriad of externalities.
And this is (partially) why in the free market, wind, solar, and decentralized gas-turnbines are killing it. In the last 10 years solar+wind have been leading new capacity installation world wide. by the end of this year solar will have reached 321GW of worldwide capacity, Wind 517GW... most of which was installed in the last 10 years period. Whereas worldwide nuclear capacity declined from 375GW to 372GW in the same period.
Even the most stupid and inconsistent/scriptable/ user interface is worth more than the best designed inextensible gui.
Use a different OS, or learn more about the one you use. Nearly every element of every application I use on the Mac OS is extendable or scriptable through OSA scripting. It doesn't just stop at piping together textfiles, but can do any type of inter-applicaiton scripting. You are limiting yourself.
You're a freaking genius -- you conceive everything in your head, and then it just works: no debugging, no refactoring, no revision control is ever needed. More curiously, the interfaces and external libraries you're using are just as perfect and immutable as your code.
No, i'm not. But to prove the point, last year I had my best programmer program in C what it took another programmer in python 10x as long. Is C more expressive than python? Not a chance. The difference isn't usually in how much or how fast you type, it is how fast you think through the problem.
Interestingly, just reading the preferred environments of winning competition coders, few list a command line editor. Most a IDE or and heavy-duty GUI editor like sublime.
I think this retro movement is a knee-jerk to "user-friendly" or "simplicity", as if that means "not expert". But as a Wired article recently made clear, most serious GUI tools are not simple at all. But the good ones are "Clear". Clarity only helps power-user tools, and certainly no unbiased observer would call a GUI editor or IDE "obtuse", and vim or emacs "Clear". Most command line tools need are solutions to their self-imposed problems. Back in the day we only had command line tools we could only dream of good IDEs that we have today.
P.S. hat are all these tedious actions? Spend all my time thinking, architecting, then writing... mostly once.
If all you want is coding monkeys, then you are right.
If you are doing real product development that comprises UI/UX, software, hardware, industrial design, PCB design, 3D mechanicals... like most products, then you are wrong.
I don't work for a big company where everybody is siloed into narrow tasks. I want everybody to contribute to their upmost potential. I understand I may be one of the broadest engineers around, but that is a requirement in a startup environment. And I really hate when people say, it is "not my job", cause all problems are just problems not software, hardware, mechanical, architectural, UI/UX problems.
If your toolbox is big enough, you can pick the right way to address the problem, not just the one you know.
i expect people in my team to be a broad as possible. If all you can do in manipulate text, it limits your potential, your perspective, your creativity, and the company
Boring is a real problem in open source. I don't find most open source applications compelling, because they generally don't move the flag forward, and instead just poorly mock existing commercial efforts. And usually they are quiet a bit less refined.
So being someone who likes to both have the best tools at the ready, and reward innovators, why would I use a a bad copy of something good... just because it is free? It is not enough. It is like a bad copy of an original painting. The validation in open source that coders get kudos amongst other coders, not users. So rarely does anybody actually care if it is usable at all. And so no mainstream users ever emerge. Until you change the personal validation proposition in the open source community (and maybe our social skills too), it is not going to change.
This is what is wrong with open source! It mistakes good design with new-fangled, fewer features, and inefficient. And yet, I find that is only true of open source, not professional applications. Adding more features beyond 128 characters of ASCII, doesn't make programs suck (just the opposite).
I've got a guy in the office just like you, only vim.
You know what? He is only slightly faster than somebody with good sublime skills, and utterly lost when skills require him to do something more than text process on the command line. I totally run circles around him when it comes to weaving together CAD, graphics, 3D, presentations, vector work, and deep-level debugging in graphical debuggers. The other day I put together a presentation that was an amalgam of 3D cad, mechanical CAD, architectural CAD, photoshop, illustrator, graphical and 3D editors, video editing, and 2D animation. While his text processing is a bit deeper than mine, it doesn't make him very much more efficient at coding, cause that is bandwidth limited by thinking, yet his skill set is sooo much narrower.
The "my command line is all I need" argument was lost 30 years ago. Text is just one of many things a GUI handles. But the thing a GUI does is provide a consistent framework that allows you to use another programs bringing 70% of your skill base to a new application, with little reboot time. Try moving vim guys to emac, and vice versa.
There are lots of really interesting and hard problems in CS. But very rarely do I interview a CS grad that has any experience in them, or more frustrating, doesn't even know the nomenclature (e.g. define "heuristics").
They can't even address simple on-the-spot software solutions (e.g. write a simple C function that flips the order of a link-list). All that time spent doing stuff in java has rotted their brains.
However, while this might be true for the work roles people are performing, the article at the end shows that EEs have lower unemployment than CSs.
This is my experience: When interviewing EEs and CS degreed employees, I'll chose the EE over CS 9 out of 10 times for a software job. In general they have a stronger grasp of the big picture, hardware, software & firmware. In fact I've been downright disappointed with the level of CS expertise by CS grads lately. It is as if the universities are training them for javascript, web site production, and IT support as apposed to a deep understanding of the CS field.
What we can say about this article is: there are more software than hardware jobs, but EEs are dual purpose, and overall have lower unemployment.
I completely disagree Swift VERY special. I'm a embedded systems programmer, and I most to use Swift. There is no other serious contender right now for a modern systems language than can replace C, C++ or objC.
Swift ia very unique language is that it: 1) Has the high level language syntactical goodness of a scripting language like Python or Ruby 2) Has the native performance of a systems language like C 3) Has strong support for multiple paradigms including Functional Programming, Object, and procedural 4) Can morph from a JIT language during compile time for faster programmer efficiency (Like Java), and compile fully native like C 5) Has a hot-coding environment like I've never seen anywhere else
There is only one language that come close to this, and that is Rust. But Rust is probably 5 years from being production ready. And it lacks the JIT-y hot coding goodness.
Having said that, I see a couple of things coming down the pike. First, Java usage have been in pretty steady continual decline since 2000 (Tiobe). In the last couple of years C has retaken the top spot. (though it is somewhat surprising that there hasn't been a noticeable bump upward in Java use since Android has taken off).
Universities are largely moving away from Java as a teaching language. It has moved very strongly to Python in the last few years. I suspect this is impacting Java usage quite a lot.
Apple went down the path of extensive parallelism using queue-based thread pools (libdispatch) several years ago... this is pretty optimal approach to concurrency. In C/C++/objC Apple added the extension for "blocks" to GCC and Clang which are the same thing as lambdas. Swift has the idea of lambdas built right in from the get-go. Libraries using libdispatch deep down, together with language hints that help autovectorization, make it so Swift enjoys parallel excution not unlike a functional language, but at native speed.
Apple has typically supported the last 3-4 generations of devices with new updates. iOS8 just released supports phones back to the 4s, which was released back in 2011. Given that *no other* manufacturer has anything close that kind of OS upgrade support history, I really don't see how you can knock Apple at all on this point. (if you compare the install rate you can get a good picture of this in 1 week iOS8 was installed on 50% of the user base, compared to just 25% of KitKat after 10 months)
These performance issue are huge! The Android team made the wrong choice with Java. essentially they have saddled Android with the need of 2-3x the CPU and 4X the RAM to do the same things as an iPhone. Not only does that cost money (and profit), but it sucks battery life, requiring bigger fatter batteries.
No doubt these are nice features. Which is why the hybrid approach of Swift is the best of both worlds. JIT live-code at development, compile time speed and memory footprint.
But some (like Linus T.) would also point-out this as a reason to keep programs in languages like 'C', it keeps the mid level programmers out who need more hand-holding.
Really? Your argument is we should waste CPU and RAM resources with inefficient languages, and try and make up for it with lots of hardware?
Every embedded system has these constraints, not just mobile phones. Welcome to the rest of the world.
For example. I recently got a Nexus 7 and benchmarked a javascript app against a 3 year old iPad2. 2x cores, 2x the GHz, 4x the Ram. The result? The Nexus 7 was unacceptably laggy in response to user touch and DOM manipulation... compared to a 3 year old iPad. Ridiculous!
Also, again, if you bother to read that article, there is no magic "throw more RAM at it" solution with systems on a chip. There are RAM limits to what can be integrated onto a SOC
Slashdot Mirror
While I agree with the journalist story telling discussions here, scientists should always approach the universe with wonder, surprise, and openness.
Just because we don't believe in magical ideologies, doesn't mean you should let egos replace imagination. Lack of wonder and imagination risks the very foundation of the furtherment of science.
For several years now Safari has outpaced Chrome nearly across the board in javascript and DOM operations.
I've been tracking it as a web app developer because it has serious implications for UX on mobile devices. The DOM operations can easily be 3-4X faster in safari, when combined with the iPhones processing advantages stacks up a 10X difference in performance between the average iPhone and the average android phone. Its a big problem for javascript app developers.
examples:
https://bugs.chromium.org/p/ch...
https://discuss.emberjs.com/t/...
The fact the Safari is left out of these comparisons puts a reality distortion field on the market, and keeps Google from getting their act together.
You have data problem. Region, education, occupation, access, software quality, and income all factor into usage.
So what you find is in the USA. Chrome is 47% market, followed by Safari at 31%. Everything else is in the noise.
http://gs.statcounter.com/brow...
If you restrict that to mobile devices. Safari is 50% market, followed by Chrome at 41%.
http://gs.statcounter.com/brow...
The problem with your data is that selling lots of $50 android phones, and cheap windows boxes doesn't mean people use them. Also, given the professional, corporate, and tech industries strong leaning toward Macs over Windows (even the Microsoft office I was in recently was all iMacs) - they will use the web 10X more than joe average.
Can you explain this a little?
As programmer it makes no sense to me. Are you saying that the only code protected by copy-write is the code inside the function curly braces, and not the code outside (i.e. the functions, parameters, returns). This seems like an arbitrarily grey line. What about expressive languages that blur the lines between function declarations and executable code? What if significant code is all written in a macros, where there is no difference? This also dismisses code architecture as uncopywriteable, and yet architecture may be one of the hardest to do right, and thus most valuable things in code.
Citations are easily had by taking statement and plugging into google. I gave you pointers.
No energy industry is separate from government subsidies. Good luck separating the two. And in fairness, should they be totally seperate? As energy is a core driver of economics, security, independence and growth.
But least of which is nuclear, which is the most subsidized industry in history.
Those are international numbers led by developing countries installed capacity like China and India who could care less about regulation.
You mean like the $100 Billion (time.com) that has gone into every single nuclear pant ever built since the beginning of the DOE? You mean like the current nuclear research, loan guarantees and insurance coverage? All for an industry that collapsed under its own economic weight, and only exists today cause Obama boosted the government research subsidies for nuclear?
This is pure Econ 101. If a $1billion solar plant has the same CapEx as nuclear plant, but I can put a panel in service every 10 seconds for $150 each, versus wait 10 years for a monolithic nuclear plant with all the safety and infrastructure to be built... by the time the nuclear pant is built I've already paid down my CapEx, and essentially have no OpEx. Solar wins every time.
You're are kidding right? We spend $6B/Year on cleanup. Untold billions on health lawsuits. Still haven't found a long term storage solution. And leave it up to the government to figure it out for industry. Oh, and right... it doesn't matter cause it isn't economical.
You sir don't know how to calculate basic math.
The plant cost $2.2B and has a gross capacity of 392 megawatts, therefore the build capacity cost were $5.6/W. The DOE EIA shows coal averages $4.4/W but can be as high as $6.6/W for cleaner plants, and nuclear built costs at a similar $5.5/W. So it was built for a very conventional cost.
But that is just build cost. Then comes the fixed and variable O & M costs for which solar is very low. Half of coal, and a third of nuclear. And that is with coat and nuclear getting all sorts of governmental freebees on the external costs of environmental, health & security impact.
We describe the combination of capital and O&M as LCOE (levelized cost of energy). For which the plant it is a quoted at a LCOE of $0.146/kWh. NOT $200/kWh. Which is competitive which a number of conventional fuel sources like natural gas (wikipedia). PV still ranks cheaper, but there have been few bigger thermal projects to drive down these costs. You might notice that the DOE only quotes the LCOE of theoretical nuclear projects to be delivered in 10 years or fully capitalized 40 year old plants, because the last nuclear plants to be built in the USA had terrifyingly bad economics, and even then don't include their obvious myriad of externalities.
And this is (partially) why in the free market, wind, solar, and decentralized gas-turnbines are killing it. In the last 10 years solar+wind have been leading new capacity installation world wide. by the end of this year solar will have reached 321GW of worldwide capacity, Wind 517GW... most of which was installed in the last 10 years period. Whereas worldwide nuclear capacity declined from 375GW to 372GW in the same period.
Even the most stupid and inconsistent /scriptable/ user interface is worth more than the best designed inextensible gui.
not at all.
software = tools.
more tools, more things you can build.
Interestingly, just reading the preferred environments of winning competition coders, few list a command line editor. Most a IDE or and heavy-duty GUI editor like sublime.
I think this retro movement is a knee-jerk to "user-friendly" or "simplicity", as if that means "not expert". But as a Wired article recently made clear, most serious GUI tools are not simple at all. But the good ones are "Clear". Clarity only helps power-user tools, and certainly no unbiased observer would call a GUI editor or IDE "obtuse", and vim or emacs "Clear". Most command line tools need are solutions to their self-imposed problems. Back in the day we only had command line tools we could only dream of good IDEs that we have today.
P.S. hat are all these tedious actions? Spend all my time thinking, architecting, then writing... mostly once.
If all you want is coding monkeys, then you are right.
If you are doing real product development that comprises UI/UX, software, hardware, industrial design, PCB design, 3D mechanicals... like most products, then you are wrong.
I don't work for a big company where everybody is siloed into narrow tasks. I want everybody to contribute to their upmost potential. I understand I may be one of the broadest engineers around, but that is a requirement in a startup environment. And I really hate when people say, it is "not my job", cause all problems are just problems not software, hardware, mechanical, architectural, UI/UX problems.
If your toolbox is big enough, you can pick the right way to address the problem, not just the one you know.
i expect people in my team to be a broad as possible. If all you can do in manipulate text, it limits your potential, your perspective, your creativity, and the company
Boring is a real problem in open source. I don't find most open source applications compelling, because they generally don't move the flag forward, and instead just poorly mock existing commercial efforts. And usually they are quiet a bit less refined.
So being someone who likes to both have the best tools at the ready, and reward innovators, why would I use a a bad copy of something good... just because it is free? It is not enough. It is like a bad copy of an original painting. The validation in open source that coders get kudos amongst other coders, not users. So rarely does anybody actually care if it is usable at all. And so no mainstream users ever emerge. Until you change the personal validation proposition in the open source community (and maybe our social skills too), it is not going to change.
This is what is wrong with open source! It mistakes good design with new-fangled, fewer features, and inefficient. And yet, I find that is only true of open source, not professional applications. Adding more features beyond 128 characters of ASCII, doesn't make programs suck (just the opposite).
I've got a guy in the office just like you, only vim.
You know what? He is only slightly faster than somebody with good sublime skills, and utterly lost when skills require him to do something more than text process on the command line. I totally run circles around him when it comes to weaving together CAD, graphics, 3D, presentations, vector work, and deep-level debugging in graphical debuggers. The other day I put together a presentation that was an amalgam of 3D cad, mechanical CAD, architectural CAD, photoshop, illustrator, graphical and 3D editors, video editing, and 2D animation. While his text processing is a bit deeper than mine, it doesn't make him very much more efficient at coding, cause that is bandwidth limited by thinking, yet his skill set is sooo much narrower.
The "my command line is all I need" argument was lost 30 years ago. Text is just one of many things a GUI handles. But the thing a GUI does is provide a consistent framework that allows you to use another programs bringing 70% of your skill base to a new application, with little reboot time. Try moving vim guys to emac, and vice versa.
The question is why.
There are lots of really interesting and hard problems in CS. But very rarely do I interview a CS grad that has any experience in them, or more frustrating, doesn't even know the nomenclature (e.g. define "heuristics").
They can't even address simple on-the-spot software solutions (e.g. write a simple C function that flips the order of a link-list). All that time spent doing stuff in java has rotted their brains.
However, while this might be true for the work roles people are performing, the article at the end shows that EEs have lower unemployment than CSs.
This is my experience: When interviewing EEs and CS degreed employees, I'll chose the EE over CS 9 out of 10 times for a software job. In general they have a stronger grasp of the big picture, hardware, software & firmware. In fact I've been downright disappointed with the level of CS expertise by CS grads lately. It is as if the universities are training them for javascript, web site production, and IT support as apposed to a deep understanding of the CS field.
What we can say about this article is: there are more software than hardware jobs, but EEs are dual purpose, and overall have lower unemployment.
I completely disagree Swift VERY special. I'm a embedded systems programmer, and I most to use Swift. There is no other serious contender right now for a modern systems language than can replace C, C++ or objC.
Swift ia very unique language is that it:
1) Has the high level language syntactical goodness of a scripting language like Python or Ruby
2) Has the native performance of a systems language like C
3) Has strong support for multiple paradigms including Functional Programming, Object, and procedural
4) Can morph from a JIT language during compile time for faster programmer efficiency (Like Java), and compile fully native like C
5) Has a hot-coding environment like I've never seen anywhere else
There is only one language that come close to this, and that is Rust. But Rust is probably 5 years from being production ready. And it lacks the JIT-y hot coding goodness.
True. True. and True.
Having said that, I see a couple of things coming down the pike. First, Java usage have been in pretty steady continual decline since 2000 (Tiobe). In the last couple of years C has retaken the top spot. (though it is somewhat surprising that there hasn't been a noticeable bump upward in Java use since Android has taken off).
Universities are largely moving away from Java as a teaching language. It has moved very strongly to Python in the last few years. I suspect this is impacting Java usage quite a lot.
Refcounts don't kill the parallelism.
Apple went down the path of extensive parallelism using queue-based thread pools (libdispatch) several years ago... this is pretty optimal approach to concurrency. In C/C++/objC Apple added the extension for "blocks" to GCC and Clang which are the same thing as lambdas. Swift has the idea of lambdas built right in from the get-go. Libraries using libdispatch deep down, together with language hints that help autovectorization, make it so Swift enjoys parallel excution not unlike a functional language, but at native speed.
I don't see any support for your claim at all.
Apple has typically supported the last 3-4 generations of devices with new updates. iOS8 just released supports phones back to the 4s, which was released back in 2011. Given that *no other* manufacturer has anything close that kind of OS upgrade support history, I really don't see how you can knock Apple at all on this point. (if you compare the install rate you can get a good picture of this in 1 week iOS8 was installed on 50% of the user base, compared to just 25% of KitKat after 10 months)
These performance issue are huge! The Android team made the wrong choice with Java. essentially they have saddled Android with the need of 2-3x the CPU and 4X the RAM to do the same things as an iPhone. Not only does that cost money (and profit), but it sucks battery life, requiring bigger fatter batteries.
No doubt these are nice features. Which is why the hybrid approach of Swift is the best of both worlds. JIT live-code at development, compile time speed and memory footprint.
But some (like Linus T.) would also point-out this as a reason to keep programs in languages like 'C', it keeps the mid level programmers out who need more hand-holding.
Really? Your argument is we should waste CPU and RAM resources with inefficient languages, and try and make up for it with lots of hardware?
Every embedded system has these constraints, not just mobile phones. Welcome to the rest of the world.
For example. I recently got a Nexus 7 and benchmarked a javascript app against a 3 year old iPad2. 2x cores, 2x the GHz, 4x the Ram. The result? The Nexus 7 was unacceptably laggy in response to user touch and DOM manipulation... compared to a 3 year old iPad. Ridiculous!
Also, again, if you bother to read that article, there is no magic "throw more RAM at it" solution with systems on a chip. There are RAM limits to what can be integrated onto a SOC
If you'd bother to look at current Swift benchmarks, not the initial betas, you'd see it racing passed C code due to its inherent parallelism.
See: http://www.jessesquires.com/ap...
In a series of typical sort tests, Swift bests objC in these tests by 6-18 times, both using Clang & LLVM. Yikes!
Except it isn't. Go ahead a read: http://sealedabstract.com/rant...
Jump to the graph: "If you remember nothing else from this blog post, remember this chart."