About PayPal's Node vs Java "fight" - <AUTHOR> http://developer-blog.cloudbees.com/2013/12/about-paypal-node-vs-java-fight.html <comment><USER2> I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it.

Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and java's poor implementation of OOP ignored.

Heck, fork Spark, split out the individual pieces as modules, and start there.

All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte.

I'd argue that java is a better back end language than javascript in and of itself, but that the community norms have led to the pain we see.

Have an extreme preference for 1.8 code (IE, the new java.time system) and away from anything bloated. Rethink for the common use cases, rather than trying to support everything under the sun. Spring still exists for that, after all. :)

The problem with java isn't that it's a BLUB language anymore, but that it's a BLUB ecosystem. I'm not saying the language is perfect, but Java 8 as good as ruby or javascript for web development if the ecosystem is ignored.

<comment><USER3> You've basically described C#:

Getters, setters fixed? Check. Functional features? Check. Most crappy OO features fixed? Check. Trendy package system inspired by npm/apt-get/gems? Check. Healthy community with libraries replacing frameworks? Check.

I'd recommend checking it out if you haven't already.

<comment><USER4> The "libraries over frameworks" notion is something I keep noticing in communities that seem to be more engineering-minded than rock-star-ninja-dev- minded. Where do you think this comes from? I think it's a mix of maturity on the part of the community members along with how often the language is used to do things that are harder than CRUD.

<comment><USER2> In my case, I'm speaking of a reaction to Spring and Struts. I personally use Grails on my recent projects, which is as close to batteries-included as it gets, but I occasionally have problems with square peg round hole problems, and fighting against a framework is more painful than a library.

The problem with the framework is that we run into a steep hill when we must diverge off the path. A good framework gives a great story. Unit tests, integration tests, consistent layers, convenient and powerful ways to access the database without writing a giant SQL generator (if x return "and b.id = c.id" else return "b.name = "%" \+ name + "%")...

But then, you hit the use case that the framework didn't consider. And suddenly, you either need to extend the framework (never pleasant) or go outside the framework for one portion, which means building all of the tools from the ground up.

Or, more often, ignore testing, hack in the best way you know how, and hope nothing breaks.

The library approach means that you have to build the integration pieces yourself. This is painful, but it means that when you reach a new use case, it isn't as large a jump to keep going.

Each has tradeoffs. There are times when each is superior. Someone like Bob Martin would suggest that you build your system independent of frameworks and treat the web as a client/compatibility layer, and that you build your system of small composable parts so that the framework/library question is a minor one. (This has its own tradeoff with an abhorrent amount of plumbing code that comes along.)

It all comes back to the problem at hand and how we judge the tradeoffs, like most engineering problems.

<comment><USER4> Do you know of any shops that use Uncle Bob's approach (besides 8th Light, of course)? I don't; I wish I did. I agree that isn't something you'd use every time, but I feel there isn't a whole lot of data out there when people have used it. All I see online are devs whining about the extra work.

I don't know what it is about the web, but it's as if we decided all of software architecture didn't mean anything and threw it out. My theory: it's harder to feel coupling in a dynamic language, thus it's just an academic concern!

<comment><USER2> I have plans to try it in a side project. I too am skeptical about the rewards of setting up a CRUD system like that.

It isn't that we've decided that software architecture meant nothing; rather, we settled on one architecture that is Good Enough. The View/Controller/Domain paradigm of Rails works for many projects.

<comment><USER4> It won't be great for CRUD. It's really meant for applications that have a bunch of business logic to them...you know, the interesting apps.

Aside: "good enough" seems to summarize the web as a whole. This is both discouraging and a fact of life.

<comment><USER2> You can still have an interesting business logic system that is CRUD at its core. A case management system, as an example, is CRUD at its basis but filled with business logic.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I've had the misfortune of using the PayPal Java SDK to integrate PayPal credit card and Express payment into a web application. Based on that experience, I find it especially difficult to digest any opinion that PayPal has on Java. They may be experts on handling money, processing credit card payments, fraud prevention, and the like. (Or maybe not, given their reputation.) But their opinion on Java is about as meaningful to me as Microsoft's opinion on Java. Or more on point, a Rails developer's opinion on Java. Both are characteristically stale. And not "whew, that bread is really ripe, throw it out" stale. Rather, "what we have here is a new form of fungal life" stale.

I've worked with a fair number of Java APIs. I would put the quality of their Java SDK in the bottom 10%. It has the stench of _really old_ Java. Remember how the first Java APIs reeked of C? The fact that the PayPal Java SDK still looked like hastily ported C code in 2011 when I last worked with it makes me worry that their entire manner of using Java is stuck in the early 2000s. That's being generous. It's the kind of Java you'd expect to see written by a company that still thinks about "applets" and "beans" and tries to come up with clever coffee double-entendres for their package names.

My theory: PayPal is big but they know they are vulnerable. They've acquired BrainTree and that helps. I suspect they want to improve their technical chops and felt a _need_ to migrate away from Java in order to break free of their organizational quagmire. PayPal is from 1998 and if their Java SDK is any indicator, they probably have a Subversion commit log for their core systems going all the way back.

This sort of move is the kind of thing I could see myself doing if I were in a decision-making position at PayPal. Attempting to invigorate sensible modern Java practices within that organization would seem hopeless. I would have to start anew with an approach that is free of poisonous legacy.

As others have pointed out, the fact that a rewrite yielded _so little_ performance gain is decidedly troubling. At least they got a fun and well- linked blog entry out of it. If I had just gone through that effort and reaped such a modest improvement, I'd be crestfallen.

<comment><USER6> Whose Java SDK would you rate at the top 10%? I'm curious.

<comment><USER5> Just to compare apples to apples—by which I mean credit card payment APIs—Stripe's Java API is superior. I'd not say it's a thing of beauty, but then, I don't want a credit card payment API to be anything but immediately approachable and obvious. And it is precisely that. Easy to understand.

[https://stripe.com/docs/api/java](https://stripe.com/docs/api/java)

As for something I am happy with in recent memory, the Undertow builder model is appealing: [http://undertow.io/](http://undertow.io/)

But you ask a tough question. I've not spent much time thinking about the best of the best. I suppose part of it is that a great API gets out of its own way and lets you get to work. So I suppose citing Stripe's first may have been the right thing.

</comment></comment></comment><comment><USER7> Regarding the JVM performance:

> Under minimum load the best page rendering time was 233ms

Regarding the node.js performance:

> Under minimum load the best page rendering time was 249ms

What the heck are they doing that takes 250ms that could possibly be app code related? That's _a lot_ of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going to be mostly waiting for external resources (DB, message queue, etc).

Without knowing how much time is spent on those external requests these numbers are meaningless.

Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).

If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms ( _though you could increase parallelism of multiple requests if done right_ ).

<comment><USER8> > Language choice is no where near as important as your DB-access patterns > (and more generally DB performance, caching, etc).

I bet they have a really crappy backend storage system for account history/data.

We have a PayPal transaction history with a low 6 digits record count. Searching for a specific email address, name, or transaction ID can take literally minutes. Exporting a transaction history CSV takes hours.

<comment><USER9> It only gets worse from there.

When we exported a CSV of our transaction history there were entries missing. We knew this because each line has a running balance and it wasn't adding up with the line before it.

When we told our paypal account manager about this it triggered an investigation. They claimed they had never seen it before and they sounded very worried about it.

They then told us that they have multiple different databases with transaction histories and that they were not consistent. They said that they had investigated the problem and found that it affected only a small percentage of customers.

They then pointed us to another CSV export form that doesn't seem to be able to be accessed via the normal UI and were told that this one would give us correct results. Unfortunately we were unable to export an entire year at once with this form as it seems to have some kind of time limit.

We had to export our history in little chunks that would take hours each. We asked our paypal account manager to prepare the CSV for us after finding this out, but she refused.

Having a large number of transactions in paypal sucks very bad.

Compare this to Stripe that proactively emailed us saying that they had noticed that queries for filtered transaction sets were taking a very long time so they had done some optimizations and were asking us to see if it had improved.

</comment></comment></comment><comment><USER10> This was a good read. Minor nitpick, given the author's stress of not comparing apples to oranges I think the motivating anecdote on protein folding struck a dissonant cord. A fair comparison would have been a profile guided optimization with comparably aggressive compile optimization flags.

For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up time.

Java can indeed be very fast, and in my opinion JVM is the one of the most optimized VMs that we have now. That said Java code beating a C or a C++ code on a CPU bound task raised an eyebrow. In my experience Java usually gets to the 80% speed of C++ quite easily but at a cost of 2.5 to 3.5 the memory. For these types of applications memory tends to be an expensive resource. For our number crunching server, 80% of its cost is sunk in the RAM.

<comment><USER11> My experience is similar: Java will get you 80% of super-optimized-compiled C++ speed for the cost of more memory (although you may choose to give Java less memory and pay in speed), and will get much closer to C++ speed with some work (off-heap memory, etc.). However, Java has the upper hand in two scenarios: 1) long-running applications that are developed by a large team – those usually make heavy use of virtual inheritance for the sake of good engineering, and the execution profile is not static, so the program can greatly benefit from JIT optimization; and 2) fairly complex multithreaded code – Java's incredibly useful and well-implemented blocking and lock-free data structures, as well as an incredible work-stealing scheduler (all expertly programmed by Doug Lea) make great use of a general purpose GC, _plus_ Java usually gets them about 5 years before C++ (if C++ gets them at all).

<comment><USER12> Don't forget the tools and infrastructure that support good engineering (dependency management, build, javadoc, findbugs, checkstyle, PMD, cobertura for code-coverage, better unit-testing frameworks, the list goes on).

I'm sure C++ ecosystem has some of those but whether people are using them or not seem quite obvious: how many C++ projects do that out there? Not as many as the Java counterpart.

<comment><USER13> > how many C++ projects do that out there? Not as many as the Java > counterpart.

I'm not sure this is a good argument.

Projects where performance is critical are coded in C/C++ , not in java ( browsers , AAA games , databases , servers , micro-controllers , oses... ). C/C++ programming is not about writing 'elegant' code with FactoryFactories , but performances. Even if it means using very basic data structures instead of classes or inlining functions everywhere.

<comment><USER11> > Projects where performance is critical are coded in C/C++ , not in java ( > browsers , AAA games , databases , servers , micro-controllers , oses... ).

This is not true. C++ beats Java performance _in constrained environments_. On servers the situation is not so clear-cut. You see some really fast Java databases.

And BTW, Java is better at inlining functions than C++, but C++ handily beats Java when it comes to controlling memory layout (though that, too, is changing).

<comment><USER13> > This is not true. C++ beats Java performance in constrained environments

Every environment is constrained. Devs just got lazy and scaling now means buying more machines instead of performance optimisation.

> You see some really fast Java database

That eat up way to much memory for little.

When you see popular java based os , tell me.

</comment></comment></comment></comment></comment></comment><comment><USER14> Well-reasoned.

I've always found framework overhead and especially tech debt to be the largest contributors to performance issues. Especially when said frameworks have lots of ways to do things and they're not all the best way to do it.

Modern JVM development starts to look a lot like Sinatra -- you don't get a lot baked in, but you probably didn't need it anyways.

<comment><USER15> The biggest contributor to performance issues these days, from what I've seen, is synchronous code. The JVM can be blindingly fast at running your code, but when it hits a point where you make a database call or web services call that's implemented synchronously, it sits there, waiting, doing nothing. No amount of VM optimizations can increase of the speed of idling code.

This is why Node apps often out-perform Java apps despite running on a VM that's significantly slower. Node is pervasively asynchronous...it's baked into the DNA of the platform and almost all libraries follow that philosophy. And as organizations move to a micro-services architecture where one external call can result in multiple internal calls between systems, the need for reactive, asynchronous programming becomes all the more glaring.

That's where this critique, for me, fell down. It's spent too much time comparing the JVM to V8 and not enough time talking about how the applications being run were designed. Because CPUs are fast enough these days that any of the VMs will give you decent performance for workloads that aren't CPU-bound as long as you, the application designer, do the right thing. It's just that some environments, Node in particular, make it easier to do the right thing. This will get easier in Java with the introduction of lambdas in Java 8 and the inevitable asynchronous community frameworks and libraries, but right now it's still harder to write reactive applications in Java than it is in Node.

<comment><USER16> > _Node is pervasively asynchronous_

Personally I view that as a drawback. It's all fine, until you end up with CPU-bound tasks or until you end up talking with backend servers that don't support many concurrent requests.

The JVM support for multi-threading is absolutely stellar. You've got true 1:1 kernel-level threading, with no GILs and you've got access to the best primitives available for dealing with multi-threading issues, atomic references, re-entrant read-write locks, fork-join thread-pools, non-blocking data-structures, asynchronous I/O guaranteed to work well cross-platform, all of them backed by a guaranteed memory model that also works well cross- platform, plus garbage-collectors that are the most advanced garbage collectors in mainstream usage. G1/CMS are amazing for servers and if you've got cash to spend, Azure's pauseless GC is probably as close to real-time as you can get with a GC.

And on top of these you can build whatever concurrency handling architecture you want. Including Erlang-style Actors (e.g. Quasar, Akka), STM (Clojure, Scala-STM), persistent data-structures (Clojure, Scala), asynchronous streams (Play2's Iteratees, RxJava Observables, Scalaz Machines, Scalaz Streams).

Even when speaking of Node.js's strengths, like asynchronous I/O, I still think Java is better because of the foundations (e.g. NIO, Netty, Mina). The only reason people don't work much with asynchronous workflows is because the language is so freaking painful for that. But that will change with Java 8 and people are doing wonders in Scala/Clojure.

I've personally built an entire web-service, designed to handle thousands of requests per second per frontend instance, with responses generated in under 30ms, with a completely asynchronous workflow, on top of Scala/Akka/Play2. Node.js people don't know what they are missing.

</comment></comment></comment><comment><USER17> > Spring brings a lot of functionality to the table. Likely far too much > functionality. Most people are moving away from the monolithic application > and moving towards smaller more lightweight frameworks…

It's high time to debunk Spring. In the name of 'Dependency Injection' many Java developers still create complex, monolithic and - first of all - untestable applications with this framework. In fact, Spring adds another layer of complexity on top of Java EE without real benefit. It fosters Anti- Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally).

<comment><USER18> I'm pretty good with Spring and have even given trainings on it and I'd argue that Spring's main problem is that it needs to be seen in the right context: a poor man's DSL for declarative system configuration (it _is_ last 10 years old after all.)

That it creates untestable applications seems like completely nonsensical FUD however since the _entire_ point of Spring is to keep code easily testable. Spring is an almost direct response to the lack of testability of the ServiceLocator anti-pattern.

I'm not saying you can't make untestable code in Spring, but if you do the problem is most likely more with the people than with Spring.

<comment><USER19> I've done a lot of Spring side work and your first paragraph is the best explanation I've ever read for the framework.

I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the both the class and module functionality layer.

<comment><USER17> With Spring you can easily test your empty mocked-out shells. Great!

</comment></comment></comment></comment><comment><USER20> TL;DR from the post: """ My take-home for you, the persistent reader who has read all my ramblings in this post...

Don't build your app on top of a pile of crap in-house framework. """

<comment><USER21> Which suggests that take-home #0 should be: Don't build a pile of crap in- house framework.

Sniffing that out before too late is the tricky part...

</comment></comment><comment><USER22> This reads like someone reading a 1995 article about a company switching from writing Netscape Enterprise Server code in C++ on a Windows machine to Apache code in perl on a Sun server, and then writing a defense of the x86 processor against SPARC.

I might have missed something but I don't recall the original PayPal article arguing that the switch was motivated by moving from a slow virtual machine to a faster one.

But just as switching from C++ to perl would trade some computing power for productivity in getting a site built, I don't see it as controversial for an organization to say they achieved the same productivity gains going from java to javascript.

</comment><comment><USER23> Two poorly written apps compared with blame for each placed on the underlying virtual machine rather than the part between the chair and the keyboard. I'd much rather compare VMs and systems with something a little more structured and open like the TechEmpower benchmarks. They still have their flaws and simplifications, but at least the source for all apps is open and you can see and contribute to them.

</comment><comment><USER24> That is a refreshingly sober point of view. Blaming frameworks is easy. Speaking of technical debt is hard.

</comment><comment><USER25> I stopped reading at the part with the "Type information". Or better i should have stopped... Another post about(and the from paypal too) about my language X vs language Y...

It's the same flameware like Facebook started with its we can't get HTML5 as fast as native... then some people who know what they where doing did it...

No don't use java No don't use javascript

For god sake learn one language or two and learn it very well! i mean very well! and you will write good code and performant code...

EDIT: Why do i get down voted? Jesus HN gets worse and worse...

<comment><USER26> You're getting downvoted because this isn't a "language X vs language Y" article at all. Its point is that the language choice doesn't matter when you're building on top of crap, and jumping from one language to another probably won't solve platform problems. It's an article about the politics of being a software developer in enterprise where management is entrenched in legacy codebases, not about language features.

<comment><USER25> What? the first part is exactly that... for example: "So which is the faster virtual machine, V8 or JVM? My belief is that when you are coding in the most basic building blocks of either virtual machine (i.e JavaScript vs JVM Byte Code) that the JVM will win out every time. If you start to compare higher up, you may end up comparing apples with oranges and see false comparisons. For example, if we consider this comparison of V8 vs JVM performance at mathematical calculations. This blog post tells us that if we relax our specifications we can calculate things faster. Here is the specification that V8 must use for Math.pow and here is the specification that the JVM must use for Math.pow notice that the JavaScript specification allows for an "implementation-dependent approximation" (of unspecified accuracy) while the JVM version has the addition that"

and at the second part too: "... a limit of Node.js itself when used with the backing APIs that they have to call through to."

It's just hidden better... to me it reads like a java fan boy is crying why a company switched to language X from his language Y...

<comment><USER26> Your analysis is too shallow. The only reason he attempts to compare node.js to Java at all is to reach his point: that the decision was probably more about company politics than tech benefits. The team used a different language not because it's better or worse, but because it'd allow them to avoid building on top of the existing framework -- a chance to get rid of technical debt and start a fresh code base, even if just a seed.

</comment></comment></comment></comment><comment><USER27> I wonder if a lot of headway could have been made simply by doing some constraint analysis on the Spring framework and figuring out how to improve the performance. I have a hard time believing that Spring itself was completely topped out. It might have been an architectural choice, or some bloat that could have been taken out incrementally.

Instead they seem to be going the route of "the unicorns will solve it". The overall cost of that approach seems higher - finding unicorns is rare. Finding unicorns that are very good at all areas is even harder. I know there are a lot of unicorns on this board, but there sure aren't a lot of unicorn resumes on a hirer's desk.

I think the value of Spring has always been not that it's super-high- performance out of the box, but that it does a lot for you, and that as you learn more and more of it, you can develop solutions fairly quickly. It's built to make it easier on the developer, not the servers - but it is still easy to improve performance by focusing on constraints.

I think it's easy to blame what's between the keyboard and the chair, but the availability of said unicorns is the one ingredient of the system that is not in an employer's control. What is in control is sponsoring more education, and focusing on simplicity and constraint analysis.

</comment><comment><USER28> What a shocker... a Java guy says that you shouldn't abandon Java :-)

Lots of wild speculations... especially about the reasons PayPal picked node.js/JavaScript instead of a Ruby stack. He says that Ruby wasn't chosen because you can run it on JVM ignoring the fact that you can run JavaScript on JVM too using DynJS (he actually mentions DynJS earlier in his blog post).

</comment><comment><USER29> First post on HN. I'm not entirely sure how the PayPal Node vs. Java message has been packaged, but I think there is a lot of confusion. From my understanding (via blogs and conferences), Node was used to replace Java on the front-end. Meaning, the Node front-end is still calling Java + other stacks upstream -- which likely explains the performance benchmarks (the front-end wasn't the bottle neck). That said, even with similar performance benchmarks, I can see how Node might result in higher developer productivity for the front-end components of PayPal -- hence the enthusiasm they are showing. Lot's of negativity and blame on this thread, but I think it's because people are making assumptions.

</comment><comment><USER30> This is more about PayPal's dirty laundry than an comparative evaluation of technologies. If a collective set of tools are used improperly, comparisons beyond the context of those walls means very little.

</comment><comment><USER31> In our first lecture at graduate college, the prof told us how to read research papers.

Rule 1 : Louder the guest shouts of his honor, faster you should count your spoons.

Similarly if someone tells you about 50% savings just because you switched to some other technology you should be extremely skeptical. Besides those people who engage in `Node vs X` debate every now and then should spend some time educating themselves about compilers and interpreters to understand what makes some programming languages faster than others in certain circumstances.

</comment><comment><USER32> He forgets to mention one critical fact: developer productivity. Most applications (sans his terrible example of protein folding) are not that performance critical. Most of the code you write as a developer will do-away with any platform or language advantages itself.

It is not productive to write web applications in Java. Everyone hates it, which is why we have ruby, php, and now javascript (node).

I'd much rather trade a little performance for a scripting language anyday.

<comment><USER33> I wonder if someone has written up comparisons on their productivity between the languages / frameworks. My previous job had me on the python stack (Pyramid / Mako / Sqlalchemy), which I loved, but have been on Java / Play! framework for the last 10 months. The one thing that has consistently surprised me is how productive I feel writing Java. Mainly, I notice I make _far_ fewer mistakes / typos while coding; the IDE does a great deal of the work for me, and as the application grows, having static types has (for me) improved the readability of code I haven't looked at for a while.

No doubt a large part of any language choice is subjective, but I'm starting to believe that developer productivity has more to do with the tools and frameworks than the language itself. As these continue to improve in Java- land, I'm willing to bet that the disparity in productivity will continue to decrease.

<comment><USER34> >The one thing that has consistently surprised me is how productive I feel writing Java.

I know exactly how you feel. I recently moved from a Java project to a Python one and felt a little amiss without the power that an IDE gives a statically typed language. The tooling for Python flat out sucks. And it pains me to say, as I love the language to death, but I do feel more productive in other languages. Whether or not that's true is another thing entirely, but it does feel like a lot of time is wasted calling `dir` on objects to figure out what the hell the name was of the function you need.

As of about a week ago I switched from my text editor + console to Eclipse + PyDev. It's not perfect -- intellisense functionality is really hit or miss, but it _does_ make me feel a lot more productive. The background linting is pretty good at catching basic errors as you type them, which is _really_ nice.

It's also does an OK job at renaming things -- which is generally a nightmare to do on a big project in Python.

So, point being, while I miss a lot of the other tooling that an IDE affords a statically typed language, PyDev gets you, like, 80% of the way there. Worth checking out if you move back to Python.

<comment><USER35> Pycharm>Pydev by many accounts.

</comment></comment></comment></comment><comment><USER36> Application based comparisons are usually flawed, because the writer will never and cannot release enough info to reveal the real problem. Just because your bad-performing application runs faster on one platform doesn't necessarily mean that platform is superior to the old one. It simply means whatever problems you have in your bad-performing application manifests less in the new platform. In the end, fix your application!

</comment><comment><USER37> TL;DR:

* Micro-benchmarks don't provide a good picture of real system performance and can be skewed to make almost anything look better/worse than anything else.

* Much of Java's "slowness," clunkiness, large amounts of boilerplate code, etc. is the fault of the Java ecosystem and libraries rather than the language itself or the JVM.

* The inverse is true for Node: the quality of its ecosystem helps make up for language and runtime shortcomings.

</comment><comment><USER38> I was reminded that self deceit is the worst of its kind on reading the article. seeing a benchmark and deciding what to write your next application in kinda like that. you browse until you find the benchmark that aligns with what works out best for the lazy you and not works out best for the faithful app. this was just an observation of mine and not necessarily true or applicable to you.

</comment><comment><USER39> Maybe we should assume the best instead of the worst. We could assume that paypal has capable developers who are knowledgeable about both the jvm and node.js, and who have concluded that their specific featureset can best be built using node. That is not a value judgment of the jvm vs node in general, as their situation is theirs and theirs alone.

</comment><comment><USER40> Lots of people trying to unblub blub.

I'd venture a guess that mimicking Node.js isn't going to fix the deeper problems with Java.

</comment><comment><USER41> So far I tried compiling some of my numeric Scala code to JS with Scala.JS and unfortunately running that code in Chrome is much, much slower (~10-20 times) than running the original version on Java 7. :( Not sure if it is because Scala.JS creates poor code, or just JS is still not as fast as they claim.

<comment><USER42> Current version of Scala.JS is an alpha release, don't expect miracles.

</comment></comment><comment><USER43> I think it comes to this: Java > JavaScript. But Java programmer < JavaScript programmer, due to culture. (ex: Spring, Maven, EJB light).

If Java programmer is true polyglot, then whatever tool you are using wins. That's why C programmers are the best.

</comment><comment><USER44> Does anyone know how vertx[1] fits into this picture? It gives you the JVM, JavaScript, and non-blocking I/O.

[1]: [http://vertx.io/](http://vertx.io/)

<comment><USER28> Nodyn is an effort to run node.js apps on top of Vert.x. JavaScript alone is not enough to make Vert.x popular for node.js people. You need to be able to leverage the node.js module echosystem. Hopefully Nodyn will do that, so you can use your favorite node modules on Vert.x. It's still a work in progress though.

<comment><USER44> Cool, Nodyn looks interesting. Thanks for the info.

</comment></comment></comment><comment><USER45> Incredible insight... Here's the TLDR: Everything is faster when you engineer it a second time. Rewriting in a different language is not an apples to apples comparison.

</comment><comment><USER46> Management won't take the blame but ... who allowed the architects/engineers to build two systems that failed the same way?

<comment><USER47> I agree that management is likely a problem here, but disagree with the framing.

If you're in a structure where management's job is to allow/deny, then I think the code is already doomed. Software development is work that can't be effectively micromanaged.

In software, I think management's job is to support and challenge. All the people coding should be professionals, thoughtful and aware of issues like tech debt, second-system effects, reinventing the wheel, and so on. Management's job isn't to be more professional than the pros; it's to support the pros and make sure they're living up to (and sometimes advancing) their professional standards.

I'm sure there are plenty of people who work with these frameworks that know that they're crap. Management didn't fail by allowing these to get built. They failed by creating power relationships that allowed the people who couldn't see the problems to control the building of the frameworks, and to suppress criticism and improvement.

</comment></comment><comment><USER48> Damn, paypal really suck at making fast sites.

</comment><comment><USER43> Summary: Most frameworks sux.

<comment><USER49> Wrong. PayPal refuses to use open source frameworks because of an internal culture (and self preservation interest) of some very old "architects" who really only care about being in charge of the next internal framework. The best part is they later get to showcase how much better the new one is compared to the old framework, even though it's multiples slower than the slowest open-source counterpart.

<comment><USER50> Spring is open source. From the sounds of things, they replaced Spring with a closed in-house framework.

<comment><USER49> "Based on Spring" is not Spring. I worked there for a bit, they called it Sparta, and its appeal to the top tech brass was they could restrict which objects are available for use in the library they provided for you. The subtle message behind it was, we can hire anyone as long as we limit what they can do.

<comment><USER4> That's atrocious.

One thing I'll never understand is how companies get so hungry for developers that they subconsciously admit to hiring amateurs: "well, Joe _can 't_ do too much damage!"</comment></comment></comment></comment></comment>


Google introduces two new Twitter tools - <AUTHOR> http://www.itworld.com/internet/104656/google-introduces-two-new-twitter-tools <comment><USER2> Like the author I didn't have great luck with the Follow Finder... <http://whoshouldifollow.com> gives better results even though it seems a bit out of date. MrTweet also does a better job here.</comment>


First spam felony conviction upheld: no free speech to spam - <AUTHOR> http://arstechnica.com/news.ars/post/20080302-first-spam-felony-conviction-upheld-no-free-speech-to-spam.html <comment><USER2>
      In her written dissent, Lacy argued that the "unsolicited bulk electronic mail" provision of Virginia's Computer Crimes Act is "unconstitutionally overbroad on its face because it prohibits the anonymous transmission of all unsolicited bulk e-mail including those containing political, religious or other speech protected by the First Amendment to the United States Constitution."

What's wrong about prohibiting the anonymous transmission of all unsolicited bulk email?!</comment>


Investors Pump $90 Million Into Airbnb Clone Wimdu - <AUTHOR> http://techcrunch.com/2011/06/14/investors-pump-90-million-into-airbnb-clone-wimdu/ <comment><USER2> Can I just point out that Airbnb has a far superior name and domain name? I mean Wimdu sounds like a character from Star Wars, while Airbnb has the "bed and breakfast" abbreviation built right into the name.

<comment><USER3> This is a totally subjective thing, but they both have terrible names, IMO. Airbnb is slightly more memorable but equally horrible to actually say aloud.

</comment></comment><comment><USER4> Every startup prides themselves on being the disruptor the industry until "me- too" clones come along and they get pissed because the disruption is short- lived.

Build a good product users want, treat those users well, and you'll be fine.

</comment><comment><USER5> At some point, shouldn't the readers of HN consider themselves the market makers? This constant hearsay about who is making money and who isn't...tiresome.

</comment><comment><USER6> From a fake interview with McLuhan:

"The attention of consumers can shift instantly and make the most profound investments obsolete in just a few years, soon to be sped up even further. We will see economic empires crash within hours, and new ones arise just as quickly.

The task of the economic manager now is to try to hold monopolies in place just long enough for economic transactions to occur."

I first read this while still in high school and it left a huge impression on me. (Big enough that I still remembered it just now, over 15 years later... wtf?!)

\--> <http://www.wired.com/wired/archive/4.01/channeling_pr.html>

</comment><comment><USER7> What I don't understand about this is - What makes Wimdu a clone of AirBnB, but AirBnB not a clone of Homeaway/VRBO?

I'm not trying to be flippant, really wondering what is new about AirBnB (other than a much better interface)

<comment><USER8> From the article, it sounds like these new sites are _literally_ clones. They are scraping Airbnb listings and posting them on their own sites. They aren't just using the _idea_ of Airbnb, they are using the _content_.

That's just what I can glean from the article.

<comment><USER9> I didn't see any mention of scraping.

</comment></comment></comment><comment><USER10> While i've nothing against Wimdu (or AirBnB), I am against putting insane amounts of money into something that not only is a "clone" of another business, it is also what I define as a business that does not exactly "push humanity forward".

I could give a myriad of better uses for that $90 million:

\- Keep the SETI initiative going (and along with a few arrays)

\- Any tpe of medical (cancer, genetics, etc) research

\- Next generation wireless infrastructure networks

\- Any viable cleantech startup

And the list goes on and on and on and on..

<comment><USER8> At some point, each person decides how much value something provides to themselves or others and acts accordingly. You put a lot of value in the items that you list, others put value in things like Airbnb. To claim that because Airbnb doesn't "push humanity forward" (by whatever measure you imagine that to be) that it is somehow a waste of money is a bit much. For one thing, $100MM sounds like a lot of money, but in the big picture of "pushing humanity forward" it is almost _nothing_. Secondly, as a society, we aren't going to put 100% of our wealth into those items, or any other list that one person considers "important". So why is it so terrible that it is going to something that provides many people real value (as they define it for themselves)?

<comment><USER10> I wasn't referring to AirBnB specifically but the gist of my comment is I don't see how an AirBnB clone can justify $90m worth of capital.

So maybe my usage of the term "pushing humanity forward" may be a lil bit grandiose but i certainly didn't mean giant leaps straight off. For example, i consider Google/Wikipedia to be an invention that "pushed humanity forward" because it raised the collective IQ of the human race (with access to it of course) by a few notches. Both companies certainly didn't need $90m worth of capital initially to start off but benefitted from a few angel investments.

What i probably should have said is that the $90m could have better been allocated to things that are more worthwhile to humanity and not investing in just another "clone" of something.

But I guess kristofferR is right. At the end of the day, the only thing most investors care about is making money and since it is their money, it is fully in their right to choose what they want to invest in.</comment></comment></comment>


Moves/Facebook lied - <AUTHOR>

This morning I read a news article saying Facebook had just bought Moves. Being a registered Moves user, I deleted my account because I'm not comfortable with Facebook having access to my location data.
In a mail they sent me, they assured me they had deleted my data and that my email address would also be deleted right after sending the mail.
48 minutes later I got a mail from them. http://imgur.com/a/icHil <comment><USER2> Previously I've seen unsubscribe emails that state you will have no more emails after those already 'commissioned' have been sent. If they used a 3rd party service for sending out mass emails like that, they may provide the users in advance and have no ability to remove them last minute. This purely speculation at a possible cause on my part though.

<comment><AUTHOR> There is no mention of it in the deletion mail and both mails came from Amazon SES servers.</comment></comment>


Ask HN: Apache Modules - <AUTHOR>

I was just wondering if anybody knows of a good resource for learning to develop Apache 2.2 modules? Just thought it'd be an interesting way to spend my Sunday afternoon. <comment><USER2> I would start here: <http://httpd.apache.org/docs/2.2/mod/mod_example.html>

<comment><AUTHOR> Didn't notice that. Much appreciated.</comment></comment>


Golang vs PHP - <AUTHOR> https://walledcity.com/supermighty/golang-vs-php

<comment><USER2> Interesting. Your post makes Go seem pretty approachable. What do you use for testing?

<comment><AUTHOR> Go has a built-in testing framework, but I've yet to play around with it.</comment></comment>


Microsoft, Adobe Push Critical Fixes in Flash, Windows and IE - <AUTHOR> http://krebsonsecurity.com/2014/07/microsoft-adobe-push-critical-fixes/

<comment><USER2> Slightly tangential point but - Its weird that its normal to not be using any of the above mentioned technologies. It was unthinkable in the very recent past to not use (directly or indirectly) MSFT, Adobe technologies at all.

<comment><USER3> Are you using Google Chrome on a desktop/laptop? If so, then you're using Flash and they pushed out a patch via their update service.</comment></comment>


Ask HN: A good text on applying FMEA to sw projects? - <AUTHOR>

During a chat (started here on HN, btw) about one of my job problems someone suggested looking into  FMEA (Failure mode and effects analysis) to try to diagnose what the main causes could be.<p>Can anyone suggest a good (and concise) book on the topic, especially with a software angle? <comment><USER2> Not sure if there are books specific on that. I picked it up as part of Six Sigma training.

The concept is you list all the possible failure modes in one column, then score the severity (1-10, 10 most severe), occurrence probability (1-10, 10 highest probability), and detection probability (1-10, 10=lowest probability) in other columns. Multiply those to rank the risks and then list out ways to improve or fix the risk, etc.

A software angle would be listing ways your application would fail, or go down to lower level components inside the app.

A tricky concept with the scoring is the detection piece. If you don't have a good way to detect the failure then it ends up being really high ranking. I typically used 1,5,10 for the scores since ending up in a debate about is it a 6 or 7 or 8 is a waste of time.

Once you work on improvements for a failure mode, like additional logging for an NullPointerException, then adjust the scores.

If you are doing TDD, this would be a good way to identify areas to build testing coverage.

<comment><AUTHOR> Thanks - yes, there are a few books devoted to the topic: [http://www.amazon.com/s/ref=nb_sb_noss?url=search- alias%3Dst...](http://www.amazon.com/s/ref=nb_sb_noss?url=search- alias%3Dstripbooks&field-keywords=fmea&rh=n%3A283155%2Ck%3Afmea) \- hoped to find someone who could provide suggestions about which one to pick.</comment></comment>


Soft contact lens technology could link renewables and the grid - <AUTHOR> http://www.wired.co.uk/article/superdielectrics-supercapacitor-electric-car-battery <comment><USER2> Smells like EEStor 2.0</comment>


Deanonymizing Darknet Data - <AUTHOR> http://atechdad.com/Deanonymizing-Darknet-Data/

<comment><USER2> The data is not anonymous to begin with if it contains plain identifying information (like an email address).

</comment><comment><USER3> > Parsed hundreds of thousands

> found 37

I agree that anonymity is hard and when you make waves it becomes harder but it would be tough to draw that conclusion from those stats. Interesting nontheless.

<comment><USER4> There would be many more than that if markets didn't (usually) strip metadata by default.

<comment><USER3> quite possibly true. I can't be asked to dig it up but either this post, or another person speaking about your data said these sites are hand coded and often don't scrub data from uploaded images.

if you as an individual can't be asked to scrub a bit of metadata off of a photo you upload to an online black market you probably aren't qualified to work part time at walmart. dodgy bit here though, it would be pretty trivial to edit it and intentionally leak false info and be moderately clever while everyone thinks you are daft.

<comment><USER4> I wouldn't say _often_. Most of them, as far as I can tell, get that right from the start, and the ones that don't fix it fairly quickly after being told.

</comment></comment></comment></comment><comment><USER4> Incidentally, 37 is definitely low. When I did the same thing in early 2014, I got >90 unique GPS coordinates.

<comment><USER5> Why the discrepancy? Just that most images on the sites aren't jpgs? (What else supports exif, tiff?)

<comment><USER4> I believe I checked PNGs as well, and I went through all my archives up to that point (it wasn't just Evolution which had forgotten for a while to strip image metadata). Possibly my grep was also better at checking variant field names? Dunno.

</comment></comment></comment><comment><USER6> Wow. What an accomplishment. :/

</comment><comment><USER7> Most online child pornography is not hidden nor encrypted in any way. Just search Bing; you can get the keywords from wikipedia then follow bing's suggested queries.

Microsoft claims that they remove child abuse links from their index upon notification by such organizations as the National Center For Missing And Exploited Children but clearly they dont.

There are some imagehosts that either have no way to locate their images from their homepages, or whose search forms dont list child pornography in their results, however its all indexed by bing.

The videos at the filesharing services commonly have obvious or easily brute- forced passwords. There arent that many different passwords in widespread use; I expect a list of the 100 most common passwords would decrypt 99% of the videos.

The passwords and lightly obfuscated links are mostly posted to dead forums. If you operate a forum yourself the simplest way to defeat this is to disable posts in threads older than a month or so.

If you want to find these posts on your server look for a large number of occurrences of the word the word "password".

I have even seen this at last.fm.

</comment><comment><USER8> TIL stop allowing your pictures to have meta tags.</comment>


A curious result hints at the possibility dementia is caused by fungal infection - <AUTHOR> http://www.economist.com/news/science-and-technology/21676754-curious-result-hints-possibility-dementia-caused-fungal?fsrc=scn/fb/te/pe/ed/fungusthebogeyman <comment><USER2> Already discussed a week ago:

[https://news.ycombinator.com/item?id=10401344](https://news.ycombinator.com/item?id=10401344)

<comment><USER3> And this Economist article had its own previous HN discussion, too:

[https://news.ycombinator.com/item?id=10446411](https://news.ycombinator.com/item?id=10446411)

</comment></comment><comment><USER4> Horribly misleading headline as well. It clearly states in the article that it's most likely having dementia makes the brain more susceptible to fungal infections, not that dementia is _caused by_ them.

While in an ideal world, people should not trust headlines alone, a lot of people do scroll and skim. And just merely being exposed to something could leave a mark in their memories. I'm pretty sure this is how a lot of misconceptions start.

<comment><USER5> The article does _not_ "clearly state" reverse causality as "most likely"; it mentions that as a possibility.

It's a fair, well-qualified headline – "hints at the possibility" – summarizing the new evidence.</comment></comment>


Hypermedia APIs - <AUTHOR> http://oredev.org/2010/sessions/hypermedia-apis This video shows how to make REST APIs with xhtml that demonstrates independent evolution and decoupled implementation of the client and server:
The code for creating the client is available here:
https://github.com/cimlabs/hypermedia-client-java <comment><AUTHOR> This video shows how to make REST APIs with xhtml that you can test in a browser. It demonstrates independent evolution and decoupled implementation of the client and server:

The code for creating the client is available here:

<https://github.com/cimlabs/hypermedia-client-java></comment>


Andrew Ng: Artificial Intelligence Is the New Electricity (2017) - <AUTHOR> https://www.youtube.com/watch?v=21EiKfQYZXc <comment><AUTHOR> What I found interesting about this talk is that Ng is very explicit about the fact that companies like Baidu launched products simply to collect data with the intention of monetizing the data (through AI). I know this is obviously the case, but I've never heard it stated so explicitly from someone in his position of influence.

He also mentions that ad targeting is probably the most profitable application of AI</comment>


New GTK Website Design Goes Live to Help Boost Linux App Development - <AUTHOR> https://www.omgubuntu.co.uk/2020/02/gtk-website-redesign <comment><USER2> Would love to see a Linux toolkit implement a flux pattern style. Building apps in Vue compared to GTK is so radically different - it's a shame no toolkit has kept pace</comment>


Tesla Model S Autopilot Reliability – Why Americans Should Love Tesla - <AUTHOR> http://www.roadandtrack.com/car-culture/news/a29944/leave-tesla-alone/ <comment><USER2> > We now live in an era where raising a billion dollars of other suckers' > money and developing a new "app" to take selfies or find imaginary creatures > in a porta-potty is considered the apex of human civilization but investing > your entire fortune in a quest to build a self-driving electric car is > treated like dangerous, egomaniacal adventurism. It makes you wonder why > Elon Musk couldn't just be content sitting on his Paypal money and living > the lifestyle of the famous one percent. It certainly would have been less > hassle.

I wish this sentiment was more common. Don't we all want the future to win?

<comment><USER3> I want the future to win. And we are one bug away from a Hindenburg moment. So if I think what they do is reckless I will say so.

It's ludicrous to expect that an otherwise untrained, average human can keep up his or her attention while day by day the automation just works. It's just not how human psychology works. Someone called this particular kind of operation here the "deadly valley" because it's good enough to lure you to be relaxed and not good enough to solve all the kind of possible problems.

I absolutely want the future to win, and I'm terribly afraid that Tesla in its hastiness might hurt the progress.

<comment><USER4> But must the standard for safety be higher than existing human drivers? We're already living the 'hindenburg' life - every day my freeway overhead sign shows me the fatality total this year for my state. Its almost exactly one per day. This is 'normal'.

What are the on-the-road stats for automatic driving? Aren't they better than human drivers already?

Its not a failing, just because they have different failure modes than humans. Because our human failings are so many and so frequent. There's so much low- hanging fruit. Auto-driving never gets tired, never argues with the passenger, never gets distracted by changing the playlist.

We're net ahead already with auto-driving.

<comment><USER5> _> But must the standard for safety be higher than existing human drivers?_

This is my line of thought as well. Same problem I have with the anti-nuclear environmental crowd. Are there substantial drawbacks? Absolutely.

That doesn't matter. The important question is not "Does this new technology solve all previous problems?" but rather "Does this technology solve a net positive number of problems while offering more opportunities for improvement?"

With decades of empirical data that average humans are pretty bad at reliably manually piloting powerful, heavy vehicles, I can't see a reasonable reason to reject deploying autopilot technology in an aggressive manner. And that sadly means a few deaths. But those should be measured against the number that would have died were nothing done, not against zero.

<comment><USER6> Long haul trucking on routes with less than 2000 feet at each end off of a limited access highway could be automated very soon. The reduction in sleepy human drivers on the road would probably increase highway safety while saving companies money.

<comment><USER7> How do you figure? I don't believe there's been any interstate testing of automated driving on freeways with human drivers, let alone a standardized legal framework that would enable end-to-end automation.

<comment><USER6> Have you seen logistics centers in Texas? They are often out in the middle of nowhere, often with dead-easy access to the highway. Automating driving in those conditions would be much easier.

If nothing else, one could have "pilots" guide the trucks by remote control for the last mile.

<comment><USER7> My point was that it's not technology that will be the hard part, it's legality and unions.

<comment><USER6> If there are no employees, what say will the unions have?

<comment><USER7> There are far from no employees with about 3.5 million truck drivers in the US. A company cannot operate an automated commercial service today because there is no licensing system for driverless trucks. The unions aren't going to allow legalization of automated truck driving with that many jobs on the line.

You're not providing any argument for the ease of legalization here.

<comment><USER6> _The unions aren 't going to allow legalization of automated truck driving with that many jobs on the line._

The unions can only have direct leverage with companies that currently employ truckers and those that work closely with those companies. All it takes is for one tech company that doesn't fit into the above category to develop the technology, then the market will make the licensing of such devices inevitable.

You thought you were giving a clever rejoinder. However, I was specifically talking about companies that don't directly employ large numbers of truck drivers. Then it comes down to the economic power of the companies that operate the trucks versus the economic power of the companies that have to pay the trucking companies. The latter is going to win the lobbying contest by sheer size.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> "It's possible to walk into a dealership and buy a car that drives itself on the freeway about as safely as you would if you were driving the thing. "

How did the author arrive at this conclusion?

"In any even remotely sane universe, this achievement would be celebrated in the most hyperbolic fashion possible by every man, woman, and child on the planet. "

So everyone who doesn't do that is not remotely sane?

"Americans would be as proud of the Tesla Model S as we used to be about the moon landing or about winning the Cold War."

It's a car.

"Note that the harshest critics of Tesla and its products are not affiliated with Nissan, General Motors, BMW, or Ford. Instead, they are gadflies who rarely have any industry experience whatsoever. "

Not sure why this article did ended up on the frontpage, it doesn't really add anything useful to the discussion and does not address the main criticisms people have about the autopilot like the limited number of sensors, wrong expectations due to the name and lack of strict enforcement of driver engagement (hands on wheel).

<comment><USER9> > Not sure why this article did ended up on the frontpage, it doesn't really > add anything useful to the discussion and does not address the main > criticisms people have about the autopilot like the limited number of > sensors, wrong expectations due to the name and lack of strict enforcement > of driver engagement (hands on wheel).

Great point.

</comment></comment><comment><USER10> I keep seeing the "130 million miles of Autopilot control per fatality" statistic, especially in the context of "look these cars are better than humans" but I think this is incredibly disingenuous. First of all, you can't just take a sample size of 1 for an effectively random event and then do (total miles driven) / 1 = 1300000000 miles/fatality and pretend like that has any statistical significance.

Furthermore, during those entire 130 million miles, there was theoretically a human also sitting behind the wheel ready to take over if the system failed. If there was no human behind the wheel, the cars would not have been able to attain 130 million miles of drive time without a very large number of crashes. When humans drive, there is no intelligent being ready to take over whenever we make a mistake as is the case for Autopilot.

In my opinion, using this "statistic" is a very lazy way of hiding behind the numbers in dealing with a very non-obvious issue.

<comment><USER11> > Furthermore, during those entire 130 million miles, there was theoretically > a human also sitting behind the wheel ready to take over if the system > failed.

Yes. That is the point, though. When Autopilot is used the way it is supposed to be used, it doesn't seem to decrease safety, and it may actually increase it.

I agree with the point in your first paragraph, though.

<comment><USER10> I would assert that you cannot make that claim, as there is no statistically significant evidence in support of it.

<comment><USER11> I wasn't making any kind of strong claim. I said "doesn't seem" and "may". My point is, whatever evidence we've got so far, it doesn't seem to indicate a decrease in safety. If anything, it seems to point (however feebly) towards a safety increase. IOW, the data so far doesn't support, in my view, the stance that Autopilot in its current form is unsafe, as long as it's used in accordance to the instructions.

<comment><USER12> The issue is that 1 data point does not point to either side. You can neither make a strong nor a weak claim for either side, because the sample size is too insignificant.

If I flip a coin twice with one head and one tail as the result, we cannot say whether or not the coin is fair. Even with both heads or both tails as the result, we still do not have enough information. It's best to just say that we need more data.

<comment><USER11> It's 1 data point if you look at crashes, there are 130 million data points if you look at miles driven. It's by far the largest amount of data available on Autopilot driving out of all manufacturers.

I agree we have no statistically rigorous argument yet that Autopilot increases safety. I agree with you and others who say we need more data. My only point is that there is no reason, IMO, to stop gathering that data in real-world conditions by banning Autopilot, as some media articles are suggesting (not anyone in this thread), because we have no evidence so far that it decreases safety.

<comment><USER10> As a person who in robotics, believe me when I say that I am interested in these technologies being developed and tested. That said, I am aware that a major PR battle is the last thing that the industry needs right now.

I think that Tesla is doing a disservice to the rest of the industry by being overly zealous with their marketing and naming department. "Autopilot" is a bit of an exaggeration that needlessly oversells what is effectively a lane- assist feature. By saying that it's "autopilot" they set an expectation of a high degree of autonomy, and thereby influence how their technology is perceived and evaluated both by users and the press. Fatal accidents caused by incorrect use of a "Lane Assist" is a very different headline than an accident caused by "Autopilot."

Tesla is not the only manufacturer with some kind of active cruise control, they just get a lot of attention because they like to pretend they are selling autonomous cars. I am just crossing my fingers that their recklessness will not cause a significant setback to autonomous car technology in general. Tesla hand waving away safety concerns by quoting dodgy apples-to-oranges "statistics" doesn't exactly make me feel warm and fuzzy.

<comment><USER13> Thank you, I'm glad to see a fellow robotics engineer speaking out against this. Oftentimes I see this debate cast as "pro-driverless-car" vs "anti- driverless-car", but the debate is more nuanced than that. It's up to people who understand the technology to point out what is actually wrong here. We're not trying to hold back progress; we're trying to promote progress in a _safe_ and _responsible_ way. No one needed to die here.

edit:

> Tesla hand waving away safety concerns by quoting dodgy apples-to-oranges > "statistics" doesn't exactly make me feel warm and fuzzy.

Same here. I've always liked Audi's philosophy and their slogan really spoke to me: Vorsprung durch Technik - "Advancement through technology". After their emissions scandal, it seems that their strengths do not extend to ethics. I was hoping Tesla would replace Audi in my eye, but they are turning out to be just as morally bankrupt, IMO.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> One wonders what Tesla did to get that laudatory article.

Tesla's "autopilot" problems come from bad engineering and bad human-factors design. I wrote on this in another topic yesterday.[1] It's not that automatic driving is bad; it's that Tesla's semi-automatic driving isn't very good. It's way under-sensored. Google and Volvo are ahead in this area.

Volvo is very close to shipping their autopilot. They're testing now. In 2017, they will release 100 self-driving cars to customers. They do _not_ require the driver to pay attention. Volvo's CEO says that if a Volvo self-driving car gets into an accident, it's Volvo's fault, and they will take full responsibility.

Their "City Safety" anti-collision system has been on all new Volvo cars for a year now. Unlike Tesla's system, it's always on. Volvo has radar and LIDAR and cameras, more sensors than Tesla has.

Volvo's self-driving car has even more sensors, for full coverage in all directions and redundancy. Redundant computers and actuators, too. And if it gets into a situation it can't handle, and the driver doesn't take over, it will pull over and stop.

There's a way to do this right, and Volvo is a lot closer than Tesla is.

[1] [https://news.ycombinator.com/item?id=12082893](https://news.ycombinator.com/item?id=12082893) [2] [http://www.volvocars.com/intl/about/our-innovation- brands/in...](http://www.volvocars.com/intl/about/our-innovation- brands/intellisafe/intellisafe-autopilot)

<comment><USER14> On a related note, here's Chris Urmson's long talk at SXSW on how Google does automatic driving.[1] This is worth watching. He shows what Google cars sense and gives an overview of how they analyze the data. This is the first time Google has released this level of detail. If you're going to comment on automatic driving, you need to see this.

Urmson goes into great detail on Google's 2mph collision with a bus. The sensor data from the Google car is shown. The video from the bus (it had cameras, too) is shown. Exactly what the software was trying to do is discussed. The assumptions the software made about what the bus driver would do are discussed. What they did to prevent this from happening again is mentioned.

Most of the talk is about the hard cases. In the beginning, Google developed a highway driving system, but that was years ago. Now they're working hard on dealing with everything that can happen on a road, including someone in an electric wheelchair chasing ducks with a broom.

[1] [https://www.youtube.com/watch?v=Uj- rK8V-rik](https://www.youtube.com/watch?v=Uj-rK8V-rik)

<comment><USER9> Cool! Thank you for sharing this.

Here's the part where he starts talking about the 2mph bus accident [1]. He says the self-driving car should not have moved. He does not say why. He says they ran a lot of tests to make sure it will not happen again.

In plain English, I'd say, when the SDC is stopped on the side of the road, give sufficient time for traffic coming from behind to clear out before the SDC moves forward. Also, if an accident is imminent, being in a non-moving position is probably safer and less likely to cause liability for the SDC than moving. Plus, rolling over some sandbags is probably preferable to being hit by a bus.

[1] [https://youtu.be/Uj-rK8V-rik?t=21m45s](https://youtu.be/Uj- rK8V-rik?t=21m45s)

</comment></comment></comment><comment><USER15> Since the Tesla autopilot will only work on long, clear stretches of road with high visibility and very predictable traffic, it's not really hard to see why the statistic would look better than it really is.

I can build an autopilot to drive a car with zero fatalities ever; it just goes forward on an infinitely straight road.

Statistics can only be compared under the same conditions, otherwise it's just pointless self-delusion.

</comment><comment><USER16> >In any even remotely sane universe... Americans would be as proud of the Tesla Model S as we used to be about the moon landing or about winning the Cold War.

While I generally agree with the author's sentiment, I think part of the difference with why Tesla is getting so much flak instead of praise is because the pioneers of yore were astronauts, scientists and soldiers who took risks they understood, and did it willingly.

But with Tesla, the intrepid pioneers of autonomous driving are everyday people who are engaging in behavior that is probably more risky than they realize, and we're now seeing some of the consequences of that.

At the same time, I think you could argue that some people, at some point, are going to have to take on these risks at a large scale, and the one thing Tesla has going for it is a rabid fan base, and it may be true that without that kind of cult following, no company would be able to survive this phase of autonomous driving development.

<comment><USER9> > But with Tesla, the intrepid pioneers of autonomous driving are everyday > people who are engaging in behavior that is probably more risky than they > realize, and we're now seeing some of the consequences of that.

Yeah. The author of this article has the same observation [1]. Tesla seems to have been caught off-guard by pushback against its driver-assistance system. Yet, everyone knew there would be pushback if a fatality occurred.

> At the same time, I think you could argue that some people, at some point, > are going to have to take on these risks at a large scale, and the one thing > Tesla has going for it is a rabid fan base, and it may be true that without > that kind of cult following, no company would be able to survive this phase > of autonomous driving development.

Fan bases are important, particularly ones that include people who can be give constructive criticism. 100% praise or 100% critique is rarely useful in identifying the path forward. It's a windy road. Everything Musk says is not gospel.

[1] [http://fortune.com/2016/07/11/elon-musk-tesla-self- driving-c...](http://fortune.com/2016/07/11/elon-musk-tesla-self-driving- cars/)

</comment></comment><comment><USER17> Tesla launched autopilot like a startup in beta mode before big co's and regulators could slow it down. If you believe computers will eventually be safer drivers, would you prefer:

A) Autopilot launches gradually over 20 years by a big co, costing hundreds of thousands of lives due to 10 year delay or

B) Tesla launches fast below the radar, iterates quickly, makes data-driven incremental updates to autopilot and saves 10 years of human error deaths?

<comment><USER18> False dilemma

C) put these tech features into the car but force the driver to keep actively driving the car getting the best of both worlds. AKA what every other automaker is doing.

<comment><USER17> If you're doing what everybody else is doing, by definition, you are not making progress

</comment></comment></comment><comment><USER19> > _Again, in any sane world nobody would pay any attention to the opinions of > completely unqualified individuals on any given topic. There 's a reason I > write for Road & Track and not Men's Health, for example, and it has > something to do with the fact that I've literally had more racing wins in my > life than I've eaten salads. If I started pontificating about whether a > particular protein supplement built more muscle mass and got you more ripped > than another one, the readers would be entirely right to point out that I am > not a doctor and that I have never been seen to bench press more than 255 > pounds, not even once._

Reminds me of the Tragedy of Theranos. A company valued at $9 billion, staffed to the gills with engineers and medical experts who were building a revolutionary disruptive way to draw and test blood, was taken down based on the accusations of a _newspaper_ reporter who has never run his own startup, nevermind having not attained enough medical expertise to even competently check someone's temperature.

I'm being a little facetious here. There's a difference between a cable news reporter blabbing about something that happened 7 minutes ago to fill an hour of airtime with controversy and fear, and a 5-month investigation by a Pulitzer-winning reporter. But let's not shit on the laypersons who dare to challenge the clergy.

But in one aspect I agree with the OP. People who aren't experts and who don't bother to check with other experts should perhaps be mindful before they propagate uninformed armchair analysis. But let's make that cut both ways. These uninformed reporters should also hold their tongues when a company touts _any_ technical feature. Maybe that would reduce the incentive for the Elon Musks of the world to name things in viral-headline-friendly ways, e.g. "Autopilot" for advanced driver assist. Tesla has benefited heavily from the press corps ignorance about technology -- you think Tesla has received $4 billion in government subsidies based on technical merit alone? And now they're paying for it. Maybe 10 years from now we'll all agree that that was a good strategic gamble. But it doesn't mean Tesla should be given kid glove treatment _today_ , after the effort they've put in to manipulate the press to their own benefit.

<comment><USER9> > People who aren't experts and who don't bother to check with other experts > should perhaps be mindful before they propagate uninformed armchair analysis

I believe some of this controversy began with an article by Fortune [1] in which they claimed Musk overlooked some business reporting requirements.

Do you agree that a financial news outlet is qualified to judge a company based on how they report to the SEC? The world of corporate finance is their wheel house, and that spans to any company, tech or not. The larger the valuation of the company, the more interesting the news would be to them.

Fortune's readers are current or would-be Tesla investors.

[1] [http://fortune.com/2016/07/05/elon-musk-tesla-autopilot- stoc...](http://fortune.com/2016/07/05/elon-musk-tesla-autopilot-stock-sale/)

<comment><USER19> That definitely falls into the field of Fortune's expertise. But I took OP's comment to be a broadside against the alarmist headlines about the recent accidents.

<comment><USER9> > I took OP's comment to be a broadside against the alarmist headlines about > the recent accidents.

Yeah. I feel the Fortune article came out, then Musk claimed it was BS, and other headlines both critical and defensive of Tesla started popping up. Fortune's legitimate criticism has been overlooked by many who believe Musk can do no wrong.

At this point, Musk has tweeted in response to the article from Road and Track titled "Leave Tesla Alone",

> "We don't mind taking the heat for customer safety. It is the right thing to > do"

Perhaps tensions are easing between Musk and Fortune.

</comment></comment></comment></comment><comment><USER20> Why is Tesla risking time, money and reputation on making their cars self- driving? The primary goal is surely to get everyone into electric powered cars so we can move to cleaner power, and lower localised pollution.

<comment><USER21> It depends on if you believe the perspective that Musk doesnt care about time, money and reputation but wants to spur on the rest of the car manufacturers to compete, in some sort of altruistic, noble effort.

<comment><USER22> I'm not denying he doesn't have that motivation, but let's not kid ourselves here: he's an entreprenuer first and the looking for every way to make his product stand out in the market. A market which will soon be flooded with electric cars produced by the major car companies as well. And _they_ are betting big on autonomous driver technology as well [0].

[0]: [http://fortune.com/self-driving-cars-silicon-valley- detroit/](http://fortune.com/self-driving-cars-silicon-valley-detroit/)

</comment></comment></comment><comment><USER23> Fatalities per 100 million miles driven is not a great metric for measuring the reliability of Autopilot.

That number is influenced not just by Autopilot avoiding accidents, but also by the overall safety of the car. Teslas are incredibly safe in accidents. The current 25% lead that Autopilot has over the average is probably not attributable to Autopilot at all, and instead to the overall safety of the vehicle.

* Fatality rates vary by make/model quite a bit (up to 8x). Some of this is surely attributable to the relative driving skill of purchasers, but most is probably the safety of the cars themselves. Given the spread seen in this IIHS report I would guess that Autopilot performs worse than the average human. [http://www.iihs.org/iihs/topics/driver-death-rates](http://www.iihs.org/iihs/topics/driver-death-rates)

<comment><USER9> It's not even a good figure for comparing fatalities. See my comment here [1]

Those 100 million miles include non-divided roads, motorcycle deaths, adverse weather conditions, and cheaper, older cars.

[1] [https://news.ycombinator.com/item?id=12087603](https://news.ycombinator.com/item?id=12087603)

</comment></comment><comment><USER9> > Here's a statistic for you: 1.08 fatalities per 100 million miles driven. > According to the National Highway and Traffic Safety Administration, that's > the death rate on the American road as of 2014, the last year for which > there is complete data.

This one per 100 million miles statistic keeps getting thrown around. I think we can come up with a better number for comparison (see #'ed list below)

I also think we can push for more transparency from Tesla and other companies offering driver-assistance systems. California already requires monthly reports on all accidents involving completely autonomous vehicles [0]. We should be getting this for systems offering driver-assistance across all states. Tesla seems unlikely to report on this until their competitors are forced to report on it too.

Here are a few reasons why the 100 million figure isn't as good as it could be,

(1) Those 100 million miles include all roads, not just divided ones where autopilot is likely to be activated

(2) Autopilot is less likely to be activated during adverse conditions like rain, ice and snow

(3) The 100 million figure includes all types of vehicle deaths, including those from motorcycles. Motorcycle deaths should not be compared to car deaths

(4) The vehicle price is lost in such an average. Safety reports are best done when considering cost. Obviously a 2016 Tesla is going to be safer than a 1990 beater

I'd like to see someone report a more useful statistic for comparison using available data such as this [1]. This guy [2] says it is 1 in 150 million when considering only divided roads. That would make Tesla's autopilot less safe than the average American driver given current statistics.

[0] [https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/auton...](https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/autonomousveh_ol316)

[1] [http://www.iihs.org/iihs/topics/t/general- statistics/fatalit...](http://www.iihs.org/iihs/topics/t/general- statistics/fatalityfacts/state-by-state-overview)

[2] [https://www.reddit.com/r/technology/comments/4sgxv1/while_te...](https://www.reddit.com/r/technology/comments/4sgxv1/while_tesla_appears_surprised_over_criticism_of/d59eazl)

<comment><USER24> Given the large error-bar on the Tesla data, you have no idea if Tesla is less safe or more safe than the average American driver.

<comment><USER9> I'm using the same data Tesla used when they made their claims.

<comment><USER24> And that adds to a well-reasoned and statistics-informed discussion on HN, because... ?

<comment><USER9> None of Tesla's recent press releases indicate their data is error-prone [1] [2]

Rather, they mention a "wealth of internal data demonstrating safer, more predictable vehicle control performance when the system is properly used."

I'm drawing a different conclusion from the same data. I'm not claiming it's gospel. I'm just an internet commenter.

Forthcoming investigations from the NHTSA and NTSB may shed more light.

[1] [https://www.teslamotors.com/blog/tragic- loss](https://www.teslamotors.com/blog/tragic-loss)

[2] [https://www.teslamotors.com/blog/misfortune](https://www.teslamotors.com/blog/misfortune)

<comment><USER24> I was trying to engage you in a discussion about _your_ error, not Tesla's. Hopefully you're an internet commenter trying to make Hacker News a better place?

<comment><USER9> > Hopefully you're an internet commenter trying to make Hacker News a better > place?

For sure. Through this discussion about assisted-driving cars, I also try to contribute to a safer driving community, more transparency from companies offering driver-assistance systems, thoughts about the best ways to advance AI, and better capital allocation.

> I was trying to engage you in a discussion about your error, not Tesla's.

I don't see what error of mine that you are pointing out here. It sounds like you're talking about Tesla's data:

>> Given the large error-bar on the Tesla data, you have no idea if Tesla is less safe or more safe than the average American driver.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> We're at the place with self-driving that air travel found itself at in the 20's.

From here on in each new technological update and safety regulation will like likely be based on some unfortunate and unforeseen event.

Like they say when you study the rules of aviation: Each one is written on a tombstone.

<comment><USER26> Most often, you don't die in an air accident if you're not on a plane. With AI vehicles sharing the road with manual vehicles and pedestrians, the case is different.

</comment></comment><comment><USER27> If autopilot is slightly better than a human driver, why not use it?

It's an incredibly low standard, sure, but more lives are saved, and it only to get better from then on.

The only problem is the public's perceived unwillingness to accept such risks in using autopilot.

<comment><USER28> Tesla over-promised: If they called the Tesla a 'driver-assisted vehicle' rather than an 'autopilot car' this would be a different argument.

You can't claim you have a driverless car (autopilot) when it is expected of the driver to keep their eyes on the road, hands on the wheel and a foot near the brake. That is so over-promising.

<comment><USER29> Tesla has never claimed "driverless" \- the driver has to be there (well, now - earlier firmware versions didn't check for weight in the driver's seat). What they did do is market it as "autopilot", which means different things to different people - in an airplane, "autopilot" merely flies the plane into the direction and altitude set by the pilot - it does not avoid other aircraft, take commands from ATC, or anything like that. So, technically, calling Tesla's auto-steer "autopilot" is pretty accurate. The problem is that most people being unfamiliar with aircraft systems think of autopilot as "something that flies the plane on its own" and analogizes that to driverless cars.

You've never flown in a pilotless airplane. Autopilot is not AI.

</comment></comment></comment><comment><USER30> > You don't have to buy a Tesla. You don't even have to like the cars.

If only that were the case. It seems to me that more likely when someone says Teslas are too expensive, or not practical they get attacked as luddites and imbeciles.

</comment><comment><USER31> Ever since I started driving in US streets, I've been shocked and terrified at the amount of people checking their cellphones in dangerous situations. Inching the car forward at a traffic light without even looking forward, texting doing 70+ mph on a bridge, yelling at their kids in the back seat, changing lanes without looking at their blind spots...

I'd really prefer if those vehicles were driverless instead. And mine as well.

</comment><comment><USER32> 0.76 fatalities for 100 million Tesla autopilot miles driven? Is that extrapolated?

<comment><USER33> Not sure what you mean by extrapolated. It doesn't mean that 0.76 people died, it means that 1 person died after 130 million autopilot miles were driven.

</comment></comment><comment><USER34> Best quote:

"These individuals are assisted in their quest by a media that long ago decided that it was completely okay with killing the society on which it parasitically feeds."

</comment><comment><USER35> When Tesla stops building "someone may die" into their decision matrix, I'll consider buying a Tesla.

<comment><USER36> By the same logic you should never buy a car period.

All forms of transport have to accept the possibility of fatalities to a certain extent. The test for Tesla is are they safer, not are they perfect.</comment></comment>


Supporting employees engaged in open source - <AUTHOR> https://opensource.zalando.com/blog/2019/02/Open-Source-Harassment-Policy/ <comment><USER2> This title feels very misleading. It seems to center around a "harassment policy" rather than encouraging employees to contribute to open source or paying them to do so.

<comment><USER3> I agree. A policy is in place just to make sure that the company does not get into trouble. To encourage employees do do open source work does not really require a policy.

<comment><AUTHOR> The policy is not the only thing provided, work time, resources, promotion etc is already available to employees.

And no, participation does not require a policy - except for those groups that worry about potential harassment - and these groups are drastically underrepresented in OS.</comment></comment></comment>


Another Reason to Avoid #includes in Headers - <AUTHOR> http://blog.knatten.org/2012/11/09/another-reason-to-avoid-includes-in-headers/

<comment><USER2> > So please try to move your _#include_ s down into the cpp files whenever you > can!

It's OK within your code, but not in your public interface. For example:

      Type& GetValue();

Sure, you don't need Type to be fully defined when you declare GetValue. But it's very likely that your users will need it when they use your function. So, please, for their sake, have your header files include everything _they_ will need, and not only what _you_ need. Thanks!</comment>


As Devs, what can we do to improve the gender diversity in tech community? - <AUTHOR> https://hashnode.com/post/as-developers-what-can-we-do-to-improve-the-gender-diversity-in-tech-community-cjetunnjs0027cws2cjqrxb74 <comment><USER2> I'm just wondering, is it really that bad at this point? It seems like most major players in the tech space work fairly hard towards diversity (See: Google, YC).

I'd love to hear someone closer to the Valley's opinion.</comment>


Ask HN: Why 'MacBook-Pro' in my terminal changed to 'Huawei'? - <AUTHOR> Hello. Recently I bought a new MacBook Pro 16 in Russia. This morning my terminal changed the prefix in front of each command:
"user@MacBook-Pro" to "user@HUAWEI_Mate_20-1a2d"
Does it mean that my MacBook is fake? Did the following: - Compared serial on macbook and "system information" on "checkcoverage.apple.com" - <USER2> - Compared exact hardware config matching official resources - Compared that manufacturing date of my battery is less than manufacturing date of macbook (via coconutbattery)
Does anyone know any way to validate the mac or the cause of this weird change? <comment><USER3> > _Does it mean that my MacBook is fake?_

There's not really a market of fake MacBooks that someone can buy (outside of China and from a legit store, none the less), and think they're an Apple product. It's very hard to make a fake one to a quality that will convince anybody with any familiarity with the platform and leave enough room for profit (from materials to unibody construction, precision etc).

The @MacBook-Pro part is the name of the machine. Perhaps the name changed? Maybe you've set it to change through DHCP, whenever a new connection tries to assign one?

<comment><AUTHOR> Those were default Catalina settings that I do want to change now.

Low price for this macbook + "@Huawei*" really scared me, hehe

</comment></comment><comment><USER4> Maybe it's just the hostname. Try 'hostname' on the terminal and see if [https://www.howtogeek.com/tips/how-to-change-your- computer-n...](https://www.howtogeek.com/tips/how-to-change-your-computer- name-on-mac-os-x/) makes a difference.

<comment><AUTHOR> Wow. You're right. I was on the train WiFi and the terminal smh changed it. Switching it off and restarting terminal solved the issue.

Thanks! Probably, Should learn more about operating systems

</comment></comment><comment><USER5> Just to rule things out, do you have a Huawei phone?

What version of Mac OS are you running?

What shell are you using? Bash or ZSH?

What terminal application are you using? Iterm2? The stock terminal app?

<comment><AUTHOR> I do not have Huawei phone and I'm running Catalina. Using Terminal as I have nothing installed on it yet :)

It happened because of WiFi I was connected, still not sure how it exactly works. Thanks for reply

</comment></comment><comment><USER6> I would guess that the owner of the Huawei phone was spoofing their mac address</comment>


What do physicists believe are the benefits of studying string theory? - <AUTHOR> https://www.quora.com/What-do-physicists-believe-are-the-benefits-of-studying-string-theory?share=1 <comment><USER2> I don't know enough information to know either way. I was told by someone to read the book "Not Even Wrong" which goes into the history of the scientific community and string theory.

I've read the first chapter or two and it seems worth checking out.</comment>


Show HN: Coward.js – Back off AJAX polling interval when something goes wrong - <AUTHOR> https://github.com/jensenak/coward <comment><AUTHOR> I know this is pretty small compared to many of the projects posted here. I'm just getting into Javascript and thought this would be useful in a lot of places. I'd love any feedback people have to give.</comment>


Problem Solving with Algorithms and Data Structures using Python (2015) - <AUTHOR> http://interactivepython.org/runestone/static/pythonds/index.html <comment><USER2> If you enjoyed this, I _highly_ recommend also giving this a try: [https://github.com/donnemartin/interactive-coding- challenges](https://github.com/donnemartin/interactive-coding-challenges)

It's in the same spirit, has some things covered in even more detail and it even has tests you can run on your solutions to verify correctness and instantly receive feedback.

<comment><USER3> Thank you! This is amazing material!

</comment></comment><comment><USER4> I'm one of the students of Brad Miller, creator of this platform, and worked on developing it for a summer. Feel free to ask questions!

<comment><USER5> Hey, this is a wonderful concept. I am a self-taught web dev who works mostly in Python, and I've just begun to learn algorithms & data structures.

What chapters to you think I, or someone like me, would get the biggest kick out of?

<comment><USER6> It is rather short and I would suggest going through all of it. It won't take long. Plus don't forget the exercises.

<comment><USER5> I will, thank you.

I asked more to hear the author's opinion about which of the concepts are most directly applicable/related to web development so I can start with those (feel free to answer if you know!).

<comment><USER7> Depends what you mean by web development. If you describe the tasks you work on, I can make some suggestions.

Otherwise, the only reasonable answer is [http://norvig.com/21-days.html](http://norvig.com/21-days.html)

<comment><USER8> This is awesome link which will guide everyone who is hunger

</comment></comment></comment></comment></comment></comment><comment><USER4> Also, Interactive python is open source! If you like it, help make it better!

[https://github.com/RunestoneInteractive](https://github.com/RunestoneInteractive)

<comment> git-pull Thank you for releasing [https://github.com/RunestoneInteractive/RunestoneServer](https://github.com/RunestoneInteractive/RunestoneServer) under a permissive, MIT license.

Any reason to keep [https://github.com/RunestoneInteractive/RunestoneComponents](https://github.com/RunestoneInteractive/RunestoneComponents) GPL?

<comment><USER4> I'm not sure. You could ask Brad Miller (@bnmnetp on twitter) to find out. Runestone is his creation.

</comment></comment></comment><comment><USER9> I'm about to complete Introduction to Computer Science with Python on Edx {about to begins it's Algorithm lecture week}, should I begin reading this book after it or should I dive into other things?

Does the book constitute of "Data Structures I & II" and "Algorithms I & II"?

I have degree in non computer science field and want to become a software developer.

<comment><USER7> Those class titles are somewhat arbitrary and mean different things to different people. After you finish the Edx class you can skim the table of contents here and decide what to read.

That said, reading the same topic from different authors is still valuable.

</comment></comment><comment> git-pull It's more than a book.

If you click into a section, you can run the python code and get the output.

</comment><comment><USER10> I really appreciated this resource for learning Python for interviewing.

My only criticism is in some cases particularly with the more advanced structures (graphs, trees) it approaches the matter as a literal translation of "data structures with python", as opposed to "pythonic data structures". A lazy example is probably Linked Lists which don't really serve any purpose in Python. Presumably that was the intention?

<comment><USER4> This book is used as the second course in the CS program at Luther College. At this point in the program python is the only language that students are assumed to be familiar with. The point of this book is to gain an understanding of how these data structures behave rather than implementing them in perfect python, so your critique is absolutely warranted. I'll suggest a "Pythonic data structures" version of the book to Brad for those looking to learn good python conventions.

</comment></comment><comment><USER11> I would like to add that the visual component of interactivepython.org seems to be:

[http://www.pythontutor.com/](http://www.pythontutor.com/)

Which is great as a visual learning aid especially for things like recursion as it allows you to step through your code a stack frame at a time.

<comment><USER12> Hey my class (CS61A) uses that!

</comment></comment><comment><USER13> Anyone know what version of Python is this in? It's hard to tell since it's not mentioned in the book. Try doing import sys on the example frames doesn't work either. Trying to see if it aligns with the version some of us use at work.

<comment><USER14> I believe it is Python 2.7. But I could be wrong.

<comment><USER15> Even if it is, it follows conventions compatible with 3.x, e.g. using parentheses with print statements.

Also, in the "Review of Basic Python" chapter, it explicitly links to the official Python 3 docs: [http://interactivepython.org/runestone/static/pythonds/Intro...](http://interactivepython.org/runestone/static/pythonds/Introduction/ReviewofBasicPython.html)

</comment></comment></comment><comment><USER16> We used this for an introductory programming course in university. Very informative.

</comment><comment><USER17> I'm currently studying python so this is going to come in handy, awesome.

</comment><comment><USER18> I prefer [http://rosettacode.org/](http://rosettacode.org/)

</comment><comment><USER19> Github version of this would be awesome! To fork this and keep. Is it available?

<comment><USER4> [https://github.com/RunestoneInteractive](https://github.com/RunestoneInteractive)

</comment></comment><comment><USER20> I have used this. To prepare for my interviews and it definitely helped. Kudos.

</comment><comment><USER21> Is there a java version of this?</comment>


There's no better place than oceans for cleaen power. Why'd it take us so long? - <AUTHOR> http://www.slate.com/articles/business/the_juice/2015/10/block_island_wind_farm_off_rhode_island_finally_brings_wind_power_to_america.html <comment><USER2> LOL, that is Wrong. Look up Liquid Fluoride Thorium Reactors. This is the Cleanest most useful power source for it's by-products. P238, U233-U235, and runs on the most accessible and abundant stuff on earth.</comment>


Announcing Glitch for Visual Studio Code - <AUTHOR> https://glitch.com/culture/announcing-glitch-for-visual-studio-code/ <comment><USER2> This is something we've been working on for a few months, and we're excited to have it available in preview to try out. Let us know if you have any feedback!</comment>