Why You Hate Contemporary Architecture - <AUTHOR> https://www.currentaffairs.org/2017/10/why-you-hate-contemporary-architecture <comment><USER2> > It should be obvious to anyone that skyscrapers should be abolished. [...] > there is plenty of space left on earth to spread out horizontally; the only > reasons to spread vertically are phallic and Freudian.

Because endless miles and miles of urban sprawl is so much more attractive than a skyline and a lot of surrounding countryside. I wonder how much more real estate the average metropolis would take up if downtown was flattened to a few stories?

<comment><USER3> This isn't a fair comparison in the US, where the majority of cities' downtowns are skyscrapers standing alone in a vast sea of parking lots and freeways. Compare Dallas to something like Paris, especially on population density.

<comment><USER2> I've never been to either city, but from looking at pictures, both seem to fit your description. If anything Paris looks "flatter", but maybe that's just the composition of these photos.

In any case, my point is that if we decide to always build out instead of up, whatever urban sprawl already exists in any city will only be made worse. City planners actively try to avoid sprawl for a number of reasons, including that it makes public transportation less effective, increases smog, and reduces access to green spaces.

<comment><USER3> That's the point. Skyscrapers are a rarity in Paris - now go look up the density of the city proper.

<comment><USER2> > now go look up the density of the city proper

Nah, I don't accept homework assignments from condescending people on the internet, sorry. Feel free to dig up the numbers yourself and post them here, though.

While you're at it, you might be interested in looking up New York City, which is far denser than Paris. What do you think would happen if all the skyscrapers in NYC were flattened out? Where should those people go? Shall we pack them into the city's existing footprint with all the other sardines?

<comment><USER3> Didn't mean to condescend. Anyway, Paris has 21,498 people/km^2 [0], twice that of New York (10,933 people/km^2), and without an equivalent Manhattan. For the majority of large cities in the USA (14 of the top 20), the given density is under 2,000 people/km^2 [1], including Dallas (1,493 people/km^2). That's the kind of thing I was referring to. Of course, New York and San Francisco are much denser; I was not talking about them, but the _average American city_. I'd like to give the article the benefit of the doubt that so were they.

ED: I should add that I don't consider New York an average American city because it's a success!

[0] (Wikipedia, but calculated from [https://www.insee.fr/fr/recherche?idprec=3293086&q=paris&deb...](https://www.insee.fr/fr/recherche?idprec=3293086&q=paris&debut=0))

[1] [https://en.wikipedia.org/wiki/List_of_United_States_cities_b...](https://en.wikipedia.org/wiki/List_of_United_States_cities_by_population#United_States)

<comment><USER2> Okay, I'm looking at the numbers more closely now and I concede that Europe's most densely populated city, an extreme outlier, is more densely populated than America's extreme outlier. I also concede that it is denser than Dallas, which is one of the least dense cities in the United States.

If you look at the population densities of median American and European cities, they're quite similar (~13,000/sq mi. or 5000/sq km.). Which makes me wonder why you insist on comparing two cities that are not remotely comparable. Seems like cherry picking.

> ED: I should add that I don't consider New York an average American city > because it's a success!

I'm _almost_ curious why you consider the "average" U.S. city "not a success", but this remark smells too much of the pompous anti-American groupthink that has become so popular on HN lately, so I know better than to expect a rational explanation.

Honestly, I'm starting to find your undeservedly superior attitude and cherry- picked data tiresome, so I don't think I'll bother with this conversation anymore. Have a nice night.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> Is it wrong to like a lot of the examples of "bad architecture" listed in the article? Are we _required_ to hate contemporary architecture?

From the pictures in the article, London's "Alexandra Road", the Poydras building, the Tour Montparnasse, and the Caltrans District 7 HQ genuinely look really nice. I would love to live in/near any of those buildings.

I don't understand why the author assumes "clean lines" and "geometric shapes" as being some depression-inducing "sickly" visual. Are things only allowed to look nice if they are wrapped in psuedo-victorian embellishments?

<comment><USER5> I agree with you, I like most of the examples shown that are supposed to horrify you. I like most of the traditional, "good" examples too, but not reflexively.

The points made are reasonable, though, and not the first time they've been made.

</comment></comment><comment><USER6> Brutalism, the focus of the piece, is not contemporary architecture. It was big _decades_ ago after WWII but fell out of favor rather quickly.

Of special note: the opinion piece compares two hospitals. The nicer looking hospital is now a museum and has been for years. The interior pictures of the former hospital's rooms show massive rooms without AC, plumbing, or privacy. The article asks which hospital I would rather convalesce in? The ugly squat one with private rooms and plumbing, obviously. I don't care what the outside of the hospital looks like when I'm in side it.

<comment><USER7> That point is addressed in the piece in one of the photo captions:

> Architects often get mad when non-architects conflate the terms "modernism," > "postmodernism," "Brutalism," etc. They love telling people that, say, > "Frank Gehry is actually REACTING to postmodernism." These terminological > disputes can obscure the fact that everything under discussion is actually > just a minor variation on the same garbage.

I for one agree with that.

> The article asks which hospital I would rather convalesce in? The ugly squat > one with private rooms and plumbing, obviously.

You know this isn't either-or, right? The old building might lack amenities just because of when it was constructed, but you can build new beautiful buildings that have them. There is no reason why modern requirements necessitate godawful buildings.

<comment><USER6> I actually agree with the bit about term conflation as well, but not the rest of the article.

They're comparing literally hundreds of years of architecture to a short 2-3 decade period following one of the most calamitous wars in history, when Europe was struggling to rebuild itself and function was more important than pretty exteriors.

 _You know this isn 't either-or, right? The old building might lack amenities just because of when it was constructed, but you can build new beautiful buildings that have them. There is no reason why modern requirements necessitate godawful buildings._

Modern requirements don't necessitate godawful buildings, budgets do. In those rare situations where the budget is unlimited (i.e., see any building being built around Mecca), you end up with both beautiful exteriors and functional interiors. But otherwise, every dollar spent on a fancier exterior is a dollar that can't be spent on interior features. And occupants (residents or companies) care more about the interior than the exterior.

</comment></comment></comment><comment><USER8> I was hoping for an explanation of why architects makes the choice they do in contemporary buildings, but instead its just a bunch of "architects are idiots" and "I hate this and you should too".

Absolutely no substance here.

<comment><USER9> I found it full of substance, with the main takeaway that architects are designing for other architects instead of the people who use the building.

I see plenty of parallels to software development, where there is a common tendency to design around engineering prowess instead of user experience.

<comment><USER10> It's interesting. Apparently, in mid-to-late 20th century, the discipline of architecture was bursting with self-described architects who rarely, if ever, had buildings created.

They instead focused on architectural 'theory', which meant anything from phenomenological approaches to space (Gaston Bachelard), to 'Architecture as Metaphor' (see book with same title by Kojin_Karatani, a critical theorist), hell, even theory-fiction (Benjamin H. Bratton).

A whole generation (or two, three?) of theorists have spent lots of time intellectualizing and philosophizing what, for a long time, seemed to be a design-oriented, practical discipline.

I wish I had sources for this -- it's only through informal conversations with practicing architects and theorists that I learned these things.

</comment></comment></comment><comment><USER11> The article cites the freaking sistine chapel here as an example of good architecture. No matter what you think of contemporary styles, one shouldn't compare things that were constructed because a few people had an unimaginable amount of money to spend on as lavish of a space as possible to functional structures.

</comment><comment><USER12> Tom Wolfe's old book "From Bauhaus to Our House" took on some of these issues. In particular, modern architecture's alleged "form follows function" taking some bizarrely twisted thought processes to end up building flat-topped buildings in climates with large snowfall. Seriously? What were they thinking?

<comment><USER13> Yup. Here's my brief list of the "what the heck is the function that this form follows" in modern architecture :

-Light management: humans need light - so, naturally, modern concrete slabs dispense with windows. Solid wall, here we go! Enjoy your fluorescent flickers. Skylights? A thing of the past.

-Air and climate: humans need air to breath, and exhibit varying preferences for temperature. So, again, no windows! Heavens forbid someone would _open_ one. If there are windows, they should be glass panes that can't be opened. And the AC should be centrally controlled, because there's only One True AC Setting. But only use single-pane glass, lest one thinks that costs were a concern.

-Rain. Rain! Humans, on some occasions, prefer not to get wet in the rain. And outside of Seattle, people have been known to carry _umbrellas_ for that purpose. Naturally, a modern building must not allow anyone with an umbrella in. Make a door narrow and hard to open, and no overhangs! Make sure one gets wet while folding the umbrella in front of the door. Bonus points for making the ground floor subterranean, ensuring the biannual building flood. (You already covered that the roof must be flat-topped to accumulate snow and be more prone to leaks.)

-On the subject of doors, make the main entrance in the back. Dispense with side entrances. Nothing should deface the monolith of the facade. You should arrive by car anyway, and walk the desolate parking lot. The building is not to be accessed from the street. Bonus points for employing electronic locks to create exit-only doorways (apparent only after you try to get back).

-It is the woe of many architects that people desire to get to floors of the building other than the ground floor. Give them a dilemma: wait for a cramped elevator, or walk the staircase that looks like it's something the maintenance crew forgot to lock down. No natural light either way, even though people have invented glass millenia ago. And make the steps on the staircase as tall as possible to make the walk tiring and unpleasant. Spiral staircases - a taboo.

-People might try to navigate the building by memory. So make the layout labyrinthine, but without any visually distinguishing elements. Every corner should look the same. Bonus points for room numbering schemes that seem to have taken a cue from the Mad Hatter.

-Did I mention doors? The more doors, the better. Humans like figuring out which ones are unlocked by trial and error.

-It is quite unfortunate that the pure architecture has to abide to such whims of human physiology as the need to use the toilet. So make them hard to find. Bonus points for having men and women toilets on different floors, just for the kicks.

-Sometimes people talk to each other. Ensure there is no comfortable space for them to do that. Corridors will do just fine (remember, no natural light in the corridors, or everywhere). No semi-secluded corners - every space must be panopticon-like. Sound insulation is a non-concern.

All this is just from a handful of examples I've had the pleasure of working in, and replicated endlessly. The list goes on.

<comment><USER14> Maybe we don't have the same modern architecture ... My experience from Sweden and France:

\- Windows are bigger than ever today, at least in Europe. It used to be that windows were not that big to keep warm inside, and because they were expensive to build, nowadays most buildings have super huge windows, and so do houses. They have actually grown so big that you need to find ways to STOP the natural light from the windows.

\- Single glass panel? Where do you even live? Old buildings have that, in modern ones you have triple pane glasses, and central AC in big buildings is a necessity. Right now I work in a XV century building and the air is MAGNITUDES worse that what it was in a modern office we had, evne when opening the window, because the air flux is not optimized and there is no AC.

\- Doors in old buildings are smaller, they have gotten much bigger due to requirements of accessibility, and you can actually open them with a button now.

\- Never seen a main entrance in the back, and modern buildings don't even have parking lots because fuck cars and hurray for public transports

\- Elevators are always over dimensioned and not so much a trouble, spiral stairs are still very common

\- Likeliness is a real thing, but on the other hand it can be the same in old buildings as well, the thing is that usually they have changed a lot so places are different, but it will be the same with modern buildings with some time. Regarding the room numbering most places I was at had a very logical system and it was independent to the modernity of the building.

\- There are much less doors than it used to be, spaces are actually too open now which is annoying for noise. I wish we had more doors in offices. On the other hand in apartments it's very nice, what were people thinking before ?I would say we have maybe half the walls there were 60 years ago, so half the doors. Who needs a freaking hall with doors to go in each room in a 70m2 appartment? Now they are finally opened.

\- That has been a problem only in old buildings in my experience because they lack signs. Modern buildings always have really well indicated bathroom, sometimes unisex, with a big logo on the door, not just a random wooden door that could be a kitchen, a meeting room or the bathroom!

\- Sound isolation is so much better now. It used to be bad (before 1940), it went horrible (1940-1970) and now it's finally OK.

<comment><USER13> >Maybe we don't have the same modern architecture ...

Yeah we don't. Welcome to the US.

> Never seen a main entrance in the back, and modern buildings don't even have > parking lots because fuck cars and hurray for public transports

( _weeps silently_ )

Also re: sound insulation:

>It used to be bad (before 1940), it went horrible (1940-1970) and now it's finally OK.

My definition of "modern" is, essentially, postwar, so it includes all the monstrosities from the 1950-1970 era. We are doing better now, that's true.

</comment></comment></comment></comment><comment><USER15> I don't know why the Alexandara Road was put in there as an example of dull contemporary architecture. It only looks that way in the heavily filtered image the author put up. If you look at other pictures, it actually loooks really nice, largely because it follows some of the principles the author himself advocates (integrating nature and aesthetic coherence).

</comment><comment><USER3> Before anyone dismisses this as a one-sided attack on socialism through the language of architecture,

"[W]hy so many on the left are wedded to defending unpopular schools of architectural and urban design is less immediately obvious."

yet further down,

"Capitalism eats culture, and it makes ugly places. Money has no taste."

and,

"There is a widespread conception, reinforced by conservative classicists, that "beauty" is just a euphemism for European imperialist art."

It has strong words for both sides of the debate.

</comment><comment><USER16> It's easy to pick and choose good and bad examples from different eras of architecture. It is unfortunate the author paints all contemporary architecture as cold. I would suggest the movies 'columbus' and 'my architect' to people looking for another perspective.</comment>


Ask HN: let's do a startup website link party - <AUTHOR>

Let's share our favorite links about startups ! I start with one that I use very usefull : http://answers.onstartups.com/ <comment><USER2> <http://localhost>

(Seriously, this is probably going to be the crappiest day for signal to noise ratio on HN. Time to get some work done.)

</comment><comment><USER3> I don't really follow "startups" outside of HN. Guy K's alltop probably has some links though.</comment>


Android Now Running On iPhone 3G - <AUTHOR> http://www.pcworld.com/article/195789/android_now_running_on_iphone_3g.html <comment><USER2> While the hacking must be interesting and rewarding in it's own right, does it have any practical advantage over running one of the existing Android phones? i.e., is there something uniquely good about the iPhone hardware combination?

<comment><USER3> It allows you to run iPhone OS alongside with Android OS?

<comment><USER2> At the same time? Surely not?</comment></comment></comment>


Wapp – A Web-Application Framework for Tcl - <AUTHOR> https://wapp.tcl.tk/home/doc/trunk/README.md <comment><USER2> Wapp is a great piece of software. The entire "framework" (including the HTTP server) is just under 1000 lines of code (and that's including comments).</comment>


After Selling Millions, Family-Run Makin Bacon Battles Amazon Counterfeiters - <AUTHOR> http://www.forbes.com/sites/susanadams/2017/02/13/after-selling-millions-family-run-makin-bacon-battles-amazon-counterfeiters/ <comment><USER2> The problem is Amazon doesn't care one bit. They do what they have to --the minimum they have to-- but eventually tell you it is a business problem that you, as the brand owner, have to contend with on your own. Meaning, outside of Amazon. If you have a popular product this is pretty much impossible.

On the other hand, they have made deals with brands just as Levi's to protect the brand on Amazon. Nobody can sell Levi's on Amazon. They've done this with other brands as well. If you are not big enough for Amazon to care you are screwed.

</comment><comment><USER3> And Amazon still gets a cut from each sale, cheap chinese counterfeit or not.

</comment><comment><USER4> Seems like there could be good money in there if someone were to create a tool that allows sellers to track down fakes on sites like Amazon and fire off the appropriate takedown requests to the retailer.

<comment><USER5> Seems like one may be covered:

FTA: " Jon uses a piece of $10-a-month subscription software called Visual Ping that scans the Amazon page of Makin Bacon's main third-party seller and alerts him when the "compare with similar items" number ticks up, alerting him that a new fake has been posted. But the fakes are so numerous, he says, he can't keep up."

Looks like a possible demand for number 2.</comment></comment>


Can Mom-and-Pop Shops Survive Extreme Gentrification? - <AUTHOR> http://www.nytimes.com/2012/06/10/magazine/can-mom-and-pop-shops-survive-extreme-gentrification.html?_r=1&hp <comment><USER2> "You make it yuppie, nobody will want to come," Walker said, improbably. "They like the old-fashioned way."

Gentrified areas are probably the best place for a lifestyle business like those described; you can't compete on cost with the big-box stores, so you need a clientèle for whom cost is less important.

The point about chains treating a store in a trendy area as an advertising loss-leader stands, though I wonder how practical that actually is.</comment>


Wandering ship becomes "best cruise ever" despite coronavirus fears - <AUTHOR> https://news.yahoo.com/wandering-ship-becomes-best-cruise-023825887.html <comment><USER2> This article may not age well.

One of the women on this ship has since tested positive for COVID-19.

She was allowed to leave and flew to Malaysia before she tested positive.

[https://www.nytimes.com/2020/02/16/world/asia/coronavirus- cr...](https://www.nytimes.com/2020/02/16/world/asia/coronavirus-cruise- americans.html)

</comment><comment><USER3> Holland America are PR geniuses. They've taken one hell of a lemon and made some very sweet marketing lemonade out of it.

<comment><USER4> Depends how many passengers test positive for COVID-19. Current count so far is just 1, but a second cruise ship that was quarantined (the Diamond Princess) now has 350+ confirmed infected passengers, or about 10% of that cruise, also from a single initial case.

</comment></comment><comment><USER5> I can't imagine a prison being nice, no matter how lavish the amenities.

Unrelated: The absolute and total no-holds-barred lack of due process is why I have always been reluctant to go on a cruise. You are basically subject to a mini floating dictatorship the whole time you are aboard. I wonder if this is a press hit designed to distract from that, now that it's been in the news. Cruises are a huge industry.</comment>


Learning iOS/Swift tempted to switch to React Native as it seems like the future - <AUTHOR> I've been learning iOS for a couple of months and I like it so far but more and more I feel tempted to switch to React Native instead as it really seems like the future and the most flexible and also quicker to develop than native (not to mention the advantage of being able to compile for both iOS and Android). More and more it seems that the market is for the app to be on both platforms, so React Native seems more viable.
Has anyone else gone through the same? What did you do? Is native development and being confined to one platform (iOS) a good long term choice?
Thanks in advance <comment><USER2> I've been a native iOS developer since 2008. So far, I haven't seen the need to switch to react. And have run across a few developers failing with products on react native platforms. The right tool for the right job. I just don't think it's an all or nothing proposition. There will be opportunities for both react and native. So, if you are leaning towards react. There are probably plenty of jobs in the react mobile space.</comment>


Traction Book available for pre-order – G. Weinberg (DuckDuckGo) and J. Mares - <AUTHOR> http://www.tractionbook.com/

<comment><USER2> Co-author here. I actually started exploring this book topic in late 2009 through an initial series of open-ended interviews that were discussed on HN (when it was much more startup focused). Here is that set: [https://www.youtube.com/channel/UC6r4nAnkQO3VpddRSVwUVDg](https://www.youtube.com/channel/UC6r4nAnkQO3VpddRSVwUVDg) (e.g. patio11 [https://www.youtube.com/watch?v=wuzNs- LhC_8](https://www.youtube.com/watch?v=wuzNs-LhC_8), Alexis [https://www.youtube.com/watch?v=enEqAq1x9UQ](https://www.youtube.com/watch?v=enEqAq1x9UQ), Garry Tan [https://www.youtube.com/watch?v=8Win0moC4cA](https://www.youtube.com/watch?v=8Win0moC4cA)).

I started angel investing around the same time and I quickly came to the conclusion that the pursuit of getting traction needed much more structure more akin to product development. I also got increasingly busy with DuckDuckGo, and so it took finding a co-author and many years to actually get this book across the finish line.

Here's my post from a few days ago summarizing the book: [http://www.gabrielweinberg.com/blog/2014/07/pre-order- tracti...](http://www.gabrielweinberg.com/blog/2014/07/pre-order-traction- book.html)

Happy to take any questions.

<comment><USER3> Hey Gabriel! Wodner if you plan selling a DRM-free book? That'd i believe be expected and really appreciated.

<comment><USER2> Yes, the Kindle version will be non-DRM.

<comment><USER4> ETA for kindle version ?

<comment><USER2> They don't let you set them up for pre-orders if you aren't a major publisher, so 8/12.

<comment><USER4> that is August 12'th I assume, same day as print version is out .... "what, December" were my first thought :-)

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> I got a sneak peak at "Traction" and I can tell you its an absolute must. The Bullseye Framework Gabriel and Justin layout has been the greatest tool in my catalog over the past year. Whether you are a seasoned entrepreneur or just getting started, Gabriel and Justin offer a framework that creates efficiency, clarity, and focus. With startups as crazy as they are, I strongly encourage you to take the time to make your life a little easier :).

</comment><comment><USER5> Hi, filled the form. How long does it take to receive the first 3 chapters in my inbox?

</comment><comment><USER6> Very much looking forward to this book. I needed it a year back.</comment>


Google Pulls Fortnite from Play Store - <AUTHOR> https://www.macrumors.com/2020/08/13/google-pulls-fortnight/ <comment><USER2> I kind of agree with both sides here. Not sure what the happy medium would be other than state regulation</comment>


The Next Mainstream Programming Language: A Game Developer's Perspective - <AUTHOR> http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

<comment><USER2> This is from 2005, love this line: "2009 developers will face cpus with 20+ cores".

btw. where is my jetpack goddamnit...</comment>


Regular expressions: Rust vs. F# vs. Scala vs. D - <AUTHOR> http://vaskir.blogspot.com/2015/09/regular-expressions-rust-vs-f.html <comment><USER2> Regarding performance Rust is the loser in this comparison. The regex crate documentation addresses this issue and says this is because of a lack of optimization. Generally I really like the fresh approach that Rust takes on the regex topic. I can't explain it better than the docs:

       This crate provides a native implementation of regular expressions
       that is heavily based on RE2 both in syntax and in implementation.
       Notably, backreferences and arbitrary lookahead/lookbehind assertions
       are not provided. In return, regular expression searching provided by
       this package has excellent worst-case performance.

       [...]

       Rust's compile-time meta-programming facilities provide a way to write
       a regex! macro which compiles regular expressions when your program
       compiles. Said differently, if you only use regex! to build regular
       expressions in your program, then your program cannot compile with
       an invalid regular expression. Moreover, the regex! macro compiles the
       given expression to native Rust code, which ideally makes it faster.
       Unfortunately (or fortunately), the dynamic implementation has had a
       lot more optimization work put into it currently, so it is faster than
       the regex! macro in most cases.

[http://doc.rust-lang.org/regex/regex/index.html](http://doc.rust- lang.org/regex/regex/index.html)

<comment><USER3> The regex crate actually has quite a bit of optimization, which is why it's #1 on the benchmark game. In the OP, it looks like Rust is holding its own to me.

Just because Rust's regexes use automata doesn't mean they have to be slow. :-) It can be tricky to make them fast, but RE2 proves that it is possible!

</comment></comment><comment><USER4> Would be nice to have JS' speed (V8)! Last time I checked they compile the regex into some really clever heuristics. I wouldn't be surprised if the speed is on par or faster than what's here.

[http://blog.chromium.org/2009/02/irregexp-google-chromes- new...](http://blog.chromium.org/2009/02/irregexp-google-chromes-new- regexp.html?m=1)</comment>


"Google Qualified" Developer Directory - <AUTHOR> http://code.google.com/qualify/directory.html

<comment><USER2> > "Qualified Developers are thoroughly vetted by Google ... and meet rigorous > qualification standards."

Followed three lines later by...

> "Google does not make any representation, endorsement or warranty regarding > the services of these developers."

These statements seem at odds with each other.

<comment><USER3> PR vs. CYA

<comment><USER2> Sure, and I'm clearly not a lawyer, but it seems difficult to say that you don't make any representations about them when you did exactly that 3 lines earlier. For example:

"This car is the best deal on the lot!" "I have made no representation as to the value of this car."

</comment></comment></comment><comment><USER4> Note that it's only for their specific API's, ie: KML, Maps API, Gadget Ads, AJAX Search API.

</comment><comment><USER5> You are graded on your paid work done, community participation, references from clients, and a qualification exam. If you get enough points, you get listed in the directory.

</comment><comment><USER6> This is interesting if it doesn't get culled by spammers.

Somewhere in Manhattan, Joel Spolsky feels a shiver running down his spine. Best of luck to both of them, though.

<comment> brown9-2 They only seem to be including people "qualified" in one or more of the various Google APIs.

<comment><USER7> Yea, I think 'Google Qualified' is misleading. "People that have shown compitence in our APIs" is entirely different than "People who are qualified to work for us", which I at least took the name to mean until visiting the link.

</comment></comment></comment><comment><USER8> Aren't Google's API's pretty straightforward? That's one of the reasons they're popular. It seems to me that the average competent IT shop who would even know about this directory would also have developers capable of quickly utilizing Google's APIs.

</comment><comment><USER9> Love the googly eyes in the default image. Way to make an attractive webpage guys.

</comment><comment><USER10> Looks fishy to me. I think someone has made a project called 'qualify' and hosted it on code.google.com; google will squash it when they notice.

</comment><comment><USER11> "The developers listed below are not Google employees." So they are really good, but not good enough to hire?

<comment><USER12> You're assuming that anyone Google is willing to hire will want to work there. That may not be the case at all.

</comment></comment><comment><USER13> One step closer to MCSE and CCNA, I suppose. Just another sign Google is a giant company now.</comment>


Facebook is down - <AUTHOR> http://facebook.com

<comment><USER2> I look forward to the write up on this one. Hopefully not a really bad first day for someone.

</comment><comment><USER3> Is it the first time?</comment>


Locked doors, headaches, and intellectual need - <AUTHOR> https://mkremins.github.io/blog/doors-headaches-intellectual-need/ <comment><AUTHOR> First motivating example:

"Here's the pattern. A new player jumps into your game and starts bouncing around your carefully crafted tutorial level. The level funnels them to the key, which they collect, and then on to the corresponding locked door, which they successfully open. Then, somewhere down the road, they encounter a second locked door… and are completely stumped. They've solved this problem once before – why are they having such a hard time solving it again?"

The second and third one are from math education and functional programming.</comment>


Archaeologists chase melting ice in Yellowstone to collect artifacts - <AUTHOR> http://www.wyofile.com/column/archaeologists-chase-melting-ice-in-yellowstone-to-collect-artifacts/ <comment><USER2> So don't they get grief from other players for camping the spawn points? :-)

More seriously though I see the evidence that humans have lived through large variations in climate throughout their existence and it makes me want to build a domed city. If you started right now how much could you build? How independent could you make it? How many replacement parts? A lot of dystopic scenarios have people scrambling to survive with systems where the underlying support structure has been destroyed, how difficult would it be to build a self supporting community while the systems are working as designed? A decade? A century?

The folks who build houses into the ground in New Mexico call them "Earth Ships", of course the dome project was ridiculed, but rather than take the position of exchanging no air with the rest of the world, how close could you get to self sufficiency?

</comment><comment><USER3> Ends with the usual admonition: don't collect or move artifacts if you find them in a National Park. Note their location and report.

Yet the theme of the article is, that artifacts are disappearing daily, there are not enough professionals to manage them all, and irreplaceable history is lost daily. So the admonition seems pointless; even counterproductive!

<comment><USER4> More history is lost to private display cases than to natural causes. Leaving artifacts and reporting their location is certainly not counterproductive.

<comment><USER3> Read the article? Its not true in this case. The artifacts are wood, grass, maybe cloth and melting ice rots them away in a season. It would be no different here, if you were to take the item, and report its location as well. Then at least the artifact still exists somewhere.

<comment><USER4> There's an order of magnitude more value for archaeology in an artifact's context than in the artifact itself. A 5000 y/o piece of wood is just a piece of wood once it's been taken out of it's context.

<comment><USER3> And what is it worth, once its rotted away and gone? What if you are the last person available to save that artifact? Should you let it rot, because Authority says to?

Rather than scold folks for saving artifacts, rather teach them how to preserve some context - pictures, date, GPS location. Something. Else its _all_ gone.

<comment><USER4> I agree with you in principal, but we're talking about a national park with 3M+ visitors a year. The public position has to be to leave artifacts where they are found.</comment></comment></comment></comment></comment></comment>


Apple could adopt ARM for laptops, but why would it? - <AUTHOR> http://arstechnica.com/apple/news/2011/05/apple-could-adopt-arm-for-laptops-but-why-would-it.ars

<comment><USER2> This is surprising considering the good relationship between Apple and Intel.

A couple of recent examples are Thunderbolt and the unreleased Z68 chipset that is in the newest iMacs.

I really doubt this will happen anywhere in the near future simply because ARM chips don't have good performance compared to x86 chips. Most people would be unwilling to accept a performance downgrade.

I could see the MacBook Air line and other consumer products going in that direction, but certainly not the MacBook Pros or the Mac Pro desktop for that matter. These products are targeted towards serious professionals who need performance. The notion of ARM chips in a workstation computer is laughable for the near future.

There's pretty much zero chance ARM will ever reach performance parity with x86. Not to mention Intel's near two year process technology lead over everyone else.

The only scenario I see something like this happening is far in the future, when everything transitions towards the cloud and thin clients. But for now, we need real computers with real performance.

<comment><USER3> _ARM chips don't have good performance compared to x86 chips. Most people would be unwilling to accept a performance downgrade_

I'm not so sure about that.

Excluding gamers and power users, I'd say that in the last 5-10 years, most people haven't even had a clue about how the performance of their personal computer will compare. Everything's just "fast enough" for most people.

Performance increases, if any, are more likely to be attributed to Windows reinstallations or the fresh setup in a new computer rather than the CPU power. Installing more memory and better hard drives have more to do with the snappiness of a personal computer than the CPU.

In fact, heck, I'm a programmer and the last time I think I cared about the processor speed was in the turn of the 2000's. I do notice CPU performance when compiling big codebases but compared to hours of turnaround time in the 90's any messages from the compilation units have generally just been swooshing by at an unprecedented pace during the last decade.

I would notice an ARM CPU on my main development laptop but I could probably live with that easily, especially given the better battery life and decreased heat production of an ARM chip.

Anyone else from office workers to my parents probably would never guess if it's ARM or x86, even if the former was 1GHz and the latter was 3GHz.

</comment></comment><comment><USER4> The most logical thing for Apple to do if they were to decide to switch to ARM would be to use it in the MacBook air only. People buy iPads and MacBook Airs to play with. People generally buy MacBook Pros, iMacs, and MacPros for work(I did.) The fact is that ARM chips are not cut out to handle the demands of professional users and won't be for the foreseeable future. Especially now that Intel has announced tri-gate. Finally, why would Apple switch when they are placing a major bet on Thunderbolt? It seems unlikely or more accurately unwise for them to switch to AMD without a tremendously compelling reason. And no, A15 isn't enough.

</comment><comment><USER5> Still waiting. <http://news.ycombinator.com/item?id=2258693>

</comment><comment><USER6> Depending whose estimates you believe an A5 costs Apple about $14 and a ULV i5 will cost them about $225. One could imagine that a $30 part in a couple generations would be fast enough for a consumer notebook that didn't need x86 virtualization. $200 savings on cost = $286 off retail if they want gross margins at 30%.

</comment><comment><USER7> This rumor was first addressed here:

<http://news.ycombinator.com/item?id=2519858>

</comment><comment><USER8> Just a few days ago I was reading about how Intel might start making ARM chips. 2 + 2 = ...?

Biggest reason the Apple-ARM rumor is not entirely infeasible to me is Apple has never been performance-first, and I could see them taking a performance hit for aesthetic or form gains.

<comment><USER7> one of the biggest reasons Apple would switch to ARM for laptop-like products is to reduce their dependence on Intel's effective monopoly!

<comment><USER8> Well, they could certainly switch _using_ intel ARM chips. Eases the transition (maybe?) and once everything is on ARM they can switch to another manufacturer anytime.

</comment></comment></comment><comment><USER9> OSX and iOS are merging. Think touch screen macbook air.

<comment><USER10> iPad?

<comment><USER9> No. Think about it. For example, even if you could make an iOS app on an iPad you wouldn't want to. There are legitimate reasons for wanting a keyboard and trackpad. iOS is the future of Apple and they want all those iOS apps to be available on all mac computers too, so they're going to continue to move that iOS to all their machines, including ones with keyboards and trackpads.

</comment></comment></comment><comment><USER11> An answer to a question that no one asked.

<comment><USER12> Did you even read _the first sentence of the article?_ It links to the recent discussion about Apple moving to ARM hardware: [http://semiaccurate.com/2011/05/05/apple-dumps-intel-from- la...](http://semiaccurate.com/2011/05/05/apple-dumps-intel-from-laptop- lines/)

<comment><USER11> I did. It's a discussion that no reasonable person would take seriously. Where is the rationale for moving Mac to ARM? It's nowhere.

<comment><USER13> Because the underpowered macbook air has demonstrated that "Good enough" performance can be greatly outweighed by ultra portable, power efficient devices.

Cutting costs, increasing power efficiency, and decreasing physical size are all good ideas in my book.

It's a new world out there. People are finally expecting software to run faster while requiring less. Each version of Android has noticeable speedups on identical hardware. Snow Leopard freed up 6GB of storage when upgrading from Leopard. Inefficient software no longer buoys hardware sales. For ultra portable devices, in which category I would put many laptop lines, power and size are all that really matter. Granted, netbooks suck, but a device that's "good enough" speed-wise is fine for such requirements.

</comment></comment></comment></comment><comment><USER14> Because Apple has always sold computers as lifestyle appliances, instead of complex work machines like the PC industry. Apple's target markst doesn't open up their box and upgrade their computer. They dont care about customisation and plugins because they dont upgrade their toaster or microwave--they use it as is. Going ARM on their laptop plus making MacOS more like iOS is all part of this grand vision.

<comment><USER15> Now, this vision of turning computers into toasters is exactly the reason why I think Apple is evil.

<comment><USER14> Apple's vision of turning computers into toasters is _exactly_ the reason why I switched _to_ a Mac. I'm too old to deal with maintaining a PC. Just give me a box and let me do my work. For most of the objects that I interact with on a daily basis, I don't care how it works or whether I can "hack" or upgrade it. I just care that it works and gets out of my way when I don't need it any more.

The only notable exception that I can think of right now is a car. But as for computers, that's very much an appliance in my eyes, despite being a developer and coding on Linux and Windows all day at work.</comment></comment></comment>


How are you using Huggin? - <AUTHOR> I have been researching Huggin and love the idea of implementing this to increase productivity. Curious to know how you use are making use of it? If you're not aware of Huggin it's on github https://github.com/huginn/huginn <comment><USER2> You might get more responses if you gave a little description.

And also spelled it correctly :-)

</comment><comment><USER3> I run a dockerized Huginn instance that sends me daily morning/evening digest emails with various bits of info & stats that it collects together. For example

\- Daily/Weekly/monthly/Yearly changes in a few investment funds

\- The closing stock market rate for a couple of companies

\- The daily/weekly/monthly/yearly change in stock market rates for those companies

\- Any reported inflation changes in my country of residence

\- The daily/weekly/monthly/yearly changes in foreign currency exchange rates

\- The forecasted weather for the day

I also have some of these checks running every 10 minutes, and if there are changes that exceed a certain threshold then a sms is sent notifying me.

<comment><USER4> have you OSS'd that? is literally the same requirements I've got.

<comment><USER3> I based my docker configuration on this setup from BytemarkHosting (but then did my own changes over time). I would recommend checking that out. [https://github.com/BytemarkHosting/configs-huginn- docker](https://github.com/BytemarkHosting/configs-huginn-docker)

My agents are very specific to my locale, so I haven't thought about sharing them. Might do that at some point.

<comment><USER5> Bytemark! What a surprise to see a reference here.

</comment></comment></comment></comment><comment><USER6> Couple of things:

* Crawl apartment listings and get notified a lot faster than the official notification channels take.

* Monitor the inventory/promotions of some vendors, e.g. for bikes, that are currently out of stock

* Get notified when there's an peak of interest in a specific topic on twitter. I use this to monitor my employer, my project, and any stocks I own.

</comment><comment><USER7> I heard about this for the first time. Will check it out. Otherwise all my work is done through cron jobs and bash scripts.

</comment><comment><USER8> I use it as a core part of my self-hosted infrastructure, as an alternative to IFTTT or Zapier.

I do simple things with it, like monitor GitHub for releases of software I use, filter out release candidates and post the info to a Mattermost server. This helps me stay current With projects where I maintain a public Docker image for them.

Huginn also does more complex things like act as the engine for an app running as a series of functions in OpenFaaS. That app pulls data from various sources, aggregates it, dedupes it according to various criteria, does a bunch of subsequent lookups, stores results in Mongo and then collects the output once a day and sends it as an email.

Huginn is an excellent tool.

</comment><comment><USER9> Not much use for huggin' right now, due to the epidemiological situation.

<comment><USER10> If corona virus, then no hugs

</comment></comment><comment><USER11> Curious if I can set this up to chart my biometric data as well

</comment><comment><USER12> also checkout [https://n8n.io/](https://n8n.io/)

</comment><comment><USER13> How does Huggin compare to Node Red?

<comment><USER14> Node Red might focus more on IoT.</comment></comment>


In Hopes of Attracting Foreign Audiences, Broadway Tries a Translation App - <AUTHOR> https://www.wsj.com/articles/in-hopes-of-attracting-foreign-audiences-broadway-tries-a-translation-app-1528153858 <comment><USER2> I was recently in Prague and got to see Lohengrin -- while they had both a Czech and English translation from low deutsch? -- I almost feel like the translation removed me from what is one of the most classic operas.

I'm not sure if translations are the best way to go about attracting foreign audience. There isn't a solution that I can provide, and my situation is truly anecdotal.

<comment><USER3> Yes, those overtitles can be distracting as hell.

I like the solution the Komische Oper Berlin uses. Individual displays for every seat, switchable between German, English, French and Turkish (and off):

[https://www.tagesspiegel.de/kultur/uebersetzerstuehle- multif...](https://www.tagesspiegel.de/kultur/uebersetzerstuehle- multifunktionssitze-in-der-komischen-oper/1595910.html)

<comment><USER2> I've never had the chance to visit that Opera house, but it does look gorgeous, and the solution makes more sense.

</comment></comment></comment><comment><USER4> Ah, nothing like having a sea of bright phones in the audience to heighten the drama of a drama, or the escapism of a musical.

</comment><comment><USER5> I have always thought an augmented reality headset would be the best interface for something like this. It would help eliminate the need to switch focus and be less disruptive to others. I guess it's just not affordable enough yet.</comment>


The Chokehold of Calendars - <AUTHOR> https://medium.com/p/f70bb9221b36 <comment><USER2> You are quite right on most of the points. But hopefully not "all calendars suck". You seem to refer calendars that are made for appointments, personal calendars shared for others to read and write more appointments on as corporate practice dictates. That is not the case with Teamup Calendar ([http://www.teamup.com](http://www.teamup.com)). Teamup is a shared calendar app, starting with no personal account attached to it. Writing on a shared Teamup calendar is not "subtracting an hour" from anyone's life, but can well be setting a goal for the group, or just inform the group (or public if it is on a public website) what's going on, which helps group transparency. If two out of the ten events on a shared Teamup calendar impact your personal goals, export the two but not all ten to your own calendar.

The goal-oriented calendar model is very interesting. Outside of the appointment context, calendar apps with color-coded multiple sub-calendars, easy drag-drop functions, and multiple viewing options may serve the needs well. Why not using the calendar grids just like table cells with given date structure?</comment>


Writing Python Extensions in Rust Using PyO3 - <AUTHOR> https://www.benfrederickson.com/writing-python-extensions-in-rust-using-pyo3/ <comment><AUTHOR> Quotes:

 __To expose this code from Rust to Python, there are a couple of different approaches you could take. The simplest approach is to expose a C ABI from your Rust program. __

 __The big problem with this approach is that this limits us to a C ABI. Both Rust and Python are safe languages and requiring going to a lower level C library interface adds a lot of extra complexity and potential for errors. __

 __The PyO3 project aims to let you have full access to Python programs from Rust. This includes both embedding Python in Rust programs and creating Rust extensions that can be called from Python. __</comment>


Helping to establish prior art - <AUTHOR>

With regard to helping the community establish prior art on patents.  I think one "cog in the wheel" that probably should be in place is a queue-like system that would shuffle patent applications (as they become available on the USPTO website) to relevant newsgroups / user groups / mailing lists.<p>Thoughts? <comment><USER2> You may be interested in Ask Patents ([http://patents.stackexchange.com/](http://patents.stackexchange.com/)). It was created by the team of StackOverflow.</comment>


PlanOut: A language and interpreter - <AUTHOR> https://facebook.github.io/planout/blog/planout-language.html

<comment><USER2> Interesting. I'm working on an "Expfile" project right now, which is tangentially related to this area of exploration. The idea is that published experiments should be reproducible, and therefore can be described in a declarative format. I'm calling Expfile the "Procfile for experiments" \-- it's a file you upload in the top level of your research's code repository, describing in declarative terms which variables to measure, how to measure them, and how to get results. If anyone wants to talk to me about this I'm doing a lot of work on it this week.

</comment><comment><USER3> Wasn't there recently something on HN about a programming language for science experiments? Anyone know what it was called again? It'd be interesting to compare the two languages.

<comment><USER4> I just spent some time re-finding that post a few days ago at an Ethereum meetup! :)

[http://www.antha-lang.org/](http://www.antha-lang.org/)

<comment><USER3> Yeah! Antha was what I was thinking about. Thanks for looking it up!</comment></comment></comment>


Ask HN: Best books you read in 2015? - <AUTHOR> What are some of the best books that you read in 2015? <comment><USER2> Million Dollar Consulting by Alan Weiss

Essentialism by Greg McKeown</comment>


Scientific Clues That We Are Living in the Matrix - <AUTHOR> https://www.youtube.com/watch?v=fV07SJz1YXI&list=WL&index=6 <comment><USER2> The use of numeric coincidences like the cotient of the Moon and Earth radius in [http://www.youtube.com/watch?v=fV07SJz1YXI&t=14m55s](http://www.youtube.com/watch?v=fV07SJz1YXI&t=14m55s) is a very big red flag.</comment>


LiveJournal Founder Brad Fitzpatrick "actually, little-known fact: I don't work on LJ, and haven't in a while" - <AUTHOR> http://brad.livejournal.com/2324293.html <comment><AUTHOR> SixApart bought LiveJournal over a year ago and it looks like the honeymoon period is over. SixApart also added additional advertising that Brad objected to. Now they're causing a "user revolt".</comment>


Announcing The jQuery Standards Team - <AUTHOR> http://blog.jquery.com/2011/10/24/announcing-the-jquery-standards-team/

<comment><USER2> My first thought about a jQuery standards team was that they would rate plugins on "adheres to jQuery interface standard". Too many times I grab some contributor's plugin for adding behavior to primitives, only to find out that they taint the namespace unnecessarily or depart from jQuery's query-and- return model and require invasive workarounds to conform. jQuery is really flexible; many "plugins" are not.

</comment><comment><USER3> One of the most intriguing parts of this endeavor is utilizing GitHub's issue tracker - <https://github.com/jquery/standards/issues> \- to openly discuss and debate topics that the standards group should be lobbying.

<comment><USER4> Here's another interesting use of the issue tracker by Paul Irish (of the jQuery Standards Team): <https://github.com/paulirish/lazyweb-requests/issues>

<comment><USER5> Thank you so very much for this. I'm a fan of all things Paul Irish and now I'm making my way through the list in great detail.

</comment></comment></comment><comment><USER6> I think browser DOM should just embed a native implementation of jQuery.

<comment><USER7> Then you'd be stuck supporting old versions of jQuery.

Why not have it the other way around? Have the webpage define the DOM implementation. Taken to its extremes, that would basically solve backward- compatibility.

<comment><USER6> > Then you'd be stuck supporting old versions of jQuery.

No, support only core functions of jQuery. All of them.

You know what is old version? Stuff like getElementById() .

</comment></comment></comment><comment><AUTHOR> This is interesting. jQuery started as a way to smooth over the variations delivered by different browser implementations. So by it's nature it's goal is delivering a better experience for developers using JS.

The tension i see is that browser implementations by their very nature are a deviation and departure from the standard. jQuery is a repair process on someone else's broken shit. So, jQuery has lots of anti-patterns for how things _shouldn't_ be done, and some of the workarounds that are actively in deployment.

It'll be interesting to see whether this injects a voice for sanity and practicality into the discussion process, or whether this will just make conversations about standards more vociferous.

</comment><comment><USER8> This is great, developers could use a voice at the W3C. Wait, how did they do that awesome effect with the screenshot that's slanted and angled like that? Is that a special filter, or did they do that in Photoshop?

<comment><USER9> Right click. View Image.

<comment><USER8> I know, I saw. My question is, how did they do that?

</comment></comment></comment><comment><USER10> Only 2 people in this standards team?

<comment><USER11> A small but significant increase from zero people.</comment></comment>


Chrome 13  - <AUTHOR> http://googlesystem.blogspot.com/2011/08/chrome-13.html

<comment><USER2> Finally, the Omnibox gets some love with partial URL/title matching. I switched from Firefox to Chrome for a while, and the Omnibox was my number one gripe: the URL matching was frustratingly poor, and it seemed to have no concept of sorting by recency or most visited. By comparison, the sort order in Firefox's AwesomeBar is so well-thought out that most of the time I can find the site I want in only a couple of keystrokes - yesterday, I needed to pull up a URL I'd used the day before, but all that came to mind was that it contained a '|' character... when I typed in '|', it appeared.

Maybe it's time for me to give Chrome another go, but it's got a high bar to beat.

</comment><comment><USER3> There is also introduced css3 bugs on chrome 12 lion (corrected in v13), backface-visibility stopped working, and this was working on snow leopard (v12)

<comment><USER4> The only problems I've had with Chrome 12 were random pages crashing (especially on, coincidentally, google.com).

This was on Chrome 12 on OSX 10.7 I'll have to see how 13 behaves.

<comment><USER5> The same problem exists in 14 on Lion

</comment></comment></comment><comment><USER6> 13 is a really high version number. One thing I love about chrome is how silent the updates are. Other browsers tend to nag you about downloading the latest version, running an installer, etc..

Chrome updates much more silently + in the background, which is one of the many reasons it's my favorite browser.

</comment><comment><USER7> I love Chrome, but it's almost unusable on Lion for me at the moment. Full screen support isn't very good, it doesn't work with desktop/spaces and it's felt more unreliable than in the past (though that's anecdotal).

<comment><USER8> How is it unusable for you? I'm on Lion too, and I find Chrome to behave pretty much the same as it did on Snow Leopard.

Edit: typo.

<comment><USER9> I get that dark blue "Aw, Snap" page quite a bit since upgrading to Lion.

</comment></comment></comment><comment><USER10> I see prefetching of doom again. I hope they have thought about the obvious problem this can cause when the browser spiders all the links on the page:

People using the GET verb for deletions. Bad practice but common as dirt.

Ouch!

<comment><USER11> The article suggests that the page author has to explicitly request prerendering of a link with a "rel" attribute, possibly to avoid this problem.

<comment><USER12> That makes sense, but it raised a question on my mind: What about malicious sites? Could this be used to do something without the user knowing?

One could mark a link as prefetch and that URL would be downloaded without prompting the user. Does that impose a genuine threat, or is that something that malicious sites can already do?

<comment><USER13> This can already be done by using a script or img tag load an arbitrary URL.</comment></comment></comment></comment>


Measuring Hurricane Arthur with smartphone sensors - <AUTHOR> http://pressurenet.io/blog/hurricane-arthur/?hn

<comment><USER2> Unfortunately there isn't much substance in the article. But it does at least showcase an interesting application of crowd-sourced data. It would have been interesting if they had tried to demonstrate how this data enables some analysis which the "official" weather stations aren't capable of. Maybe something like a better spatial–temporal sampling of the hurricane's pressure depression?

<comment><AUTHOR> Yes, I agree. This is a very simple and early-stage view on the data and its utility - maybe treat this as a minimum viable graph ;). We're actively experimenting with weather models and density plots to discover the biggest strengths of the data. You'll see more in-depth analyses later on!</comment></comment>


Ask HN: Developers - what is your Company type? Development process/stages? - <AUTHOR> <comment><USER2> Que?</comment>


Go Date Format - <AUTHOR> http://fuckinggodateformat.com/ <comment><USER2> While I got also shocked at first by Go's time formatting, is by far the easiest to learn and memorize once you get it.

The argument from the issue [https://github.com/golang/go/issues/444](https://github.com/golang/go/issues/444)

> It would be much easier to port preexisting code if you could just copy your > time formats over.

It's not really much of an argument, since transforming the sprintf format to Go is a trivial as printing an specific date.

<comment><USER3> > While I got also shocked at first by Go's time formatting, is by far the > easiest to learn and memorize once you get it.

I completely agree. I've used strftime and the like for _years_ , and I still can't remember %m vs %M without thinking twice about it, at which point I usually just look at the docs to make sure I'm not making a mistake.

By contrast, as soon as I learned the "trick"[0] behind the canonical date in Go, I had it committed to memory, and I haven't needed to look it up once since.

YMMV, but personally, I'd much rather write "Jan" when I want a three- character month and "January" when I want a full month than try to remember that the former is %a and the latter is %A (...or is it the other way around? Time to check... again!)

[0] [http://golang.org/pkg/time/#pkg- constants](http://golang.org/pkg/time/#pkg-constants)

<comment><USER4> > By contrast, as soon as I learned the "trick" > [http://golang.org/pkg/time/#pkg-constants](http://golang.org/pkg/time/#pkg- > constants)

 _Since MST is GMT-0700, the reference time can be thought of as 01 /02 03:04:05PM '06 -0700_

Such sadness. Using a reversed month/year date as a "reference" when we have ISO 8601. Much american-centrism.

Otherwise I like the trick, but I'm not sure it scales to locale-specific time formats (whereas strftime does a bit with %aAbBxX).

<comment><USER5> The line _right above_ that one is the first cited reference format:

        Mon Jan 2 15:04:05 MST 2006

<comment><USER4> I know, I'm talking about the mnemonic used to remember this date.

</comment></comment></comment></comment></comment><comment><USER6> Personally, when I first read the spec. for time.Format, I thought "well how bleedin' sensible is that?!" The _only_ thing that annoys me is that it isn't in ISO order (I'd have preferred 2001-02-03 14:05:06 ), but all that you need to remember is "2006-01" and the rest just falls naturally into place. I've seen a couple of "complaints" about this over the last few days, and I just don't understand what the problem is. It's logical and neat.

<comment><USER7> ISO ordering would make expressing time in AM/PM ambiguous, i.e. the format string "2:05PM".

<comment><USER8> 12:34:56 2007-08-09 would work equally, though. (EDIT: oops, no.)

<comment><USER7> How do I cleanly express single digit minutes?

The format string "4 minutes after 12", is unique, but it's not clear that I could turn "34" into "4". Similar for the hour (12 is now 2).

That would also break the "Print this exact time in the format you're currently using" method of creating a compatible time format string.

</comment></comment></comment></comment><comment><USER9> It's unfortunate that languages are so monolithic. You want to make a language that does concurrency differently and you end up having to design date format strings! Sad that we still don't have any kind of common libraries or whatever it might take to just do this a couple of times and let language designers pick and choose the preexisting components they want.

<comment><USER10> "Sad that we still don't have any kind of common libraries or whatever"

We do have those. In this case the common library is called "libc." In this case (and in a few others) the Go team decided to intentionally avoid providing an interface to this function.

The good news is it would take just a few minutes to add support for go to call strftime directly from libc.

</comment></comment><comment><USER11> I, for one, deeply appreciate any project which isn't afraid to do things differently when they decide there's a better way. I see it similar to iOS not supporting Flash, or Angular 2.0 rethinking things.

You can't change everything, but it's what you do differently that gives your project value.

<comment><USER12> Sure, but date formatting? That's where Go is going to differentiate itself? Even though it still uses a C-like format string? This seems like exactly the kind of area where leveraging the existing conventions would be a no-brainer.

<comment><USER13> It isn't the format string syntax that is the problem that they're trying to solve. I see this as being an iterative, backwards-incompatible improvement on the existing format convention. Changes in convention don't have to be all or nothing.

</comment></comment></comment><comment><USER14> I personally love the way it works. This is actually one of my arguments in favor of the golang standard library which is, in my opinion, a great piece of software by itself.

</comment><comment><USER15> The Go date format is one my huge annoyances about the language (not generics, interface{} magic, or the lack of immutable types). My biggest issue is that despite the fact the designers call Strftime bad because no one remembers the letters, and has to have documentation handy - the Go docs don't even document the magic numbers you have to use.

Why 2006? How do I represent a day? When do I use _2 vs 2? Its very poorly documented and thankfully all I use is RFC3339 and Unix timestamps.

<comment><USER16> If you ask "Why 2006?" then you missed the point.

        Mon Jan 2 15:04:05 -0700 MST 2006
        0   1   2  3  4  5              6

How to represent a day? "2". Want a leading zero? "02".

<comment><USER15> Again, where in the documentation is this listed? Why is the timezone 7 even though its before the year? Did you just make this up? It seems to me that this might just be a happy coincidence in the way you ordered the date.

<comment><USER17> Here, directly below the actual listing of the constants: [http://golang.org/pkg/time/#pkg-constants](http://golang.org/pkg/time/#pkg- constants)

But I would also observe I missed this documentation myself a couple of times, and I think it probably should have gone on the package documentation, so while I'm linking you to this, I'm not necessarily disagreeing that it's misplaced a bit.

</comment></comment></comment></comment><comment><USER18> Strangely the non-profanity version [http://flippinggodateformat.com](http://flippinggodateformat.com) still has profanity.

<comment><USER19> Ha my bad. Fixed :)

<comment><USER20> It still has profanity, in the form of a link to [http://fuckinggodateformat.com/](http://fuckinggodateformat.com/) :)

Personally I see no problem with this being a WONTFIX. I wouldn't even have built the flipping thing in the first place. (I might have built the fucking thing, though.)

</comment></comment></comment><comment><USER21> I generally agree with Cox but "no one remembers all the letters, so the only way to use it is with documentation in hand."

Huh?

Who can remember the numbers? The only way to use this format is with the documentation.

It is an easier to read and verify format. However if you think a casual user will remember that "02" is hour and "03" is... wait, is 02 hour? Let me check the documentation.

<comment><USER19> While it seems random, it is simply:

1 2 3 4 5 6 => January, 2, 03:04:05pm, 2006

<comment><USER22> It's 1,2,3,4,5,6 in the default format of the posix 'date' command.

</comment></comment></comment><comment><USER23> First: neat, funny ("I can now write Go date format strings...you win this time"), and I follow the "sprintf may be awful but at least I know it" argument.

While there's a lot to say for sticking to your language's idioms even when it's a pain, if you _really_ need/want strftime there are third-party libraries:

[https://github.com/search?l=Go&q=strftime](https://github.com/search?l=Go&q=strftime)

</comment><comment><USER24> > Because I've used sprintf a million times before

Did you mean strftime?

<comment><USER25> That's different too, of course. Everything is %v. Just use %v.

</comment></comment><comment><USER26> People who say "he could just use sprintf" are missing the point: this lets you use sprintf _while writing idiomatic Go_.

If I see a Go programmer import a sprintf library just because he doesn't want to conform to the programming environment, that's going to ruffle some feathers during code review.

But if he uses this, well, I'd be none the wiser.

Readability counts.

<comment><USER27> > Readability counts.

Oh yeah: `01200602150405`

<comment><USER26> Look, I'm not trying to make an argument for how good or bad Go's string formatting is. Tbh I forget both and I find myself back in the documentation either way.

But in this case, you're programming Go already. Better stick with the tools that everyone knows and expects. In .go files, Go code is more readable. In .py, it's not.

People who read your Go code will know Go, and they will be in "Go mode". To them a Go-style date formatting string will make more sense than a sprintf one.

</comment></comment></comment><comment><USER28> I just recently had this problem while working with Hugo, a Go static site generator.

Suffice to say, it was not intuitive at all. I had to look at the support forums to learn about this Go eccentricity.

I can't say that I hate it. I could probably get used to it.

</comment><comment> guard-of-terra I was wondering why they didn't borrow java SimpleDateFormat

But then I noticed they decided to tackle the dd-MM-yyyyTHH:mm:ss problem AKA crazy case. Which is kind of noble.

</comment><comment><USER29> I understand there may be legacy issues from other languages, but in a new language... why on earth would you not take the time to make %p the lower case am/pm and %P - AM/PM?

</comment><comment><USER30> TIL that the hardest thing to do in computer science is to learn something new and different.

<comment><USER19> I think the real lesson here is developers have a warped sense of time and would rather spend relatively much more time building a website to solve a problem than it would just to learn it

</comment></comment><comment><USER31> grey on white, lightgrey on white, yellow on white

my oh my, my slightly blurred vision is having fun

</comment><comment><USER32> I'm no designer but that yellow color used on the site is not easy to read.

</comment><comment><USER33> I appreciate the "flipping" version but why such an obnoxiously immature primary domain?

<comment><USER34> I agree with you (and upvoted you). The reasons is simple to express emotion and obviously to get attention.

A little bit of history. I don't remember exactly when in the 90's it changed but at a certain point there were actually certain words banned from being used in domain registrations.

<comment> vhost- >I don't remember exactly when in the 90's it changed but at a certain point there were actually certain words banned from being used in domain registrations.

Isn't that censorship? Maybe that's why it changed...

</comment></comment></comment><comment><USER35> Who the fuck _buys a domain name and sets up a web site_ just because they're frustrated at a date format? I don't get kids today.

<comment><USER36> $8/year, for fun. Why not? Probably took an hour to do.

<comment><USER35> I can do a lot of things in an hour. I could yell out my window for an hour. I could rant on irc for an hour. I could write a blog post about how pissed I am for an hour. I could register a domain name, make a website, host and publish it on news sites, then track the comments of people who comment on it, in an hour.

I'd rather either patch Go or focus on something positive/productive for an hour.

Call me crazy.

</comment></comment></comment><comment><USER37> There are two thing I don't like in IT:

1- Using names for software that is confusing with names of real things that have nothing to do with it, like Cocoa for a user interface library and so many others.

2- Using the terms a two year old will use when she discovers it is funny and gets attention just for saying dirty words.

In this particular case, this combines both in one. The first thing I thought was: This will have something to do with dating and having casual sex or something. Then you discover that no, it has nothing to do with it, it is just a two year old like mindset creating a "funny"(for him) name for their pet project.

<comment><USER38> > _Using the terms a two year old will use when she discovers it is funny and > gets attention just for saying dirty words._

So, preffering what a prude 50 year old from some place with a strong puritan culture would want to see.

<comment><USER37> For me puritan culture is exactly what makes someone believe this is funny when it is not.

A kid does not find funny what it is not "tabu" or "forbidden".

<comment><USER39> "Not funny" doesn't mean "offensive".

Why do you allow mere words to have such control over you?</comment></comment></comment></comment>


Types for Python HTTP APIs - <AUTHOR> https://instagram-engineering.com/types-for-python-http-apis-an-instagram-story-d3c3a207fdb7 <comment><USER2> In our startup we use marshmallow [1] to validate and make REST API type aware. So marshmallow models validates the data types based on validation rules for request/response.

In place where we need client to be able to define the validation the request/response will consist of data, validation json schema. In this case use jsonschema validator [2] [3].

So for every json request/request data, it's passed through a marshmallow model which validates the json. In some cases we use jsonschema validator when we have dynamic json data with schema definition for validations.

For response the function return value pass through a marshmallow model. We are moving towards making all of internal functions/methods with type annotations to generate documentation using Sphinx [4] plugin.

We are not Instagram but are very happy with it and can replace flask library with bottle or other wsgi compatible framework and it will still work.

[1] [https://marshmallow.readthedocs.io/en/stable/](https://marshmallow.readthedocs.io/en/stable/)

[2] [https://python-jsonschema.readthedocs.io/](https://python- jsonschema.readthedocs.io/)

[3] [https://pydantic-docs.helpmanual.io/](https://pydantic- docs.helpmanual.io/)

[4] [https://pypi.org/project/sphinx-autodoc- typehints/#data](https://pypi.org/project/sphinx-autodoc-typehints/#data)

<comment><USER3> Marshmallow is good but it can be slow. We also use it over a Flask API for input/output serialization and in the worse cases it can take a significant amount of time if the objects are large enough (maybe a hundred milliseconds). We also use the Marshmallow models in conjunction with a project called `flask-apispec` by the same authors to generate Swagger docs.

I've wanted to explore using the Typing module to replace Marshmallow since it started making the rounds to see if it results in better performance, but haven't had a chance. I would have liked to see Instagram release a library to go with this blog post so I don't have to do as much legwork.

<comment><USER4> > Toasted Marshmallow implements a JIT for marshmallow that speeds up dumping > objects 10-25X (depending on your schema).

[https://github.com/lyft/toasted-marshmallow](https://github.com/lyft/toasted- marshmallow)

</comment></comment></comment><comment><USER5> Been doing this before the typing module was released, using hug: [http://www.hug.rest/](http://www.hug.rest/)

FastAPI has a lot of advantages at this point for someone looking to do the same: [https://github.com/tiangolo/fastapi](https://github.com/tiangolo/fastapi)

hug has some catching up to do, some of it just because it got in so early (It needs to be updated to be compatible with mypy and the types defined typing.py!) in any case using typing on API endpoints - independent of how you feel about Dynamic vs Static typing in general, just makes a lot of sense IMHO.

<comment><USER6> Thanks for the mention @timothycrosley! I feel honored :)

</comment></comment><comment><USER7> Looks like FastAPI framework with handler type anotations

<comment><USER8> Yeah I feel FastAPI will become the new Flask in a few years. The growth this year has been amazing. I wish I had started my project with it, but I am still using Flask. I found this nice extension though called Flask-Rebar that does a similar task with Marshmallow.

<comment><USER9> _Yeah I feel FastAPI will become the new Flask in a few years._

What else does it offers besides performance (switching to async is no free lunch)?

<comment><USER10> I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me:

\- Integrates nicely with some existing libraries (Starlette, Pydantic)

\- Well documented

\- Auto-validation of endpoints from data models

\- Auto-generation of OpenAPI schemas from those models

\- Auto-serves live API docs from that schema

\- Easy definition of sync and async endpoints

Again, it was just a tiny proof-of-concept prototype, but I'm sold on using it on future projects.

<comment><USER11> > \- Auto-generation of OpenAPI schemas from those models

Is there a package that can do a reverse? Can I give it an OpenAPI spec and get a code stump going?

<comment><USER12> OpenAPI-generator [0], written in Java, can produce Python stumps, but I never liked that approach.

Connexion [1] is built on top on Flask and does routing and validation based on an OpenAPI spec.

I've recently started developing Pyotr [2], which does the same only based on ASGI and Starlette. It also includes a client module.

[0] [https://openapi-generator.tech/](https://openapi-generator.tech/)

[1] [https://connexion.readthedocs.io/](https://connexion.readthedocs.io/)

[2] [https://github.com/berislavlopac/pyotr](https://github.com/berislavlopac/pyotr)

</comment></comment></comment></comment></comment></comment><comment><USER13> Nice writeup - I've been doing this type of thing for 10 years before type annotations by passing the types to the decorator and then using kwargs to supply defaults.

      @annotate(foo=int, bar=str)
      def view_func(foo=0, bar='hi there'):
        ...

The types could also be arbitrary callables to parse things like datetime and what not. I'd parse the params from either the get params or post data (json, urlencoded, etc).

But now I'm using graphene and graphql to handle all this -- it's a better way to do all of it imho. Of course this all came along after instagram, so you didn't have that choice back then.

</comment><comment><USER14> Rather than reimplementing this stuff, and assuming you are using Django, you could just use Django Rest Framework to get OpenAPI, typed serializers, etc.

In that framework your serializers are by default auto-generated from your model classes; this is convenient to get started, just like Django itself.

</comment><comment><USER12> I'm always amazed that, in majority of cases, we use formal specifications -- like OpenAPI -- for documentation instead to guide our implementations. The common pattern is to build an API first, and then extract routing and validation information into an OpenAPI spec, which is then used to set up a test server for clients to develop on top on.

But if you have a relatively clear idea of what your API should look like, there are great benefits to be gained by providing the specification first. This way, you don't need for the API to be implemented to start developing the clients, even by completely unrelated teams. Second, your spec will already include your routing and validation rules, and there is no need to manually specify e.g. Pydantic models.

I recently wrote a PoC of a framework [0] that uses the OpenAPI spec to easily implement a REST(ful) API; in a nutshell, you need to implement endpoint functions that correspond to the spec's `operationId` names, and it will automatically route a request to the right endpoint. It is fully ASGI compliant and as has a bonus client module, which allows you to do the requests.

[0] [https://github.com/berislavlopac/pyotr](https://github.com/berislavlopac/pyotr)

</comment><comment><USER10> I'd love to see some more details on the tooling they created to generate OpenAPI schemas by extracting types from their code.

Related: are there any good Python libs for doing request/response validation based on OpenAPI v3 schemas?

<comment><USER8> I have used Connexion ([https://github.com/zalando/connexion](https://github.com/zalando/connexion)) in the past. The only thing I didn't really like is that the OpenAPI file grows rather unmaintainable after some time if you have a big service.

</comment></comment><comment><USER15> No one is mentioning that Instagram app which doesn't have that many features, and is quite poorly designed, somehow requires over 2000 API calls to function.

I would dare anyone come up with even 100 for the Instagram app.

<comment><USER16> endpoints

</comment></comment><comment> move-on-by I love types and I'm stoked about them coming back into style. For awhile, it was a major trend to avoid static types. I think most people's problem ended up not being with types themselves- but poor type systems. For myself, I am particularly impressed with what TypeScript has done with its types, really amazing how expressive/flexible/and inspective it is. Anyways, just happy with the trend of embracing types and hopes it continues.

</comment><comment><USER17> This is a bit lower level as it's only concerned with serializing, but a package I wrote called json_syntax[1] will take @dataclass or @attr.s classes decorated with type annotations and build encoders and decoders for them.

It also handles Union types reasonably well and lets you put in hooks to handle ugly cases. It's used in production on a system with a big complicated payload, and I designed it to be easily extensible if the standard rules don't work for you.

[1]: [https://pypi.org/project/json-syntax/](https://pypi.org/project/json- syntax/)

</comment><comment><USER18> I've been working on a similar solution for Flask in K Health. Currently we have great serialisation / deserialisation from types to JSON, next step will be creating OpenAPI documents

<comment><USER8> You should check out Flask-Rebar, I am using it a lot in my projects and it's very nice. Does all of this automagically.

</comment></comment><comment><USER19> I've been using type hints with my bottle projects for some time now. Makes it a lot easier to write JSON based apis.

[https://github.com/theSage21/bottle- tools](https://github.com/theSage21/bottle-tools)

</comment><comment><USER20> When I read the headline and saw the source, I assumed this would be about GraphQL. I know Instagram utilizes GraphQL, for example on the web client, so now I'm wondering how that fits in.

</comment><comment><USER21> Flask Swagger already has a way to annotate it quite well.

</comment><comment><USER22> I find it really impressive that such a large organization runs anything on Python. Isn't the speed optimization potential immense? Does the amount of Python involved just not matter compared to image data?

Secondly I find it really impressive that such a large company with so many smart people can produce an application so mediocre and make the experience extra terrible and me wonder what the absolute fuck is up with that company by trying to block desktop browsers from the perfectly useable on desktop web app (the one in which you can upload things).

Especially for a photo centric application (that has since begun to be used for original video production, of course hampered by the insane lack of any options, starting with the aspect ratio) one could expect a normal work flow to include transferring photos from a camera to a desktop computer. Making your browser pretend to be a mobile phone seems like a step that could maybe, if you really tried (to take out the arbitrary restriction that you must have explicitly added in the first place), be made unnecessary.

So that's my (condensed) rant about Instagram as a whole.

<comment><USER23> Who cares if it's 10% slower running on Python if the whole thing is going to be distributed across 1000s of containers that are behind layers of caching. At that point developer productivity is more important than runtime performance.

<comment><USER24> What exactly are those developers doing all day then? Because every time I open an Instagram.com link I'm struck by how bad it is. The images are small, the comment list is the same height as the image, so wide but short images have short comment list, the comments are scrolled to the bottom so the poster's description isn't visible without scrolling up, videos doesn't have any kind of playback controls so you can't even see how long they are, and so on. It's a terrible web site and I don't understand where all the developer time and productivity is going.

And wouldn't a 10% hardware cost decrease be worth a lot at a company with such a high load, or is it all rendered so seldom because of the caching?

<comment><USER25> Really? You're dogging the product because you don't like how it looks on mobile? The article is about how they use python and types to improve their APIs.

</comment></comment></comment></comment><comment><USER26> The whole Type thing in Python and all the workarounds to make Python type- safish looks and feels absolutely pathetic. I have no idea why a company like Facebook takes so much time to apologize for the inadequacy of Python as a programming language in the broader sense. Especially since they are utilizing a service based architecture they easily could make the switch to a language that actually supports types. Also the obvious performance gains...

<comment><USER27> Python does support types though. It's type system is, imo more pleasant and powerful than Javas.

<comment><USER28> Can you elaborate on this? I'd love to actually use types in Python.

<comment><USER10> Python 3 has optional static typing:

[https://docs.python.org/3/library/typing.html](https://docs.python.org/3/library/typing.html)

[https://realpython.com/python-type-checking/](https://realpython.com/python- type-checking/)

<comment><USER29> Static typing is exactly what python doesn't have. It will remain dynamically typed. It has type hints which can be used with external tools to enforce type correctness to some degree, but python code will run even if you assign:

        def f(x: int):
            x = "str"
        f(42)

<comment><USER27> This is true of java and c as well.

You can cast things or subvert the type system and the code will still run.

At least where I work, my build process prevents me from running Python code with invalid type annotations, so it's exactly the same as for Java is cpp or any other statically typed language.

<comment><USER29> In my opinion, the main difference between the two from a developer's perspective is this;

You can't grep for dynamic type errors. You can grep for a cast to see where you've made a mistake and find a way to do it without a cast. This of course goes for the named casts in C++. It is harder to grep for casts in C.

<comment><USER27> Right, but if you run mypy over your code, you're in the same situation as in java. It's a one liner to run mypy before you invoke your tests. You have to cast to subvert the type system.

In c you have void ptr everywhere anyway.</comment></comment></comment></comment></comment></comment></comment></comment>


Rich Skrenta: AppEngine - Web Hypercard, finally - <AUTHOR> http://www.skrenta.com/2008/04/appengine_web_hypercard_finall.html <comment> meat-eater For all its usefulness, where are those wonderful hypercard stacks now? That's right you can't use them anymore or at least not that easily. This is due to the fact that it's a proprietary platform that the vendor stopped supporting.

Although google's appengine is more open, a lot of its key components are proprietary and can't be easily rebuilt. So while hypercard and appengine are both wonderful technologies, I believe people should prefer something more open. This allows you have an out in case google stops supporting appengine or does something that prevents you from using it effectively.

<comment><USER3> I violently agree. I am upset that others dont see this. Hypercard was great, that that is totaly irrelevant now. Is everyone so short sighted and money grubbing not to see it this time? Why do we have to repeat this over and over.

<comment><USER4> But porting your GAE application to another provider is easy, it won't automatically have the scaling capabilities and the Google login is a problem but mostly they can be easily ported.

<comment><USER3> yeah it appears doable, it doesn't appear to be googles intent to lock people in (but then I am sure it wasn't the intent of hypercard either).

Its still up to the diligence of the people who write the app. The problem with hypercard, was that the people using the app were the ones that created the cool stuff, and the people maintaining hypercard wouldn't/couldn't keep it going for them.

<comment><USER4> Actually now that I think about it, because Google is now an OpenId provider, you can probably just accept OpenIds when you port it out of GAE and everything will work fine.

<comment><USER3> well that solves the least interesting problem at least ;)

</comment></comment></comment></comment></comment></comment><comment><USER5> Why hasn't Amazon made it easier to build web applications with EC2/S3?

I'm waiting for Amazon to respond with something similar. Just to get an application up and running on Amazon seems to involve delving into message boards (I have EC2/S3 accounts but it's learning how to port my web app is not a priority at the moment)

The premise of EC2/S3 is that you can ask for services/CPU on demand - <USER2> Google with AppEngine has significantly lowered the barrier to creating a scalable web app (by handling scaling for you, once you write to their APIs and give them your code [another issue]). Not everyone wants to be an Erlang expert and roll their own scalable code.. (some people just want to be able to build a cool popular app and outsource worries about scaling).

</comment><comment><USER6> Is there anything significant Hypercard did that you can't do in flash these days?</comment>


Affordable Cloud-Hosting, in Switzerland - <AUTHOR> https://www.exoscale.ch/pricing <comment><USER2> For what it's worth, this was one of the companies I tested for a recent project of ours, as we were in the market for European hosting. While we ultimately didn't use exoscale, I can only say good things about them. They were very professional and gave good service, and even voluntarily gave a refund on the used prepaid credit.

I say this, as when trying a bunch of small providers you never really know what you're getting into. As an example one of the companies we tried was entercloudsuite.it which is quite literally the most ridiculously worst company I've ever dealt with. At a point during our benchmarking they they froze the account (with zero warning) and locked out access (?!) and refused to give a refund. Correspondence with their (Italian) staff hit a huge language barrier and their explanation was when we originally registered we had multiple attempts at getting the credit card right (possibly fat fingers?), they refused to be reasonable or restore access, and had to solve the issue with a credit card charge back.

Sorry that diverged into a rant, but if you're int the market exoscale is a good option (along with what we ultimately went with: OVH)

<comment><USER3> I think your Data would be much safer hosted on exoscale than ovh, if it matters to you...</comment></comment>