Arguments against JSON-driven development - <AUTHOR> http://okigiveup.net/arguments-against-json-driven-development/ <comment><USER2> > The fundamental advice on Unicode is decode and encode on system boundaries. > That is, you should never be working on non-unicode strings within your > business logic. The same should apply to JSON. Decode it into business logic > objects on entry into system, rejecting invalid data. Instead of relying on > key errors and membership lookups, leave the orthogonal business of type > validity to object instantiation.

This right here is the correct approach. Serialisation formats should be serialisation formats, whether they be JSON, S-expressions, protobufs, XML, Thrift or what-have-you; application data should be application data. There are cases where it makes sense to operate on the serialised data directly, for performance or because it makes sense in context, but in the general case operate on typed application values.

<comment><USER3> Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods.

By the same token, in Lisp, Sexprs aren't a serialization format. They're a notation for the linked cons cells that Lisp data is made of. In Lisp, that Sexpr will be crawled for data, or maybe even executed.

So while in Python, both may _seem_ to be serialization formats, they aren't.

Either way, if the application programmer has any sense, they'll abstract away the format of their data. In a lisp app, you won't be cdring down a sexpr, you'll be calling a function to grab the necessary data for you, usually from a set of functions that abstract away the underlying sexpr implementation, and treat whatever it is as a separate datatype.

Of course, the sexpr might have been fed to an object constructor. Heck, it might _be_ an object constructor, or a struct constructor. All of those types typically provide O(1) access, and autogenerated access functions, so it's the same story.

<comment><USER4> From the official source: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. "

[http://json.org/](http://json.org/)

It's nothing about pressing into service. This is the authoritative source.

<comment><USER5> From the official source: "Democratic People's Republic of Korea"

[http://www.korea-dpr.com/](http://www.korea-dpr.com/)

It's democratic, and for the people. It says nothing about being a totalitarian dictatorship.

Not everything is/does what it says on the tin. You don't have to agree with official or otherwise authoritative sources without question.

(not that I wish in any way to compare Mr Crockford or whoever runs json.org with DPRK or its leadership - I'm just using a deliberatly extreme example to highlight that what is written may not be what is, at least not from absolutely everyone's point of view)

<comment><USER6> I hope you feel clever, because in context, this is far too inapplicable to the discussed reality of JSON to be an actual point.

<comment><USER5> _> I hope you feel clever_

I generally do, thanks, though I'm not any sort of genius by any measure.

 _> because in context, this is far too inapplicable to the discussed reality of JSON to be an actual point._

You seem to be missing a bit of an intentional context switch. The comment was more about the logic of the GP's response to "<something> isn't really X" which was "yes <something> is X, it says so on <something>'s home page", than it was about <something> or X in particular.

So it was relevant in the context of the discussion and the facts being used for reference but not, as you call out, in the context of _the subject of the discussion_ (hence my somewhat defensive clarification of intent in the last sentence)

</comment></comment></comment></comment></comment></comment><comment><USER7> I'm not entirely in agreement.

Use of object-oriented programming paradigms here would merely distribute the logic that is necessary to achieve the desired mapping over multiple points in the code.

The example function presented is only marginally too complicated. I'd split it in two: one to obtain the book list given the same arguments as the example function, and one taking the result as its only argument to build the mapping.

I find myself shying away from rigorous adherence to encapsulation more and more these days. I prefer small functions that operate on data explicitly.

Edit: and I'm a bit confused how the example has anything to do with "JSON- driven development", other than the coincidence that a hash/dictionary is the core data structure being manipulated here. This example function could exist and be (mostly) reasonable had JSON never existed. I'd expect to see an argument that the JSON serialization schemes that abound are problematic, given the title.

<comment><USER8> This. I've been programming this way for over a decade. Long before JSON was a thing. I find I rarely need anythng more than a list or a dict for most of the data manipulation I do. Being on the web has only strengthened my tendency for this, since everything ends up being stringly typed anyways. Nearly every function/API I write is: get some data from somewhere (hopefully serialized), manipulate the data, return data (very possibly serialized). Nearly every time I've seen coworkers try to improve things with classes, it complicates the code, and often adds little encapsulation given how much we do is reliant on external data sources.

Every once in a while I think how nice it would be to be able to use typed data and smart setters to avoid much of the bounds checking I have to do, but I find there's never enough code between the boundaries of serialization to make it worth the added complexity that this introduces (also my problem domain involves mostly copy so most things are basically strings, ints, or datetimes anyways).

<comment><USER9> Lists are lists, and I have no issues there. It's dicts as objects (often nested) where things to get hairy. I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break (or explode in a ball of fire).

The more systems I've built, the more I've wanted to have very well-defined seams between "inside" and "outside" \-- well-defined interfaces with external APIs, libraries, databases, systems that may be maintained at a different speed, etc. Having an explicit translation/serialization/etc. step forces you to do this. It's not the only way, but pretty much every codebase I've interacted with that doesn't do this gets careless, and it's can get really messy when things get any longer than a "script".

<comment><USER10> > I often see folks end up relying on internal implementation details of other > libraries, or other data sources, and things can subtly break

I'm not sure how you can get around this as a consumer of a service? How do you know what is an internal implementation detail? Why are they exposing implementation details?

As a producer of a service there are lots of techniques. E.g.

\- Only expose data and provide a spec for that data.

\- Provide "helper" classes in target languages for consumers to use

\- Publish an API spec + gaurantees

\- Always maintain backwards compatibility

<comment><USER9> As a consumer, you're not going to get around it. But what you can do is quarantine it to a specific area within your application. I find dependencies to be a very natural place to divide up an application -- at the very least, to consider "What would have to change if I ripped this thing out entirely?". "What are the methods I would need to implement?", etc, and writing a translation layer implementing that interface.

As a hypothetical, let's say you needed to implement a binary persistence layer in your application. Rather than interacting with S3 in 10 different places, you define a "BlobStore" interface with the methods that you need, code against that interface, then implement an S3BlobStore that handles the calls to Amazon using whatever library necessary.

</comment></comment></comment></comment></comment><comment><USER11> I disagree with the anemic object argument. If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. A large portion of back-end services are CRUD and data wrangling operations anyway - as in, convert data format A to data format B (which I guess could be a constructor or factory method if you're comfortable with having the conversion logic in a data class).

<comment><USER12> > If an object is just there to store data and no behavior

Then why do you have it at all?

<comment><USER13> To define a valid shape for related data.

</comment></comment></comment><comment><USER14> The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class".

I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata won't catch everything (they have to have a lowest-common-denominator notion of type) but distributed bugs are the hardest bugs to track down; anything that helps you spot a bad network request earlier is well worth having.

<comment><USER15> An article about the "attrs" library was posted here a couple weeks ago. Really highlighted the tedium of Python objects while offering a neat solution.

[https://glyph.twistedmatrix.com/2016/08/attrs.html](https://glyph.twistedmatrix.com/2016/08/attrs.html)

Regarding protobuf, I'm a bit disappointed with the direction of version 3. Fields can no longer be marked as required - everything is optional; i.e. almost every protobuf needs to be wrapped with some sort of validator to ensure that necessary fields are present. I understand the arguments, but I did enjoy letting protobuf do the bulk of the work making sure fields were present.

<comment><USER16> Required fields are bad; don't use them.

 _You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead._

[https://developers.google.com/protocol- buffers/docs/proto#sp...](https://developers.google.com/protocol- buffers/docs/proto#specifying-field-rules)

<comment><USER14> They're a tradeoff. Sometimes you really are confident enough that this attribute will be required forever that the saving of not having to write custom validation is worth it.

</comment></comment></comment></comment><comment><USER17> This basically repeats the ORM arguments/counter-arguments, but now it's a slightly more complex data structure instead of the DB-row-as-hash/array you get there. "row-driven" in this context often leads to barely wrapped DAO Objects.

On the other hand, sometimes (surprisingly often) a hash is good enough and the effort spent in modeling the database (...) doesn't need to be replicated.

And as with ORMs/SQL generators/DAOs/etc., there's a whole spectrum of solutions and you really have to look at the task to see what's appropriate...

</comment><comment><USER18> This isn't JSON-driven development, it's just choosing to apply logic over loose-typed data structures instead of named constructs. It's more awkward in Python because it doesn't have sugar syntax to index an object like JavaScript has.

But using clean built-in data structures instead of named types has its benefits especially if you need to serialize for persistence of communication as it doesn't require any additional knowledge of Types in order to access serialized data, so you can happily consume data structures in separate processes without the additional dependency of an external type system that's coupled and needs to be carried along with your data.

This is why Redux uses vanilla data structures in its store or why JSON has become popular for data interchange, any valid JSON can be converted into a JavaScript object with just `JSON.parse()` which saves a tonne of ceremony and manual effort then the old school way of having to extract data from data formats with poor programatic fit like an XML document into concrete types.

If your data objects don't need to be serialized or accessed outside of the process boundary than there's little benefit to using loose-typed data structures, in which case my preference would be using classes in a static type system to benefit from the static analysis feedback of using Types.

<comment><USER19> > as it doesn't require any additional knowledge of Types in order to access > serialized data

You still need to know the shape of the data you're working with, or you won't get anything useful done. So you can't skip defining types or a format, you're just skipping the tools that help you follow said format.

<comment><USER18> You only need to know how to access the data you need, not the entire class structure that's coupled to the monolith that created it.

</comment></comment></comment><comment><USER20> Anemic objects and whether they are harmful or harmless has been debated in software engineering for long.

I find over-relying on encapsulation more harmful than useful nowadays specially if you are going to write scalable software that are inherently distributed. For example, hiding accessing a database behind a simple getter function makes another programmer ignore performance implication and other issues that may arise.

<comment><USER3> Yes, but OTOH, it lessens the likelyhood of errors, and means you'll have to rewrite minimum amounts of code when you, say, switch from MySQL to Postgres.

Abstraction always lessens awareness of that which is abstracted. Decide where to draw the line for your app.

</comment></comment><comment><USER21> It sounds to me like these arguments aren't so much against JSON, per se. They're against using JSON.parse() (or json.loads() in Python, json_decode() in PHP, or whatever) as your entire data-import process.

Instead, the argument goes, one should load the JSON, walk the redulting structure, and use it to build your native data structure/objects/whatever. Similarly, when the time comes to save, you crawl through your native structure to build a dict/array/primitive structure, then call JSON.stringify() (or the analogous function) to serialize that.

Uncoupling your data structure from the serialization format, though, is really just basic good software design anyway, is it not? Does anyone argue in favor what this article calls "JSON-driven development" as a design principle? Or is it just a shortcut that developers -and I am no less guilty of this than anyone else- sometimes take in the interest of getting a quick-and-dirty solution out the door?

Yes, working directly on the output of JSON.parse() is a code smell. But I'm not sure that claiming there's a rising trend of "JSON-driven development" is entirely founded. It's just people taking shortcuts.

<comment><USER22> This. "${PRACTICE}-driven development" suggests a practice that someone actively pursues because of perceived merit rather than a shortcut taken because of time/resource constraints.

</comment></comment><comment><USER9> With dynamic languages (certainly Python, Ruby, and JS), there's a definite lack of nudge from the tooling to translate from "interchange" format into an internal "smart" format (procedural code + everything is a hash = easy hacks). Whereas with something like Scala, the tools make it very clear that if you serialize/deserialize on the periphery, you're in for a bag of hurt (or, at the very least, fighting with one hand tied behind your back).

This is not to say that one tool is better than the others, but tools do have opinions, and while being more permissive/ambivalent makes throwing together a quick script easier, a tool that nudges you in the direction of building something in a more-sustainable way is useful when building nontrivial systems.

</comment><comment><USER23> While I see the point the Ulaş is getting at, I wouldn't call this JSON-driven development. I think JSON-driven development would use abstraction layers that are based on JSON, like JSON schema, and perhaps an OOP library that leverages it.

What I'd actually call this problem is a lack of abstraction. In functional programming, simple data structures are often preferred, and composable functions are used to manage complexity. A functional programmer might declare a function `to_structured_dict(enumerable, path)` and call it with `to_structured_dict(book_list, path=('shop_label', 'cell_label, 'book_id', count'))`

<comment><USER3> And then EVERY programmer would further abstraact that, as you really want the bare minimum of your code depending on your datastructure internals.

</comment></comment><comment><USER24> If you're in Python, and are afraid of "anemic" objects, I would recommend checking out collections.namedtuple. It's a fantastic lightweight and performant object-like data structure.

You also get a few additional features, such as in-order iteration, the parameters are fixed at run time, and there's a method for turning it into an ordered dictionary (which is serializable in, wait for it, JSON).

<comment><USER25> If you're not limited to the standard library, [https://github.com/hynek/attrs](https://github.com/hynek/attrs) is also worth taking a look at.

<comment><USER26> I just found out about it in this article, and already posted a new story (it looks that good):

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

</comment></comment></comment><comment><USER27> > Once you go dict, you won't go back. This style of development is too easy, > since dictionaries are baked into Python, and there are many facilities for > working effectively with them.

How is this an argument against using dictionaries?

After 10 years of Python development, I do find myself using dictionaries rather than objects, in just the way that the author proscribes, but I'm finding it to be a genuine pleasure.

<comment><USER28> And what happens when one of those keys changes?

<comment><USER29> You change your code. Loose coupling a nice goal to aim for, but at the end of the day, somewhere deep down inside the code, you have to tightly couple to actually get anything done. Where that transition occurs is entirely programmer's discretion.

<comment><USER28> But there's a difference between changing it once when you serialize/deserialize it, and changing it every time you try to access the key.

<comment><USER7> Writing the code with the assumption that a key will change is on the same level with premature optimization, in my opinion.

It might be reasonable to make the assumption for some keys. In these cases a function taking the data and key as arguments and returning the value is sufficient and appropriate.

Frankly, if the code base is so littered with references to that specific data and key combination it might actually indicate a poor design.

<comment><USER28> "Writing the code with the assumption that a key will change is on the same level with premature optimization, in my opinion."

Considering how easy it is, and how often I've had keys change on me, I have to strongly disagree.

"Frankly, if the code base is so littered with references to that specific data and key combination it might actually indicate a poor design."

That's kinda the point of the article.

</comment></comment></comment></comment></comment></comment><comment><USER30> I think this article is somewhat off-base. The problem isn't JSON, it's lack of respect for separation of duties. JSON is just a data exchange format.

Want to program in an OO way using JSON? Easy. Just build a factory to generate objects from JSON input. Put your validation and error handling right there. Now you can get a known valid object from the JSON, a class instance with all the encapsulation and business logic your heart desires. Need to share it with the outside world? Provide a JSON output method.

Translating data formats is at the heart of day-to-day programming. It ain't rocket surgery. Fix the problem, not the blame.

(And if you think JSON sucks, believe me, you never dealt with data file formats from the pre-XML days!)

<comment><USER31> The author isn't saying the problem is JSON.

The same programming style exists quite a bit in older PHP code as well. This is because one of it's primary data types is an list/hashtable hybrid. And JSON is similar -- it promotes those same structural types; the list and the hashtable (array and object, respectively). So programmers are using them, not just for building structures for data interchange, but for actual programming logic.

The fix for the problem is just education.

</comment></comment><comment><USER32> There is so much wrong with this blog post that I don't even know where to begin. He appears to have included Python-specific details in his list of why he hates lists and dictionaries. Apparently Python throws exceptions if a key doesn't exist and seemingly has no Maybe/Option alternative? I don't know if that is true or not.

He claims using lists and dictionaries means you lose encapsulation - does it? A smarter programmer would realise that actually it entirely depends on the _types_ you are storing in those data structures.

</comment><comment><USER33> The rule of thumb I've always used for when to use OO is "will there be more than one extant object at once or not?" If yes, and especially if these objects need real behavior, then use OO.

If you're essentially going through one object at a time, then discarding them, you're may just be doing conduit data processing, and so there's little advantage to using objects. I think what's missing in this (well-written) analysis is this distinction; if you're slurping data from one place, making a few changes (or especially if you're not making any), then sticking into a DB or vice versa, OO may be the wrong choice.

Ask yourself while writing the code: "are these active, behavior-driven objects that need encapsulation and relatively sophisticated behaviors, or is this just data I'm doing some relatively simple processing on?"

</comment><comment><USER34> The author has lots of good points. Because I write most of my Python in the style he is advising against, I recognize that style has issues. The main issue for me is that a dict of dicts of dicts is not an interface. It doesn't have any constraints. It doesn't communicate expectations for use for the actual intent of the code. The best you can do is a comment explaining what to expect and a lot of error checking.

That said, almost all of the python I write these days is in the form of functional transforms on built-in data structures. And I love it!

There was a great Pycon2012 talk titled "Stop Writing Classes". You can find it linked and discussed here [https://news.ycombinator.com/item?id=3717715](https://news.ycombinator.com/item?id=3717715)

<comment><USER35> Start Writing More Classes: [http://lucumr.pocoo.org/2013/2/13/moar- classes/](http://lucumr.pocoo.org/2013/2/13/moar-classes/)

HN discussion: [https://news.ycombinator.com/item?id=5204967](https://news.ycombinator.com/item?id=5204967)

</comment></comment><comment><USER36> On the one hand I agree with OP on directly interacting with JSON is not really a good idea but on the other hand I completely disagree with that behavior should be shoved into data objects. Also I think part of the problem is Python doesn't have much typing (I know they recently added optional typing in python but I don't think many use it).

As more of an FP guy I'm firm believer of the separation behavior and data. Clojure's Hickey sort of has a valid point... its freaking data... stop making it complicated to access it.

</comment><comment><USER37> I'm surprised no-one has linked Steve Yegge's Universal Design Pattern – [http://steve-yegge.blogspot.co.uk/2008/10/universal- design-p...](http://steve-yegge.blogspot.co.uk/2008/10/universal-design- pattern.html)

It argues that loosely defined objects are an excellent design pattern, but I'm too tired to decide if it is directly relevant to this.

</comment><comment><USER38> It's called a hash. Or a dict. Or a map. Not JavaScript Object Notation, FFS.

</comment><comment><USER39> At this point everyone should be using an evolvable (thrift, protocol buffers, avro, etc) schema format when they are storing or transmitting their data if they want to run an always on service - there is no downtime for migrations in the real world. Trying to do this ad-hoc with JSON is a lost cause and will eventually lead you to failure at runtime or worse, data loss situations.

<comment><USER40> JSON isn't un-evolvable. In fact, thrift can serialize to JSON.

What makes thrift evolvable in practice is that we don't remove fields and don't add mandatory fields. The same discipline can be applied to JSON definitions.

Well thrift also tags all fields with integers, so a consumer with an older schema can parse a record with a newer schema, skipping the new fields. Of course JSON trivially has this property.

Maybe the key here is "ad-hoc"; something like JSON-schema is needed.

<comment><USER39> Yep, I mentioned below that using JSON as a serialization format is fine but you still need to specify a schema and understand what happens when you read data written by newer/older code.

</comment></comment></comment><comment><USER41> At least lists, dictionaries map relatively well to a tabular (SQL) format. Objects don't map well at all! Anyone who's spent enough time with "mature" ORMs knows this. Especially when there's a deadline and you have to write "native" SQL just to get whatever the hell you needed in the first place. "Well maybe you should have read everything and understood the ORM to its most minute detail..." NO! That's the whole point of abstraction! If I understood everything about that code, I'd be better off re-writing it to better suit MY specific problem. Look, I don't want to be another OO basher. OO definitely has a place in complex systems like game development, where the lives of the objects are longer than a page refresh. But in web dev, its becoming increasingly obvious to me that the OO paradigm is a huge time suck. /rant

<comment><USER42> I feel like we have this discussion at work daily involving nhibernate. It is an abstraction that makes 80% of work quicker and easier, but what it makes easier and cleaner would have been trivial anyways.

</comment></comment><comment><USER43> Lots of religion in this thread!

I think the point is, if json is your data exchange format it _could_ be bad if you let that structure propagate into your application.

so in general you should prefer :-

json => <chosen languages best form for dealing with data>

over json => <chosen languages tools for dealing with json>

Different languages are going to have different mechanisms. Some languages you may abstract from json completely, some languages may natively deal with json, and your persistence layer may deal with json also.

So what you need is a well considered design that takes advantage of your chosen languages philosophy / mechanics, whatever that may be. There is no one way to design anything. The thing to avoid is - not working out how to structure your code to make things easy / appropriate to the task at hand. That path leads to messy code.

</comment><comment><USER44> I find that code that uses dictionaries a lot ends up with mysterious unnamed types used in various places throughout the system disguised as dictionaries. They have required fields, and must interacted with using business logic that is not obvious. This becomes a real problem when the original authors of the system are gone, and new maintainers have taken over and have to implement new features.

By using objects, or lightweight objects like namedtuple, which have already been mentioned in other comments a bunch, you formally document the data- structure. You give it a name, expected fields, and required behaviours when interacting with it. The code becomes much easier to follow and understand clearly. Bugs don't creep in when a new maintainer forgets about the mysterious undocumented required business logic.

</comment><comment><USER3> For crying out loud, you don't have to build an object hierarchy around the thing (although it would make sense to in this case), but at least have the common sense, or the sense of shame, to abstract away data lookups into separate functions. That's data structure abstraction 101.

</comment><comment><USER45> I take a couple of issues with the author here. I don't personally worry much about breaking away from strict OOP. When a pattern like this develops it is usually because the data is too dynamic for a static property list. An obvious example is for creating reports. No one is going to sit down and hand design every single multi column report in a large project (I tell a lie, people do, it just makes the code base a horror show). By letting the data be more dynamic (Usually with JSON) it is trivial to create generic report structures and populate them.

Additionally, if you are using NoSQL as a backing store then solutions like class serialization don't make any sense since you will need to communicate in JSON anyway.

</comment><comment><USER46> The code in the example has poor encapsulation, but I do not think it's the "JSON" style that causes that.

Much OOP code includes a hodgepodge of exposed internal state and methods that offer a combination of derived state and behavior to mutate that state.

Often, using data literals (like JSON) can make code clearer by making it explicit what is going on with state (when/if it is being mutated), and making the system easier to snapshot, test, etc.

While much code that uses JSON-like constructs is overly verbose and error prone, adding a bit of structural typing (with Flow) or creating schemas to ensure system invariants (jsonschema) can lead to a system that is easy to reason about and maintain.

</comment><comment><USER47> Use GraphQL or Really stick with RESTful routes. The more predictable the schema of these Dictionaries/hashes/JSON are the less likely you are to see that mess above. This is true whether you are using a FP approach or an OO approach. Using an Imperative coding style when doing ETL will always be hairy.

That function also violates the Single responsibility principle. I wouldn't even know where to begin to write a unit test for that other than breaking it down into smaller parts. There are design patterns that could be followed in dynamically typed languages that would avoid that mess altogether other than just OO.

</comment><comment><USER48> Coupling your code to the JSON you receive over the web can lead to some interesting problems. If the system on the other end decides to make some change you are not expecting, it can lead to errors.

In JavaScript, a simple thing that helps is to use lodash.get and provide a path to the property you are wanting.

      lodash.get(someObject, 'path.to.a.property')

If the path isn't there, the lodash.get returns undefined. This is much nicer than getting the error "Cannot read property 'to' of undefined" when "path" isn't there.

<comment><USER26> Yeah, this is currently pretty bad in Python, which led me to create the jsane library:

[https://pypi.python.org/pypi/jsane](https://pypi.python.org/pypi/jsane)

>>> j = jsane.loads('{"foo": {"bar": {"baz": ["well", "hello", "there"]}}}')

>>> j.foo.bar.baz[1].r()

u'hello'

</comment></comment><comment><USER49> Yes, any useful technology will get over-applied, at the detriment of better ways to do things.

Not the fault of the technology, but of the developer who failed to consider alternate ways of accomplishing the same task.

</comment><comment><USER50> JSON is best when it's solely used for serialization (or config files).

Using it deep into the project makes no sense, the first step in handling JSON should always be to code it into native data structures.

<comment><USER51> The point made here seems to be that often, these native data structures are dicts and lists, because that is JSON. Meanwhile, you'd often want something else when looking at only the internals.

</comment></comment><comment><USER52> I think the "anemic objects[domain model]" is a red herring in this case. It would be much cleaner to create separate serialized and deserializers that convert your actual domain models to JSON and back. By the time you are doing something as shown in his example like building a book inventory it should be all proper objects and no primitives dictated by what should be the serialization layer.

Edit: Fixing phone auto correct typo - "property objects" -> "proper objects"

</comment><comment><USER53> I actually saw this coding style _way_ before JSON, for example at Apple. I even jokingly created DUKE: Developers United against Keyed Everything.

Another place I see this is in the eternal dynamic/typing debate. A lot of the criticism of dynamic typing will be with examples from JavaScript, Ruby, Python and maybe even PHP. Hardly ever from Smalltalk (or Objective-C), because Smalltalk code tends to not have the types of problems cited. This puzzled me for a while, because I also find these languages somewhat less "solid", yet couldn't quite put my finger on why.h

That is, until I realised that all of these languages use hashes as their basic object representation. Coincidence? I think not. So I coined the term "hash language" for these languages, both because they are hash-based and it appears to be easy to make a hash of things in them, possibly for precisely that reason.

That said, I think it's also a mistake to disregard the power this sort of very generic programming brings, especially once you consider objects composed of multiple facets that are interpreted in different contexts.

IMNSHO, the way to combat hash-programming is to provide powerful and convenient metaprogramming facilities for object representation, so dealing with objects generically is just as easy and obvious as dealing with dictionaries.

Not entirely surprisingly, my own language ( [http://objective.st](http://objective.st) ) has some facilities for this, mostly by making identifiers into first class entities. More research needed ;-)

</comment><comment><USER54> Is the OP familiar with Object.keys()?

You don't have to hard-code explicit dot notation into your code when you're processing JSON or any other hierarchical object serialization format, which is what JSON is.

If you want to make your code more robust, you should process the structure of the JSON document and infer meaning from its keys based upon your position in the tree and of the values of the key names that are meaningful to your application.

This makes it possible to accept any kind of JSON, even if the original format changes, and you won't get uncaught exceptions and your application can decide what to do in a more graceful manner.

You should also centralize the code that is responsible for serializing and deserializing your JSON wire format and creating objects. There's no reason to have ad-hoc code in each object constructor like his example. A good example of such a thing is dnode [https://www.npmjs.com/package/dnode](https://www.npmjs.com/package/dnode). It handles all the JSON abstraction (in this case for RPC) and you don't even need to worry about the JSON ever again.

This has nothing to do with JSON and more to do with poor design and tight coupling of interfaces.

</comment><comment><USER55> I may be missing something, so I'd appreciate a correction, but why all that effort when you can use collections.namedtuple and a custom object_hook for json.loads?

        import json
        from collections import namedtuple

        data = '{JSON string goes here}'
        fancy_data = json.loads(data, object_hook=lambda d: namedtuple('X', d.keys())(*d.values()))

</comment><comment><USER56> I agree with this and I've raised it several times in Objective-C codebases that can some times end up littered with NSDictionary:s everywhere taking no advantage of the Objective-C type mechanics. I don't think it's necessarily as bad in python or javascript. This is because these languages are dynamically typed and that diminishes the benefits of deserializing json to a native model. It's still valuable because you can guard against bad data by rejecting at the boundary of your program.

In statically typed languages however the added bonus is a lot more significant because the type system increases the benefits of deserializing JSON to native models. Take this Swift example

        import Foundation

        enum SerializationError: ErrorType {
            case InvalidData
        }

        struct Thing {
            let a: Int
            let b: String

            static func deserialize(fromDictionary data: [String:AnyObject]) throws -> Thing {
                guard let a = data["a"] as? Int, let b = data["b"] as? String else {
                    throw SerializationError.InvalidData
                }

                return Thing(a: a, b: b)
            }

            static func deserialize(fromArray data: [[String: AnyObject]]) -> [Thing] {
                return data.flatMap {
                    try? deserialize(fromDictionary: $0)
                }
            }
        }

        let data: [[String: AnyObject]] = [
            [
                "a": 10 as NSNumber,
                "b": "Hello" as NSString
            ],
            [
                "a": "10" as NSString,
                "b": 10 as NSNumber
            ]
        ]

        let models = Thing.deserialize(fromArray: data)

Not only do you end up with a native array of models you can also be certain that any type information is correct because invalid results have been thrown away during parsing.

<comment><USER57> It's good to use lots of NSDictionary's in Objective C, in my opinion. The alternative is to create lots of different object types that takes much more code, and very little benefit for that extra code. If you're just shifting data around then there's no need to define objects for them.

</comment></comment><comment><USER58> This is what keeps dragging me back to moose & perl5. You describe the attributes of a class, the constructor for that class is created for you, and you can pass in hashes and it will automatically instantiate (and fail if the rules you have set for attributes are not met).

I've found that you can kinda sorta do the same with other languages (python/ruby/javascript) by writing static factory builders inside the class that do this checking for you and raise an exception or return an object for you, but it still doesn't compare to me to Moose/Moose::Util::TypeConstraints::coerce/subtype and attributes with the coerce option set. It makes it so easy to coerce a deep json object into a deep class structure.

I always try to hunt down things that are similar in other languages (python allows named arguments from a dict, IIRC, and that allows similar things, but you still have to write the constructor yourself), but I've yet to find something that makes it as simple.

</comment><comment><USER59> If he used tuples as keys to the dict, he wouldn't have this absurd code and the article wouldn't have been written

</comment><comment><USER60> And this is where we end up without easy to use and well supported schemas...

If this was XML, you'd write a very simple RELAX NG grammar (use the compact syntax: [http://relaxng.org/compact- tutorial-20030326.html](http://relaxng.org/compact-tutorial-20030326.html) ) that describes the structure of the incoming data, then use it to validate the input data before processing it.

After that, you know data is valid and in the right structure, so you can throw away most of the "is this in the right place?" checks.

JSON and YAML's various schema implementations can't hold a candle to this, and it's been around for over a decade.

The XML ecosystem does have some very bad parts, but it's not all bad, so it's worth learning from places where it actually works well.

<comment><USER61> In Java land, swagger + dropwizard validation do a rather good job of this with json. I wouldn't be excited to return to using soap/xml all the time.

</comment></comment><comment><USER62> This is space that the Clojure community has already visited.

<comment><USER63> And every other Lisp community.

<comment><USER64> And what was their outcome?

<comment><USER65> heat death.

</comment></comment></comment></comment><comment><USER40> I agree that the supplied code is improvable. Consider this:

      def set_r(adict, keypath, val):
        key = keypath[0]
        if len(keypath) == 1:
          adict[key] = val
          return
        if not key in adict:
          adict[key] = {}
        set_r(adict[key], keypath[1:], val)

      def build_book_inventory(book_ids, shops):
        shop_labels = [shop['label'] for shop in shops]
        books = Persistency_books_table_read(
          shop_labels=shop_labels,
          book_ids=book_ids)
        inventory = {}
        keys = 'shop_label cell_label book_id'.split()
        for book in book_list:
          keypath = [book[k] for k in keys]
          set_r(inventory, keypath, book['count']
        return inventory

First, the author clearly needed "autovivification" as supplied by Perl. We supply a substitute with set_r().

Second, I'd avoid creating local variables like "book_id". It creates mess. We never had the slightest interest in the book_id; it's just part of the wine we are pouring from one bottle into another.

Third, I've preserved (modulo names) the interface of this function but I suspect the surrounding code could also be improved. Also call a list of books "books", not book_list; list is the assumed sequence container in Python. "books=book_ids" is unfortunate; to thrive in a weakly typed language we need variable names that distinguish objects from ids.

Larger point: the author wants to create classes for the various business objects, which is a common enough pattern, but ultimately just makes extra work and redundant lines of code. A relational database can handle a wide variety of objects, with some knowledge of their semantics, without any custom code per-class.

As you know, the difference between dicts and objects in python is mostly semantic sugar. We can easily enough make a class that gives dot-notation access to values in a dict, if one objects to the noisiness of foo['bar'].

If you want to enforce object schema at system boundaries, there are better ways (more compact, expressive and maintainable) than writing elaborate "classes" for each type of object.

</comment><comment><USER66> More generally, using data structures well-suited to your problem is really important but often underappreciated in software engineering. Elegant code and algorithms naturally follow.

In the example in the article, OO seems like a good way to go.

</comment><comment><USER67> From an OO perspective I can completely agree with this and the encode/decode pattern the author is suggesting seems to be the right way to deal with this problem as it will also hopefully translate in having an esperanto data type which can be used for all sorts of APIs and formats.

But from a functional perspective I would disagree. The code example wouldn't even make sense in that world. You would query it as is and compare it with other data or create new structures as with any other data you handle in your language.

</comment><comment> tony-allan I agree 100% with the article.

I've just written a script which makes every one of the mistakes listed in the article. I am consuming a JSON based API in a long ugly mash of code, exactly as described. It doesn't look pretty.

In my defence, I wrote the code as I was trying to understand the API. I had not read ahead and didn't really know which API's I would need or how fiddly it would be to bring it all together.

I am now exposed to pain if the API changes or if anything breaks. Time to go back and tidy up the code!

<comment> tony-allan I went back and fixed the script to turn a portion of the JSON API into a set of useful Python objects. The code looks mostly OK now.

It's no surprise that it took about the same amount of time again to tidy it up. Apart from making me feel better, and a promise of less work in the future for updates, it's hard to justify the extra effort.

</comment></comment><comment><USER68> JSON is the equivalent of a UNIX pipe; it is for passing data between applications on the Internet, just like a pipe is a way for passing data between applications on a machine.

</comment><comment><USER69> In PHP we call it "Array Oriented Programming" ( [http://www.epixa.com/2012/04/array-oriented- programming.html](http://www.epixa.com/2012/04/array-oriented- programming.html) ). So looks like Python developers finally discovered this paradigm too. Let's wait for JS developers now.

By the way, PHP has type hints for functions that help to understand what are the types of arguments and the return type.

</comment><comment><USER70> Pretty much statically typed vs dinamically-typed discussion. It depends on your particular case, if there is a sufficiently defined schema or not

<comment><USER52> I don't see how this is related to statically typed vs dynamically typed. This is more a case of Primitive Obsession [http://c2.com/cgi/wiki?PrimitiveObsession](http://c2.com/cgi/wiki?PrimitiveObsession) and a lack of a adapter/serialization layer.

<comment><USER70> I meant, typed vs not-typed. Someone mentioned Clojure, and for me thats the whole point: on one hand, and for a whole category of problems the best abstraction is not to have a strong schema, given the variable parts. On the other hand however there are scenarios where you already know the structure sufficiently well. A matter of abstraction IMO

</comment></comment></comment><comment><USER71> Just an aside, I'm not sure I agree with the title of "JSON-driven" development.

The problem being described is about using parts of a language in an inefficient or ineffective way of solving a problem.

The solution to this particular problem can be summed up in concepts like encapsulation or DRY. More to the point, let's not blame components like JSON for basically poor implementation.

</comment><comment><USER72> I prefer XML + schema (for which I use RelaxNG + jing) because this makes validating the input very straightforward and normalizes that process. But I understand the appeal of JSON and use it for some APIs myself. What experiences do people have with JSON.net Schema? Does anyone know of a json schema + validator system that is cross-language?

</comment><comment><USER73> There's no particular reason objects can't be serialized as JSON and deserialized back into strongly typed objects.

</comment><comment><USER64> Thankfully there isn't really JSON _driven_ development as a methodology. Its just a bit of a crappy pattern (for many tasks) that far too many people use. Hopefully no one is advocating it as _the_ way to develop software.

</comment><comment><USER74> I like to wrap relevant objects around a type, that is responsible for creating, validating, serializing, deserializing and mutating that object.

But taking a JSON and passing it around, with no ownership, no predictability... it's the mindset of the tech debt programmer.

</comment><comment><USER3> I think the general rule is "validate anything coming in from the internet, ever."

</comment><comment><USER75> I couldn't agree more. My life these days consists 90% of marshalling json around. Hooray for microservices.

</comment><comment><USER76> So we just need references? Let's all switch to XML (just kidding) or YAML (maybe not kidding)!

</comment><comment><USER77> Although I coincidentally mostly agree with the conclusion "encode on entry and decode on exit" I disagree substantially with the rest of the article.

> I know that it's now en vogue to sneer at OO

I don't _sneer_ at it. OO has been the dominant coding religion for most of my career and I rage against the educators and propagandists who spend a decade smothering everyone with it. I curse them for all the time I wasted trying to build classes for my data only to realize that if I had used a simple dictionary or list my code would be shorter, simpler, more robust, and more flexible.

The logic in the article above is all premised on object-oriented religion. OO for OO's sake because OO. Using the power of dictionaries is bad, using the power of objects is good.

> It completely defeats object orientation.

You could just as easily say using objects defeats the point of having lists and dicts.

> It offers nothing of the abstraction powers of object orientation.

Most of the abstraction power of object orientation happens when you create the methods. If you aren't defining new classes, you write functions instead. You still have abstractions, what you don't have is the encapsulation of code with data.

> It doesn't say what it's doing.

Sure it does, and better yet since you are using the standard data types it will be said in a language that any other Python developer is likely understand immediately.

> The above code is filled with auxiliary logic that has nothing to do with > what it actually tries to achieve.

The above code is filled with auxiliary logic because the author of it apparently didn't write any useful functions for operating on dictionaries.

I'm not sure that any of the auxiliary logic in that code has anything to do with the choice to use dictionaries. It's a standard data munging problem that comes from having data from different sources. You have the exact same problem with objects if you didn't write any useful methods for operating on them.

> but done right, it can be very powerful, especially in big and complex > codebases.

And in my opinion, the right way to do Object-Orientation in Python is to _not do it_ until you really know you need it: your code is heading towards big and complex and you need to lock it down and organize the data and methods into well-encapsulated classes. (Although maybe at that point you realize it's not a big deal and don't bother)

Designing around lists and dicts from the start is a much more flexible strategy than trying to get all the encapsulation exactly right on the first try. If you don't have lots of time to spend up front UML'ing an object heirarchy for your big, complex application, you're probably better off sketching and iterating with JSON in mind (and yaml if humans need to edit it). As your application takes shape, it will become apparent where it makes sense to lock down functions and data into objects.

This is especially true given that all of Python's standard types are inheritable classes.

</comment><comment><USER78> Arguments for dict/list driven development:

NOTE: This isn't JSON driven-development, JSON just mimics base types like dict, list, string, numeric etc of all languages and a big reason it is so common especially in Python/Javascript.

\- Large unknown lists/dictionaries data structures can be deserialized into dicts/lists for any language without issue.

Sometimes keys/data are unknown such as large attribute data sets that may always have new keys. In that case strong typing to an OO object will always be broken. Example: a facebook attribute set, keys/data that aren't set will not appear, new ones are added all the time, which would create a cat/mouse serialization/deserialization game. Same problem a binary structure has (offsets) when you really need a flexible keyed structure.

One missing key doesn't break your whole serialization/deserialization system built with strongly typed OO. Validation can be done on accept and _if necessary_ convert into an OO system.

\- If needed, classes that are backed/extended/inherited by a dict/list or set (or composition) that can load in the JSON/dict/lists and only expose the needed values after validation are useful.

i.e. a class that inherits from or composes to Dictionary<string,object> for instance in C# would only fill keys that are necessary for the view data, not a bunch of extra null fields because it might not have that key/property. It also has the ability to deserialize objects that may have new keys. Not everything is a perfect world where data structures are known before-hand.

\- It reduces complexity many times, no need for an OO serialize/deserialize layer when you are passing back as basic dict/list or JSON.

Why add complexity to something simple?

\- Unless you control the server and the client, real-world data structures aren't a perfect map of keys/values to OO properties.

Assuming that is a system ready to break in the real-world many times. Someone adds a field to the DB object then all clients that use it can't serialize/deserialize. Real world serialization/deserialization has to accept in basic types dict/list, validate and then use as needed (some go to OO objects behind scenes). I see too many systems where people just have an EF object and expose that over a web api and just expect it to work, that is a bad example of poor encapsulation. Some fields don't need to be serialized to public apis. In Microsoft land MVVM was created to help stop this practice but still creates two sets of OO objects and breaks on any new keys/data (though breaking here may be desired for strong typing).

\- Dict/list data structures can be easily setup to have cleaner naming and keys without tons of attribute/helpers

i.e. first-name key instead of first_name, FirstName, or firstName. This is more friendly to web/url naming that is common.

\- Noted in the article, less memory used in many cases and highly optimized time in basic lists/dicts.

There are many more reasons...

Dicts, lists and basic string, numeric types are the base of all languages and computer science types. The reason this is common is it is simple to work with these types without added cruft of OO when needed.

OO does add complexity and if it isn't necessary you are just upping complexity for no reason (and memory). It is similar to the complaints of C coders to C++, basic structs and sets are sometimes less complex than C++ OO objects. Same thing with dict/list of some monstrosity of an OO serialization/deserialization system that breaks on every new key or field and you have to update the server and client rather than just increment a version and validation. The longer you code the more you see this.

OO objects should not be used all the time just like dict/lists shouldn't be used all the time.

</comment><comment><USER79> Completely agree.

</comment><comment><USER80> > If an object is just there to store data and no behaviour, then that's fine > - don't add behaviour if it doesn't need it.

In that case, you want values rather than objects. Alas, Python doesn't have compound values.

<comment><USER3> Please stop it.

Every single time anything so much as slightly related comes up, you talk about compound object. Incessantly. And then you act superior when nobody knows what you mean, or cares about compound values. They're not really relevant to this discussion anyways, as storing data as desribed in GPP is perfectly reasonable.

The worst part is, your definition of "value" and "object" in this context is so far out of the ordinary that people should be expected to not understand it, and you should provide an explanation pre-emptively.

To quote Randall Munroe, "Communicating badly and then acting smug when you're misunderstood is not cleverness"

<comment><USER81> You've repeatedly become uncivil in this thread. That's not ok, regardless of wrong or provocative someone else may be. If you can't remain civil, please don't comment here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

<comment><USER3> You are, of course, correct. I appologize, and will go to greater lengths to remain civil in threads in the future.

<comment><USER81> We very much appreciate it. Thank you.

<comment><USER3> It's all part of being a good commenter. My irritations, frustrations, and nitpicks ade my problem, not yours, and I'll do my best to ensure it stays that way in the future.</comment></comment></comment></comment></comment></comment>


Mozilla lost. DRM won. Five years ago, this wouldn't have happened. - <AUTHOR> http://venturebeat.com/2014/05/14/firefox-will-begrudgingly-support-new-drm-standards-as-flash-silverlight-die-off/

<comment><USER2> Does the article ever address why it wouldn't have happened five years ago, or did I miss that?

<comment><AUTHOR> Could have been more clear, but this is the reason in a nutshell "Since Chrome's rise, Mozilla has hardly any weight to thrown around." Chrome is over 5 years old.</comment></comment>


US Military Will Offer Path To Citizenship - <AUTHOR> http://www.nytimes.com/2009/02/15/us/15immig.html

<comment><USER2> I can't belive this has not been instituted before. Not only does this provide advantages for the army, but the it provides away to get conservatives to accept immigrants more easily.

<comment><USER3> By sending them to die in foreign(for them and the US) wars? I'm reminded of the scene in Gangs of New York where Amsterdam is getting off the ship and the Army is there enlisting people right on the dock.

I think this kind of policy reeks of Imperialism.

</comment></comment><comment><USER4> Unless that article is dated 1862, the verb tense is wrong.

The US Military has offered a "path to citizenship" for over a hundred years through naturalization law that isn't under the control of the US Military.

Note that the article even mentions said law, pointing out a 2002 change, passed by Congress and signed by Bush.

</comment><comment><USER5> The French have done this for years via the Foreign Legion. We Brits do it to a more limited extent with the Gurkhas and the Commonwealth nations. Russia offers citizenship to recruits from the former Soviet Empire. Frankly I am surprised it took the US, a nation built on immigration, so long to come up with this.

<comment><USER6> The idea behind this is not immigration but empire. The countries you mention have or still do identify with the latter, the US less so.

</comment></comment><comment><USER7> Very starship troopers-y..

</comment><comment><USER8> Draft is next?</comment>


Are STEM Workers Overpaid? - <AUTHOR> http://spectrum.ieee.org/riskfactor/computing/it/are-stem-workers-overpaid <comment><USER3> >> _Greenspan is not alone in his thinking that STEM worker salaries should look a lot more like non-STEM worker salaries. In March, over "100 executives " [wrote an open letter begging Obama to increase the number of H1-B visas]_

Perhaps, as STEM workers, we should suggest that executive salaries should look a lot more like non-executive salaries?

>> _And those [immigrant] workers would compete with high-income people, driving more income equality._

Really, Greenspan? You're going to paint _STEM workers_ the posterboys for income inequality? Not your banking brethren making 5X, 10X, 50X the average STEM salary? It's a cheap, transparent ploy by those at the top to increase corporate profits at the expense of the workers and the middle class.

<comment><USER4> From an economist's perspective, STEM workers are still just labour. 'Bankers' represent investment, and their compensation is based mainly on the fact that they take on risk by allocating money...

Compensation is based on supply (which itself is based on many factors, including education and demographics), demand (number of businesses in a market, demand for the products created by those businesses), and risk. Assuming no government meddling, an efficient market will properly price workers wages.

What Greenspan is suggesting makes sense from a macro perspective, but of course on a personal, human level, isn't ideal for many people.

<comment><USER5> I don't understand why you put 'bankers' in 'quotes' like that.

Saying bankers represent investment isn't exactly non-controversial.[0] Perhaps that's exactly what you're saying?

[0] [https://en.wikipedia.org/wiki/The_aftermath_of_the_repeal_of...](https://en.wikipedia.org/wiki/The_aftermath_of_the_repeal_of_the_Glass–Steagall_Act)

<comment><USER6> A normal banker doesn't take _any_ risk himself, he risks money belonging to others. Back in the old days, Goldman Sachs (for example) was owned by the partners, who were risking their own capital in every transaction. That setup is very rare these days. An investment banker should be paid like an accountant or a lawyer, well enough by most anyone's standards, but in line with what the work actually is.

<comment><USER7> Why not tell the rest of the story ?

Then a crisis happened, where a lot of banker's decisions turned out wrong due to factors that cannot reasonably be said to be the fault of those bankers. A lot of people, who were told beforehand that their money was indeed at risk in trade for that "interest" demanded the government step in and guarantee the deposits (which the government didn't do for them, but implemented for all savings from then on).

This meant that anytime a sizable bank would topple, it would cost the government massive amounts of money, which meant the government became complicit, by necessity more than by bribes, in making banks grow and bailing them out if "risk" strikes.

Which is what you're complaining about.

BTW: the "risking your own capital" demand also meant that only the wealthiest of people and their immediate families could reasonably get jobs at banks, for obvious reasons. And I'm certainly not unhappy that particular tidbit ended.

<comment><USER8> Just because the government insures deposits to keep public trust in banks does not mean that it justifies banker's high wages. It's actually the opposite - the fact that bankers require government insurance 1) takes risk away from them (meaning the risk that "earns" them money according to economists isn't as high) and 2) they should be paying more money for insurance or using profits to mitigate risk instead of paying themselves. Insuring deposits has resulted in the opposite - it encourages risk and overpayment.

<comment><USER7> My point is that you're wrong. It's not (or at least it was not) the banks that demand the government take the risk away from banks, it was voters, you and me.

And I'm positive that today, a vote would turn out the same.

So this whole too much risk followed by bailouts process is exactly what the average voter wants (in the sense that it's what he'll vote for). Sure they'll complain about the bailouts but faced with the prospect of losing their savings (as they will naturally be when a bailout is proposed) ...

<comment><USER8> "Banks require government insurance" doesn't mean they demand it, it means they need it or people won't trust them. Both banks and people demand the insurance, because without it everyone fails.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> > Significantly opening up immigration to skilled workers solves two problems. > The companies could hire the educated workers they need. And those workers > would compete with high-income people, driving more income equality.

TL;DR Income equality is being redefined as cost cutting through wage suppression. W. T. F.

If you want to define income inequality as the "problem" of different skills demanding different wage premiums based on demand, then sure... If you want to define it, as it has been in almost every report I've seen on the matter, as the widening gap between the _rich_ and _everyone else_ , then that doesn't help at all, it just exacerbates the problem.

STEM work is still a quick, mostly egalitarian way to allow movement from the lower to _middle_ classes. Defining middle to upper-middle class as high- income earners might technically be accurate, especially with a shrinking middle class, but then making decisions based on them being "high-income" when it's so relatively different than it was in the past seems the exact _wrong_ way to go about things.

<comment><USER10> We need downward pressure on wages so that the executives can make more money and the corporations can profit. Clearly borders should be open to throw away any avenues to prosperity that still exist in this country still. A mix of corporate and union greed f'd up previous iterations of the middle class, clearly we should follow the same path in all cases to the benefit of the 1%. Yeah, that works.

I believe in the global economy, but I also believe that local markets have their demands and wages should be commensurate. If I were to live in San Francisco working as a full stack developer, I should expect one wage. If I was in Berlin, Stockholm, Singapore, etc. I would expect something commensurate that maintained the similar lifestyle in the community I work.

There are cultural/societal tradeoffs, but personally, I am pretty tired of the "US IT wages are too high, let's open the borders" argument. The opposite side of that argument -- corporate america promised X, but failed to deliver for aged populations, oh well...just moves along doing it's thing.

Between my age and that of my parents, there was a shift of "spend your life working for a company, you would get training to your potential, and your efforts would be reciprocated"; to today it is "fend for yourself, the contract you enter in is at will on both sides with no guarantees" with the caveat of "hopefully we are both striving for the same thing for an acceptable duration".

<comment><USER11> How can you compare corporate greed to union greed? The best paid union workers were autoworkers and longshore workers, and the companies they worked for were still huge and profitable. So as "greedy" as these well paid workers were (and I mean "were," because autoworkers make a lot less today) they weren't greedy enough to destroy the company.

If it weren't for this so-called "greed" there wouldn't have been a middle class at all. And now that unions are shrinking to almost irrelevance, the middle class is vanishing.

The old attitude of companies holding onto workers was created by unions making demands. Now that unions are few, and in many sectors, were never present, the "fend for yourself" at-will contract is the standard.

The unions made those "good old days". The labor strife of the 20s and 30s set the conditions for the middle class of the 50s and 60s.

<comment><USER10> By greed, I mean the failure of unions to adapt. They relied wholly on seniority even when senior members became settled and were no longer contributing as they should. Seniority as the sole measure of contribution was a huge hit to how unions were perceived -- be it autoworkers, teachers, etc. This is where I mean greed comes in. A refusal to self evaluate what was working and what wasn't.

<comment><USER12> Your use of seniority seems like a straw man to distract from the fact that unions have faced an unprecedented corporate and political offensive in the last 40 years that has no desire to compromise and is only intent on destroying any fragment of organised labour. To blame senior union officials for the decline of the unions is to miss the point entirely. Yes they were a contributing factor, but certainly not the main cause.

<comment><USER10> Not a strawman at all...teachers unions are all about seniority over effectiveness and will fight tooth and nail accordingly. Many other unions are similar. I agree to the policy of public bargaining, but individual members should be subjected to measurements of their effectiveness. Tenure based on the sake of time (only) should not have equal weight to merit within the union structure. I say this as a product of public education and having many wonderful teachers, but saw younger ones forced out where older were tenured in and safe but not effective. I can't speak to other unions which I did not experience.

The unions helped build the middle class in this country. The apprentice/journeyman/master levels within the trades is a great measure of skill and advancement, but regardless of trade (metal working, teaching, programming, etc) your tenure should be one component of your measure, but not the sole measure. Do you continue to learn? Do you teach? Are you advancing the best interests of the group? There is more than "oh, I've been here longer than you".

This is what I mean when I talk greed and seniority.

Yes, unions have faced an offensive, but their insular nature has also harmed them just as much as the outside offensives.

</comment></comment></comment></comment></comment></comment><comment><USER3> It entirely depends on perspective. When I moved from the west coast to the east coast after completing a STEM PhD, my perspective changed completely.

My girlfriend worked for a hedge fund, where her co-workers and bosses received bonuses that were multiples of my annual salary. I had a few friends who landed law jobs with lockstep compensation, where, within just a few years, they'd be make more than I could ever hope to make at my research lab. Another friend, an english major from a second-rate college, was hired to manage a team of programmers. She had no STEM skills but great people skills, and was eventually chosen to head up a new west coast division. She's compensated extremely, extremely well. We'd occasionally travel down to DC, where there are many, many people feeding off of government excess who make far more than STEM careers pay.

That's what they don't tell you when picking a college career. You'll get paid relatively nicely out of college, sure, but you'd better not expect to make much more than that if you want to be a "STEM worker" __no matter how hard you work or how good you are. The glass ceiling is very low compared to many other careers.

Not only that, a $100,000 salary was, not very long ago, the key to a comfortable upper middle class life. The cost of living, housing, everything has gone up so fast in proportion to income that it just doesn't feel that way anymore. I cannot provide my family with the material comforts my parents enjoyed and provided me (and neither worked in STEM... or had college degrees!).

 __Yes, there are exceptions _at the moment_ if you're considered a "rockstar programmer". Still, that (and programming in general) represents a tiny slice of the overall STEM pie.

<comment><USER13> I totally agree and have made similar points here on HN in past threads.

It is nice that you can fairly easily make $85k or higher in some regions as an entry level developer, but it sucks that outside of a few exceptions that prove the rule you're unlikely to ever make more than about $150,000 (and I'm talking Bay Area, CA dollars here) without moving into a pure manager role or playing the lottery ticket of starting your own company.

Granted, $150,000 is a _lot_ of money relative to the average income globally, even when you factor in cost of living adjustments, but to have bankers(!) and politicians(!) saying it is too much is a fucking slap in the face.

<comment><USER14> Except 150k in Bay Area is nothing and you won't even make it into the middle class (i.e. buy a house).

<comment><USER15> Then maybe the Bay Area, the tech industry, and the economy broadly shouldn't be run so "efficiently" that salaries and real-estate prices become locked to each-other.

</comment></comment></comment></comment><comment><USER16> Quick refresher on what the word "shortage" actually means.

SHORTAGE: Below market rent-controls. If more people want housing than there are apartments, and the price can't adjust, that's a shortage.

SHORTAGE: An oil supply shock as in the 1970s, and gas stations choose to ration fuel rather than profiteering by jacking up prices. More people want gas at that price point than there is gas. That's a shortage.

NOT A SHORTAGE: The lack of first-class flights from London to Chicago for $1,000. That ain't a shortage, it's a market-clearing price I don't want to pay.

I like the BCG quote: "Trying to hire high-skilled workers at rock-bottom rates is not a skills gap."

<comment><USER17> You're so right.

In Germany this is called "Fachkräftemangel", which translates to "Shortage of Specialists". But it can also translate to "Mangle for Specialists".

</comment></comment><comment><USER18> If there's downward pressure on salaries in Software development, you're going to see two things that will counter-act this long-term:

1) An exodus of developers. Devs will be likely be leaving either as the result of fat getting trimmed or by transitioning into management and analysis roles that offer better career prospects.

2) Less "young blood". A big reason why everyone is pumped these days to learn to code is due to the career opportunities it provides: the great salary, the job perks, and working for companies that are perceived cool. Most aren't looking to become entrepreneurs. If software shops lose their charm and gains a reputation for long hours with mediocre pay, people will seek opportunity elsewhere.

I saw the same thing happen in the early '00s after the dotcom crash and the outsourcing craze. Startups became a punchline instead of an aspiration and everyone thought most of the world's code would be written in Bangalore. CS enrollment tanked. People lost their appetite for learning programming. But by '05 we were back into a "shortage" again after believing the first-world programmer had gone extinct.

But I'm not surprised business and political leaders think STEM workers are overpaid. The general attitude is that exceptional salaries should only be doled out to exceptional individuals - if you're just a mere mortal that's in demand, well, that's clearly just an inefficiency in the market.

</comment><comment><USER8> It's cute that the income inequality Alan Greenspan is worried about threatening capitalism is between regular engineers and everyone else, instead of between executives\owners and everyone else. Explains why I see so many documentaries about STEM workers and their lavish 2 bedroom homes they own after 20 years.

</comment><comment><USER19> So basically, Greenspan and other companies think that us STEM folks are beneath lawyers, doctors, and most people in the financial industry? That we should be "put in our place"?

Anyone who knows anything about the H1B rules knows it's all a bunch of hogwash that there is a "skills gap". The corporations simply want higher profits. It's just simply a known fact. Better profits for the promise of a green card.

Let's see the companies prove that there truly is a skills gap. Instead of paying the 'prevailing wage', H1B workers should get the _top_ pay for non H1B engineers in the company + 20% or at that the 90% mark of engineers + 20%, which ever one is greater. Then I say, please open up as many H1Bs as possible. I'll tell you one thing, H1Bs applied for will go towards near zero...

</comment><comment><USER20> One thing that gets overlooked in this debate is the survivor bias. STEM people have a pretty good way to drive down incomes in certain STEM occupations by automating them out of existence.

WordPress alone probably killed a good portion of formerly gigantic market of HTML programmer, CMS companies and consulting companies installing and configuring the CMSes. Potential income from building simple HTML Web sites nowadays is roughly zero, so people with those skills don't stay in the industry (and get counted in surveys) - they either upgrade their skills or move into other careers.

</comment><comment><USER21> Alan Greenspan made approximately $180,000/year as Chairman of the Fed. Perhaps Presidential-appointee salaries could be made equal to non- Presidential-appointees by opening up those positions to foreigners.

</comment><comment><USER22> A withering brilliance shows through this casually abusive headline.

I feel like this is a few steps away from some sort of revolutionary political speech. Did Greenspan really say that shit while representing the country I'm supposed to love?

</comment><comment><USER23> Given the skill level and investment required to get a competitive STEM degree and the amount of profits a STEM person can produce for a company's long term profits I think that they are actually potentially underpaid.

<comment><USER24> They should've written an article titled "Are Financial Analysts Overpaid?"

</comment></comment><comment><USER25> I can play this game too:

Are bankers, lawyers, and doctors overpaid?

Well, it depends on what you want to pay people for -- what if we argued for the value they added to society on average? What about the banking industry during the financial crisis? What about the price of lawyers in California staying stable even though the supply has increased multi-fold in the past few decades? What about the people who design, validate, and erect the buildings in which these guys work? The people who created the private jets in which the questionably wealthy have always flown? The internet through which information became significantly more accessible (aka affordable)?

The people who truly enable the good parts of modern life? I know where my vote is going.

</comment><comment><USER26> They really should have picked a different title and hinted at the conclusion which was STEM workers are suffering the same wage stagnation as everyone else and the only companies with hiring problems want STEM workers on the cheap. :/

</comment><comment><USER5> I would gladly take a pay cut if we also raised the minimum wage to $30 an hour, got rid of most welfare programs and replaced them with a $10k/year minimum income, and simplified to a flat tax rate (I think Dick Armey liked 17%).

<comment><USER27> Given that the mean wage was only $43,460 in 2009, in order to raise minimum wage to $60,000 per year, your pay cut would be to minimum wage. The government would have to confiscate all income, supplement it with printed money, then redistribute it evenly across the population. In that kind of scenario, why would anybody do anything but the absolute minimum? Isn't that largely why the Soviet Union wasn't competitive? If there was no economic incentive for hard work, I'd wager many of the presently most productive people would optimize for work minimization.

<comment><USER28> > Isn't that largely why the Soviet Union wasn't competitive?

The backwater pre-industrial, post-war torn nation that beat the US to space? No, I don't think that was why they couldn't compete.

As far as I recall, pay is a pretty poor motivator -- while low pay is a pretty strong _" de-motivator"_. So if you give people interesting challenges and make sure they can meet their basic needs, people are likely to preform.

But, even if competing for exceptional wages was a great motivator, no-one is saying that you couldn't do that in such a system -- you might have to limit it to fewer "exceptional" people, and there might be a higher risk of being demoted -- but I can't see why it wouldn't be possible. I don't think it would be a good idea, however.

All that aside, a household income of 80.000 USD sounds pretty good for most of the US (never mind 120.000) ?

<comment><USER27> _The backwater pre-industrial, post-war torn nation that beat the US to space? No, I don 't think that was why they couldn't compete_

Pretty amazing what you can do when you're willing to spend your country into insolvency and collapse.

 _So if you give people interesting challenges and make sure they can meet their basic needs, people are likely to preform._

It's not like 50% of workers in the USSR admitted to drinking on the job, or 40% held second jobs to make more money, right? I guess if you're not motivated by a strong aense of community and bullshit pay, the gulags and purges might help.

</comment></comment></comment></comment><comment><USER29> Wages are so skewed towards the top earners - A typical corporate CEO gets paid $7000/hour. Suppressing tech wages isn't going to make a dent in income equality. Tech is already more egalitarian with the offering of shares to employees at most (if not all) levels.

[http://moneymorning.com/2013/04/19/ceo-pay-now-7000-an- hour-...](http://moneymorning.com/2013/04/19/ceo-pay-now-7000-an- hour-350-times-the-average-workers/)

</comment><comment><USER30> _Of course governments and current social elites from all parts of the world want us overworked and underpaid!_

"STEM workers" can be the base of the new "over-middle" class - educated, well-off and with good social mobility plus political mobility and geographical mobility (this is fucking dangerous for governments and elites!).

You wouldn't want the class underneath you to have "well rested minds" and time to think about the world and their proper place in it (at the very top that is, because same as in old military societies warriors were the "natural rulers", in the new info-tech society techies will be the new "natural rulers"). Let's overwork them and stress them with unemployment so they don't get any funny ideas in their heads...

Though to be honest, all this sounds good for us STEM workers outside US in lots of indirect ways... I'll bet US will have a nice civil war / revolution soon, and more immigrants moving in any directions will only mean that the enlightening ideas from such a conflict will be easily exported worldwide.

</comment><comment><USER31> Over the past few years I have seen starting salaries at top tech companies (Google, Dropbox, Twitter) increase by huge amounts. This may not be true at all companies, but it is definitely true at top companies. I also know that these companies will hire anyone who can pass their interviews.

I feel like many times the argument is that preventing high-skilled workers from staying in the US will help US citizens. This assumes that there's a fixed pie of jobs and that basically bringing talent from outside will burden the US economy. I definitely don't think that's true.

It also assumes that top tech companies have no option but to hire people in the US. I have many friends who had trouble with getting a visa and instead went to work in Canada for Google. This basically means the US lost one job, plus the taxes and economic stimulus that a high paid worker would bring in.

</comment><comment><USER32> I am incapable of discussing this rationally, obviously, but this feels silly.

Why do these 100 executives who wrote an open letter to Obama care so much? Obviously they don't want to pay the prices they're paying, but would they be campaigning so hard if the work wasn't important? Ok, so the work is important; they also can't just hire someone off the street, because the skill requirement is high. Sounds like a normal market to me - your demand is high relative to the supply, so the cost rises.

Again, being in this field, I'm wildly partial...but I have very little sympathy for an executive who wants to pay below-market rate for business- critical work. Why not cut your own salary if you are so concerned with profitability? OH, that's different; you _deserve_ it.

</comment><comment><USER33> Gut Reaction: Do non-STEM workers do anything useful?

<comment><USER34> A better question might be.Can we automate away the jobs of sales people, middle management and strategic directors? Yes, I believe we can.

<comment><USER9> The real question; Can we automate the job of corporate officer? The cost savings would be enormous...

<comment><USER34> Thats is a really hard problem. How do we define priorities and goals? There is certainly an argument for a company where the only goal is to make money and there is no overriding authority between divisions but there is so much sociopathic behavior in companies already.

</comment></comment></comment></comment><comment><USER35> I cannot believe you guys even discuss this. We are grossly underpaid. Mainly because we are (en masse) not able to negotiate the compensation. That would be a problem if we were able to organise, so someone else would do that for us.

Look around, everything is driven by computers now. EVERTHING. Even bloody banks. And we are still not sure are we underpaid or not. En masse IT person is shy, ready to accept lower pay, and easy to accept more hours.

</comment><comment><USER36> That is how your bosses look at you, IT workers are a cost center - <USER2> you are a programmer or sys-admin or db.

The simple fact is the MBA dude hates you.

</comment><comment><USER37> > Likewise, tech companies are definitely not interested in paying higher > wages

Most tech companies understand that the best engineers are 10x better than the average, but you rarely have to pay them 10x the salary. Most are happy to pay the higher wages if it means they are winning the 10x guys.

If the argument is all about the average -> poor engineer, I don't know that I entirely disagree

</comment><comment><USER38> Comrades:

Either get lean, or seize the means of production.

Which, mirabile dictu, is yourself.

</comment><comment><USER39> I'm not sure I agree that STEM workers are overpaid. I mean, I make a bit more than the customer support, PMs, and sales people in our company, but I'd rather do their jobs if the pay was equal.

</comment><comment><USER15> Oy gevalt.

 _Either_ there is a shortage, in which case STEM workers' salaries need to go _up_ to attract more people into the field, _or_ STEM workers are overpaid, which can happen if and only if there is an _oversupply._

It can't work both ways. You can't have a shortage of overpaid, useless employees.

Unless, of course, you're a capitalist begging the government to let you manipulate the labor market to deliberately suppress wages below the natural market-clearing level set by supply and demand.

Capital, capital uber alles! Fuck the markets and fuck the workers! /s

</comment><comment><USER40> No.

</comment><comment><USER41> These STEM salary stories seem empty. They are all price and no value. What is the price elasticity curve for engineers? How much of the salary loss would be offset by increased prosperity from more workers?</comment>


Ask HN: How do you get that dream job you want? - <AUTHOR> I'm in a position where I decided that I want to work for a certain company. The whole "dream job" thing. The thing is, they don't have any position open that I can fill at the moment, and though they solicit queries from people who "may not see a position right for you", they have not responded to me. Either generally or when I email individuals ("hey we live in the same city and I want to work for your company, can I pick your brain?").<p>Unfortunately, google doesn't really give good advice on how to track down a company and convince them to give you a job. And so I turn to HN. Have any of you pursued a specific company and succeeded in getting the job you wanted? What tips do you have? To avoid survivorship bias, what techniques have you found to not work? <comment><USER2> Actions speak louder than words. Don't just say you passionately want to work at <company>. Show them you passionately want to work at <company>. Be visible in their periphery at all times. Make them think reaching out to you was their idea, and they will be much more likely to do so.

<comment><AUTHOR> How do you do this? The thing that pops to mind is getting involved on github, but what if the company does not have any OSS?

<comment><USER2> The how is the hard part, and is going to vary by industry/location/etc. I guess I would start by looking where your target company is active.

Do they do any live conventions? Be there. Do they have heavy internet presence on any forums or otherwise (outside of their own site?)? Be there. If there own site has user forums, be a contributing member. Old fashioned networking works well too. Look up who works there on LinkedIn or whatever, start making friends. Be a contributing member of their community.

Perhaps writing a few LinkedIn articles within their area of expertise? If you are aware of any technical/whatever problems they are facing, present a solution. Im just spitballing here.</comment></comment></comment>


Droid Doesn't: It's Not Ready For Prime Time - <AUTHOR> http://alsop-louie.com/gadgets/droid-doesnt-its-not-ready-for-prime-time/ <comment><USER2> I've used my droid for a month, and most of the time it has been flawless. It doesn't have the dialing issue my blackberry tour had. I have only had to force quit a couple of times, and usually when I was exiting the app anyways. My only complaint is the keyboard and sometimes the phone comes out of sleep (setting a lock pattern prevents this) and dials people that I didn't want them to. Other than that, the phone has been great. Fast as I would expect, and plenty of apps to keep me busy.

<comment><USER3> I'm sorry, but every time I have checked out a G Phone or the Droid and tried to scroll through their menus, I am both thoroughly disappointed at how jerky it is and a bit shocked that for some reason, no other company has been able to pull off the smooth touch screen scrolling like the iPhone has. It gets me every time and is a big reason why I wouldn't purchase a Droid, as pathetic as that reason may be.

<comment><USER4> why "no other company has been able to"

I gonna take a wild guess that it's because Apple folks don't want to hear Steve Jobs say those magic words.

<comment><USER5> Huh? Companies other than Apple haven't been able to make scrolling work nicely because Apple folks don't want to hear Steve Jobs say, er, whatever magic words you have in mind?

What am I missing here?

[EDITED ~1m after posting to add: Perhaps what you mean is that the reason why Apple _has_ been able to do it is that everyone there is scared of having Jobs tell them their user interface isn't good enough. But the previous poster's question wasn't "how come Apple were able to do this astonishingly difficult thing?" but "how come other companies haven't bothered to do this apparently easy thing that would make the user experience so much better?". Jobs's perfectionism can hardly explain _that_.]

</comment></comment></comment></comment><comment><USER6> I think these kinds of harsh reviews are where a video would really come in handy.

Mostly because it seems like it's almost too horrible to believe. Also (though fanboys will never truly accept the problems) it's just too easy for them to respond with 'you're doing it wrong!'

This account does speak to some specific points, but I'd be nice to see some clear examples that all can see and discuss, instead of just describing general experiences. Shouldn't be too hard to collect, either, if the phone is consistently this bad.

</comment><comment><USER7> Maybe the guy has a defective phone. It doesn't seem that his experiences line up with anyone else's. My 'underpowered' 192MB HTC Magic certainly doesn't have these problems. Seems strange of him to assume that this is the experience that many others are raving about.

<comment><USER8> yeah, it seems like he is out of the norm. I've played with a couple different droids and loved it. still plan on getting one.

</comment></comment><comment><USER9> If the article's author's Droid behaves in the ways he says it does, it is clearly defective. I have never, not once, had to "force quit" any built-in application. The contact list works flawlessly. When I click an application icon, it starts every time. As a phone, the thing is rock solid.

The only applications that I have had to "force quit" have been a couple buggy apps from the market, which I subsequently uninstalled. Yes, buggy software is allowed into the market. That's fine by me; sometimes a buggy beta app is better than no app at all.

And about the shutter button: why would I want it to launch the camera app? On my standalone digital camera I sure don't expect the shutter button to turn it on...

</comment><comment><USER10> Just to add my own data point: I've had the Droid for about a month, and I've never had to force quit the phone, maps, or browser (which I consider the three most important apps). The scrolling on the menus and desktop sometimes feels laggy, but is usually good. The camera button either doesn't work, or I don't know what it's supposed to do (I just use the button on the touch screen). Besides that, I haven't had any problems. I love the keyboard, and I've never dropped a call or accidentally dialed a number in my pocket.

</comment><comment><USER11> I don't buy the implication that voice has to be glitch-free. First, many people who buy smartphones are light voice users, and use the web most of the time. Second, many cell phone users have imperfect voice calling anyways, due to coverage issues or network glitches. Finally, if a product really shines in some important areas, there will always be people who are willing to put up with poor performance in other areas.

<comment><USER12> Everything is a feature. So, the iPhone can always make or receive a call. And what does Droid have to make up for that? More pixels? A keyboard that many people find inferior to the software one? A replaceable battery that no one will ever replace? Most people would take the bug-free OS.

<comment><USER13> Is everyone forgetting how many people are complaining about iPhone dropped calls? Might be AT&T or something else, I'm not seeing as many complaints with their other phones.

I have an HTC magic, never had issues with the dialer. Rogers in canada is pretty good, no dropped calls after 4 months of use. Only app that seems to hang my phone is twidgit. Great app, horrible performance.

<comment><USER14> AT&T isn't an iPhone. I have an iPhone on SFR and it works fine. If the network is built properly than any phone should be able to use it just fine.

I certainly hope Apple disconnects themself from that deathstar and chain called AT&T. Because everywhere else (except maybe the UK where O2 had the exclusive) the iPhone works just fine.

</comment></comment></comment></comment><comment><USER15> I still maintain that Java is _not_ a good choice for a mobile OS. Dalvik might be the best Java VM ever in the history of personal computing, but it's still just a VM. It cannot beat native code, especially on a mobile device like the Droid. I think GCC is smart enough at producing fast, tight machine code. And then there's LLVM. Why choose Java?

<BEGIN RANT>

I'm sick of people going on about how programmer productivity is more important than performance. I seriously don't give a fuck about programmer productivity. I only care about the end product. You have a 600MHz processor with about 128megs of RAM on your mobile device, and you _still_ can't make it perform well? There was a time when _desktop computers_ were slower than that, and programmers optimized the hell out of their software to make it perform acceptably on the limited hardware. I can't believe that a company like Google can't make Android perform at least acceptably, if not blazing, fast.

<END RANT>

I consider performance a feature. If it's not fast, I'm not using it. This is how I choose my desktop software, and this is how I choose my mobile devices. Currently, I'm looking at some Symbian devices. Symbian might not be the best mobile OS, but it's extremely responsive even on my mum's ancient Nokia 6600.

EDIT: removed offending "bring on the downvotes" comment.

<comment><USER5> I largely agree with that, but downvoted you on principle because I always do that to people who play the "oooo, I'm going to get downvoted, see what a nonconformist I am" card. (Which I think lowers the signal-to-noise ratio both of HN's content and, since unfortunately it sometimes works and garners lots of upvotes, of the rating system.)

<comment><USER15> Point noted. I've edited that part out now.

<comment><USER5> I regret that the HN software doesn't allow me to un-downvote you.</comment></comment></comment></comment>


Three.js: Javascript 3D engine - <AUTHOR> http://github.com/mrdoob/three.js

<comment><USER2> In case anyone else noticed that the author seemed familiar, he's the same one who did the Harmony sketcher: <http://mrdoob.com/projects/harmony/>

Lots of other incredible demos on his portfolio page: <http://mrdoob.com/blog>

<comment><USER3> hey, glad you like my stuff :D

<comment><USER4> Last time I played with harmony sketch, I found a cool bug/feature. I wanted to know if you knew about it…

If you open it up and use the grid mode to draw a bunch of dots on the screen, then switch to a different mode (like long fur) and hit clear it will immediately render all of the grid dots connected with fur. You can then cancel and save the image. I know it works in safari… not sure about other browsers. Is that an intentional behavior?

<comment><USER3> I'll have to try it on Safari, but that's not supposed to be normal no... Sounds like a wicked bug though! ;)

</comment></comment></comment></comment><comment><USER3> To the poster: thanks for spreading the little library over here! ^^

<comment><USER5> Nice lib and examples!

Some time ago I also started with a 3d engine (path tracer). If anyone like to have some code: <http://thuijzer.nl/jsrender/> (I never took time to optimize/bugfix the code).

</comment></comment><comment><USER6> First, processing.js and Raphaël, now Three. Man, js is definitely getting all the love these days :-)

</comment><comment><USER7> Fantastic work. I wonder how long before this sort of thing can be used to do 3D development on the mobile web for devices with full browsers (iPhone, Palm Pre, Android, etc...)

</comment><comment><USER8> I think this is also JavaScript: <http://www.ambiera.com/coppercube/webgldemos.html>

</comment><comment><USER9> Fails for me in Firefox, runs great in Chrome.

All the same, this is awesome. Thnx!

</comment><comment><USER10> pretty amazing what can be done with 7.5 kb worth of javascript

<comment><USER3> Well, you'll then be amazed with what can be done with just 297 bytes ;) [http://www.p01.org/releases/512b_jspongy/jspongy_hardcore.ht...](http://www.p01.org/releases/512b_jspongy/jspongy_hardcore.htm)

<comment><USER11> Warning to other clickers: It pegged a core and made browser (FF3.6) pretty unresponsive.

Nifty none the less.

<comment><USER7> Your comment only made me want to try it more!

</comment></comment></comment></comment><comment><USER12> Awesome</comment>


The GitHub way of blog discussion and commenting - <AUTHOR> http://nikosbaxevanis.com/2013/04/28/the-github-way-of-blog-discussion-and-commenting/

<comment><USER2> Why does that blog post use Disquis then, instead of a github issue? :)</comment>