Fifty or Sixty Years of Processor Development for This? - <AUTHOR> https://www.eejournal.com/article/fifty-or-sixty-years-of-processor-developmentfor-this/ <comment><USER5> Wonder what this means for system software and application development.

There's a factor of 10-40x speedup by going from an interpreted language like Python/Ruby/PHP to a tight compiled one like C++/Rust/Ocaml. 2-4x going from a good JIT like V8 or Hotspot (or Go's runtime, though technically not a JIT). Probably another 10-100x by cutting out bloated middleware like most web frameworks or the contents of your node_modules.

All this was irrelevant when you could get your 2-4x speedup by waiting 18 months, and your 10x speedup by waiting 5 years. It's very relevant when your 2x now takes 20 years and 10x takes a lifetime. Maybe this is why Rust gets so much attention recently.

<comment><USER6> I run a production Rust web service. The speedup for this service over using slightly stripped Rails was only about 5x. As you said, you can gain like 50-100x performance improvements from not using the default Rails JSON serialization and skipping ActiveRecord.

After that, you're lucky to gain 5x performance from re-writing the whole thing in Rust. Most of the hot spots of serving web applications using Ruby are already written as native extensions.

I think Rust is fantastic. I'm writing a tinyrb like "Ruby" VM in Rust at the moment. But... it's just not worth the hassle for plugging web services together. Maybe if you're at Google scale and already have web services in C++ it'd be a good choice.

<comment><USER7> I find the fact that anyone can speak dismissively about a 5x speedup disheartening. Has anyone ever done a study on how much CO2 we are emitting in the name of "developer productivity"?

<comment><USER5> It's probably less than you think. Humans - just by virtue of existence - produce a _huge_ amount of CO2, both through the air they breathe, the meat they eat, the automobiles they get to work in, the heavy machinery used to build those roads & buildings, the manufactured goods they consume, etc. And the CO2 cost of a developer isn't just that one developer's emissions; it's also those of all the support staff needed, from managers/admins/HR at work to the food service workers that serve them meals out to the doctors/lawyers/therapists and other service providers they visit to the parents that raised them.

It's almost certain one developer generates more CO2 than any reasonable number of servers that run their code. Anything that reduces manpower costs is a net positive for emissions. Besides, when the equation changes (say, when the software enters maintenance mode but the servers stay up), they'll be a strong economic incentive to spend the developer time to rewrite it more efficiently.

<comment><USER8> _It 's almost certain one developer generates more CO2 than any reasonable number of servers that run their code._

I'm not so sure. Let's do a back-of-the-envelope estimate.

Assume a single really hefty server that consumes 1 kilowatt. Over one year, this is about 10,000 kw hr. 1 kw hr of electricity produced by a coal fired plant generates about 1 kg of CO2 ([https://carbonpositivelife.com/co2-per- kwh-of-electricity/](https://carbonpositivelife.com/co2-per-kwh-of- electricity/)). Thus that big server running for a year produces about 10 metric tons of CO2.

An average American lifestyle (all in, total country production divided by population, [https://www.theguardian.com/environment/datablog/2009/sep/02...](https://www.theguardian.com/environment/datablog/2009/sep/02/carbon- emissions-per-person-capita)) involves the production about about 20 tons of CO2 per year. So if you write code that full-time on more than 2 really big servers per year, your code might be producing more CO2 than the rest of your lifestyle.

I'm guessing that most of the errors in this are probably overestimating the code's CO2 (probably not coal fired, probably less than 1 kw, a year is less than 10,000 hours), so more realistically maybe it's 4-8 servers to be break- even? Still, I think it's fair to say that there are some participants in this forum whose running code probably generates more CO2 than the rest of their lifestyle.

</comment></comment></comment></comment></comment><comment><USER9> Speaking of Moores law being dead this time, check out this old article from 2012 predicting we would be at 7nm Intel chips with 5nm on the way: [http://www.tomshardware.com/news/intel-cpu- processor-5nm,175...](http://www.tomshardware.com/news/intel-cpu- processor-5nm,17578.html)

Intel is still trying to figure out 10nm because it is rumored that there are material science problems that are causing yield issues. Remember the 1960s when rapid gains in space tech made everyone think we'd be travelling around the solar system by 2000? The tech hit a plateau and stopped. Maybe we're in that situation with chip technology...

<comment><USER10> Why do we have to go below 10nm at all? We'll have hard physics limitations. Can't we improve on other frontiers? Say more cache?, better design ? More cores? Etc. I don't know.

<comment><USER11> Probably the #1 area that can produce results is avoiding/conquering the processor-memory gap: while processor performance has been growing exponentially, memory (bandwidth) performance has basically grown linearly. There is now a factor 1,000 difference between processor/memory speeds compared to 1980.

One of the areas that I have much hope for is near-data processing: since processors scale so much better, pretty much every peripheral device already has its own microcontroller. The idea behind NDP is basically to offload some data-heavy processing to the data layer. What if your disk layer could already preselect your data so the database wouldn't have to read and discard so many rows for each query? What if the network controller could evaluate your firewall rules itself, so dropped packets wouldn't have to interrupt the main CPU?

<comment><USER12> So NDP is essentially what Commodore did with their 1541 disk drive. That disk drive had a 6502 in there to complement the 6502 in the actual VIC-20.

From what I remember, the IBM System Z mainframes also do this sort of thing and have dedicated IO processors that can decode XML on the fly for you and other fun things like that.

<comment><USER13> Every modern hard drive is a computer in its own right.

<comment><USER14> Seagate had a cool project where each hard drive ran linux and they used the physical sas cable to run a 2.5 Gbit network (or two actually) per drive.

So you could use that as block storage for luster, hadoop, or similar and enable things like direct disk to disk copies.

Cool idea, seems unlikely to hit a reasonable price point though.

</comment></comment></comment></comment></comment></comment><comment><USER15> The thing that really killed plain vanilla RISC is memory latency. Compared to on-die registers and cache memory might as well be disk. True RISC is more efficient to execute but it results in more instructions and hence more code that has to be read from RAM.

Modern CISC chips that immediately unpack CISC into RISC micro-ops are really something that I've termed "ZISC" \-- Zipped Instruction Set Computing. Think of CISC ISA's like the byzantine x86_64 ISA with all its extensions as a custom data compression codec for the instruction stream.

We got ZISC accidentally and IMHO without us realizing what we'd actually done. The x86_64 "codec" was not explicitly designed as such but resulted from a very path-dependent "evolutionary walk" through ISA design space. I wonder what would happen if we explicitly embraced ZISC and designed a custom codec for a RISC stream that can be decompressed very efficiently in hardware? Maybe the right approach would be a CPU with hundreds of "macro registers" that store RISC micro-op chunks. The core instruction set would be very parsimonious, but almost immediately you'd start defining macros. Of course multitasking would require saving and restoring these macros which would be expensive, so a work-around for that might be to have one or maybe a few codecs system-wide that are managed by the OS rather than by each application. This would make macro redefinition rare. Apps are compiled into domain specific instruction codec streams using software-defined codec definitions managed by the OS.

The neat thing about this hypothetical ZISC is that while 99% of apps might use the standard macro set you could have special apps that did define their own. These could be things like cryptographic applications, neural networks, high performance video encoders, genetic algorithms, graphics renderers, cryptocurrency miners, etc. Maybe the OS would reserve a certain number of macros for user application use.

<comment><USER16> I agree with a lot of what you said, but ZISC already stands for zero instruction set computing.

Also, RISC and CISC instruction cache hitrates are pretty similar.

<comment><USER15> Ahh I forgot about zero instruction set computing. Maybe CISC should just stand for Compressed Instruction Stream Computing because on today's chips that's exactly what it is.

Cache hit-rates being similar may just show that the ad-hoc evolved compression codecs represented by CISC instruction sets are sub-optimal, hence my point about what might happen if we intentionally designed a CPU with on- board compression codec support for the instruction stream.

</comment></comment></comment><comment><USER17> At the end of this he says transistors are now doubling every twenty years(!?) and it reminded me of another law Patterson doesn't include in his graph:

        Proebsting's Law: improvements to compiler technology double the performance of typical programs every 18 years.

<comment><USER18> The derivation of that law is very suspect:

[http://proebsting.cs.arizona.edu/law.html](http://proebsting.cs.arizona.edu/law.html)

(go on, it's just a paragraph.)

The key issue that this ignores in my opinion, is that a compiler optimization will rarely make last year's program faster, but it will make next year's program faster. Why? Because if the compiler can't make an optimization, programmers will do it by hand, even if it makes the code worse in some way.

For instance, if your C compiler can't inline small functions, you would use a macro instead. When it finally starts learns to inline, your program won't get any faster, but the next version will be able to use functions in places where macros are a bad fit.

Pile up enough of these optimizations, and eventually it starts to feel as if you're coding in a higher-level language than before, even though the syntax that's accepted by the compiler never changed.

<comment><USER19> > programmers will do it by hand

Only if better performance is needed.

Thus, corrollary: compiler technology will double program performance every 18 years, _but only if it doesn 't matter_.

<comment><USER17> Developers have a nasty habit of convincing themselves that things aren't needed when they see them as too difficult. Even if the rest of the world thinks your code is too slow you can convince yourself it's good enough.

And in a world where we rely more and more on libraries, my ability to improve on a piece of code is greatly curtailed. Sending in the compiler to help might be my best option.

</comment></comment></comment></comment><comment><USER20> Yes, we're kind of stuck on individual CPU power. Clocks have been around 3GHz for a decade now.

There are now architectures other than CPUs that matter. GPUs, mostly. "AI chips" are coming. And, of course, Bitcoin miners. All are massively parallel. What hasn't taken off are non-shared-memory multiprocessors. The Cell was the only one ever to become a mass market product, and it was a dud as a game console machine.

<comment><USER21> Perhaps it (Cell) would not have been a "dud" as you put it had IBM not been a morally bankrupt villain.

I've read that Sony was under the impression that the licensing agreement meant that IBM would market Cell tech to other customers, those customers being in other computer markets like datacenters and stuff, rather than to Microsoft, for the 360, at the same time that the PS3 was still in development.

"As the book relates, the Power core used in the Xbox 360 and the PS3 was originally developed in a joint venture between Sony, Toshiba and IBM. While development was still ongoing, IBM–which retained the rights to use the chip in products for other clients–contracted with Microsoft to use the new Power core in their console. This arrangement left Sony engineers in an IBM facility unknowingly working on features to support Sony's biggest competitor, and left Shippy and other IBM engineers feeling conflicted in their loyalties."

from [http://gamearchitect.net/2009/03/01/the-race-for-a-new- game-...](http://gamearchitect.net/2009/03/01/the-race-for-a-new-game- machine/)

(it's a book, and worth reading)

<comment><USER22> I have not read the book, but I have a hard time imagining any world in which the Cell could possibly be successful. Its heterogeneous architecture thrust a huge amount of complexity onto software developers in exchange for meager gains. Writing good code for it was difficult and expensive compared to other platforms. Sony was just completely out of touch with reality.

In 2007, Gabe Newell famously complained that the Cell was "a waste of everybody's time. Investing in the Cell, investing in the SPE gives you no long-term benefits. There's nothing there that you're going to apply to anything else. You're not going to gain anything except a hatred of the architecture they've created."

<comment><USER23> > I have not read the book, but I have a hard time imagining any world in > which the Cell could possibly be successful. Its heterogeneous architecture > thrust a huge amount of complexity onto software developers in exchange for > meager gains. Writing good code for it was difficult and expensive compared > to other platforms. Sony was just completely out of touch with reality.

This was a different time. At that time researchers tried to build clusters out of PS3s - because the speed advantages of the Cell made it worth and "regular" Cell clusters were much more expensive. Some years later GPGPU became feasible and one could forsee that it will become faster than the Cell, too, in near future - and at that time the same kind of researchers dropped their PS3 clusters and built GPGPU clusters. Don't tell me that particular in the beginning GPGPU was easier to program for than the Cell.

It was also the time when Apple switched to Intel CPUs. I know at that time IBM was also trying to sell the Cell to Apple, but Steve Jobs refused and decided for Intel instead.

This decision of Apple and the decisions of researchers to stop tinkering with PS3 clusters and build GPGPU clusters instead were in my opinion the two landslides after which the fate of the Cell was destinied.

<comment><USER22> I'm sorry, but I pretty much entirely disagree.

> Don't tell me that particular in the beginning GPGPU was easier to program > for than the Cell.

The alternative was to use bog-standard homogeneous cores.

Yes, the air force bought a compute cluster of PS3s for some specialized calculations. I wouldn't read too much into that. It says little about the suitability of the architecture for more general purpose computing. Supercomputers were always weird.

> It was also the time when Apple switched to Intel CPUs.

I don't believe there was much chance of Apple moving to Cell. Their switch to Intel was because IBM could no longer seriously compete outside of a few niches. There's nothing positive to infer from IBM's unsuccessful pitch to Jobs.

> This decision of Apple and the decisions of researchers to stop tinkering > with PS3 clusters and build GPGPU clusters instead were in my opinion the > two landslides after which the fate of the Cell was destinied.

You're assigning far more importance to research group purchases than I think is warranted. They don't buy enough to create economies of scale. That's why researchers so frequently adopt consumer products already manufactured at scale, like the Novint Falcon, Microsoft Kinect, and gaming graphics cards.

The Cell was best-in-class for a few specialized use cases, but it was never going to take the world by storm. If we turn to a heterogeneous architecture in the future, it will be begrudgingly, after all simpler alternatives have been exhausted.

<comment><USER23> > You're assigning far more importance to research group purchases than I > think is warranted. They don't buy enough to create economies of scale. > That's why researchers so frequently adopt consumer products already > manufactured at scale, like the Novint Falcon, Microsoft Kinect, and gaming > graphics cards.

This is true, but in the consequences I have to disagree: Very often from this kind of "abusing" consumer products for research purposes there emerge quite interesting applications that _do_ become quite popular and economically important. For example from such research there came the idea to use the Kinect as a 3D scanner - from this commercial applications emerged. Or from GPGPU (which at the beginning NVidia was quite the opposite of enthusiastic about) CUDA and later OpenCL emerged (which is much better to program for than abusing vertex and fragment shaders).

That is why I considered it is quite important for the future of the Cell when researchers went from tinkered PS3 clusters to GPGPU and called this a "landslide event for the future of the Cell".

</comment></comment></comment></comment></comment></comment><comment><USER24> Mirror: [https://web.archive.org/web/20180404023027/https://www.eejou...](https://web.archive.org/web/20180404023027/https://www.eejournal.com/article/fifty- or-sixty-years-of-processor-developmentfor-this/)

<comment><USER25> Also here: [https://archive.is/tY5Cl](https://archive.is/tY5Cl)

</comment></comment><comment><USER26> The problem is that we have designed ourselves into an architectural cul-de- sac when it comes to processors. We have fifty-plus years of evolution on programming methodologies built on top of von Neumann architectures. Moore's Law has given us decades of exponential gain without significant challenge to that architecture, and now that Moore's Law is reaping diminishing returns in terms of compute performance we are in the situation where we'd have to go backward forty years on our programming model in order to take advantage of a superior (given today's technology) architecture. For example, FPGAs can in many cases outperform von Neumann machines by orders of magnitude in terms of compute performance and (more importantly) performance per watt. However, the programming model and ecosystem for FPGAs is worse than primitive. Something you could write in a couple hundred lines of C code could take months to get up and running on an FPGA. We need a way to transition from von Neumann computing to alternative architectures without starting over on computer science. Or, perhaps recent trends in neural networks will eliminate the need for that?

<comment><USER27> Just this afternoon I finished reading David Harland's 1988 book "Rekursiv: Object-Oriented Computer Architecture". It describes a completely different way of designing machines at the low level that can support better programming environments at the high level. You might want to check it out.

I believe we are going to see further balkanization between different operating systems / programming systems and computers based upon what they are use for. Cloud services will be the domain of what today we call "systems programmers" who work in compiled languages and care about speed. In contrast, we might now be able to get real "personal computers" running environments that teach their users how to peel back the layers and manipulate them — the long sought personal computing medium. This all could have happened back in the 80s, but we didn't have widespread or fast use of the Internet. Now it's different, and both of these types of systems can interop together in the blink of an eye because of it.

Both will require completely new computing architectures.

</comment></comment><comment><USER28> It's not all bad - one upside is that you don't need to upgrade your hardware anywhere nearly as often as 10 or 20 years ago.

I put this PC together in 2013 for maybe £500-600 total and apart from adding some RAM I haven't needed to upgrade anything and can still run games on highish settings.

<comment><USER29> You can probably run 2016-2018 games on medium settings if you are not interested in 60fps. I imagine you can play no graphically intense game @60fps at any respectable resolution.

I say this because building a computer which can play say Assassin's Creed Origins or Far Cry 5 at 1080p60 High Settings would easy run you over a $1000 right now, due in no small part to the extravagantly over-priced GPUs.

Heck, it costs $400-600 to get a GPU to play those games on medium to medium high right now. Not a computer, JUST the graphics chip to get 60fps on medium.

Crypto has destroyed affordable PC gaming and it makes me so sad. I can recommend Alienwares on sale that are dramatically cheaper than self-built. What happened to this industry :(

<comment><USER30> 60 FPS? I had a desktop I built in 2014, with a 4770k and an r9 290x, run Overwatch at 144 FPS at 1440p with low settings. The machine could still play Just Case 3 and GTA 5 (2015 games, but I didn't really play any graphically intensive 2016+ games on it) at 1080p 60 FPS with decent graphics settings, if I recall correctly.

I have since upgraded to a 6700k and 1080Ti, but that 2014 hardware lasted well into 2017 - and the current GPU cost just under 3/4 the price of the entire 2014 computer, despite the r9 290x being a top of the line GPU. High end PC gaming definitely isn't affordable anymore.

<comment><USER31> That is mostly due to cost of GPUs having been inflated by miners and perhaps the expense of having a huge monitor.

Neither CPU nor GPU are progressing as fast as some predicted anymore.

Additionally the shift to consoles as stable hardware platforms over time has put a damper on computing power required by economically viable games.

The remaining outlets are VR and huge resolution (same thing actually) - <USER2> high quality and fidelity simulations. (Including AI.)

</comment></comment></comment></comment><comment><USER32> What is the limit on creating bigger chips? If some of the money/effort was focused on being able to fab larger chips instead of decreasing feature size... I don't know much about lithography so maybe the answer is obvious to those that do.

<comment><USER33> Chips are fabb'd on a large wafer, which is then split up (see here: [https://s3.amazonaws.com/ksr/assets/003/150/280/9b6a64c4d8ed...](https://s3.amazonaws.com/ksr/assets/003/150/280/9b6a64c4d8ed23068b87cd56737810ca_large.jpg?1421462097) )

Now, the process isnt perfect, and you hear a lot about "yield" Which is basically how many chips on a wafer are not working to spec. Now, as you make a chip bigger, you increase the chance of a mistake. This reduces the "yield" and drives up the cost. (I'm not sure if its actually possible to make a full sized wafer without a mistake, I'll defer that to someone who knows)

In some cases those broken chips arn't all that bad, so they are shipped with the broken bits deactivated (This could be lies, but I think some AMD procs were done like this )

yes, there are other factors like propagation time, but thats solved by not having chip wide cache coherency.

<comment><USER34> You don't increase the chance of a mistake, you increase the cost of a mistake because each little defect means you're throwing out a whole chip. The larger each chip is, the more expensive each little defect is.

Sony had a hard time when they were ramping up Cell processor production, so they designed the chips with 8 SPEs but only shipped them with 7 activated. That way if a defect happened to be in one of the SPEs, they could just turn it off and still ship the chip.

</comment></comment></comment><comment><USER35> Found an older youtube video that touches on the same topic: [https://www.youtube.com/watch?v=1FtEGIp3a_M](https://www.youtube.com/watch?v=1FtEGIp3a_M)

</comment><comment><USER36> There is a lot of focus on the end of Moore's law here, but it isn't main driver of what's happening. The slow down we are seeing is driven by the end of Dennard scaling.

There is a thermal dissipation limit of 200W per chip for air cooling. We hit that decades ago of course, but it didn't matter while Dennard scaling kept dropping the power consumption. Once that stopped we squeezed a bit more of stuff by being more power efficient, which boiled down to two things - <USER3> stuff off when it wasn't needed and devoting the transistors Moore's law gave us to specialised tasks (like silicon dedicated to encryption or h264 encoding) that did the job more efficiently. However, that doesn't get you very far.

Which is probably why he didn't mention 3D, even though we have it 32 layers of it now and they are talking about 256 layers. What is the point of having 128 CPU's on a single die just running 4 of them exceeds your power budget? Indeed, what's the point of spending billions perusing Moore's further?

Or to put it another way again, the human brain fits roughly the same number of synapses per unit volume as modern 3D silicon has transistors. The brain's raw switching speed is roughly 1,000,000 times slower than silicon (1ms vs 1ns), but power consumption of a synapse vs a transistor is roughly 100,000 times better.

So while AlphaZero learnt to play Go between than any human in a few days, it used more energy that an entire human (not just their brain) would use in several life times to do it.

</comment><comment><USER37> I wonder what will happen to the CPU, especially if it's not speeding up much anymore. Perhaps with Apple doing its own chips, the CPU will just have less and less of the work assigned to it.

<comment><USER38> At some point it was going to be germanium to replace silicon.

<comment><USER39> Remember GaAs? It was the Future in 1980.

<comment><USER16> He's talking about germanium channel FinFETs, GaAs was intended to entirely replace silicon, which probably was never going to happen.

<comment><USER40> GaAs logic is probably happening at some point, just not yet. All improvements like that which would be incredibly expensive to develop will be held off on until all cheaper options have been exhausted. It does seem to be slowly moving though.

</comment></comment></comment></comment></comment><comment><USER19> So Moore's Law really is dead this time. And TPU's are only faster than GPU's through lower precision.

Will compute at least keep getting _cheaper_ , perhaps through economies of scale?

Is Kurzweil's magical next information technology, to carry on the exponential, anywhere in sight?

<comment><USER41> Imagine asics for everything. I mean everything, like implementing a javascript engine directly. The energy efficiency could go up 2-3 orders of magnitude (looking at the difference in bitcoin mining between gpus and asics).

Old gaming consoles had cartridges (with memory); I can imagine a future in which complex software is transported in the same manner, except cartridges contain specialized asics. Or perhaps a step forward - a chip making device in every home, an equivalent of sorts of burning music to cd.

<comment><USER42> _I mean everything, like implementing a javascript engine directly._

In that case, rather than a Javascript engine, wouldn't you have an ASIC for the script itself?

<comment> yjftsjthsd-h You wouldn't want a new chip per website. Maybe hardware handling of a standard library, though.

<comment><USER31> Or even just of the expensive operations like synchronization, context switches, DMA to cache from network interface...

Wait. We have most of that already. :)

</comment></comment></comment></comment></comment><comment><USER43> This should be a sobering account to the remarkably popular theory, that given enough time we should inevitably make powerful enough processors to model a universe in sufficient 'detail' that creatures within it will be convinced they live and are as important as we find ourselves, in this one.

<comment><USER44> If I were to do that, I'd put some constraints in to limit how much the creatures can explore of that universe. For example a maximum speed at which any matter can travel, for one.

<comment><USER43> Even with the parallelism afforded by speed limits, a computer many trillions of times as powerful as we have today could not model the thoughts and life experiences of the billions of human beings and other creatures in this planet.

Its not even clear that modelling thought in a virtual world has any equivalence to thinking in this world.

It is clear that we are unlikely to ever model anything nearly as complicated as this.

<comment><USER45> I don't think it's clear. How long before our digital neural networks exceed the complexity of our human biological ones? It's possible today with a super cluster of sorts. That is to have roughly the same number of connections between neuron type thingies - it still wouldn't be able to match our brains functionally - that's another problem. And yes our biological neurons are way more sophisticated than what we use today for AI, but again that can be overcome eventually.

This suggests that it's possible one day to have computers some orders of magnitude better. If you look at it from first principles, of course it's possible. The brain is unlikely to be the most efficient design of neural network allowable in this universe. So given enough time, we'll learn how to build it better.

Then it's just a manufacturing and energy problem to match the number of human minds on the planet. So no, I don't think it's impossible at all.

Just ridiculously freaking hard, and not likely to happen in our lifetimes.

<comment><USER46> It's not a matter of it being "hard". Nor is it a matter of "complexity" (how many parts something has).

A simulation is a model which picks out a tiny subset of regularities in the target to _model_. There is an infinite density of such regularities to pick upon, because _we_ are imposing the structure on the target in order to model it.

The target of the model has no "model structure" it has causal structure. That is, when light interacts with the surface of a mirror its interaction isnt "abstract", ie., some description. It is an actual photon interacting with an actual electric field, etc.

To "model to infinite density", ie., to have every single test that can possibly be applied to a model come out identical to that test of the target, the model needs to be just another example of the target.

The only thing which can be investigated in _any_ way to behave as light hitting a mirror, is light hitting a mirror.

A digital computer is just an electric field oscillating across a silicon surface. It cannot be programmed into being a mirror, nor into being light.

Programming gives the electric field a "model structure". Chalk gives a blackboard a "model structure". Lego gives a bridge a "model structure".

Programming cannot not -- it is _impossible_ \-- give silicon the causal structure of light interacting with a mirror.

Model structure is actually just an observer-relative isomorphism: when the user of the computer (chalkboard, lego,...) looks at it, the _user_ , is able to inform himself of the target by use of the model. To do so the _user_ identifies certain aspects of the model with the target. The model is not _at all_ causally alike the target.

No amount of lego will make a lego brain. No amount of oscillation in an electric field will make a thought. Neurological activity, and indeed every causal mechanism of the universe, is only _described_ by a model.

<comment><USER9> My argument against simulation is similar in thst certain algorithms for modeling physical processes can only run in exponential time. Protein folding is a good example. How could a computer simulation perform exponential time operations efficiently? It wouldn't work no matter how big a computer was made because the complexity would explode very quickly while reality can do it in real-time.

<comment><USER47> Quantum computers can solve protein folding efficiently.

<comment><USER48> "Can" or "could in principle"?

<comment><USER47> "Can" as in quantum chemistry is one of the best applications for quantum computers.

<comment><USER48> Sorry for the naivety, I am not an expert of quantum computing, therefore I asked. I am quite interested in the topic, might you give me some references, please?

<comment><USER47> Googling for "quantum chemistry computers" yields a number of interesting results, e.g.

[https://www.chemistryworld.com/feature/quantum-chemistry- on-...](https://www.chemistryworld.com/feature/quantum-chemistry-on-quantum- computers/3007680.article)

[https://www.technologyreview.com/s/603794/chemists-are- first...](https://www.technologyreview.com/s/603794/chemists-are-first-in- line-for-quantum-computings-benefits/)

Or if you like something by Feynman:

[http://doc.cat-v.org/feynman/simulating- physics/simulating-p...](http://doc.cat-v.org/feynman/simulating- physics/simulating-physics-with-computers.pdf)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> > Maurice Wilkes first conceived of microprogramming in 1951

Zuse's Z1 was microprogrammed in 1937.

</comment><comment><USER50> > _Consequently, the x86 processors in today's PCs may still appear to be > executing software-compatible CISC instructions, but, as soon as those > instructions cross over from external RAM into the processor, an instruction > chopper /shredder slices and dices x86 machine instructions into simpler > "micro-ops" (Intel-Speak for RISC instructions) that are then scheduled and > executed on multiple RISC execution pipelines. Today's x86 processors got > faster by evolving into RISC machines._

Going by that and the graph, then we can conclude that Intel saw the rapid 90's and early 2,000's gains because it was converting its chips into RISC chips?

Also, that paragraph is basically saying that Intel's architecture has an extra layer of abstraction - so now we actually see that there _is_ indeed an "x86 bloat" and why ARM chips seem to be so much more efficient (assuming all else, including process node is equal). It also looks like Intel may have made a "mistake" going with CISC decades ago, and it tried to rectify that in the 90's.

<comment><USER51> Which is not true, since ARM processors - the faster ones anyway - use micro- ops as well. Arguably µops are not RISC, either, unless you consider "very wide instruction word whose bits map to control lines" RISC.

<comment><USER52> ARM isn't exactly your typical RISC either.

</comment></comment></comment><comment><USER53> I found this article from a Synopsys User Group meeting to be very interesting. The steps and changes needed to get to 7, 5 and 2 nm are really, really big:

[https://www.eetimes.com/document.asp?doc_id=1333109](https://www.eetimes.com/document.asp?doc_id=1333109)

</comment><comment> Const-me I don't think the main reason for Moore's law slowdown is technical one. Intel enjoyed no competition for quite a few years. They simply lacked incentive to improve performance of their chips.

In areas with healthy competition, mobile processors and GPUs, Moore's law still doing OK.

E.g. here's a graph I recently made for top of the line single-chip nVidia GPUs: [http://const.me/tmp/nvidia-gpus.png](http://const.me/tmp/nvidia- gpus.png) The numbers represent single precision floating-point performance. The graph is in logarithmic scale and it looks pretty close to the exponential growth predicted by Moore's law.

</comment><comment><USER54> Couldn't find a video of the event, but probably this talk comes close?

"Past and future of hardware and architecture"

[https://www.youtube.com/watch?v=q9KRq2Ns0ZE](https://www.youtube.com/watch?v=q9KRq2Ns0ZE)

</comment><comment><USER55> So, whats the way forward? FPGAs on Die? Asics? Or doubling down on EVU, Germanium, etc?

<comment><USER40> I think we're far from the ceiling on CPU performance so far, but we seem to have hit a (micro)architectural dead end. Currently a _lot_ of time and transistors is spent simply shuffling data around the chip, or between the CPU and memory, while the actual computational units simply sit idle. Or similarily, units that sit idle because they can't be used for the current task, even if they _should_ be - the FPUs on modern x86 cores are a pretty good example of this. FP operations are just fused integer/fixed-point operations, but it's been designed into a corner where it _has_ to be a special unit to deal with all the crap quickly.

We've probably optimized silicon transistors to death though; that's why it's coming to a stop now. GaAs or SiGe are some of the alternatives there. Although there's still quite a lot of advancements there that simply aren't economical yet. For example, SOI processes at low feature sizes seem to be suitable for mass-produced chips now, but it hasn't made it out of the low- power segment yet. MRAM seems to be viable and might be able to provide us with bigger caches (in the same die area), but right now it's mainly used to replace small flash memories (plus some more novel things like non-volatile write buffers, but it's horrifically expensive). So we've probably got a few big boosts left there, but it's not gonna last forever.

The next obvious architectural advancement right now is asynchronous logic. In theory, it's superior in every way - power and timing noise immunity, speed isn't limited by the worst-case timings, no/reduced unnecessary switching (i.e lower power, meaning higher voltages without the chip melting itself). On paper, you run into some big problems on the data path - quasi-delay- insensitive circuits need a _lot_ more transistors and wires, and the current alternative is to use a separate delay path to time the operations, which is a bit iffy. You do at least get rid of the Lovecraftian clock distribution tree that's getting problematic for current synchronous logic. In practice, the tools to work with it and engineers/designers that know how to work it don't exist, and the architecture is entirely up in the air. So it's many years of development behind right now and a huge investment that nobody really bothered with while they could just juice the microarchitecture and physical implementation.

<comment><USER56> > You do at least get rid of the Lovecraftian clock distribution tree that's > getting problematic for current synchronous logic.

No, you don't. You make it even bigger and far more complex.

You can take any synchronous design, and refine the clock gating further and further, to the point where no part of it gets a clock transition unless it actually needs it on that cycle.

And then when you're finished, congratulations, you've made an asynchronous circuit.

Fully asynchronous design and perfect clock gating are one and the same thing.

The clock distribution and gating approaches we already have are actually a sign of progress towards asynchronous design; they're just quite coarse- grained.

Of course, it's probably not the case that a clock-gating transform of an conventional synchronous design is also the best possible solution to a problem, so there's clearly still scope for improvement. But a lot of the possible improvements are probably equally applicable, or have equivalents in, optimising clock distribution and gating in synchronous design - <USER4> that's ultimately the same thing as moving towards asynchronicity.

So talking about clock distribution issues as a problem that will just go away with asynchronous design is misleading.

</comment></comment></comment><comment><USER57> Hmm, doesn't mention ARM once. A bit of an oversight, or a convenient omission when one is advertising a new RISC instruction set for "purpose-built processors"?

<comment><USER58> "Purpose-built" means you can change the ISA to suit your whims, which for ARM requires you to A) pay for an architecture license and B) pay for the privilege of changing the architecture.

<comment><USER57> I'm sure RISC-V has merits, in fact as a hacker who used microcontrollers I think that would be great. Certainly ARM isn't the be-all and end-all. Technically it's not even 1 ISA, but you still know what I meant. Not mentioning the most* used architecture though? Come on.

* most = number of CPUs shipped

</comment></comment></comment><comment><USER59> I seriously wonder if cryogenic computing won't break out of this. From what I hear it is very promising by several orders of magnitude both in terms of power and speed.

<comment><USER60> I heard a rumor that the big guys did the math on the energy costs for running the compressors to keep nitrogen or helium liquid and compared it to their projected cooling cost for normal computers and found that the compressors were cheaper. Trick is, apparently no one has a good story for super conducting circuit parts, so everyone has to start from scratch.

</comment></comment><comment><USER61> It's also interesting to note that Fabrice Bellard has developed a RISC-V emulator [https://bellard.org/riscvemu/](https://bellard.org/riscvemu/)

</comment><comment><USER62> Is the host down? I can't open that page.

<comment><USER63> It worked for me, but the page took a very long time to load (1 minute or longer).

</comment></comment><comment><USER64> Is there a video of this talk available anywhere?

<comment><USER35> Not sure, but this one might be similar: [https://www.youtube.com/watch?v=1FtEGIp3a_M](https://www.youtube.com/watch?v=1FtEGIp3a_M)

</comment></comment><comment><USER65> So the moral of the story is that everyone with a grand vision and an ambitious project is doomed to failure, but there's still plenty of success to be had for those willing to quickly slap some junk together.

<comment><USER66> To put it more positively, progress is made by stringing together many small incremental improvements. Even the RISC revolution started as a special purpose project that stripped away the inessential to achieve a specific, narrow goal.

</comment></comment><comment><USER67> "Moore's Law are Dead" only for CPU.

Moore's Law is alive and progressing at the same rate for GPU.

Applications such AI, Crypto-Currency are leveraging that.

<comment><USER68> Actually not true. Perhaps surprisingly, CPUs and GPUs are progressing at about the same rate if you look at the high end. GPUs are all about massive parallelism, and if you compare against high end Xeons, the CPU core count increases plus things like AVX512 & FMA means they have been scaling similarly to GPUs over the past 10 years or so.

Nice analysis here (URL says 2013 but he has updated his numbers to end-2016). Looking at the graphs, you might even conclude that CPUs are improving faster in some respects.

[https://www.karlrupp.net/2013/06/cpu-gpu-and-mic-hardware- ch...](https://www.karlrupp.net/2013/06/cpu-gpu-and-mic-hardware- characteristics-over-time/)</comment></comment>


Android 4.1 Jelly Bean: 5 Features We Want in Google's New OS - <AUTHOR> http://www.wired.com/gadgetlab/2012/06/things-want-android-4-1-jelly-bean/

<comment><AUTHOR> A lot of the ideas in this article seem to be inspired by iOS. I wonder what the patent situation around them is.

<comment><USER2> I've seen articles about wanting iOS 6 to have some Android features as well. It seems most writers can't think beyond "getting the extra features the other OS has".</comment></comment>


Seriously, why is software so hard for non-software companies? - <AUTHOR> http://pandodaily.com/2013/06/27/seriously-why-is-software-so-hard-for-non-software-companies/ <comment><USER2> Interesting article. One thing I've found working with tech and non-tech companies is that the tech companies generally talk more in absolutes (truths) while non-tech companies prefer to talk in assumptions (this is how it always worked).

In my opinion the biggest challenge of working with non-tech companies on a budget (time/resources/cash) is to get them to commit and consider all the consequences (ea. edge cases) during software design. They tend not to get that programming is the act of implementing a (designed) solution and not a method of solving problems.</comment>


It's so cold in Chicago, crews had to set fire to commuter rail tracks - <AUTHOR> https://jalopnik.com/chicago-is-so-ridiculously-cold-that-the-railroad-track-1832177510/ <comment><USER2> >When it gets to be several degrees below freezing, the metal of the train tracks can contract to the point that it will pull up the bolts holding it in place, or even stress fracture.

This is bad reporting. This is nothing new, and happens every winter. It is only necessary to manually light them up with a kerosene soaked rope when repairing a piece of track.

As should be obvious, below-freezing temperatures happen every year in Chicago, and train tracks need to be repaired even in the winter.

<comment><USER3> That doesn't say it's new, or that it doesn't happen every winter.

<comment><USER4> The way the headline is worded, along with the fact that it's a headline in the first place, implies that it's an unprecedented thing, even if the article doesn't go out and state it.

Had they wanted to, they could have come up with a much less linkbait-y way to talk about how track maintenance works in the winter.

<comment><AUTHOR> Everyone outside of the areas where it gets cold enough for this to happen... I found it fascinating. Hacker news is partly about hacking a problem to find a solution and it seems this is a good hack. It's click-baity but you can imagine yourself in the shoes of the original person looking at the problem and going through the steps until they figure out that it can be solved by burning a rope... it is interesting.

</comment></comment></comment></comment><comment><USER5> Just a note, there is a difference between setting fires manually to tracks and permanently installed switch heaters:

[https://metrarail.com/about-metra/newsroom/the- signal/fighti...](https://metrarail.com/about-metra/newsroom/the- signal/fighting-fire-switch-heaters-2)

<comment><USER6> But that isn't nearly as exciting of a clickbait headline as "setting fire to railroad tracks on purpose".

I would be interested if any Metra folks could chime in as to why induction heat isn't used instead of open gas flames.

[https://patents.google.com/patent/US5389766A/en](https://patents.google.com/patent/US5389766A/en) (rail snow-melting by electromagnetic induction heating)

[http://indheater.com/](http://indheater.com/)

[https://www.youtube.com/watch?v=wpQi0DEcGWs](https://www.youtube.com/watch?v=wpQi0DEcGWs)

<comment><USER4> The induction heaters you're linking are designed to be permanently installed. They're perfect for switch heating, but probably not a cost-effective option for maintenance work. You'd need to have the heaters installed very close together over the entire length of the track, and the likelihood that any one of them actually needs to be used to heat the track for repairs would be very small.

A portable option might be possible, but then you'd have to mess with batteries or generators or something to provide the power. Ropes soaked in kerosene sounds to me like the "the cosmonauts used a pencil"† option.

† (Yes, I know that this is an urban legend.)

</comment></comment></comment><comment><USER7> Are there alloys that don't have this level of thermal expansion/contraction that could be used instead?

<comment><USER8> There are, but the cost of building thousands of miles of rails out of it would be incredibly prohibitive.

<comment><USER7> Ah yep, I meant alloys that are reasonable to use for rail, including cost restrictions.

I had heard that the TGV has welded rails rather than expansion gaps, which necessitated a low-thermal-expansion alloy. But I don't anything about it beyond that.

</comment></comment></comment><comment><USER9> This is good though, right?

In the UK the points regularly freeze at even just a couple of degrees below zero, and the trains are just cancelled.

</comment><comment><USER10> >as a smart race of human beings, still have to resort to medieval methods of re-warming metal train tracks

Drinking water and eating food to stay alive is so outdated you guys. Groceries don't even have touchscreens.</comment>


Babies On Display: When a Hospital Couldn't Save Them, a Sideshow Did (2015) - <AUTHOR> http://www.npr.org/2015/07/10/421239869/babies-on-display-when-a-hospital-couldnt-save-them-a-sideshow-did <comment><USER2> That's the most heartwarming NY "hustle" story I've ever heard. Working long hours at a carnival, in the NY summer heat, pre-air conditioning (he started in 1896!) to save thousands of lives for no recognition. He did this for half a century, and for no profit either: he provided free medical care to the parents!

This man is a damned hero. Stories like these are why I could never sympathize with eugenicists, who prevented incubators from being introduced in hospitals until the 1940s.

<comment><USER3> Although no one uses eugenics to justify it anymore, there are still plenty of infants who are allowed to die because of severe birth defects that prevent mental development or give a high risk of early death. The moral situation arguably has greatly improved, but the difference between then and now is not nearly so clean cut.

<comment><USER4> That's a different situation, isn't it?

I mean, it depends on the specifics, but if you have someone who'll never reach even the intelligence of a cat... It's hard to justify their life on ethical grounds, when effectively "they" don't exist. Maybe that wasn't the situation you had in mind.

<comment><USER3> Most people don't value human life in proportion to intelligence. You can certainly construct an ethical framework with various thresholds, but my point is that the actual rules in place today reflect a regulatory equilibrium rather than a self-consistent moral philosophy. Most sensible philosophies will consider at least some modern accepted practices to be morally reprehensible.

<comment><USER5> > but my point is that the actual rules in place today reflect a regulatory > equilibrium rather than a self-consistent moral philosophy

I guess since people's morals are so varied, it's too hard to agree on a self- consistent moral philosophy. As an extreme example, just look at cases where people will ensure the right for a child to be born, but then not ensure rights to continuing health/nutrition/education. Beyond outliers like that there's a spectrum of every kind of opinion

<comment><USER3> Under that logic, we'd stop saving the lives of the homeless in ERs unless we also gauranteed their health and education.

<comment><USER5> Makes sense to me. Why save someone's life if you're going to kick them right back out onto the street to die in some alley again?

You may not be surprised to hear I'm from a country with a strong social safety net (which I guess works because there is more consensus on life over liberty)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I hope I wasn't the only one who thought for a moment that this was talking about a startup incubator. Even though that wouldn't have made a whole lot of sense.

<comment><USER6> The title was "Incubator pioneer funded his work by displaying premature babies at a carnival" before it was changed.

<comment><USER7> I read the current title, "Babies On Display: When a Hospital Couldn't Save Them, a Sideshow Did (2015)" as slideshow instead of sideshow!

<comment><USER8> That'd have to be one hell of a PowerPoint!

</comment></comment></comment></comment><comment><USER9> Context: [https://www.amazon.com/Black-Stork-Eugenics-Defective- Americ...](https://www.amazon.com/Black-Stork-Eugenics-Defective- American/dp/0195135393) [https://en.wikipedia.org/wiki/Harry_J._Haiselden](https://en.wikipedia.org/wiki/Harry_J._Haiselden) "Harry John Haiselden (March 16, 1870 – June 18, 1919) was the Chief Surgeon at the German-American Hospital in Chicago in 1915 who refused to perform needed surgery for children born with severe birth defects and allowed the babies to die, in an act of eugenics."

</comment><comment><USER10> We changed the URL from [http://www.npr.org/sections/thetwo- way/2017/02/25/517221933/...](http://www.npr.org/sections/thetwo- way/2017/02/25/517221933/lucille-horn-who-was-nursed-to-health-in-a-coney- island-sideshow-dies-at-96) by the submitter's request. The two articles are closely related of course.

</comment><comment><USER11> I was not expecting "sick babies displayed at carnival sideshow" to be a wonderful, heartwarming story.

</comment><comment><USER12> This is a lesson in shifting morals, and brings to mind a discussion I had that for me puts the nail in AI, modelling rational systems is 'easy', modelling systems that change over time is very hard, how would an AI's moral system keep in lockstep with the shifting whim of humanity ?

<comment><USER13> Speaking of morals, is it really moral to not promote and invest in kidney transplants rather than have the federal government pay for dialysis for 5+ years before a person dies (due to the failed kidneys usually)?

We could easily get most people off Dialysis, and allow them to live much healthier and longer lives if we allowed patient collectives (akin to Iran) to reward donors with cash and healthcare for the rest of their lives.

Why do we choose to let this chunk of our population die slowly and at great expense, rather than do a (relatively) inexpensive & safe transplant? Seems twisted and sadistic on society's part to basically tourture this segment of the populace.

<comment><USER14> That's the first step on a bad road.

Step 1: Reward volunteer donors with cash, healthcare

Step 2: Reward 'volunteer' donors with welfare, housing

Step 3: Reward 'volunteer' donors with reduced criminal penalties

Step 4: Reward 'volunteer' donors with reduced prison sentences

Step 5: Make donation a compulsory sentencing option

Step 6: Compel criminals to donate _both_ kidneys

Now you're China.

<comment><USER15> Ha! Fun game. We can make up junk and make anything look bad! How about:

1: go to church

2: compel others to go to church

3: lock the doors and burn the place down

<comment><USER14> What you're missing is that China is _already_ executing prisoners in order to harvest their organs. This isn't hypothetical. So anyone who wants to advocate for selling human organs for transplant need to address how to avoid abuse of powerless victims who may be compelled to donate.

<comment><USER15> Speculative? They're using kidneys from prisoners, once they are executed. To turn around cause and effect is disingenuous. You can guess that that may be happening; to state it as fact is quite a stretch.

</comment></comment></comment></comment></comment></comment><comment><USER16> My great-aunt was one of the Coney Island babies. She's not dead yet, last I heard.

<comment><USER16> BTW - I just confirmed that she is alive and well with my Uncle.

</comment></comment><comment><USER17> Pictures of the carnival stand at different times:

[http://www.theblaze.com/wp-content/uploads/2014/11/Infant- In...](http://www.theblaze.com/wp-content/uploads/2014/11/Infant-Incubators- building-at-1901-Pan-American-Exposition.jpg)

[http://www.neonatology.org/pinups/ConeyIslandBooklet1.jpg](http://www.neonatology.org/pinups/ConeyIslandBooklet1.jpg)

[https://ichef-1.bbci.co.uk/news/720/cpsprodpb/D28F/productio...](https://ichef-1.bbci.co.uk/news/720/cpsprodpb/D28F/production/_89730935_976549_martincouneybabyincubatorexhibitentrance.jpg)

</comment><comment><USER18> I think about this story every time I hear "Goodbye My Coney Island Baby" and imagine someone serenading an infant in an incubator in 1920.

</comment><comment><USER19> this seems applicable to libertarianism

</comment><comment><USER20> Couney used Coney to incubate his incubators!

<comment><USER21> Couney hacked Coney to incubate his incubatores</comment></comment>


It's not too late to learn how to code - <AUTHOR> http://www.jeanhsu.com/2011/10/16/not-too-late-to-learn-how-to-code/ <comment><USER2> I saw my first Unix prompt two years ago, nested inside of this editor called "Emacs." In my 23 years I had only programmed conditionals in Excel, and now I was responsible for using this system to maintain some of the most important econometric models in the world.

Fast forward to present day, where I'm writing linear classifiers in a Lisp dialect I had never seen before this weekend. I've previously built scrapers in Python, a website with Django, side projects with a bunch of technologies (R, JS, SQL, Redis, MongoDB, etc. etc.). I enjoyed working on all of these enough to start a graduate program in CS.

People start writing, running, painting, and working on other awesome trades at all ages. Coding shouldn't be any different. Click on pg's link to Codecademy, go check out MIT's introductory CS courses on OpenCourseware, and don't worry about how old you are!

</comment><comment><USER3> I always chuckle when anyone says, "It's not too late to..."

It's never too late to do _anything_.

And it's never too late to get good at almost anything, especially programming.

My story:

      Age 21 - graduated college
      Age 23 - graduated graduate school
      Age 24 - got my first job programming
      Age 24 - touched my first computer (that's right)
      Age 27 - touched my first personal computer
      Age 30 - purchased and set up my first personal computer
      Age 31 - wrote my first framework
      Age 32 - did my first start-up
      Age 36 - did my second start-up
      Age 46 - build my first web page
      Age 50? - wrote my millionth line of code
      Age never - got as good as I wanted to be
      Age always - loved it!

A few other thoughts about OP:

 _It's easy to think that it's too late, because look at those people who spent four years in college learning to code!_

Don't look at anyone else. That's your problem. Just look at the problem at hand and your approach and solution. It's just you and your computer, mano-a- mano. Pretty primitive. That's when you stop worrying about the negatives and just go ahead and build something. And that's when you know nothing else really matters.

 _It is difficult!_

Not really. Difficulty is relative. Start out by copying a "Hello World" program and getting it to run. Then add one new capability and get that to run. Then another. Then another. Always saving your last good version so that you can go back and start each step over, just in case you really fudge things up. Hey, you're programming! It wasn't that hard, was it?

 _I used to think I was cursed, because every time I tried to setup something new (new development environment, tool, library, etc), something would always go wrong._

There's a difference between systems administration (which all of this is) and programming. I hate the former (which I view as a necessary evil and takes 1% of my time) and love the latter (takes the other 99%).

 _Do you like it? ...do you feel a rush of excitement?_

Yes! Nothing else I've ever done gives quite the same feeling as experiencing something I've built working for the first time ever. Happy dance!

<comment><USER4> Yup. It's only too late if you don't want to do it in the first place.

While I started programming at 13, I didn't become a pastor until age 40. I suppose I could have said that I was too old to add such a different activity to my life, but I wanted to do it and dove in with enthusiasm. Was it difficult? Yes thank you. It's a small congregation and I still have to work the day job as a programmer, but coming up on five years now and we are close to doubling the original size of the congregation (was just over twenty people). It's the best job I've ever had and my dream is to eventually go full time ... just gotta get Ramen sustainable!

</comment></comment><comment><USER5> Not to argue with the sentiment -- you can and should always learn new things -- but I wonder... How true is it?

In linguistics, the conventional wisdom is that native-language acquisition is fundamentally different from non-. Anyone besides a small child will quite likely _never_ develop native fluency in a new language, no matter how long they speak it.

I often feel that way about programming-- I started learning C at an incredibly young age, and while I sure wasn't very _good_ at it, I do think it patterned my brain somehow.

I get the sense when I work with other developers, people who learned to code in their teens or twenties, that there's something different going on. They're fluent in the language, they probably know more about it than I do, but they're _thinking_ differently. I'm certainly not a genius or a savant, I've never taken a programming class in my life that taught me something, and I don't brag about my code, but I often experience a near-effortless acquisition of new languages, styles, even paradigms that other, talented devs seem to struggle with. I'm sure there must be many other people out there who share this experience.

So this is just speculation, but is it possible there's some underlying aspect of code- _thinking_ which, sadly, it _is_ too late to learn?

<comment><USER6> I am not a linguist, but I have been working on learning Portuguese, and based on what I read the conventional wisdom among laymen is that native language acquisition is different for children, but the research actually shows the opposite. The only thing I've seen research suggest children are different at is accents. Furthermore, I think many of us know Americans who immigrated in their teens and have been here for a long time and really are indistinguishable from native speakers.

I also am highly skeptical of your claim you are more native in programming, but I started when I was in my early teens so I'm not sure I can comment.

I think your skill at learning languages rises when you are very young, and you face diminishing returns after that, so adults never get that much better at learning a language than when they were young. With other things you begin later in life, you start at the bottom of the learning curve and improve much more. So adults and kids are usually about as good at language learning, unlike most things, so people think kids are magically gifted at learning languages because they are about as good as adults. And of course, adults are actually much better because they already know all the real world concepts from their L1. I've also seen it asserted many times that children learn languages faster, and I've only seen research supporting the opposite, so I think your claim is just the programming version of that fallacy.

<comment><USER5> I'll believe you've seen people saying that kids learn languages faster, but I'm not :) There's a lot of research both ways, and second-language acquisition is very similar to first-, but there's definitely something different going on or we wouldn't have any idea how a baby can learn a language starting from knowing none.

There's also solid evidence that learning two or more languages as a child, while being slightly slower, sets you up better to learn more as an adult, as well as just making you a cooler person overall.

That aside, though, I share your skepticism. I was just relating my experience, and hoping maybe we could, you know, have a conversation about it :)

</comment></comment></comment><comment><USER7> I didn't start really learning to program in earnest until I was 31. I got my first internship the month before I turned 32, and was hired as a full-time programmer 6 weeks ago making nearly double what I had been making in PR (not to mention actually enjoying my work).

It is indeed never, ever too late to program.

<comment><USER8> How did you get an internship at that age? Was it fresh off a grad program or through networking? Which languages do you use?

<comment><USER7> No I have no degree but am in school for CS. I had met the hiring manager a few times at the local Python meetup and given a couple of small talks on Python tools like Fabric. He gave me a shot via internship based on that and the relative strength of my github repo.

That, and there's a serious shortage of programmers around here.

</comment></comment></comment><comment><USER9> <http://codecademy.com>

<comment><USER10> <http://codeschool.com>

<comment><USER11> I would add to the ad(d)s here ;-) , become a mentee to || code with other good programmers. Preferably ones with humility / kindness as much as skill. Changes your life. Its like guitar.. you've got to find mates to jam with.

And read lots of different code from low-level to SICP.. from early 80s to the present day. Get ( legit ) access to closed, commercial code as well.

Also, its really weird, but learning in these sorts is rather non-linear.. you will feel like there is no hope for 10 months, then the 11th month comes and suddenly you are freaked out about what you can do.

</comment></comment></comment><comment><USER12> People need to a good place to start and a map of how to continue. These are almost never provided together.

<comment><USER11> That is an exceptional aphorism. Very true. I've not even checked the parent link yet, but now will do so given this comment.

p.s. there is an additional "to" that you can drop, then its perfect.

</comment></comment><comment><USER13> That first line ("Coding is sort of like a superpower; with it you can create things that millions of people see.") exactly nails it for me. That's what made me switch about fifteen years ago: I was a geographer (of all things :) with a Master's degree and I was working for a research company. And then I met the internet and instantly knew that I wanted to be building stuff there. So at the tender age of thirty I did my first little scripts. Today I like to think am a pretty seasoned web developer with lots of projects under my belt. I could never ever beat the hardcore coders at the company I work for (I'll always be the allrounder) but I have not regretted learning code for one day. To be able to make something out of almost nothing and publish it all by yourself is simply wonderful.

</comment><comment><USER14> I have always struggled with coding even though my University major was CS.

I feel like I'm missing so many basics, like a major 'a-ha' moment. I've done the codecademy & codeschool tuts, the MIT and Stanford online courseware and built a few bits and pieces.

When I build things I just sort of hack it together from whatever resources I have available. I've got no idea of how to build robust systems from scratch.

I still don't feel even remotely capable. I think spending time with established (and patient) coders would be really useful.

Even just videos of folks explaining what working environment they have set up for themselves, some good practices and how they leave projects ready to work on again would explain so much.

I want to balance the enjoyment to frustration ratio out a bit more! :)

</comment><comment><USER15> Programming can seem really daunting.

It feels like the bits in portal where you find a crack in the shiny polished walls & go exploring in the grungy maintenance areas outside. There isn't anyone guiding your hand anymore (for good or ill).

If your program doesn't work (or you can't even install the programming language to begin with) you are often left with arcane, generalised instructions or nothing at all. There's no button you can click that will fix buggy program logic & sort out your unique mess of dependancies.

You need to be able to thrive outside the comfy embrace of the user ecosystem, & it can be scary out there ;)

</comment><comment><USER16> I think what bogs down many non-coding people is getting stuck on a problem for perhaps tens of hours before figuring out a solution does not appear to be worth it in today's age of instant gratification (especially if you're in a time limited situation, where you only have 2-4 hours of "free" time each day.

</comment><comment><USER17> That does make sense but doesn't solve the problem. Why don't they learn to code is not that it will take them long to learn. But what boggles them down is the fact that it will take them long before they can reach where they anticipate to.

If only one could _sell_ them the joy of coding.

Of course they are forgetting that it's fun right from step 1. (Read: The Joy of Building)

Learning to code is like learning to write. You can do without it but learning it opens a new world for you. Time to write "Ruby / C / XYZ for babies".

</comment><comment><USER18> It depends on the situation.

At 32 I took CS101 at a local university, never had the money to go before so my first time in Uni, first formal programming training and felt like I was 1,000 years older than my classmates.

I had to drop out do to work problems (laid off), money problems and just the level of stress from the social part of it. Each day I was soaked when I left class I was so nervous just being in that environment I felt like I had just run marathon.

Probably at least twice per week I was in the professor's office getting help. Years later I learned most people in class just copied samples off the Web, some assignments I handed in practically blank after being up until 4am trying to figure it out then have to go to work at 7am.

My mark was 60% for the first part of semester that I completed.

I haven't touched Java since then but I did like it maybe a different environment would have been better.

</comment><comment><USER19> All very encouraging, good comments, but I disagree.

Its easy to 'code', harder to design, debug, structure, deconstruct, architect.

So sure, code away, make that webpage or service. But you know who's creating the ecosystem you're 'coding' in? Somebody that started as a kid, dedicated their life to computers and software, lives and breathes multiprocess automata or whatever.

So everybody is right, sure, and there's lots of money to be made in coding so don't be afraid to jump right in. But like athletics or physics or whatever, either be a savant or study all your life, but don't fool yourself.

<comment><USER7> Don't fool yourself about what? That it's never too late to learn to program? I don't really understand the significance of who created the "ecosystem" I program in. What's an ecosystem, to you? Why does it matter who created it?

I don't get your point but it sounds vaguely insulting.

<comment><USER19> I find it explicitely insulting to claim 'programming isn't all that hard; anybody can do it'.

Its Pollyanna to say "you can be a programmer! Anybody can!" without explaining the layers of the onion. You can be a (passable) applications programmer with a little effort. The rest takes sweat and study, sometimes years of it.

</comment></comment></comment><comment><USER20> Two outstanding books that will help anyone get started regardless of whether they have any coding background are Learn Python the Hard Way by Zed Shaw, and Land of Lisp by Conrad Barski.

<comment><USER21> Learn Python the hard way is available online for free, or you can buy it. (<http://learnpythonthehardway.org/>)

Here's the link for Land of Lisp. (<http://landoflisp.com/>)

</comment></comment><comment><USER22> I've always admired people who started late in life and went on to succeed more than child prodigies. I guess this is a biased opinion as I never truly fell in love with programming until my last year in college. Now I'm trying to make up for time lost (slacked my way to a diploma) by having a study and coding regimen outside of work, taking online and offline classes. I'm also testing the theory that a skill can be learned and mastered with enough discipline and correct feedback by taking up piano (never touched an instrument before in my life) and art. Hmmmm... sounds like a good idea for a blog...

</comment><comment><USER23> I've been a front-end developer for many years now and lately I've been considering learning a programming language. I learned html/css first and focused more on learning design softwares to improve my designs.

But the problem now is when I have an idea for an app, I can't develop it since I don't know any back-end language. I have developers I work with but they don't have the time to develop my little ideas. My JS is also weak. I'm 23, I don't think I'm too old to learn but it would have been easier a few years ago.

I think the problem for most people (including me) is constantly thinking of how long it would take to reach mastery.

</comment><comment><USER24> I first started learning programming with java/android 2 years ago. It took full 1 yr (3 hrs per day, since i also had a full time job) for me to understand the IDE, Object model and of course the android framework.

After the initial brush up with a language your coding potential will be increased exponentially. I build a iOS app, XNA game within next 1 year, and Currently in the process of creating a web application on rails.

</comment><comment><USER25> Great post. I started at 28. Wrote my first DB driven site at 29. Now 30. With 9 out of 10 ideas that come to my head, my first question is no longer "Who will build it for me?", but "How long will it take me to do it". The last idea is something I just know I won't be able to code.

</comment><comment><USER26> I think most of the anxiety comes from expecting the results very fast. In this fast pace lifestyle, reaching a goal, like learning a programming language is not a craftsmanship challenge but a huge motivational and focusing challenge.

</comment><comment><USER27> Code hero is pretty amazing (primerlabs.com). Alex has managed to leverage Unity to create a 3d game to teach programming.

<comment><USER28> Krazy koder ( <http://www.krazykoder.com> ) is a great way to learn programming by making games online.

</comment></comment><comment><USER29> As good as it is to learn to code, much as is the case with any situation where you'd normally hire a professional (doctor, lawyer, accountant) don't kid yourself that you know everything once you can sling some code.

A good example would be how terrible the code the Google Founders wrote. Their initial engineering hires had to rewrite everything from scratch.

And the Google Founders _did_ have a background that would lend well to coding.

<comment><USER30> A lot of web apps are very basic from a development point of view.

Sure you need a doctor if you are very ill, but plenty of people can self- diagnose smaller problems using the internet.</comment></comment>


Human-AI Partnership for Mixed-Initiative Fact-Checking [ACM UIST] - <AUTHOR> http://fcweb.pythonanywhere.com/ <comment><AUTHOR> _Believe it or not: Designing a Human-AI Partnership for Mixed-Initiative Fact-Checking An T. Nguyen, Aditya Kharosekar, Saumyaa Krishnan, Siddhesh Krishnan, Elizabeth Tate, Byron C. Wallace, Matthew Lease_ (UIST '18: ACM User Interface Software and Technology Symposium Session: Crowds and Human-AI Partnership)

Abstract: Fact-checking, the task of assessing the veracity of claims, is an important, timely, and challenging problem. While many automated fact-checking systems have been recently proposed, the human side of the partnership has been largely neglected: how might people understand, interact with, and establish trust with an AI fact-checking system? Does such a system actually help people better assess the factuality of claims? In this paper, we present the design and evaluation of a mixed-initiative approach to fact-checking, blending human knowledge and experience with the efficiency and scalability of automated information retrieval and ML. In a user study in which participants used our system to aid their own assessment of claims, our results suggest that individuals tend to trust the system: participant accuracy assessing claims improved when exposed to correct model predictions. However, this trust perhaps goes too far: when the model was wrong, exposure to its predictions often degraded human accuracy. Participants given the option to interact with these incorrect predictions were often able improve their own performance. This suggests that transparent models are key to facilitating effective human interaction with fallible AI models.

video: [https://www.youtube.com/watch?v=3GDA3jSzRgs](https://www.youtube.com/watch?v=3GDA3jSzRgs)

DOI: [https://doi.org/10.1145/3242587.3242666](https://doi.org/10.1145/3242587.3242666)

PDF: [http://www.cs.utexas.edu/~atn/nguyen- uist18.pdf](http://www.cs.utexas.edu/~atn/nguyen-uist18.pdf)

code: [https://github.com/thanhan/uist18](https://github.com/thanhan/uist18)

author: [https://www.cs.utexas.edu/~atn/](https://www.cs.utexas.edu/~atn/)</comment>


Does AngularJS really go well with Node.js/JS versus others? - <AUTHOR> http://voidcanvas.com/describing-node-js/

<comment><AUTHOR> By others meaning(Ruby, Python Java etc) for real time, concurrency type of capabilities? Or am I terribly misinformed? I dont have Node experience but Ruby seems not too easy to put together with AngularJS.

I understand Node.js's primary con is the usage of multiple CPUs. However my understanding of backend is not as good. This article also talks about difficulty with relational databases? Can someone explain it better or correct it if the link is wrong?

Wish to hear your experiences (both sides) dealing with Node.JS and other parts of your stack as a whole. Please feel free to rattle all you wish, I will be happy to hear more about them.

</comment><comment><USER2> > 1\. Node.js doesn't provide scalability. One CPU is not going to be enough; > the platform provides no ability to scale out to take advantage of the > multiple cores commonly present in today's server-class hardware.

[https://github.com/Unitech/pm2](https://github.com/Unitech/pm2)

> 2\. Dealing with relational database is a pain if you are using Node.

[http://sequelizejs.com/](http://sequelizejs.com/)

</comment><comment><USER3> > _2\. Dealing with relational database is a pain if you are using Node._

Can someone explain why ? (I'm not using node)

<comment><AUTHOR> Yeah this is the part Im confused too. And when you think about JS and JSON ...messy.</comment></comment>


School project showing the amount of sugar in beverages - <AUTHOR> http://i.imgur.com/pzqfmru.jpg?1 <comment><USER2> This image is being shared a lot lately, don't know its origin, but I want to note, that before people jump to assumptions, please be careful to remember, that sugar is not always, in its natural form, most of the times, it is in complex compound forms, forming with other ingredients.(see the article on coke for 2 days ago that made it to HN frontpage)

also, a just way of reading this, is that if you start counting how many carbons and hydrogen atoms are inside human body, it would sound silly. The same thing goes for sugar here.

<comment><USER3> What are you talking about? Glucose and fructose is all you'll find. It might be sucrose, but it is all the same by weight and effect once it hits your stomach.

<comment><USER2> I'm talking about neutralization effect, which is caused by anti-nutrients. sugar compounds, based on its form is digested differently and have different effects.

Like a famous case is fibre in food, disallows the benefits of zinc.

You might want to check this: <http://www.britannica.com/EBchecked/topic/571880/sugar>

Additionally, how you can also see this is, the difference in sugar concentration, means that though the amount is large, it is still not the same. sugar is a very broad term, as you may find from the above article.

If this is a genuine school project, that it is good for that general age.</comment></comment></comment>


Paul Graham, Please Start a YC Podcast - <AUTHOR>

<comment><USER2> I have a better idea. How about a reddit/digg style podcast channel on YC News where users can submit links to mp3s, and the community upvotes them. And then YC offers the top 10 as a podcast feed so you can automatically download them.

mp3s can be on startups, tech, entrepreneurialism etc.

<comment><AUTHOR> I think thats a great idea. I am just so hungry for good podcasts and I go through them by Wednesday every week. If they can do jobs, podcasts should be easy.

<comment><USER2> Yes I love some of ITConversations (or whatever it's called now), but it's like drinking from a firehose. I only want to the best ones.

We could also chuck in some classic ones like classic ones on Dr Dobbs etc.

<comment><AUTHOR> I also want more startup/business related podcasts instead of straight up technology podcasts

<comment><USER2> Yes! One I like to listen to is Venturevoice.

<comment><AUTHOR> I like Venture voice, but they haven't had a new podcast in months and I have listened to every single one of their podcasts.

</comment></comment></comment></comment></comment></comment><comment><USER3> Sorry, podcasts are not my kind of thing. Jessica Livingston is about to start a blog, though.

<comment><AUTHOR> I think podcasts and essays are close. Podcasts are just more efficient....

Not even for the founders dinner speakers? Looking Forward to Jessica's blog. I am about to finish her book.

<comment><USER3> We could never record the speakers. Dinners are off the record so that speakers can say things they would never dare to say publicly.

<comment><AUTHOR> Makes sense. I am just so hungry for information and tired of reading.

Are you writing a June essay?

<comment><USER3> Actually I've been working on News.YC lately. And advising 19 new startups. I can just about remember what they're each working on...

<comment><USER4> Think you're getting close to the upper limit of startups per session?

<comment><USER3> I felt that way at the first dinner, but things are under control now.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I think a podcast by the YC partners would be cool too.</comment>


Python 2.x vs 3.x use survey - <AUTHOR> https://www.surveymonkey.com/s/N5N5PG2 <comment><USER2> For Mercurial, this is the biggest problem with Python 3:

[http://bugs.python.org/issue3982](http://bugs.python.org/issue3982)

They got rid of format for ordinary strings, and since we have to use bytestrings for handling hg's binary format, converting back and forth with .decode and .encode just to get the formatting is a lot of work.

The Python devs have actually acknowledged this use case and apologised to hg. Kinda weird, considering how Python itself is hosted with hg. :-/

<comment><USER3> Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?

<comment><USER2> Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.

<comment><USER3> Mercurial is a big project. Surely there's _one_ skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code- path, that's _normal_ development for great performance.

I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple _problem_ , which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.

<comment><USER2> It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings _everywhere_. And again, it's a lot of work with no huge payoff.

<comment><USER3> > _It 's more work than it appears._

I completely believe that, and good point about Python 2. I wasn't considering that side of things.

Is it a _complicated_ rewrite, or just _big_? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)

<comment><USER2> Come join us in #mercurial in Freenode or in firstname.lastname@example.com if you're interested in solving this problem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> "Do you think Python 3.x was a mistake?"

That's where I stop filling out the survey.

And that's the python community biggest problem. Moving forward, everyone needs to pick a version (and I'd pick 3). A new user just sits and spins his head. Even the training materials are all over the place.

<comment><USER5> I think that's a very significant question. I would guess that 50%+ of Python users don't use Python 3, and thus would be counted as anti-Python-3, if not for that question which allows them to say "I don't think Python 3 is inherently a bad idea."

It would be nice if the question were more specific and more positive, but the survey would be worse if it were simply taken out.

<comment><USER6> It's way way way higher than 50%, if my sample is accurate.

I've been teaching Python in China, Europe, Israel, and the US for years. In the last four years alone, I've taught about 2-3 Python courses (usually intro, but sometimes advanced or on specific topics) each month, at companies like Apple, Cisco, Intel, and SANDisk.

In only one case did a company ask me to teach them Python 3. The rest of them ask specifically for Python 2. In some, more advanced and unusual cases, they ask me to describe the changes that will happen in Python 3. They all have legacy code in Python 2 that they cannot imagine upgrading, mostly because there are libraries (internal or external) holding them back -- and the benefits aren't obvious.

(I should note that almost none of my courses are at startups. So it's quite possible that I'm seeing a sample of large companies, which are inherently more conservative than smaller ones.)

I thought that the survey was fine. But really, there's a problem in the whole Python 2/3 split, and while I've convinced myself over the years that people are switching, I've rarely met any of them. Which is really too bad.

<comment><USER7> Being a newbie at Python myself and seeing how much the Python devs are trying to get people using Python 3, I was initially planning on just using Python 3 for all my Python coding. That was until I realized how many libraries exist only for Python 2.

</comment></comment></comment></comment><comment><USER8> Dear Apple. Please include python 3 as /usr/bin/python3 in all future Releases. And Microsoft, if you're listening, it would be extremely sweet if you would install python by default as well...

<comment><USER9> Microsoft would prefer you to use PowerShell and Visual Studio. Python wasn't invented in Redmond.

<comment><USER8> Yes, well, that's why I said it would be sweet of them. You know, like, a grouchy old military dad taking his daughter to see Snow White. It may not he his choice of entertainment, but it's very sweet of him to take her. :-)

</comment></comment></comment><comment><USER10> The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...

<comment><USER11> > The biggest thing that drives me nuts about py3 is just that its repl > doesn't evaluate generators.

If by evaluate you mean "convert to a list", that's sensible, since a generator may or may not be safe to convert to a list. If you want a list, wrap the generator to a call to the list() builtin function, and, voila.

<comment><USER12> This. Not all generators can be converted to a list in a timely manner, seeing as infinite generators are supported.

</comment></comment></comment><comment><USER13> Only reason I still use 2 over 3 is that 2 gets the job done, is well supported and I don't see a big enough reason to move to 3. If 3 had a big performance increase, then maybe I would switch. Anyhow, I'll probably move to 3 at some point just because at some point more people use it (more code on the Internet in 3, more StackOverflow answers in 3 etc.)

</comment><comment><USER14> The survey is missing sets of answers for users who _rejected_ or moved away from python because they were turned off by the disconnect between core devs and the community when python 3 got released.

<comment><USER15> I can't say I understand this attitude. It's analogous to cutting off your nose to spite your face. Both Python 2 and 3 are actively supported, and there's a clear migration path defined. The migration isn't complete yet, but it's progressing at a development friendly pace.

I say this as someone still on Python 2.6 due to environment restrictions.

<comment><USER16> The migration is so difficult that you might as well migrate to a different language and solve the speed and memory usage issues while you're at it.

<comment><USER15> What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage?

Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or `<` operation) and feels a lot more like writing C than Python (not to mention its lack in the "batteries included" department).

Ruby? Same speed and memory "problems" as Python.

Perl? Faster, but its language design philosophy is diametrically opposed to that of Python.

Clojure/Haskel? Syntax and program structure are so radically different from Python there's no comparing them to Python3 when discussing differences from Python2.

<comment><USER17> I would actually pick Go. Yes, the strong static typing is a pain in the ass, but the rules are simple and regular. It's easy to understand and implement.

The same cannot be said for the multitude of changes to Python.

<comment><USER18> I use/used Go for a while, but early on I thought the type system was stronger than it was. I was disappointed in a later project, and started looking at languages with stronger type systems.

I came across Haskell and Hindley Milner ;)

I believe Haskell replaces Go for me and with some experience (when I can picture types in my head better) it will replace python as my go to dynamic language.

</comment></comment></comment></comment></comment></comment><comment><USER19> Missing a question. "Would you switch to python 3 if they brought back the print statement"

Edit: I really just like the statement for the interpreter, and IPython Notebook. To me the statement syntax feels less like programming, and more like using a computer.

<comment><USER20> Personally, I prefer function. I can understand that others have a different preference; what I find surprising is the number of people who seem to care _so much_ about this. Nevertheless, it is very evident that you are not alone.

<comment><USER21> I prefer it as well. Being able to do things like throw

        print(<SOMETHING I'M TRYING TO DEBUG>) or

into a lambda has been useful on multiple occasions.

</comment></comment></comment><comment><USER22> It would be nice if we could see the results

</comment><comment><USER23> Where are the real-time results? :)

</comment><comment><USER24> In my view, the importance of the 2 vs 3 issue depends on who you think the typical Python user is, and the user population may be changing rapidly.

I'm not a CSist or professional programmer. I use programming as a tool, typically to solve short term problems for myself or for a small circle of colleagues. When I started using Python, not too long ago, it seemed like I had discovered a secret productivity tool. A project manager asked me: "What's a Python?"

Today, Python seems to be everywhere. It's been taken up by curious characters such as scientists and hobbyists. It seems to be the lingua franca of the Raspberry Pi. My non-CSist colleagues are getting into it, and I don't think it's just because of my incessant evangelism. ;-) A great thing about Python is that you can use it at whatever skill level you happen to be at, by ignoring its advanced features until you need them.

I could switch from 2 to 3 today, but I'm lazy. I'd get bonked by errant print statements for a while, and probably not experience any other hurdles. I spend more time already, keeping up with the changes that I make to my own libraries.

</comment><comment><USER25> I may be old, but this just reminds me of Larry Wall's Perl 6 and in my opinion Python 3 should have been a hobby project / incubator for changes that could be introduced to Python 2 eventually.

</comment><comment><USER26> I'd also like to see the results. Curious, did you create this survey to see if there would be interest in a long-running Python 2.x fork?

IIRC the Python community was already expecting a fork to happen eventually (because 2.7 is the "final" 2.x release) so getting the community involved would be a good thing.

I would imagine that the purpose of maintaining 2.x would be for fixes, security, and back-porting of features that make it easier to have 2.x and 3.x-compatible code.

</comment><comment><AUTHOR> Results from this survey can now be found at

[https://wiki.python.org/moin/2.x-vs-3.x-survey](https://wiki.python.org/moin/2.x-vs-3.x-survey)

</comment><comment><USER27> A wise man once said, [http://www.aaronsw.com/weblog/python3](http://www.aaronsw.com/weblog/python3)

</comment><comment><USER28> I'm curious what the Python 3 adoption status is inside of Google, which I think of as a place that's relatively pro-Python, very pro-new stuff, but also possessing a lot of institutional inertia and giant amounts of code. Have parts of Google overcome the inertia and switched to 3? Do fights break out in the halls? Is it 2 forever and always?

</comment><comment><USER29> I don't think people realize how easy it is to run a Python2 and Python3 codebase at the same time if you have decent test coverage and run tox.

Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.

</comment><comment><USER30> I don't really have a strong reason to prefer 2.x, but I'm stuck on it as I mostly (exclusively) use Python on Pythonista for iOS.

But I'm fascinated by the debates over the merits of the two. Thanks for posting the survey!

</comment><comment><USER31> There was a dynamic graph somewhere showing the number Python 3 and Python 2 packages on PyPi against time, no amount of googling can find it, does anyone know what I'm referring to? I'd love that link.

<comment><USER32> Do you mean the wall of shame/superpowers?

[https://python3wos.appspot.com/](https://python3wos.appspot.com/)

<comment><USER12> From a cursory glance it seems like this may be somewhat inaccurate. It states NLTK doesn't support 3, when it definitely does.

<comment><USER33> The NLTK site says the Python 3 version is still alpha.

</comment></comment></comment></comment><comment><USER34> My only question is... does Gunicorn+Gevent work on Python 3 yet? Last time I checked one worked and the other only had a branch which you could use but wasn't in master yet.</comment>