In defence of SQL - <AUTHOR> http://seldo.com/weblog/2010/07/12/in_defence_of_sql <comment><USER2> I've never understood why programmers don't love SQL the language. It's the closest thing you can get to the silly voice interface they use in Sci-Fi:

"Computer, give me a list of orders for red sweaters, but skip ones from customers who signed up more than 3 months ago"

... and it will figure out how to get you that list. And the syntax is so simple that you can do pretty much everything you'd ever want with _six keywords_. The query to get the list above is actually _shorter_ than its English language description.

Whenever I see some new ORM come out with its own way of asking for records from a database, a little question mark pops up over my head. Why would you do that? Did you really spend time building something to make your problem harder? Your code less elegant? Why why why?

The only thing I can imagine is that people simply don't bother to learn SQL before deciding they don't like it. Too bad too, because writing queries is one of the most enjoyable bits of the software development game.

<comment><USER3> Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code.

[tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple.

Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app.

ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled.

SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice.

It all depends what the task is anyway though.

<comment><USER2> _Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code._

That's not unique to ORM. We don't use an ORM at Expat, yet all our objects still have .Load() and .Save() methods. I hope you didn't read my post to mean I advocate hand-writing your CRUD!

I think LINQ is a great example of needlessly re-inventing something that wasn't very hard in the first place. Especially since its syntax is so close to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot of trouble?

<comment><USER4> There's a lot of power and flexibility using a Model with LINQ. The strongly typed nature has saved me many times. When you alter a table and remove or rename a column you know exactly which queries are now broken at build time. If you were generating or hardcoding sql there's a chance that you hosed a lot of things and need to dig through all the code.

Dynamically creating queries is amazing in LINQ. Building them with strongly typed expressions is much better than messy string concatenation.

<comment><USER2> Again, that's not unique to LINQ. Drop a db column in the thing we use and the project will fail to compile until you fix up the references. And of course, if you're keeping your stored procedures in source control and recompiling them at build time (which of course you should), you'll know when you break them too.

As you say, strongly typed dataobjects are pretty cool. Regardless of how they interface with the database.

</comment></comment></comment></comment></comment><comment><USER5> I think he's got it backwards. He says SQL is a great language in front of a crappy model, the relational model. I think SQL is simply a limited language in front of a great model. The NoSQL folks are throwing out both, so I guess that's "the only way to be sure." Going to be fun seeing them re-invent the wheel for the next 5 years.

What we need is a more elegant, flexible language instead of SQL for data retrieval. SQL++, since the relational model is sound. Beyond that, we need a more intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language.

There's no reason in theory this can't happen, its just hard. To think that dropping us down to GET and PUT operations is the answer is just saying "we give up."

<comment><USER6> That's an overly simplistic framing of 'NoSQL'. Despite every piece of FUD to the contrary, 'NoSQL' is a stupid name for a set of tools designed to solve an entirely different set of problems.

I don't _want_ some data in a relational model. Yes, I could put it there, but I would be doing so solely so that it fits in the relational model. Which is pretty pointless.

The fact that the relational model is "sound" doesn't mean that everything belongs in it. Plus, I'm not holding my breath waiting for an "intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language". That's the description a mythical database panacea that solves all problems with no downsides.

The continual pitting of NoSQL vs SQL is a gross mis-characterization perpetuated out of holy-war fervor, yet based on few facts or even understanding of the differences.

<comment><USER5> The relational model is a comprehensive, complete way of representing any form of data. Just because the abstractions in front of the relational model make it somewhat klunky to access, say, keys and value based data models, has nothing to do with the mathematical soundness of the model. The limited "models" most of these NoSQL stores provide are simply subsets or re- projections of the relational model where the implementation basically bleeds all the way up to the modelling abstraction of the system: they are one in the same.

The database I described is not a panacea, you'd still have to do both good modelling _and_ describe the ways to optimize the materialization of your data. It doesn't make the core challenges of data architecture any simpler, you still need a brain. It does, however, provide a clean abstraction and would in theory maintain most of the good things that RDBMSes have brought us without throwing all the hard work of our elders in the trash can.

<comment><USER7> If you (and everyone else who've made the same argument) substitute "Syntactic Sugar" for "Abstraction" and "Turing Complete" for "Relational Model" I think you've just made the claim that every application can or should be written in Brainf*ck or one of the other Turing tarpits. Just because a model is mathematically proven comprehensive, (I'm not 100% sure if relational is but that doesn't matter) doesn't mean it's the most natural way to express/solve your problem. And really, that is the only thing that matters. At least when comparing models and not implementations.

</comment></comment></comment></comment><comment><USER8> This article reiterates a fundamental point that object stores quite clearly present less friction during development than relational stores. This is plainly true: your domain object is meant to model the domain, and if you can store it directly that is the best you can hope for. There's a reason there's a whole topic of study and research called "Object-relational impedence mismatch" ([http://en.wikipedia.org/wiki/Object- relational_impedance_mis...](http://en.wikipedia.org/wiki/Object- relational_impedance_mismatch))

However I think ORMs are too quickly dismissed. In the simplest case, an ORM can appear to be a key-value store at the API level. Of course that is a gross abuse of a relational store, but there's no reason it can't be done. Additionally, the author fails to note that an intelligent ORM can provide a caching layer that improves performance over raw SQL. A more detailed examination of the various patterns to resolve the impedence mismatch, such as active record versus data mapper, ORM caching strategies, and how those compare to a key-value store solution, I think would be a valuable topic of discussion.

<comment><AUTHOR> If the ORM layer is providing a caching layer on top of the RDBMS, that caching layer is effectively a non-relational store for the data. If that works better, why not use it as the primary store?

<comment><USER8> Not necessarily - you could store a resultset based on the query and parameters, and if the same query and parameters come within a certain amount of time, you return the whole resultset from the cache. In this scenario, the resultset could contain a filtered list, aggregate functions, etc, that are more difficult to replicate in a key-value store.

<comment><USER9> That is exactly what Oracle Coherence (nee Tangosol) does.

</comment></comment></comment></comment><comment><USER10> >> The birth of ORM lies in the fact that SQL is ugly and intimidating

I disagree. In my opinion, the birth of ORM lies in the fact that a lot of people want to work on problems that have almost nothing to do with SQL but need persistence. They want to spend time working with objects in their domain model and just have persistence that works.

So if that's the case, why did ORM even appear? Why didn't everyone just spend time figuring out "NoSQL"/key-value stores/object stores and move away from RDBMS? 1) SQL and relational data stores, as the author himself points out, are trustworthy and standard. People may not like working with them or be intimidated by them, but most people can at least figure out simple joins and things. The relational model may not be the best answer for some things, but it at least gets the job done. 2) Just because I want to work with my domain objects in my application, and just because I'm short-sighted and all I care about at the moment is enabling a business idea or solving an interesting problem with my app, doesn't mean that I won't want to "get answers" from my data in the future. Maybe it won't be me - maybe it'll be another group in my company with more RDBMS knowledge than I have that's interested in data-mining my store, and because I've used an RDBMS, it will work extremely well.

I don't think developers are scared of SQL, I think they just don't care about working with it because it doesn't have much to do with what they're interestd in. Maybe ORM isn't a perfect solution, but it lets me have my cake (persistence that gels with my domain model) and eat it too (a relational backend when we need BI and reporting).

<comment><USER11> I agree. The OP seems to fall into the camp that, if ORM can't replicate _everything_ that you would do in native SQL, then therefore ORM is bad. Which is absolute nonsense of course.

I just don't see how the pure SQL people and ORM people are philosophical opponents, other than how ORM tools make dealing with SQL (which is an awesome, proven technology) so much easier, I suppose it could theoretically be a threat to their livelihood. The way I see it, they are partners in the same cause.

I'm the same as you, I write applications that need to store and interact with data. The difference between using an ORM or not is like light and day, and for me, this constitutes 90% of my work. Certainly, there are situations where it is just common sense to drop down to raw SQL (and if your ORM doesn't support this, you are screwed), but people like the OP seem to subscribe to the "throw the baby out with the bathwater" philosophy of life....if you can find a single problem with a solution, throw the whole thing out.

This is one of those arguments that will never, ever go away. I used to be passionate about the subject, but I don't care much anymore. The anti-ORM people will continue to say it doesn't work (ever), while the pragmatists will continue to use ORM because it does work, and for the edge cases, they will drop down into pure SQL, which most developers know very intimately anyways.

On a related topic, how many DBA's have you met that understand SQL, query plans, etc deeply, and have a strong knowledge of database system tables (as well as you do as a developer?) Most DBA's I've met basically follow: <http://en.wikipedia.org/wiki/Argument_from_authority>

<comment><USER12> The reason pure SQL people and ORM proponents don't always get along is that ORMs make it very easy to write really crappy queries. I'm fully in the ORM camp, but it is true that I can't turn on SQL statement logging without being terribly embarassed. And tuning and optimizing these queries isn't always as trivial as some make it sound. For fetching some data, it's not terribly hard, but try explaining to Hibernate that you want to bulk delete a bunch of objects (with inheritance) without screwing up your session...

<comment><USER13> It's all about people, not the ORMs or other technical inventions.

Most shithead queries I encountered during years of DBAing were written by hand by poor folks abandoned by their colleagues and over-confident managers.

Just no one cared to educate them, but everyone expected "progress" from them. So they did what they could..

In fact I wished many times that they used some abstraction layer which would save them from doing such harm, simply because this layer would be written by more educated people.

</comment></comment></comment></comment><comment><USER14> These arguments make me feel like DBMS technology is insufficiently distinguishable from magic.

Databases do two things: they _persist_ data, and they _answer queries_ about data. Neither of those requirements put any restrictions on how they _serialize_ data. Relational storage, object storage, document-based storage, key-value storage, graph-based storage, etc.—it all just seems like different _optimizations_ on the same "real" data, something that should be abstracted away from the database administrator entirely.

Why can't we just have a database that gets fed a normalized, relational- algebra-style model of the data, but then _profiles_ the kinds of queries fed to it, and the kinds of data given, and _builds_ whatever kind of denormalized tables/indexes/k-v stores are optimal for your usage patterns, using a Relational, or Object DB, or Graph DB, etc. engine when each is appropriate (perhaps firing them off in parallel and returning whichever answer comes first, killing the other threads)? Is this something anyone is working on?

<comment><USER15> A "query optimizer", let's call it.

That'd be so cool. I wish RDBMSs came with query optimizers. Maybe something that could ANALYZE (or, better yet, EXPLAIN) their performance, so people could tune it.

And yeah, sarcasm aside, it's easier to have a DBA tune things than some AI - of course: "Why can't we just have a compiler that gets fed a description of the problem, then solves it, calculating the optimal solutions for all of the engineering trade-offs, and then builds whatever kind of interfaces are optimal for your users choosing Design Patterns as appropriate. Is this something anyone is working on?"

<comment><USER14> Yes, RDBMSes already _have_ the capability to tell you how to best optimize them. The problem—and it's a sociological problem, not a technological problem—is that people don't _want_ to tune their databases. Instead, they want to install something that is already tuned 80% correctly (i.e. a NoSQL store), and then ignore the other 20% of possible optimization.

There's a big, unaddressed opportunity here: if you can just make your DB smart enough to tune itself _81%_ correctly (and that's not very hard—certainly not AI hard) then you can conquer the market for people who don't know how to EXPLAIN their way out of a paper bag. It's not like it would be inventing its schema on the fly; you'd still be feeding it a formal, completely-specified _but unoptimized_ set of tables. It would just do things like:

* Notice when it gets a query with the same parameters 10000x in a row, and grind out an index for it;

* Notice when a large (>100000) set of rows in a table is identical save for their primary key, and only queried by COUNT(foo), and turn those rows into a single row with a foo_count field (and a log table in case a query ever does come in that cares about the IDs);

* Notice when two tables are only ever queried joined together, and morph the primary store for them into a denormalized table, turning the previous, separate tables into views on the denormalized table.

And so on. If you look at, say, Python's hashtable library, it has all sorts of these little "rules of thumb" for when to alter its internal representation, because of what it guesses the user is up to (storing unique pairs, creating mathematical sets, nesting hashes to mimic a complex data structure, etc.) Databases, on the other hand, much bigger systems _purely for_ flexibly storing and querying data, just stubbornly _sit there_ until the DBA (because there must _always_ be a DBA, even if the DB is just being fed migrations written by Rails CRUD coders) comes along to tell them to do the things they already _know_ would make them faster. It's just silly.

<comment><USER2> Are you really saying that people are too lazy to draw lines between tables in their database? Too lazy to right click a column name and click "Index"? That you wouldn't notice on your own that a particular query took four minutes to run and maybe open it up and poke around? That this should be something the database does for you???

That is not the hard part of my job. That is the _easy_ part. No thank you.

<comment><USER14> But, as you say, it _is_ part of your job. The difficulty, or ease, of the problem, has nothing to do with it; at some shops, it's _nobody's_ job, and so it just _doesn't get done_. In 90% of shops, the last time anyone so much as glances at the database is to run the CREATE TABLE query. No one profiles, no one optimizes—you're lucky if anyone even declares any indexes (ahead of time, as a guess, of course.)

And, consider: if it's the _easy_ part, why are [some] people switching to NoSQL just to avoid doing it? ;)

<comment><USER16> The most frightening part of this debate is that people who are too lazy to properly define indexes are considering NoSQL solutions (and most of those require indexes too)! Properly utilizing a NoSQL requires more work than an RDMS, that's trade off for using a more low-level technology.

</comment></comment></comment></comment></comment></comment><comment><USER17> I don't believe that there really are all of these developers around who lack knowledge of SQL.

I learned SQL while I was learning to program. My very first (real?) program was a php hit counter that wrote to a hits.txt on the server. My second one was a guestbook that used mysql. My third one was a basic hierarchical forum. I wasn't a wizard, I was just a kid reading a book, bored at the Pennsylvania Farm Show.

Thus, I have spent my fair share of time working with sql queries in php code. Guess what? The SQL queries weren't very hard at all.

However, SQL Queries had almost nothing to do with actual using SQL itself. 90% of the code written in such a project is guaranteed to be cruft code surrounding the sql queries. Special cases abound. The difference between "column = $val" and "column is null" is so painful that I just can't imagine going through that anymore.

And that's just the first example! What does "" mean if you save it in a db column? Should you save it as a null value, or as a string with zero characters?

I just don't care about this at all, and you'd have to be a damned fool to think that I would ever willingly go back to doing that bollocks.

I already have my in-memory data structure laid out. ORM lets me keep from worrying about it it again (at least not nearly to the detail I would with SQL). With an ORM, 90% of the database code that I used to have to deal with is simply a non issue.

<comment><USER18>
        I don't believe that there really are all of these developers around who
        lack knowledge of SQL.

I'm not sure why you don't believe that, but as someone that has done development at a variety of companies: trust me, there are plenty of those. They may even be reasonable at PHP or Java, but they couldn't subquery their way out of a paper bag. At one place, the CTO, formerly main PHP/MySQL developer, didn't know what an index was. You can figure out the rest ;)

<comment><USER17> Sorry; I'm not saying that all developers know SQL. I'm saying that the ones that we are all talking about know, or are competent enough to quickly know, SQL.

To me, the people that you are talking about have no context in the discussion in the least. They would be the last to jump on the NoSQL bandwagon because they don't really care, for example.

The universe of discourse only includes the devs who care, e.g. the people who are creating ORMs, using ORMs, using NoSQL, etc, not _all_ developers. I kinda assumed that was implied.

</comment></comment></comment><comment><USER13> This article has its amount of religious bias and wishful thinking. The author tries to establish his base on a fact that SQL is all about relational algebra and it's the right paradigm to query your data. While I agree with the latter, the author (and lots of other people) seems to forget that SQL is a dumbed- down-aimed-to-mediocre-programmers contraption _inspired_ by relational algebra, but not really properly relational! It's really far from what Codd had in mind. If you read the history of early SQL dialects and DB2 vs Oracle competition it's clear that SQL was marketed as a language everyone can program in (thus the stupid imitation of a natural language) -- we know in XXI century that this is a bs...

I'd say that SQL is a COBOL of relational algebra...

<comment><USER19> Are there any (more suitable) alternatives to SQL?

<comment><USER15> The K/Q people (<http://kx.com/>) have one interesting interpretation. It's quite expensive for production use* and uses an APL dialect as a query language, which tends to scare away a lot of developers. I'm utterly fascinated with it, albeit from a distance. (J is cool, too, but doesn't come bundled with a high-end in-memory database.)

* I've heard it can run $60k/CPU. It's designed for realtime stock data mining (<https://cs1.cs.nyu.edu/cs/faculty/shasha/papers/hpts.pdf>), so they get away with it.

<comment><USER11> Can you give us some syntax examples?

<comment><USER15> <http://news.ycombinator.com/item?id=1511121>

I meant to reply to this, didn't notice until after the edit window closed...

</comment></comment></comment></comment></comment><comment><USER20> "The birth of ORM lies in the fact that SQL is ugly and intimidating"

The notion that people steer away from SQL because it is intimidating is absurdly ignorant.

The communities that embrace ORMs and NoSQL are the ones who are learning and creating new things all the time. No one's first language is Ruby, they didn't learn node.js in college, they didn't take an (N)Hibernate certification course. They learn in their free time!

Meanwhile, if you were good in SQL 12 years ago then you still are today!

Smarter people than me have written on these subjects, but for me, the answer is simple. As Fowler says, the most pervasive smell in software is duplication. If I litter my code with all the CRUD SQL (even worse with sprocs that contain column sizes) then my software is quite brittle.

<comment><USER21> If you little all your code with CRUD, your code is horrible indeed.

If I hard code filenames all over my code, I also have horrible code. This doesn't mean that files and file names are a problem or that they caused duplication.

The normal (I hope) practice is to this in terms of transactions or activities and create functions that wrap those activities. SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM.

<comment><USER22> > SQL should only live within those functions that provide a logical interface > to the DB. Its called TAPI or XAPI (transaction API). Think of it as your > own domain specific ORM.

Which is generally repetitive and full of duplication, exactly the thing that drives people to use ORM's in the first place. It doesn't matter that it's isolated into a separate layer, it's still more manual work than an ORM.

<comment><USER21> It is more work than ORM, but if efficient access to data is an important part of your application, it seems to be extra work that brings benefits. At least that has been my experience.

I'm not clear on why this layer has to be repetitive and full of duplication.

<comment><USER22> > I'm not clear on why this layer has to be repetitive and full of > duplication.

Let's say you have a database with 100 tables in it. How many insert statements might there be, just a rough estimate, in your layer of functions? My ORM has 1. At the most basic level, a simple ActiveRecord ORM has 1 insert, 1 update, 1 detele, and 1 select statement. How many are in your typical app? If it's more than 1 of each, then it's duplication.

I haven't written an insert/update/delete statement in years because I don't need to. When I need a fancy select that's an aggregate of several tables, I write a view and then map it into a list of objects with the ORM. This is virtually no work, I spend all of my time working on the actual problem at hand and virtually none marshaling data in or out of the database.

<comment><USER21> I'm totally not following here...

How can multiple insert statements be considered duplication if they are inserting different things to different tables? My apps have multiple insert statements. They also have multiple calls to "print". Do you count that as a duplication as well?

We can continue the discussion by email if you prefer. It is interesting to me, but we may be getting off topic.

<comment><USER22> > How can multiple insert statements be considered duplication if they are > inserting different things to different tables?

Because they're all the same pattern of code. Whenever you see common patterns, you're missing an abstraction that can greatly simplify things.

Why would I write 100 different insert functions when I can write one that generates itself dynamically using reflection over whatever object it is given? You only need one insert statement, it just needs to be smarter rather than static hand written code.

You need only tag your objects with a little bit of metadata using attributes to give a generic insert/update/select/delete everything it needs to dynamically generate parameterized statements on the fly for every table in the db that you use. Put simply, the only thing I need to do to use a User table in an app is write something like the the following...

        class User : ActiveRecord<User> {
            [PersistentString(MaxLength=50, Required=true)]
            public string UserName;

            [PersistentString(MaxLength=50, Required=true)]
            public string Password;

            [PersistentString(MaxLength=5000)]
            public string About;

            public User(){}
        }

And I'm done, I can now Find, FindAll, Save, Delete, Count, Sum, Min, Max, Avg, Count, Exists, Not Exists, etc... on those records without writing a line of SQL. All of these methods are inherited from the superclass and work on the table User. The same thing applies to view and stored procedures.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Well, it's all happening now. First step towards that which I noticed is Moneta (Ruby gem), that is giving you some abstraction over key value stores. I don't think that it's a whole lot of performance overhead and it does let you switch when you realize it's time to.

Overall, you may also want to use orm for sakes of interchangeability of your SQL as well, and it certainly gives you advantages.

Im working on a project that involves no orm and uses oracle as a primary data store. Though I don't want to install oracle On my machine but repository idea built-in to project doesn't let me use postgre for development. And yet schema creation involves varchar2 that's simply inaccessible in postgre. Its quite easy to fix but I'd expect to have some kind of a fallback....

In any case, it's a good point that key-value storages are not for every problem, but that's quite obvious. someone said that every time you say "nosql", a kitten dies. so, careful there.

</comment><comment><USER24> SQL always seemed to me to be the way it is in order to lend itself to optimisation at the database end. It is easy to look at any SQL query (that doesn't use subselects) and see how the DB engine can efficiently execute it by walking down the appropriate indexes.

Try doing that with an ORM or a key/value store.

<comment><USER8> Can you elaborate the issues an ORM has in dealing with indexes? An ORM can be made aware of indexes via, e.g., annotations or other declarative syntax, and prefer those when joining and filtering, and will probably be more consistent about it than a human developer.

<comment><USER24> I didn't mean that ORMs have problems with indexes; just with efficiency: because you can tell the SQL engine what you want done instead of having to bring the data to the code (in particular when iteration can be folded into the query).

<comment><USER8> Yes; but even this only goes so far. Execution plans change based on statistics collected by the query optimizer. SQL was invented because query optimizers do a better job than humans. The same is commonly true for ORMs.

</comment></comment></comment></comment><comment><USER25> In defense of SQL syntax, I think that, in its very constrained domain, it models table / set operations with the best balance of expressivenes, readability, and generality today. At least compared to any other syntax I have seen, including ORM's. We take our old friends for granted until they are gone, and I have had to work with a number of data environments without SQL and its lack was _sorely_ missed. The SAS community was overjoyed at the addition of PROC SQL for this reason, and the goofiness one has to do in R/ SPLUS is quite unpleasant.

<comment><USER21> Even in its own domain, SQL sacrificed parsing for "user friendly" English- like appearance.

SQL error messages are very unhelpful in every DB. You can't easily debug misbehaving queries and there are no tools to help. There is even a lack of indentation standard.

Fixing very long queries that fetch the wrong results is something I've been doing daily for the past 10 years of my life. It is not easy, and I believe the language is to blame for a large part of the difficulty. In some aspects of doing unexpected things with no warning - it is worse than C.

<comment><USER26> Further: SQL is not composable. If I have a fragment of SQL in my hand, there is no reasonable way to insert that into a larger expression. You can further tell this is a problem by the way any nontrivial SQL function degenerates into an enormous hellstorm of SQL that any Haskell programmer will see as full of redundancy. This is because SQL is almost immune to abstraction. (I have to specify the "Haskell programmer" bit because of the characteristics of this sort of language is that working in it directly for a long time causes you to think natively in that language and thereby miss the opportunities for abstraction that you _no longer see_. FWIW, Erlang also bothers me this way.) Yes, the "bad programmer" issue is in play too, but as a good programmer who has tried to write good stored procedures and has experience in numerous other languages I can not help but notice how much SQL _fights_ me on this front.

SQL is very difficult to debug in general, which combines rather poorly with the previous characteristic. Perhaps there are nonstandard extensions in Oracle that make it easier but there's nothing I know of in the core language.

SQL has fooled people into thinking it is equivalent to the Relational Model, when in fact as kunley points out elsewhere it is merely _inspired_ by it.

SQL dates from the 1970s and _it shows_. There are syntax quirks around every corner. The behavior of NULL is sensible, but it is merely one of several sensible choices and there are reasons why the SQL choice is not the one that has "won". Why is "value IN ()" a _syntax error_? It's perfectly reasonable. What's with the syntactic drama around subselects, which ought to be a core part of the better language that we really ought to be using? (A language in which the equivalent is probably going to be so simple we won't even believe people had a special syntax for it.) What's with the rigid specification of the order of GROUP BY and ORDER BY and everything else, when those should simply be instances of some sort of combinator that applies in order, in a sensible manner. Why is SELECT used both for data queries and aggregate queries when in fact the two operations are so different they should have entirely different keywords? Why is it so hard to mix an aggregate and non- aggregate query together when it's obvious to me exactly what I want?

Why can't my columns contain tables themselves, recursively? The fact that there are databases that can do this proves it's not impossible.

SQL needs to be replaced by a combinator-based language that backs to a richer data store that is more sensible, both from a relational model point of view and from a recursive point of view. LINQ points the way, but still is hobbled by LINQ-to-SQL being the flagship LINQ product. (And I don't think it's complete as-is.)

<comment><USER21> I completely agree with every word you said.

But why do you want columns that contain tables recursively?

Aggregate and non-aggregate mixture is supported in the standard and Oracle with the analytical expressions (if I got your meaning correctly).

<comment><USER27> Why not columns that contain tables? It would certainly make things easier. e.g. Get a list of customers with their orders:

SELECT ... FROM customers LEFT JOIN orders ...;

To get this into a presentable table, I would have to keep track of the previous customer's ID and only start a new row if the current customer ID is not equal to the previous customer ID. If table-valued columns were available, each customer row would have a column containing a table of their orders.

<comment><USER21> I have a problem with designing a data model with the "ease of displaying it in a pretty way" as the main consideration.

Nested tables may well be the bee's knees, but probably not for this reason alone...

</comment></comment></comment></comment></comment></comment><comment><USER28> Very good article, I myself have found the "NoSQL" label pointless, when you label something you normally tell what it is, instead of what it's not.

<comment><USER29> "NoSQL" is generally understood to mean "Not Only SQL", not "SQL is evil, begone foul beast".

<comment><USER30> >"NoSQL" is generally understood to mean "Not Only SQL"

I think that that is a bit of convenient revisionism as it becomes clear that the Emperor is wearing no clothes.

There absolutely was a very antagonistic, "this changes EVERYTHING" philosophy behind the movement called NoSQL, and the name is not accidental. Perhaps it was just a bit of trolling to get attention, but in no way was it a live and let live initiative (data tactics that are now bound in "NoSQL" long existed in computer science, since before the days of SQL. They just didn't feel the need to make it a comfortable community of evangelists). It was a "that was yesterday and this is today".

Of course things have changed. A bit of realism entered the mindset, so now it's more of a "Heh heh...no bad blood right? We're all good, eh?"

<comment><USER7> Actually the name was very much accidental. Read this post by the guy who coined the term: [http://blog.sym- link.com/2009/10/30/nosql_whats_in_a_name.ht...](http://blog.sym- link.com/2009/10/30/nosql_whats_in_a_name.html)

"it was one of 3 or 4 suggestions that I spouted off in the span of like 45 seconds, _without thinking_."

<comment><USER30> >Actually the name was very much accidental.

Spur of the moment isn't really accidental, any more than Mel Gibson accidentally said the N-word. There's a bit of a history and a thought process that leads to such a decision.

</comment></comment></comment></comment></comment><comment><USER31> The NoSQL datastores are aimed at solving scaling issues. The current relational databases are a pain to scale. It's not about hating SQL.

</comment><comment><USER32> _> Awkward it may be, but SQL is a lot more succint and readable than multiple lines of API calls or crazy, math-like relational algebra languages._

I'd have to totally agree with this. SQL also achieves higher level of abstraction than any of the above.

Perhaps, as the author said, there is a chance that SQL (or subset of it) will be used as the query language for _No SQL_ -type back-ends.

</comment><comment><USER33> If you know just a tiny bit of relation algebra, then sql is not hard at all. I love ActiveRecord, since it makes you mix the DSL and SQL. Hibernate is impressive, but sometimes i miss SQL, and get's frustrated with it's HQL.

</comment><comment><USER34> >It triumphed over other query languages not because it was particularly great (though it was easier to read), but because it was standard.

Isn't that a tautology?

<comment><USER35> Not all standards are popular. Microsoft's OOXML, for example, is technically an ECMA and ISO standard but I wouldn't call it exactly popular (even though it's widely used due to Office's market position). Because being a standard does not always imply popularity, the statement is not a tautology.</comment></comment>


A Man Just Acquired Hard Drive full of Apple Secrets Documents - <AUTHOR> http://prohackingtricks.blogspot.com/2011/09/man-just-acquired-hard-drive-full-of.html <comment><USER2> I'm surprised he didn't find it in a bar.

<comment><AUTHOR> i can't just imagine how cappuccino could be so careless like this.

</comment></comment><comment><USER3> i bet am never gonna hand that over to Jobs.</comment>


Employer offers of health insurance in Massachusetts are up - <AUTHOR> http://theincidentaleconomist.com/wordpress/employer-offers-in-massachusetts-are-up/ <comment><USER2> There are employers in Massachusetts that don't offer health insurance? What?</comment>


A Chinese farmer has built his own pair of prosthetic arms from scratch - <AUTHOR> http://www.telegraph.co.uk/news/worldnews/asia/china/10079000/Chinese-farmer-creates-his-own-bionic-arms-from-scratch.html

<comment><AUTHOR> Keep hearing stories like this.

Makes me think there's quite the hacker culture in China and other developing countries, driven out of necessity and lack of (or looser) regulation.

This farmer couldn't afford to buy prosthetics so he built his own for 1/10 of the cost and is now selling them to other people in the same situation.

I imagine in the US and EU he would have been shut down over patents, health & safety, etc.</comment>


More Ways to Sell Out of Your Startup Stock - <AUTHOR> http://blogs.wsj.com/digits/2009/06/11/more-ways-to-sell-out-of-your-startup-stock/?mod=rss_WSJBlog?mod=

<comment><USER2> Wonder when the SEC will step in, as they did with Prosper in the P2P lending space. Looks like they're restricting access to only qualified buyers, but I'm wondering how rigorous those checks are. Is it just me ticking off a checkbox on a form?</comment>


There's No Fire Alarm for Artificial General Intelligence (2017) - <AUTHOR> https://intelligence.org/2017/10/13/fire-alarm/ <comment><USER2> A few things here immediately reminded me of an article I recently read about how, regardless of whether or not SARS-CoV-2 was "created" in a lab, the knowledge and tools for such genetic engineering have reached the point where it would have been no great feat to do so.

> Progress is driven by peak knowledge, not average knowledge.

The cutting-edge researchers are already building on their work from two years ago, and in many cases that work has not even been fully digested by other leading figures in the field, much less industry commentators or science journalists. Anyone who is moving the needle of peak knowledge in modern applied sciences is by definition an outlier, and it will take everyone else a while to figure out what they actually accomplished.

> The future uses different tools, and can therefore easily do things that are > very hard now, or do with difficulty things that are impossible now.

The second point seems extremely salient for genetic engineering. From what I have read, processes that required the full resources and expertise of a cutting-edge lab 10 years ago can now be performed by grad student technicians in a few hours with kits manufactured by biotech startups.

</comment><comment><USER3> There are a lot of people in this thread who seem to be very confident and skeptical of the author's position. Maybe this would be a good opportunity to try the exercise he challenges in the article?

Please post your nomination for what's the least impressive accomplishment that you are very confident cannot be done in the next two years.

We can check back in 2022 and see how we did!

<comment><USER4> Proving theorems. I will nominate Cauchy's Residue Theorem. It has already been formalized so a neural network or any generally intelligent agent should be able to do the same: [https://www.cl.cam.ac.uk/~wl302/publications/itp16.pdf](https://www.cl.cam.ac.uk/~wl302/publications/itp16.pdf).

Complex analysis in general is one of the more fun parts of math and I doubt it's getting automated any time soon. It also has a lot of application in signal processing ([https://www.quora.com/What-is-the-application-of-complex- ana...](https://www.quora.com/What-is-the-application-of-complex-analysis-in- engineering?share=1)) so any automation improvements in complex analysis can be carried over to those fields.

More generally, I don't think AI is the scary monster people make it out to be. It's another tool in the toolbox for automation and intelligence augmentation. I don't fear hammers so I don't see why people fear AI and the benefits of extra automation that AI enables.

<comment><USER5> Depending on who's holding the hammer, I do fear the hammer.

<comment><USER4> Why would you fear the hammer and not the person holding the hammer.

Addressing the problem of a person coming at you with a hammer is a much more pertinent issue than worrying about self-aware and malevolent hammers.

</comment></comment></comment></comment><comment><USER6> "Intelligence is situational — there is no such thing as general intelligence. Your brain is one piece in a broader system which includes your body, your environment, other humans, and culture as a whole. […] Currently, our environment, not our brain, is acting as the bottleneck to our intelligence."

"Human intelligence is largely externalized, contained not in our brain but in our civilization. We are our tools — our brains are modules in a cognitive system much larger than ourselves. A system that is already self-improving, and has been for a long time."

"Recursively self-improving systems, because of contingent bottlenecks, diminishing returns, and counter-reactions […], cannot achieve exponential progress in practice. Empirically, they tend to display linear or sigmoidal improvement."

"Recursive intelligence expansion is already happening — at the level of our civilization. It will keep happening in the age of AI, and it progresses at a roughly linear pace."

François Chollet

[https://firstname.lastname@example.com/the-impossibility-of- in...](https://email@example.com/the-impossibility-of-intelligence- explosion-5be4a9eda6ec)

<comment><USER7> Here's an extensive reply to Chollet's essay, also by the author of "There's No Fire Alarm":

[https://intelligence.org/2017/12/06/chollet/](https://intelligence.org/2017/12/06/chollet/)

> ...some systems function very well in a broad variety of structured low- > entropy environments. E.g. the human brain functions much better than other > primate brains in an extremely broad set of environments, including many > that natural selection did not explicitly optimize for. We remain functional > on the Moon, because the Moon has enough in common with the Earth on a > sufficiently deep meta-level that, for example, induction on past experience > goes on functioning there.

>> The intelligence of an octopus is specialized in the problem of being an octopus. The intelligence of a human is specialized in the problem of being human.

> The problem that a human solves is much more general than the problem an > octopus solves, which is why we can walk on the Moon and the octopus can't.

>> Recursively self-improving systems, because of contingent bottlenecks, diminishing returns, and counter-reactions arising from the broader context in which they exist, cannot achieve exponential progress in practice. Empirically, they tend to display linear or sigmoidal improvement.

> Falsified by a graph of world GDP on almost any timescale.

<comment><USER2> Still plenty of time for GDP to turn into a sigmoid

<comment><USER8> Sure, and if we're very lucky it'll eventually go quadratic as our species expands out into the universe in an ever-widening sphere. :-) Few things can grow exponentially forever, but a lot of things can grow exponentially for long enough to have huge consequences -- and that's usually what we care about.

</comment></comment></comment></comment><comment><USER9> If you told people in 90s that at one point in future AIs will be able to:

\- drive a car in traffic in almost all circumstances safer than majority of human drivers basing only on video input

\- take a video and replace faces from another video well enough that more than 90% of people are fooled

\- have 95%+ accurate OCR and speech recognition

\- predict people's preferences regarding music/movies/books better than any human could

\- generate short press articles on arbitrary subject appearing to most readers to be written by a human being

\- win a game of chess/go/starcraft/whatever against the best human players

and asked them how far from that point till we have a general AI - they would most likely say less than a decade.

But now that we are there we devalue these acomplishements because we know how to do them, and still don't know how to do general AI.

<comment><USER10> > drive a car in traffic in almost all circumstances safer than majority of > human drivers basing only on video input

Has that happened? Don't self driving cars use a huge range of sensors, and are they actually legal / widely deployed anywhere at all? Are any for sale? I don't mean improved cruise control, I mean "OK computer, take me to work".

> take a video and replace faces from another video well enough that more than > 90% of people are fooled

Are you talking about deepfakes? I haven't seen an example that was anything other than creepy, and really really obvious. Do you think I'm just really sensitive to this kind of thing, or have I not seen the really good examples?

> predict people's preferences regarding music/movies/books better than any > human could

Why do you think that's happened? Spotify regularly recommends me things I don't like, but I've also never had a dedicated human butler that recommends me music so it's hard to compare, _but_ but I don't think spotify is doing any better than last.fm was doing a decade ago (if I had to have an opinion I'd say it was worse).

\---

I don't want to sound rude or that I'm jumping down your throat, but I don't really feel like we live in the future you're describing, at least not today.

<comment><USER11> > haven't seen an example that was anything other than creepy, and really > really obvious. Do you think I'm just really sensitive to this kind of > thing, or have I not seen the really good examples?

Here's a really good example (the video, not the audio, which the creators say was intentionally degraded):

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

<comment><USER10> So my positive take is that this is the best (or worst depending on your perspective) I've seen for sure.

The negative take is that this still looks really fake to me. His eyes are dead, his head whips around weirdly, his neck undulates and flickers, his face doesn't appear attached to his head, etc. Also, due to how Obama looks he may be easier than other people (ie no hair).

Also, this isn't exactly what OP was talking about, though it's similar. They were talking about replacing faces, whereas this is (I presume) actually 100% Obama video from his various speeches reconstituted. So tbc my reaction was to the various videos I've seen of _that_, none of which have been remotely convincing.

<comment><USER12> Not to mention that there's way more video of Obama speaking than most people

</comment></comment></comment></comment></comment><comment><USER13> Our civilization and ability to dominate over other animals largely exist because of human intelligence. An AGI could be a great partner toward unprecedented prosperity, but an AGI not _fully_ aligned with human values may also spur a major catastrophe.

Two promising approaches toward AI Safety I have encountered:

* Make sure the AI is not too certain of itself and will always defer to humans as the final judge. [https://www.ted.com/talks/stuart_russell_3_principles_for_cr...](https://www.ted.com/talks/stuart_russell_3_principles_for_creating_safer_ai?language=en)

* Get the AI to learn and internalize human values. A possible technique is Inverse Reinforcement Learning: [https://thegradient.pub/learning-from-humans-what-is-inverse...](https://thegradient.pub/learning-from-humans-what-is-inverse-reinforcement-learning/)

Both are being developed by Stuart Russell among others. See his book here: [https://en.wikipedia.org/wiki/Human_Compatible](https://en.wikipedia.org/wiki/Human_Compatible). The latter approach was also discussed on several occasions by Ilya Sutskever.

Many believe AGI will not be realized for at least a few decades hence but no one can really be certain it will not be developed before then.

Since several different approaches together are better than one. Bright minds including those outside the field should propose more ideas for such a significant & unique problem of our time.

<comment><USER14> I'm not sure what the unique existential threat that AGI poses is - humans are more than capable of spurring major catastrophe all by themselves.

I say we take a chance; if it doesn't work out well we are probably going to stuff it all up without the help of an AGI anyway, and at least something intelligent will remain if it decides to kill all humans.

<comment><USER13> From the article, would you say we shouldn't prepare for anything if we suspect that a horde of advanced alien space ships may be landing on earth in a few decades (and possibly sooner)?

<comment><USER14> My point is in thirty years, due to humankinds inability to work together on a common goal of self-preservation and equality, we'll most likely simply be further down the path of the probable collapse of civilization.

If we knew aliens were coming, we'd probably be best off hoping for their benevolence and mercy and preparing as best we could to deserve it.

<comment><USER13> I respectfully disagree. You may wish to check out "Enlightenment Now" by Stephen Pinker for a more optimistic perspective on human progress.

Aliens may not share our values. What we perceive as good may not be so for them, nor might they care if we are "good".

</comment></comment></comment></comment></comment><comment><USER15> "Subsequent manipulations showed that a lone student will respond 75% of the time; while a student accompanied by two actors told to feign apathy will respond only 10% of the time"

My own anecdotal data confirms this: a colleague crashed with his bike just meters from our office. Pretty much the entire company stood there watching him bleeding and screaming on the pavement. I called the ambulance,as it didn't seem anyone was considering doing it at all. I'm sure every single of them would have called the ambulance if they were there on their own. On a different occasion,a friend pulled a few almost drowning drunk guests out of water during a wedding,while the rest stood on the shore watching the whole situation.

</comment><comment><USER16> The decisive moment for AI will come when a program can run a corporation better than humans. That's not an unreasonable near-term achievement. A corporation is a system for maximizing a well-defined metric. Maximizing a well-defined metric is what machine learning systems do well.

If a system listened in on all communication within a company, for traffic, sentiment analysis, who responds to whom how fast, and what customers, customer service, and sales are all saying and doing, it would generate more data than a CEO could ever process. Somewhere in there are indicators of what's working and what isn't. That may be the next phase after processing customer data, which has kind of been mined out.

If this starts working, and companies run by algorithms start outperforming ones run by humans, stockholders will put their money into the companies that peform better. The machines will be in charge.

This is perhaps the destiny of the corporation.

<comment><USER17> I've been saying AI won't be Skynet launching the nukes, it will be a corporation maximizing productivity with complete disregard for human needs heh

<comment><USER18> In a free market, a corporation has to please its customers in order to maximize profit.

For example, Apple.

<comment><USER19> > in order to maximize profit

I'm wondering where this idea comes from (I'm not criticizing you specifically, but that maxim).

Do no investors value stability, longevity, ethical behavior etc?

<comment><USER18> I tend to invest in companies whose products and behavior I like. It's not terribly surprising that they've done well - pleasing customers is good business. I've dumped stock in companies that began a business model of suing their customers to make money - and those companies (again unsurprisingly) tilted down.

Buy companies that customers love, sell companies that customers do business with only because they have to.

</comment></comment></comment></comment></comment><comment><USER20> Artificial General Intelligence isnt a goal its a fear. We reduce everything that we try and program into computers into simple rules because complexity is too hard for us to think about. ML has allowed us to move up a level of complexity but we've had to give up understanding the mechanics of the machine as a consequence. AGI using machine learning techniques needs a function to optimise for. If someone can explain to me how you'd even, in theory, go about teaching an AI about EVERYTHING rather than one specific thing I'll take it seriously. We think the game of Go, because it displays chaotic and complex patterns and is difficult to predict, somehow this 'models' the real world. What it actually shows you is the bewildering complexity the universe is capable of given only very simple rules. The actual complexity of the world is on a different scale. Go has an aim, you can measure if you're getting better at it. General intelligence does not have a defined goal, understand everything perhaps? Even in theory how do you tell if you are closer to this goal or not. In a game of Go you 'nearly' won or lost. How do you get close to AGI and know that you were closer than the last time you tried? Modeling the state of a game of Go in a computer is trivial. What is the model you use to teach a computer about the world or the universe?

Imo not only is our software nowhere close to AGI, neither is our hardware or our ideas.

That said having a fire alarm to tell us the terminator is coming seems like a great idea in theory. As long as the sprinklers spray something that melts metal

</comment><comment><USER21> > The breakthrough didn't crack 80%, so three cheers for wide credibility > intervals with error margin, but I expect the predictor might be feeling > slightly more nervous now with one year left to go.

Good call on that by the author; according to this summary paper [1], a model reached ~79-93% accuracy on various Winograd data sets.

[1] [https://arxiv.org/pdf/2004.13831.pdf](https://arxiv.org/pdf/2004.13831.pdf)

</comment><comment><USER22> The best AI minds are still working on AI consistently recognizing stop signs.

<comment><USER23> The article does directly address this, at considerable length. I'll quote just the subsection headings from that section, each of which is followed in the text by many paragraphs of explanation.

One: As Stuart Russell observed, if you get radio signals from space and spot a spaceship there with your telescopes and you know the aliens are landing in thirty years, you still start thinking about that today.

Two: History shows that for the general public, and even for scientists not in a key inner circle, and even for scientists in that key circle, it is very often the case that key technological developments still seem decades away, five years before they show up.

Three: Progress is driven by peak knowledge, not average knowledge.

Four: The future uses different tools, and can therefore easily do things that are very hard now, or do with difficulty things that are impossible now.

Five: Okay, let's be blunt here. I don't think most of the discourse about AGI being far away (or that it's near) is being generated by models of future progress in machine learning. I don't think we're looking at wrong models; I think we're looking at no models.

</comment></comment><comment><USER24> Discussed at the time: [https://news.ycombinator.com/item?id=15470920](https://news.ycombinator.com/item?id=15470920)

</comment><comment><USER25> General artificial intelligence is nowhere on the horizon, but in it's lesser form - deep learning - it is already happening and already hurting a lot of people. The problem is that its development is concentrated at the hands of a handful of companies and they use it to their competitive advantage. Smaller firms just can't compete. You need 1) algorithms - these are more or less public 2) a lot of hardware - this is very expensive 3) a lot of (labeled) data - this is just not available. You can't get access to the training set that Google collects when billions of people solve reCaptchas, or the NSA listening to billions of conversations, or the Amazon looking at what people buy and what people search.

</comment><comment><USER26> That's because there won't be AGI in my or my children's lifetime. We are successfully solving some perceptual problems now, but cognition is so far out of reach, nobody has even started working on it yet.

<comment><USER27> We went from discovering fission in 1938 to building the bomb in 1945. I think it's entirely possible that AGI won't happen in the next century or maybe even ever, but history is filled with people who say "this can't happen" and are proven horribly wrong.

<comment><USER26> Yes, but then we did not invent much else in this area since then. Computing is fundamentally the same today as it was in the 60's. Sure, transistors are smaller, there's more memory, and clock is in gigaherts, but it's the same paradigm. And this paradigm is not going to take us to AGI even if Moore's law weren't dead for the last decade. Which it is.

<comment><USER28> Have you heard of this thing called quantum computing?

<comment><USER29> Are quantum computers even relevant to AGI? I'm under the impression that the belief that human brains are quantum computers is considered fringe in both computer science and particularly neuroscience, despite having a handful of high profile proponents (notably Penrose.)

<comment><USER30> People have a common tendency to connect one thing they don't understand with another they also don't understand.

<comment><USER31> "If only AI were powered by quantum computers, then AGI would emerge."

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> You don't need a fire alarm for something that doesn't exist and is complete science fiction at this point. We would be better off building asteroid defences as long as we are talking about far-fetched threats to humanity.

<comment><USER3> I mean, general intelligence exists and is not science fiction. I assume I'm responding to one. What should be the first sign that it's no longer science fiction, and it's acceptable to start making a plan?

<comment><USER32> That's actually a bit of an interesting question. General intelligence and human-like intelligence are not necessarily the same, and I'm not 100% convinced there's overlap. We can solve lots of the problems it occurs to us to try to solve, but that alone doesn't prove that we're "general intelligences". There are probably categories of problems we can't solve or even properly conceive, just like every other specialized intelligence. In short, be careful with your definitions. :)

<comment><USER33> Good point and interesting idea, but it's well established in common usage and the field of AGI that the term is meant to refer to human-like intelligence. So that's the default understanding, and you would need to qualify the term to mean something more general as you are describing.

<comment><USER32> Are these the same people in the field who worry about runaway self- improvement and paperclip optimization? If so, then someone is being sloppy with their definitions, because those are not properties of human-like intelligence.

<comment><USER3> Human-like in capability, not in goals. Ability to do AI research and craft paperclips are both human abilities. If the AI has human-like goals then there's very little need to worry.

</comment></comment></comment></comment></comment></comment><comment><USER34> Needs an editor tbh, far too long and waffly.

I'm guessing from the title there may be a useful point to it, but it could do with some tough love to unearth it.

<comment><USER35> "progress is closer than you might imagine"

<comment><USER31> "but it also may be much, much further away than you might imagine. That's the problem when you don't understand something. You don't know what you don't know."</comment></comment></comment>


Real Time Foto Moderator – The Rambling Anti-Elevator Pitch - <AUTHOR> http://blog.crowdflower.com/2012/05/real-time-foto-moderator/

<comment><USER2> I could use this service, but I can't seem to find the pricing for image moderation. The blog post in the link says "clear pricing" but the products page is undefined for image moderation: <http://crowdflower.com/products>

<comment><USER3> You just got to the wrong page. We'll fix the link :)

<http://crowdflower.com/rtfm/pricing>

<comment><USER2> Thanks! This image moderation issue has been a real stumbling block for me.

</comment></comment></comment><comment><USER3> See the app at <http://crowdflower.com/rtfm></comment>


Surprising new feature in AMD Ryzen 3000 - <AUTHOR> https://www.agner.org/forum/viewtopic.php?t=41 <comment><USER3> There have been rumors that Zen could do memory renaming [1], this pretty much confirms it.

[1] Basically the same as register renaming, but instead of using the register file to rename architectural registers, it can rename memory instead.

<comment><USER4> Wonder what side channel attacks this will result in.

<comment><USER5> If the memory renaming cache isn't cleared, I can foresee Spectre-like attacks against that micro-architectural buffer. However, for a new feature like this hopefully they've figured out how to not leave that open…

<comment><USER3> The memory renaming cache is almost surely just the register file.

<comment><USER5> Figured I might as well mention it in case AMD was doing something totally wild, but I would agree that using the register file sounds likely :) I wonder how they manage the pressure on it between renaming and memory mirroring…

<comment><USER6> In principle if you are using the GP PRF it is possible to implement it so that there is little additional pressure: the store instruction already has it's data input a register which has been renamed: now you just need to organize it so that the subsequent load that targets the same location is a no-go: simply alias the arch reg targeted by the load onto the existing register used by the store (much like mov-elimination)

So except for a small window in the middle you have the same pressure on the PRF.

I don't know if that is how it is _actually_ implemented, of course!

</comment></comment></comment></comment></comment></comment><comment><USER7> It's interesting that the author uses a forum as a personal blog

<comment><USER8> KISS at its finest.

You can inline images and code easily. Easy to self-host, so you can own all the data, and you get solid support for comments so you can avoid data- peddling companies like Disqus.

<comment><USER9> _> Easy to self-host_

I wouldn't go as far. Forum software is notoriously annoying to configure securely and to maintain.

 _> you get solid support for comments _

... at the price of people having to create Yet Another User/Password Set, and likely bother you at some point for user-admin tasks.

You definitely keep control of the data though, and some people _really_ like forums.

<comment><USER10> > Forum software is notoriously annoying to configure securely and to > maintain.

I'm not familiar with setting up forum servers specifically, are they difficult to setup for just one user? I can totally see how having proper authentication, emails, caching, etc getting complicated, I'm just curious if it's any user for personal use? Obviously you lose the ability to receive comments though.

<comment><USER9> A lot of forum software is "old school" (i.e. some php, perl, or even vb), which means it's a missed patch away from being compromised. Because they are "standard" engines, they are discovered and attacked often and automatically by tools, like Wordpress - they are a prime spam target for linkfarming. They typically ship a lot of dangerous features like file uploads, and overall security practices are often subpar (integration passwords saved on disk, etc).

Setting a forum up for one user seems like a big waste of time, when there are plenty of perfectly useable blog engines out there that are simpler and more secure to run. Unless, of course, one is already an expert in a particular forum engine.

</comment></comment></comment></comment></comment><comment><USER11> Trying to understand this.

Using latencies from Zen 1 instruction table (see [https://www.agner.org/optimize/instruction_tables.pdf](https://www.agner.org/optimize/instruction_tables.pdf)):

        mov dword [rsi], eax ; MOV m,r latency is 4
        add dword [rsi], 5 ; ADD m,i latency is 6
        mov ebx, dword [rsi] ; MOV r,m latency is 4

Total = 14

Each instruction depends on the result of the previous, so we need to sum all the latency figures to get the total cycle count. Is this right? How does Agner make it add up to 15?

Then for Zen 2:

        mov dword [rsi], eax ; MOV m,r latency is 0 (rather than 4,
                             ; because it is mirrored)
        add dword [rsi], 5 ; ADD m,i cannot find an entry for this.
                           ; Looks like there's a typo in the doc.
                           ; I guess the latency is 1.
        mov ebx, dword [rsi] ; MOV r,m latency is 0

Total = 1

Again, how does Agner make it add up to 2?

And for Intel Skylake:

        mov dword [rsi], eax ; MOV m,r latency is 2
        add dword [rsi], 5 ; ADD m,i - latency is 5
        mov ebx, dword [rsi] ; MOV r,m latency is 2

Total = 9

<comment><USER12> I think the Zen 2 reasons about the operations and operands and converts them into something like these micro-ops and then schedules them for a functional unit and the renamer:

      functional unit       renamer
      add tmp_reg, eax, 5
      st [rsi], tmp_reg     mov ebx, temp_reg

Consequently, I don't think you can use the latency tables directly to get "2". I think Agner probably got those 15 and 2 aggregate numbers from measuring them directly rather than calculating them from the latency tables.

BTW, I'm hand waving on the micro-ops and FUs. There's probably some address generation, ... going on that I'm leaving out. I don't even think the renamer requires a translated micro-op. You could replace _tmp_reg_ with _renamed(ebx)_.

Now the downside. What happens at an exception? You have to back all of this optimization out.

<comment><USER13> > Now the downside. What happens at an exception? You have to back all of this > optimization out.

Just what always happens at an exception. You just replay everything up until the exception occurred.

</comment></comment></comment><comment> dis-sys The author wrote in another thread that

"If anybody has access to the new Chinese Zhaoxin processor, I would very much like to test it."

Will be very interesting to see how much actual changes Zhaoxin made to the VIA cores. I'd expect it to be minimum.

</comment><comment><USER14> Another great thread from the same author: [https://www.agner.org/forum/viewtopic.php?f=1&t=6](https://www.agner.org/forum/viewtopic.php?f=1&t=6)

</comment><comment><USER15> Interesting, L1 caches are fast and even if compilers do register allocation they kinda rely on it being not-too-shitty so when spilling (and many compilers for higher level languages doesn't always invest too much time in reg-alloc since they might need to de-opt soon).

I'm curious if this change is an effect of more transistors (more space for a bigger register file) or if they're taking advantage with the microcode translation of the fact that most code doesn't use the SIMD vector registers and re-use unused parts of the register file for these memory aliases.

<comment> Tuna-Fish I'd bet dollars to peanuts that the temporaries are stored in the gpr prf. It's big, and it's sized so it's not usually a constraint, so they can just push memory operands in there when there is free space and when it would be useful. And most importantly, unlike the vector registers (or any other structure already in the CPU), it can directly feed the ALUs without any new datapaths.

<comment><USER16> gpr prf? General purpose register something register file? Private?

<comment><USER17> Probably _physical register file_ as referenced by [https://en.wikipedia.org/wiki/Register_file](https://en.wikipedia.org/wiki/Register_file). PRF in this context refers to the actual memory that contains all of the register data, which can be much larger than the number of architectural registers to provide for register renaming, which can help performance (basically, the mapping from architectural register names to actual physical registers continually changes so you relieve the bottleneck of waiting for a particular physical register to become available).

<comment><USER16> Ah, probably. I thought "private" might also make sense, in that it's an implementation detail hidden behind the architectural register set.

<comment> Tuna-Fish PRF = Physical Register File. In modern CPUs, there are no separate architectural registers, all register state is held in a single very large register file (for example, 180 entries in Intel Skylake) that contains all register data, and the architectural register names are pointers into this file.

This is different from previous approaches where in-flight register data was held in the ROB and later written back into architectural registers.

</comment></comment></comment></comment></comment></comment><comment><USER18> I love this kind of technical analysis. Is there any repository containing more of these kind of analysis?

<comment><USER19> [https://www.agner.org/optimize/#manuals](https://www.agner.org/optimize/#manuals)

</comment></comment><comment><USER20> I wonder how many little wins like this contribute to AMD's immense efficiency over Intel's current chips?

<comment><USER21> I think the area where Intel is currently lagging is not so much the internal architecture of the chips, but the fabrication process, where they have fallen behind AMD (who is using 3rd party fabs): [https://www.forbes.com/sites/linleygwennap/2020/07/28/intel-...](https://www.forbes.com/sites/linleygwennap/2020/07/28/intel- fab-troubles-problem-for-pc-servers/#6d3eb334408f)

<comment><USER22> Bigger (or rather, smaller) than the fab process was the clever use of chiplets to improve yields.

</comment></comment></comment><comment><USER23> As a Zen2 owner I'm very disappointed in VPGATHERDD througput, that's so 2013. On the other hand I like the loop and call instruction performance a lot.

<comment><USER24> That gather needs to issue 8 independent loads. It's never going to be fast, and I think there's a strong argument that you don't even want to spend the transistors on all the extra load/store units required. The goal of scatter/gather instructions is that they should be demonstrably faster than assembling the values in scalar code, and beyond that... meh.

If you're doing random access to memory like that, you're probably out of the realm of what is appropriate in vector code and should be looking at other hardware (c.f. a GPU's texture units) to manage your memory access.

<comment><USER25> Its theoretically possible to run gather as fast as one cache line per cycle instead of one SIMD lane per cycle. I don't think anyone has thrown that much permute hardware at the problem, though. Its only profitable if you believe that scatter and gather do have cache locality even when they don't have regularity.

<comment><USER26> Isn't AVX512 basically cacheline-instructions?

<comment><USER24> That's the way normal SIMD loads work, yeah.

But the scatter/gather instructions do random access memory operations. You have one SIMD register with a 8 (or whatever the width is) indexes to be applied to a base address in a scalar register, and the hardware then goes and does 8 separate memory operations on your behalf, packing the results into a SIMD register at the end.

That has to hit the cache 8 times in the general case. It's extremely expensive as a single instruction, though faster than running scalar code to do the same thing.

</comment></comment></comment></comment></comment><comment><USER27> Surprising... and a little scary. This is not something I would've expected to be done in the current world of multiple cores. I wonder if things like volatile and lock-free algorithms would behave any differently or even break.

<comment><USER28> Volatile, at least in C and C++, is already broken when used for thread coordination. Lock-free algorithms need to use atomic instructions, which with work.

<comment><USER29> volatile was never meant for thread coordination.

<comment><USER28> And, yet, people still try to use it for that. So it's worth pointing out that it doesn't work.

I think volatile in general is pretty useless, and it'd be better to replace it with atomic style functions:

        x = volatile_read(&v);
        y = use(x);
        volatile_write(&y);

Which is both clearer about what's going on, and doesn't cause optimization barriers to happen everywhere, just around the specific loads and stores you care about.

<comment><USER30> Volatile is for memory-mapped IO. It's not particularly useful anywhere else.

<comment><USER28> Thank you for repeating me again. Though it's not even what I want then. I think the only time I've wanted volatile as is currently specified was around setjmp/longjmp -- and I think I'd prefer that setjmp/longjmp were specified in a less error prone way.

If you're paying attention to the standards community, what I'm wishing for was mostly sketched out in ISO/IEC TR 18037, section 6. ([http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1169.pdf](http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1169.pdf))

</comment></comment></comment></comment></comment></comment><comment><USER31> I sense this question is pretty elementary, but maybe someone can point me in the right direction for reading:

"When the CPU recognizes that the address [rsi] is the same in all three instructions..."

Is there another abstraction layer like some CPU code that runs that would do the "recognition" or is this "recognition" happening as a result of logic gates connected in a certain static way?

To put more broadly: I'm really interested in understanding where the rubber meets the road. What "code" or "language" is being run directly on the hardware logic encoded as connections of transistors?

<comment><USER32> On most x86 chips since the Pentium Pro (and the K6 for AMD, IIRC) the machine code instructions which are visible to the programmer are turned into "micro operations" by the CPU's instruction decoder. See here for a introduction: [https://en.wikipedia.org/wiki/Micro- operation](https://en.wikipedia.org/wiki/Micro-operation)

<comment><USER31> Thanks for the link! So on older chips, like maybe an 8080, I could expect to see literal hardware implementations of instructions?

<comment> Const-me Modern CPUs don't have RISC cores, complex instructions are all the way down.

On current-gen CPUs, only rarely used instructions are decoded into multiple micro-ops, the majority of them decode into a single micro-op, even when they do many things at once like memory load + compute. More often the opposite happens, multiple AMD64 instructions are merged into a single micro-op, this is called "micro-ops fusion".

<comment><USER33> > Modern CPUs don't have RISC cores, complex instructions are all the way > down.

Proof: Intel's LEA instruction is executed as one uop. That's a super complicated instruction that you'd expect to be split into other uops, but... lo and behold, complex all the way down to the end silicon.

Even a "risc" machine: ARM has macro-op fusion, with AESE / AESMC instructions. (Macro-op fuse AESE / AESMC into a singular AES macro-op. A full AES cycle includes both steps, so its very rare to ever need to only do one of the steps).

As such, I've considered "RISC" to be a misnomer. Even RISC-V and ARM are now doing macro-op fusion (and micro-ops). So what exactly is RISC mean anyway?

<comment><USER5> You can't do an operation on something in memory directly?

<comment><USER33> That's just "Load/Store Architecture" though. RISC machines are usually load/store, but so are a bunch of other things, like GPUs and such. Hardly unique to RISC.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> I wonder if it's worth the effort to add functionality to take advantage of this in GCC, clang for just these CPUs?

<comment><USER35> I think the point is that most ordinary C-code should already conform to this access pattern. The side comment about aliasing is a great big hint in that direction.

(This article is grist to the mill of my "every CPU eventually evolves to become an interpreter for its dominant programming language" thesis.)

<comment><USER36> I wonder if this causes a performance penalty on position independent code, which seems to be used a lot on non-Windows platforms [ _].

[_] It always struck me as one of those propeller-head features that GCC & co. love but which the MS and Intel compilers avoid 'just to be on the safe side' :]

<comment><USER37> He mentions this doesn't work with RIP-relative addressing, but I don't see how it would cause a penalty otherwise.

</comment></comment></comment></comment><comment><USER38> Waiting for next side-channel attack..

<comment><USER39> Could you explain the connection between this feature and a possible side channel attack?

<comment><USER40> Agner Fog mentions that the CPU assumes different registers have different values and the calculation has to be rerun if it turns out a write with one register invalidated a cached read with another register. That means you can measure this penalty and infer that the registers had the same or overlapping addresses.

<comment><USER3> This is no different than the existing memory aliasing predictor that has existed for a long time already though, so it doesn't add any new speculation opportunity as far as I can tell.

</comment></comment></comment></comment><comment><USER41> Ok, so most my asm coding and knowledge of exactly what the CPU was doing ended sometime between the Z-80/68K/8086 timeframes. Are there any good books/resources on all the modern trickery that CPUs now utilize?

<comment><USER42> Well, there is the Hennessy&Patterson book, "Computer Architecture - <USER2> Quantitative Approach". The newer editions include modern features and follow industry's developments.

This will of course not be able to tell you all the black magic that is happening inside AMD's and Intel's newest designs. The software optimization manuals for these processors do include some more interesting insights, but especially the Intel ones are not the most entertaining read...

</comment></comment><comment><USER43> This hidden copy feature, do you think someone can exploit it in a similar way as recent exploits like meltdown and spectre?

<comment><USER44> The attacks for meltdown and spectre are completely different to this, I'm fairly certain that explicit features that could break memory protection would be tested. The point of the other attacks is to trick branch prediction to circumvent these protections. It is of course possible this could be used in a way I haven't foreseen...

</comment></comment><comment> Paul-ish It looks like there is a significant miss penalty for aliasing. Does anyone know if Rust's ownership rules would help avoid these penalties.</comment>


User uploads fake flag to Wikipedia, flag companies run with it. - <AUTHOR> http://forum.watmm.com/topic/52097-fucking-nice/

<comment><USER3> The internet is a very complicated machine that can turn boredom into a flag.

</comment><comment><USER4> I think this is good commentary for what people will believe. This suggests that entrepreneurs can make larger leaps in "logic" (although they may not be based upon reality or fact) and make a success out of it.

I'm sure there are examples of this in real life.

Microsoft anyone? (we certainly cannot deny their revenue.)

<comment><USER5> It's usually just called advertising.

</comment></comment><comment><USER6> It's a pretty good flag. I think Herefordshire should adopt it.

<comment><USER7> I agree. It's pretty naff but it still beats my own county's eye-piercing _real_ flag design: [http://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Fla...](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Flag_of_Lincolnshire.svg/800px- Flag_of_Lincolnshire.svg.png)

<comment><USER8> Oh _jesus_ , whoever designed that clearly hated people with sight.

</comment></comment></comment><comment><USER9> [http://www.dissidentcongress.com/index.php?page=countyflags....](http://www.dissidentcongress.com/index.php?page=countyflags.php&flag=herefordshire&ext=gif)

I think this is the real flag, if anyone cares.

<comment><USER10> The Wikipedia version seems better laid out, IMO.

<comment><USER11> There's a whole study behind flags and heraldry which is many centuries old. It has its strict rules. You can't just go around and "fix the layout" according to the latest esthetic trends. Look at the flags / coats of arms designed in the 60s / 70s to see what sort of disaster this leads to.

<comment><USER12> Just curious: what sort of "disaster" DID they lead to?

<comment><USER11> Of course I meant "disaster" metaphorically. No one actually died or got injured because of ugly coats of arms and flags.

Here are some examples of antiheraldic flags and coats of arms:

* The flag of the State of Georgia <http://www.50states.com/flag/gaflag.htm>

* The coat of arms of a city in Easter Europe: [http://upload.wikimedia.org/wikipedia/hu/8/89/Zalaegerszeg_a...](http://upload.wikimedia.org/wikipedia/hu/8/89/Zalaegerszeg_antiheraldikus_1974-1989.PNG)

* Generally any flag / coat of arms designed in the Soviet Union

</comment></comment></comment></comment></comment><comment><USER13> I am amused. Although someone already has it flagged for deletion. Gotta add my 2 bits.

[http://commons.wikimedia.org/wiki/Commons:Deletion_requests/...](http://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:Flag_of_herefordshire.PNG)

<comment><USER5> The humorless editors of wikipedia need to stop fighting it and embrace their role as dictators of truth already.

<comment><USER13> Humorless indeed. And folks wonder why the wikipedia foundation has to beg so hard for donations, well, the constant bureaucracy and rule-worship tends to disuade contributions.

</comment></comment></comment><comment><USER14> I don't know what he's complaining about. The flag was uploaded as public domain. People should be able to do whatever they want with it. If he wants to make money, he should go produce and sell flags too.

<comment><AUTHOR> I don't think he's complaining, really.

<comment><USER15> Yeah I thought he's more amazed that people apparently just take stuff off of wikipedia and start manufacturing it without cross-checking with a single other source...

<comment><USER16> He is. Flags are a market with a necessarily huge selection, though - <USER2> _wouldn't_ they snag every legally available design someone might buy? They probably manufacture the less-common selections on an as-needed basis, after all.</comment></comment></comment></comment>


Taught my GF the basics of open-source. Now she is creating an open city design - <AUTHOR> https://www.colaburbis.com.br/?lang=en <comment><USER2> Not sure how well known Christopher Alexander's books (from 1970s) are in these circles, but his ideas are very related:

"At the core […] is the idea people should design their homes, streets, and communities. This idea […] comes from the observation most of the wonderful places of the world were not made by architects, but by the people."

I originally ran into the books as he was called as the father of design patterns. In the books he has collected design patterns for houses and cities.

At least couple of years ago books were also available in Amazon.

[https://en.m.wikipedia.org/wiki/A_Pattern_Language](https://en.m.wikipedia.org/wiki/A_Pattern_Language)

<comment><USER3> Founder here! Thank you for your comment :D

He is one of my main references. If you like his thoughts you may also like:

The Open Source City: [http://www.theopensourcecity.com/](http://www.theopensourcecity.com/) Freeland: [https://www.youtube.com/watch?v=vMoQCRweXdU&t=2s](https://www.youtube.com/watch?v=vMoQCRweXdU&t=2s)

The first one is being held in Raleigh, EUA and the second one in Almeere Oosterwold, The Netherlands.

</comment></comment><comment><USER4> I never expected to read about Goianira on HN. I lived there for a couple of years in early 2000. It seems to have grown quite a lot since then.

I wish your GF good luck with her project!

<comment><USER3> Founder here! Thank you for your comment :D

I worked in the Director Plan of Goianira in 2018, that is why it is my study object! It has grown a lot this past few years, but I am not from there, I am from Brasilia.

Thank you for the good luck wish!</comment></comment>


TiML: A Functional Programming Language with Time Complexity - <AUTHOR> https://github.com/mit-plv/timl <comment><AUTHOR> paper: [https://people.csail.mit.edu/wangpeng/timl.pdf](https://people.csail.mit.edu/wangpeng/timl.pdf)</comment>


Ask HN: What are some challenging web apps I can build? - <AUTHOR> What are some challenging web apps that I can build for learning purposes? Thanks. <comment><USER2> \- human v cpu rock, paper, scissors (bonus round: real-time human v human)

\- human v cpu tic tac toe (bonus round: real-time human v human)

\- human v cpu battleship (bonus round: real-time human v human)

\- Wordpress clone

\- IRC clone

\- E-commerce site (focus on the product catalog and shopping cart, with a checkout process that doesn't really have a payment integration, and a history of orders)

\- A dashboard that provides visualization of data sets

\- Twitter clone

\- Facebook clone (basically, take your Twitter clone, remove the character limit, add in some comment and group functionality, and add your IRC clone into the mix)

\- Expand Twitter/FB clones with tweaks that let you manipulate how the timeline is displayed to a logged-in user

Look at anything you've used, played, tried that you feel you understand how it works. Then build it.

<comment><USER3> "checkout process that doesn't really have a payment integration"

What do you mean by that ?

<comment><USER2> Don't bother adding a real payment processor like Stripe. OP said for learning. Tackle that later.

</comment></comment></comment><comment><USER4> Well since you asked... Build a website that teaches kids to code in python by creating simple games. All the python should be written and executed on your server so the students don't have to setup anything. The site should include a simple 2d game engine framework that more experienced programmers can develop tutorials for. I was going to build it myself but go for it if you want.

<comment><USER3> a quick google search shows this [https://www.penjee.com](https://www.penjee.com). looks cool

<comment><USER4> Very close to what I am looking for. Thanks for the link.

</comment></comment></comment><comment><USER5> 1) What is an app you use often? 2) How would you improve upon that experience?

Ok, build _that_

</comment><comment><USER6> Most web apps are not very challenging to build until you start thinking about scale. Twitter for 100 users is easy Twitter for 1,000,000 users is much more challenging.

<comment><USER7> Genuine question - could you please elaborate a bit on that? I sort of know what you mean, but I'm just an amateur. So the problem with large scale is creating algorithms that distribute and balance the workload on the servers, database access speed, optimal cashing, keeping 100% uptime, backup, separating different parts of the application and putting them on different servers, concurrency and solving the problem of simultaneous access to same resources? Anything else?

<comment><USER8> I think a part of what you forgot is that often you're doing those things you list "in-flight" and on an as-needed basis as the application scales. You don't start out building Twitter for 10,000,000 users, you start out building for 10 users. As the userbase grows, you've got to start thinking about how you're going to change major components of the system safely and without any hiccups.....and in a way that they still work with legacy systems, legacy code, third party code, etc etc

You've also got to make key decisions about whether to scale vertically or horizontally and often there's no one right answer in any of these scenarios. You can re-build today's Twitter in any number of ways to get to the point they are at now. However, the process of getting to today's Twitter would look very very different depending on how much time, money, talent, and other resources you had at each step along the way.

Basically, it's the _process_ or _transitions_ that are very notably difficult, perhaps not the end implementation itself. You've also got to balance these transitions with constraints like time and money. For example, you can't just throw a bunch of AWS instances at an infra problem to buy time, unless you've got the money.

And that's only from an infra perspective. From a product perspective there's a whole slew of things that are needed at scale that you don't necessarily need early on. One example is "how are you going to scale the cost of user/customer support"?. When it's 100 people using your product, you can deal with all the emails, but if it's 10,000,000 people using your product, can you really handle each and every case that comes through? Do you have money to hire a team to handle these cases? Can you build stuff into the product that reduces case-load? etc, etc.

Anyway, I'm rambling now....perhaps someone more experienced than I could share some better insights.

</comment></comment></comment><comment><USER9> The one app I've always is an SMS forwarder on MS mobile platform. You'll make one person happy if you build this.

<comment><USER10> Make that two ;)

</comment></comment><comment><USER11> a system that allows people transparent voting of the so called arbitrary laws, so we can verify and stop complaining about corruption.

Im not saying that democracy is the best form of government always. You wouldnt want to stay in a place where the majority of people vote: 'F __k freedom, we want islam '

<comment><USER12> seriously? I'm muslim and when you use the word islam as the opposite of freedom that's actually offensive. Not here to correct or change your mind about your view on Islam (not a topic for HN anyways) but just saying that choosing your words more carefully is a valuable skill.

</comment></comment><comment><USER13> VR porn demo / teledildonic dashboard</comment>


PUT or POST: The REST of the Story - <AUTHOR> http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ <comment><USER2> Rather than mentally mapping REST verbs onto traditional CRUD verbs, I recall a quote from TBL to the effect of "Uniform Resource Locator is the term you get when you squeeze 'remote object reference' through a standards process". I think of PUT as being like Python's __init__ method, constructing a new instance with the given details; DELETE is like Python's __del__ method, cleaning up references and removing it; GET is like Python's __str__ method, returning a readable representation of the object's state, and POST is like Python's __call__, invoking the object as a function with some given arguments and who-knows-what side-effects.

</comment><comment><USER3> His key point:

After that discussion, a more realistic mapping would seem to be:

* Create = PUT iff you are sending the full content of the specified resource (URL).

* Create = POST if you are sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm.

* Retrieve = GET.

* Update = PUT iff you are updating the full content of the specified resource.

* Update = POST if you are requesting the server to update one or more subordinates of the specified resource.

* Delete = DELETE.

I am not sure about "Update = POST if you are requesting the server to update one or more subordinates of the specified resource" - seems to me that if the subordinate updates are idempotent - then this can be PUT, why not. But going a bit further - of all the server side algorithms used for Create calls the most used one is computing the primary keys for auto increment columns. So if you are not using some special database functions - a Create needs to be POST if the primary key is auto-increment and can be PUT otherwise.

<comment><USER4> In regards to the Update PUT vs Update POST, with the PUT you can only address a single resource. So while the Update POST maybe idempotent, to accomplish the same thing with a PUT, you would have to issue multiple PUTs to address all of the resources that were updated in the POST.

</comment></comment><comment><USER5> I think of PUT as PUT == (over)write.

        GET == read
        PUT == (over)write
        DELETE == delete
        POST == invoke (custom processing)

The effect of a POST then comes down to the definition of that "custom" processing. This is outside the scope of HTTP; don't conflate the two.</comment>


How to Stay Marketable as a JavaScript Developer in 2019 - <AUTHOR> https://cvcompiler.com/blog/game-of-frameworks-javascript-trends-of-2019/?hackernews <comment><USER2> That seems a strange premise. The way to stay marketable is to be more than a Javascript developer. Nobody should be a one-trick pony.</comment>


The biggest games company you may never have heard of - <AUTHOR> http://www.gamesindustry.biz/articles/2010-09-13-money-games-tencent-tagopt-brief-feature-type-research

<comment><USER2> Nothing new, chinese market has been good for Tencent for a long time...</comment>