Fun vs. Computer Science (2016) - <AUTHOR> http://prog21.dadgum.com/221.html <comment><USER2> I have happily traded working in a nice language with slow iteration times to working in a lousy language with very, very fast turnaround.

My favorite extreme example was the time I used a super fast 6502 assembler environment that would do the "change a line of code and get the target running" cycle in a couple of seconds. This kind of interaction is _magical_. You're still writing kind of crappy assembly language, but it almost doesn't matter. Things just flow.

On the other extreme: A large component of me deciding to quit a job was the fact that a build of the product took four hours. And the build was typically broken. So: Arrive in the morning, sync, wait all morning for the build to fail. Do another cycle after lunch: fail. Go home, repeat for _weeks_. (Add to this: Managers who refused to buy decent development machines, people who kept checking in busted code and making things worse, and a crushing schedule. Who needs that?)

These days I'm do a lot of C++, and some PHP. The C++ projects take a few minutes to build, which isn't great, but it's survivable. The PHP "builds" as fast as I can refresh a browser page. And as much as it pains me, on most days, when I grit my teeth and get honest about it, I'm more productive in PHP. And I despise PHP.

I learned LISP early on in my career; wrote a few LISP interpreters, goggled at the majesty of LISP machines, read all that I could. But I've never shipped a significant project in LISP, nor am I likely to. And the Newton actually flipped from a LISP (well, OOPy-Scheme) implementation language to C++ in order to ship. I'm wondering if there is some law of human nature at work: You can have elegance and comfort or you can have a product. I sure hope I'm wrong.

<comment><USER3> > _The PHP "builds" as fast as I can refresh a browser page_

JavaScript is just as fast, or faster. That's probably an important reason why it's "eating the world".

<comment><USER4> I agree that JavaScript is fast - but we've ruined that in a lot of places by throwing in things like code genertion, compilation, builds, and other nasty words. The turnaround for the last React&Node program I had the displeasure of working with was on average 30 seconds.

PHP - for all its faults - does not suffer from these kinds of recompilation issues, yet can be optionally pre-compiled for added speed when you do go to production.

<comment><USER5> I don't use backend js, but things like webpack-dev-server which on file save do an incremental recompile and then hot reload have made this a non issue on the frontend for me. Not sure if this applies to your use case, but figured it couldn't hurt to offer a partial solution.

<comment><USER6> On the backend side, tools like nodemon provide a very similar solution. Then just setup your webpack server to proxy requests to your backend, and you're good to go.

</comment></comment></comment></comment></comment><comment><USER7> I feel like this is a false dichotomy: you can have a fast iteration cycle, _and_ have statically checked guarantees. I've worked in Haskell for 7 years and had exactly this. I could load my entire app in GHCi, make changes, reload and test. Now I'm working in Java and in IntelliJ I can have something similar with hot-swap. And in the browser with typescript I have a strong type-system and can reload my app in seconds.

I agree that it's easy to build a slow, batch based build system and just tell people that's how it is. Fast iteration is important and requires effort to keep working. It might even be more important than a static type system, at least for some apps. But you can have both.

<comment><USER8> One very common complaint I've heard about Haskell is slow compile times, see this discussion for example with a bunch of GHC developers:

[https://www.reddit.com/r/haskell/comments/45q90s/is_anything...](https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/)

<comment><USER9> It's funny how when someone describes their own experience, you tell them they're wrong. Are you claiming the GP didn't actually experience fast reloads?

Initial compiles of some Haskell libraries that essentially do exponential inlining ( _cough_ vector-algorithms _cough_ ) can take a long time. An incremental non-optimized compile of a small change to a project with a good module structure takes a couple seconds.

The GHC devs are correct that it has been slowing down and are putting a lot of effort into getting that speed back. But it's not at the level of "rebuilding my project takes hours" that you frequently get with some build systems.

<comment><USER10> Well, here's another data point. I made a single file prototype to implement a Tetris game just for fun. I think it was with the Haskell SDL bindings or so, and I went with the most straightforward way about the implementation, and do have a reasonable level of experience with Haskell.

I gave up when the code reached about 400 lines. The compilation times were at 10-15 seconds already, and the error messsages were really ugly.

In short, compilation times depend on how you use complex type system extensions, or even only how much the libraries that you use make use of the type system. (And if you don't use the type system much - it becomes such a bad developping experience in most application domains, or you code performs very badly, etc.).

It was so much simpler to do it in C. <1 sec compiles, incredibly performant with straightforward non-optimized code.

</comment></comment></comment></comment><comment><USER11> I think, to some degree, the idea that drives strongly typed, theorem proved languages is a bit different than what most people think of when coding.

A large set of people in that community want to derive algorithms mathematically, using a deductive or proof based process, as in math.

Iterative development conflicts with a top down form of development, and also conflicts with the safety oriented culture of strong typing. While rapid iteration languages and environments are good for initial development, they can be awful for projects requiring maintenance.

About a decade ago, I built a small web app using Common Lisp (SBCL) and a lot of the development I did was done through adding new features and debugging in the REPL. While I saved the VM, reading the code months later to add a feature was terrible because the app was hacked together. I wonder if there's a way to fix this. Typed Racket looks like a promising move in that direction.

FWIW, ghci already interprets Haskell quite quickly for iterative development.

<comment><USER4> One thing to remember - the domain under discussion in the article is gaming. There's little maintenance typically involved with games.

There's more today than there was yesterday, but it's still not a system expected to be built, maintained, and extended for decades.

<comment><USER12> Yeah, this sounds right 99% of the time, although there is at least one genre that, if successful, breaks that mold - MMOs. WoW is 13 years old, Everquest is 18 years old, and Ultima Online is 20 years old. For us hobbyists, there are MUD codebases based upon code written 27 years ago.

<comment><USER13> If you're WoW you are printing money. You can just throw people at the problem.

</comment></comment></comment></comment><comment><USER14> I feel it's the other way round.. Everyone is advocating Javascript, python etc. JS webapps are more and more developed directly in the browser in the dev console, CSS interactively modified to directly see the results. But this also lead us to code coverage abominations where people write hundreds of tests for manually checking input types that otherwise might crash the thing after two days running because that hashtag less of lists of objects contained a string instead of a float. Is that fun?

In gaming Unity3d embraces this interactivity by modifying more or less everything directly while the game is running. The unreal engine blueprints show data flows live etc.

In technical sciences there was always Matlab with its interactive mode of development. We have similar technology in data science with ipython, Spyder, jupyter notebooks etc.

Actually I'm seeing more interactivity than good type systems out there. Elm, Haskell & co is something you find advocated in internet forums but rarely in companies.

(and as the author mentioned - those two actually don't have to be exclusive)

<comment><USER15> Yes, I don't think type systems (or, in general, "computer science-y stuff") are the enemy here. I do at least wonder about some of the stuff that passes for "best practices" nowadays: CI tools sound like a good idea on the surface, but can serve to (partially) hide complex build and deployment processes where once someone might have just typed _make_. Automated tests of awkward corner cases can be pretty valuable, but easily lead to test suites that take minutes (or worse...) to run on every build. I don't really know how best to get the good without the bad, but giving at least some weight to the "sense of fun" stuff sounds like a pretty good starting point.

</comment></comment><comment><USER16> Agree whole heartedly!

That's why my favorite language is Clojure. That interactivity, instant feedback, seeing the program running as you are tweeking it, its a bliss to use and it creates better more functional software.

Imagine playing music as you hear it when trying to come up with a good melody. Now imagine not playing it, but composing it on music sheets instead, and occasionaly playing what you've got every 10 to 30 minutes.

Lisp championed interactivity, it invented dynamic programming for that sole purpose. The idea is that you morph a running program into shape, molding it like you would clay.

The first thing you do when writing in a Lisp like Clojure is run your program. In most other languages, running your program happens much later, and much less frequently, and it can actually be quite challenging to run.

<comment><USER17> When showing off Clojure the application is often molded while running by patching it via the repl. But what I don't understand is if you can actually develop real programs like that? Surely even in Clojure code there are lots of dependencies so you can't just change one place in isolation. And I also guess that changes done on the repl aren't actually saved for the next time you run your app? And how do you do testing?

How is the actual work flow you use when molding your app?

<comment><USER4> The trick with some of these runtimes (I don't know if Clojure does this, just noting that the paradigm exists) is that the state of the runtime _is not lost_ when going from development to production.

The entire state of the program, including the code and the globals in memory, is preserved, and simply spun up in a different environment. This tripped me up for some time with Smalltalk - I didn't understand this.

It's the same with many lisps - you can frequently get a REPL directly inside a running program, and query/change the objects (including code) that is running. This was used to great effect in fixing the Deep Space 1 probe while it was 100 million miles away from Earth.

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

<comment><USER15> Clojure doesn't do the image-based persistence thing. You can ahead-of-time compile to Java byte code if you want, but that's probably closer to the .fasl files created by some Common Lisp implementations. No old bits of state floating around when you deploy a new server. Do occasionally miss the ability to save an image, but it doesn't seem to be the modern way (and would be a nightmare to implement well on top of the JVM).

Can easily add a REPL to any Clojure program though.

</comment></comment></comment></comment><comment><USER18> Flutter ([http://flutter.io](http://flutter.io)) strikes an interesting balance here by (1) allowing just-in-time compiled, state-preserving "hot- reloading" during interactive development and (2) supporting optimized deployment using classical ahead-of-time compilation to native code.

Disclaimer: I work on the team at Google that builds the underlying language platform for Flutter.

<comment><USER19> Hmm, looks interesting, but it's quite unfortunate that making the compilation process be useful at runtime-error-removal is merely _optional_ ("strong mode"). So one wonders how many shops write enough "prototype" code in "weak mode" that they decide to leave it in its Python-like mess instead of rewriting for "strong mode"...

<comment><USER18> Don't worry; strong mode will be the only mode going forward and it already is the only mode for Flutter. Not merely optional.

</comment></comment></comment><comment><USER20> Worth noting that "fun" in this case means player fun, not programmer fun. My productivity and my enjoyment of game development in C++ are secondary to the user's enjoyment of the finished game, and this is where the author's point gets more interesting and valuable. There are a lot of comments here already talking about fun, code safety, and productivity from the programmer's point of view, which IMO misses the most important part.

As a game programmer, building systems with fast turnaround times is more valuable to the artists and designers in the studio than for me personally. And the value in the artists and designers and programmers all having fast turnaround time is in being able to make a game that's more fun for the consumers.

</comment><comment><USER21> I think it might be possible to get the benefits of static type checking while still allowing interactive modifications, but most current type systems don't lend themselves to that.

While it would be possible to replace any value by another of the same type (e.g. redefining a function without changing the signature), I'm not aware of any statically checked language with a REPL that allows that. When I'm playing around in the Haskell REPL, redefining a function requires also redefining all other functions that use it, and that's a chore that isn't even required by the type system.

Other modifications are likely to break static checks, e.g. adding a new case to a sum type would invalidate exhaustiveness checking (and thus probably a bunch of compiler optimizations), so no standard type system would allow it. But having a check that makes sure you handle the added case everywhere would actually be nice to have, especially when it can tell you interactively where you need to add more code.

The major hurdle to altering a running program without violating type safety is the fact that you can't just check the original program and the modified version for internal consistency, you also have to ensure that old code that's still running won't be confused when it calls new code and gets an unexpected return value. In the case of adding to a sum type, you could compile in a fall-through case for all pattern matches, and then patch in the new handler code.

For even larger changes, like completely replacing the return type of a function, it might be necessary to specifically engineer the type system such that it can support this case. Ideally, it would support almost all modifications that work in a dynamically typed language, while still preventing anything that would take the program into an inconsistent state.

<comment><USER22> > Ideally, it would support almost all modifications that work in a > dynamically typed language, while still preventing anything that would take > the program into an inconsistent state.

This is impossible. Data structures have these little things called "invariants" that require proof to be established. In statically typed languages, abstract data types are used to prevent users from breaking these invariants, by making the representation invisible to anyone but the implementor.

If the data structure underlying an abstract data type can be modified anytime, then every time you patch your program, you would have to check two things:

(0) That the new data structure respects every invariant relied upon by other code.

(1) That either the new data structure is compatible with the old one (which is often not the case), or there are no reachable instances of the old data structure in memory.

This is an even bigger pain in the ass than just stopping the program and fixing it.

<comment><USER21> I'm aware that a fully general invariant checker is impossible, but there are still type systems that can catch a lot of errors in practice. If dynamic modifications have to be taken into account, that makes the problem more difficult, but not necessarily impossible. Even though there are changes that can't be checked at all, those can't be too common, or humans wouldn't be able to handle them either.

I'm not sure why you think that the checking will be painful, it almost sounds like you think that it would be done by the programmer. The whole point of type systems is that they can be checked automatically, so the programmer is prevented from doing something stupid.

Dynamic languages already allow all kinds of modifications that might or might not break invariants or introduce subtle incompatibilities; a type system would only make it safer.

It is also not just a matter of "stopping the program and fixing it". Suppose you are writing a game, and during playtesting you encounter a bug, where something is stuck in an endless respawn loop. In a dynamic language, you could look at the misbehaving code, develop a fix, and immediately observe its effects. This allows you to quickly iterate until you have found a solution that works. Compared to a "stop, fix, retry"-cycle, it's simply going to be faster, even assuming you can reproduce the bug reliably (maybe using some kind of input replay).

<comment><USER22> > but there are still type systems that can catch a lot of errors in practice.

I have yet to see a type system that can take a putative implementation of a data structure with arbitrarily complicated invariants, and spits out whether the implementation is correct or not. (Note that Coq, Agda, etc. don't quite fit the bill, because they require the _programmer_ to enter the proof _himself_ , even if these tools can partially automate the process.)

> I'm not sure why you think that the checking will be painful, it almost > sounds like you think that it would be done by the programmer. The whole > point of type systems is that they can be checked automatically, so the > programmer is prevented from doing something stupid.

My point is precisely that type systems aren't normally used to enforce data structure invariants directly. Instead, _data abstraction_ (i.e., the inability to inspect the representation of abstract data types from client code) is used to _confine_ the potential to break data structure invariants to a small fragment of a big program (namely, where the abstract data type is implemented). This is in furious contradiction with the idea of inspecting and modifying anything anytime from anywhere.

<comment><USER21> I'm not talking about the kinds of invariants that require an undecidable type system to formalize, but about the most simple things. "Any value passed to this function can be iterated over." "This sequence of checks is exhaustive." "Calling this function with these arguments won't throw an exception."

Those tend to be the mistakes I make when programming interactively in Python. Forgetting to put a single value into a one-element list. Forgetting to check for _None_. Misspelling a key in a dictionary. Swapping the order of two arguments in a function call.

Yes, in some cases those properties can only be verified by proving some invariant equivalent to the Collatz conjecture. I'd conjecture that most instances could still be solved by an appropriate type system. I'm not too worried if it can't prevent me from invalidating invariants, so long as it can prevent me from making simple mistakes that are obvious in retrospect.

<comment><USER22> > Those tend to be the mistakes I make when programming interactively in > Python.

Those tend to be the mistakes that I take for granted any seasoned programmer can detect and fix almost instantaneously and effortlessly. (Of course, not because programmers are superhuman, but rather because Hindley-Milner is the bare minimum a high-level language should have.) It's pathetic that we're still discussing these in 2017.

> Yes, in some cases those properties can only be verified by proving some > invariant equivalent to the Collatz conjecture.

I have yet to see a useful program whose correctness is contingent on the Collatz conjecture being true. But I have seen lots of programs that are much easier to verify by hand than using a type system.

> I'm not too worried if it can't prevent me from invalidating invariants, so > long as it can prevent me from making simple mistakes that are obvious in > retrospect.

I'm not worried either. I'm just saying that "allow anything to be modified anytime, anywhere" is counterproductive. But if you _really_ want to do it, you can do that in ML and Haskell too: just stuff all your top-level definitions into mutable cells.

<comment><USER21> > It's pathetic that we're still discussing these in 2017.

Evidently most language creators find it difficult to integrate both interactive programming and static typing, which suggests to me that the problem is not easy. Or maybe there just isn't enough overlap between the groups who value one or the other.

> just stuff all your top-level definitions into mutable cells

That seems like it could be part of a potential solution, but it would require rewriting the program so that everything is implicitly wrapped in the IO monad. And it still doesn't handle the case were you want to add to an existing data type.

<comment><USER22> > Evidently most language creators find it difficult to integrate both > interactive programming and static typing.

Interactivity is one thing. Randomly redefining things is a-whole-nother thing. ML and Haskell are interactive. They just don't stuff absolutely everything in mutable cells like most dynamic languages do.

> That seems like it could be part of a potential solution, but it would > require rewriting the program so that everything is implicitly wrapped in > the IO monad.

You can't have it both ways: either you have effects and accept that you have effects, or don't have effects and accept that you don't have effects. (IOW, lying is bad.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Maintainability is also important for "fun".

If you can't touch the code for fear of breaking something, fixing bugs takes forever and new features / levels / versions never happen.

<comment><USER4> Games are rather infrequently maintained. There may be a few early patches, but after a year or so, the game is left as-is.

As a great (yet personally disappointing) example, I give you Mass Effect: Andromeda. No more patches or content will be released for the single player game only 5 months after its launch.

Different needs for different domains.

</comment></comment><comment><USER23> >Does choosing C++14 over C++11 mean the resulting game is more fun?

Even though I agree with the main point of the article, I have to point out that when a game doesn't crash every hour, it's definitely more fun.

Few examples of games that do crash: many games in the Elder Scrolls series, Fallout 3 (and New Vegas), Dwarf Fortress. Games that are undeniably complex and emergent in such ways that the coders have no way of testing everything.

It will be so great that people will be able to make even more complex games, and have them not crash.

<comment><USER4> The article agrees.

> A better argument is that some technologies may result in the game being > more stable and reliable. Those two terms should be a prerequisite to fun > [...]

</comment></comment><comment><USER24> I'm rather late to this party, but it is _so nice_ using C# with "Edit and Continue". Program hit an exception? No problem! We'll just make that didn't happen(+), move the next line of execution back a bit, edit some variables, put the correct code in, and carry on.

Of course, sometimes E&C just doesn't work for mysterious reasons of its own.

(*) English unsurprisingly lacks an acausal past tense to describe doing something that changes an event that has already happened.

<comment><USER25> I think "We'll just make that not have happened..." would be correct English, but your version, though clumsy, is more evocative of what you actually meant. It's coming into more common usage, too.

<comment><USER26> The past is (currently) immutable, and the english idiom to handle this case is "we'll just pretend that didn't happen".

</comment></comment></comment><comment><USER27> Sorry to be off topic, but I just want to mention that this site is _not_ an AMP website, but just try browsing around it to see what a website feels like without bloat.

</comment><comment><USER28> The thing is that most people working in academic computer science are not very good programmers. They don't have to be, as their main duty is not to produce working code, but to produce publishable papers. Of course there are very good computer scientists who are also great programmers, and this is where the practically relevant research is produced.

</comment><comment><USER29> Video games are getting massive and they're not slowing down much. We're relying more and more on the engine to do the hard work for us and leaving the creative stuff to the humans. The only way I can see video games moving forward is to have a massive fixed costs of development in reusable, optimized code, and push all the variable costs onto the individual game made by the individual humans making them. The stuff that goes in libraries and into the game engine and even the tools needs to start sticking around longer and to be sane and safe. Basically, it's what almost every engine has already discovered: game scripting and game logic can use its own language optimized for development time and accessibility. We can leave Python to the animators and level designers, but keep your Rust and your Go and your fancy data structures to people who are building the infrastructure.

</comment><comment><USER30> Computer science and software development are different disciplines, and software developers do value iteration time a lot. Tooling you use and algorithms/programming language principles at play should be viewed independently.

</comment><comment><USER31> Yes, yes, and yes.

I'd go even further and claim that productivity is the ultimate currency in programming, because you can convert it into pretty much anything and everything else. Better quality, better performance, better UI. Of course, there is no guarantee that you _will_ actually do that.

Reaping these benefits does mean that you need to constantly work at improving the code, "if it ain't broke don't fix it" leads to entropy, and so does being afraid to make fundamental improvements due to lack of test coverage.

</comment><comment><USER32> Fighting with a bad technology stack definitely takes time away from the domain, where "the fighting" is different for everyone. One should be in a state of flow during dev, game or anything. So the tools that enable you to get there are the right tools.

Does correctly implementing a composable state machine and effects system mean the game is more fun? Usually.

This essay is full of question begging and false dichotomies.

</comment><comment><USER33> Game programming is never about comfortable programming languages. I think this is pretty well known isn't it. In other programming fields I'd say the experience is definitely getting more and more "fun", headache-free and productive in general.

</comment><comment><USER34> The author has a point that I generally agree with, but note that PHP, JavaScript and Basic all went through a phase of revision that made them more 'CS conformal', removing some notable corner cases in how they worked. (On the other hand, C++ has also had some corner cases removed over the years...)

</comment><comment><USER35> The most fun language (having tried lots of them) I put my hands on is Julia, I just love it. You can do so much with such little effort and it can be optimized to almost match the speed of C.

The 2 main downsides is the lack of proper interfaces and object.method() notation, which is sometimes more readable.

</comment><comment><USER36> This is _exactly_ why I switched from native iOS development to React Native. Swift is really nice and probably my favorite compiled language right now, but 10s+ compile times will never compare to hot reloading in React Native, period.

</comment><comment><USER37> > It's about being able to implement your ideas.

This is where the choice of language might help or hinder you. One language might take longer to implement it or be more prone to bugs.

The question of whether or not your ideas turn out to be fun is completely orthogonal.

</comment><comment><USER38> Has anyone seen the straw man that article argues against? What does "computer science" have to do with "writing games"?

</comment><comment><USER39> >pretend all the computers in the movie work like your desktop PC. RIP Matt Damon.

</comment><comment><USER40> I will leave the details as an exercise for the reader but one would have to quantify fun in its full spectrum.

Ill give you one clue or more like a hunch...

If you have a tool that is trying to do everything it isn't going to be equally great at all those things and it will likely be confusing/hard to use.

The generic programming languages tend to be more popular but they do so in the same way TV programs or video games are trying to appeal to an audience as large as possible. (This is how we got all these absurd hacker movies for example)

In the future (lol) we will discover that single purpose languages are just better at the limited scope of things they do.

PHP is perhaps a bad example that I shouldn't even have mentioned here but such a language knows exactly what its goal is in life like PHP knows it is suppose to bake websites.

Maybe you've touched the awesome with your fun. Someone should try build a language entirely around the core mechanics of fun.

In games there is fun in the form of rewards for stuff that just takes a fucking long time to do, there is fun from rewards for stuff that requires skill, there is fun from rewards obtained though luck, there is fun from a storyline progressing, there is fun from unexpected things, fun from buying ingame shit, fun from selling ingame shit, fun from cooperation as well as growing to be able to do those things on your own.

But the real list is probably much longer.

The language should probably have a basic fun object that looks something like: { temporal: 0. skilz: 0, luck: 0, story: 0, randomEv: 0, pay2win: 0, progaming:0. coop: 0, solo: 0, [...etc...] }

Then you have to benchmark the fun people are taking out of a bit of code or graphics using real world data.

And then....

Then you would be able to focus your attention where your effort produces the largest amount of fun as well as see the areas where your game is teh suck. Answer the big questions like what parts are people playing and why? Where do they rage quit?

If they didn't give up on creating content for Diablo 2 I would probably still be playing it.

If they had a language where fun was the central mechanic they would have known that changing all the items and ruining all the heroes had a negative dev time to fun conversion ratio.

It wouldn't have to be limited to games at all. One could quantify the fun on HN using the same language. It would all of a sudden be obvious that the karma system and submission ranking lacks random rewards and events. A thing no one considered up to now but if we know it is fun and the system is lacking it it becomes worth considering it.

</fun>

</comment><comment><USER41> I'm considering writing a post about "Fun vs physics". In it I will explore rhetorical questions like

"does higher build quality make formula 1 cars faster"

and

"do better materials in a car make it more fun to drive"</comment>


Porn's Lessons on Perl and PHP - <AUTHOR> http://www.technewsworld.com/story/70236.html?wlc=1276880514&wlc=1301146737

<comment><USER2> I keep reading how porn is at the forefront of technology, driving innovation and being a real game changer.

Yet HTTP authentication is still the norm, tubes appeared several months after YouTube and porn hasn't migrated to make good use of HTML5.

I think the industry made one good choice with VHS decades ago and has been rewarded with such unjust acclaim ever since.

<comment><USER3> You're totally right. I was a freelancer in the adult biz for ~2 years and the level of technological incompetence in the industry is hard to believe. For example, no one is using version control systems, most people hardly know the difference between a CMS and a framework, most still update their websites with FTP, virtual hosting is still a scary beast, cPanel is the norm, they still refer to web apps as "scripts", etc.

Innovation in the porn industry is a complete myth in 2011.

PS: If anyone doubts my claim, I suggest you take a peek here and see the level of discussion (the world's largest adult industry board): <http://gfy.com/forumdisplay.php?f=26>

<comment><USER4> "no one is using version control systems, most people hardly know the difference between a CMS and a framework, most still update their websites with FTP, virtual hosting is still a scary beast, cPanel is the norm, they still refer to web apps as "scripts""

Wrong. At least where I work. But I do still call web apps "scripts" because 1) I'm old and 2) that's what they are.

<comment><USER5> From the comments here, most of the developers commenting on the adult industry are being fairly liberal with the term "industry". Sort of like equating the slot machines at the local bar with the casino industry as a whole. Ignore the fact that Apple is adopting business models pioneered in the online adult industry, or that PayPal was years behind what was offered in the adult industry regarding credit card security.

One thing the adult industry can't push on right now is iOS Apps, where most of the action is taking place. But companies like GroupOn, Foursquare, and others are using technology and business models that adult has been using for a long time.

</comment></comment></comment></comment><comment><USER6> These seem to be standard guidelines most tech companies have followed for the past 10 years. What I would like to add to this is metrics collection through something ganglia will give you an overall view of performance and usage across your servers, not just at that point in time but summarized over an hour, day, week, month. I cant tell you how helpful that kind of thing can be. And you can add your own stats to it as well very easily to track any number of things. I've added mail, apache and release graphing to my stats. John Allspaw of Etsy, formerly of Flickr is huge on metrics collection, so is John Adams of Twitter. It plays a key role in assessing where you've been and where you are going.

</comment><comment><USER7> 1\. "12% of the websites in the world contain adult content". 2\. "The online adult industry pulls in nearly US$5 billion a year worldwide." 3\. "Most of the world's adult entertainment sites, a.k.a. porn sites, operate on a relatively thin budget"

Let's combine this with two things:

A. Moaning from porn industry about "intellectual property" piracy: <http://www.stuff.co.nz/technology/216765> B. The paid online pron industry getting blindsided by the free/amateur sites: [http://abcnews.go.com/Nightline/porn-industry-struggles- free...](http://abcnews.go.com/Nightline/porn-industry-struggles-free-content- piracy/story?id=9795710)

You can find a lot of article detailing the porn industry's problems with both.

So where's the $5 billion a year coming from and going to? Something smells really fishy here.

<comment><USER8> Advertising?

<comment><USER7> Well, maybe, but I was thinking more like rake offs by organized crime, or maybe industrial strength money-laundering.

</comment></comment></comment><comment><USER9> This is one of the poorer articles I've read on HN.

The author writes like a Star Wars screenwriter - lots of meatless platitudes and tautologies jumbled together in the hopes that some meaning worth more than the sum of its parts may spontaneously emerge from the soup.

And its references to porn could just as well have been to Facebook, Youtube, or any other highly scalable site. The porn angle is clearly just to drive hits and upvotes, but otherwise useless. C'mon guys, HN is for thinking with your real head, don't get let yourselves get taken so easily by charlatans selling sex.

</comment><comment><USER10> This article misses an important point. The online porn industry pays for high-performance web software. When I worked for Zeus (maker of the world's fastest webserver) I was surprised to see how many porn sites paid for it. For some reason I had assumed that they would do everything on the cheap. No so. They are paying out where it makes sense to: webservers, load balancers and traffic managers.

</comment><comment><AUTHOR> _You're not going to find a bunch of Ruby on Rails or Django sites because it's harder to find Python and Ruby developers on the cheap._

The article is a bit old, but should still make for an intersting discussion.

<comment><USER5> I see the reasoning. Especially considering not all development takes place in California. And don't assume top adult companies don't pay well for developers doing PHP. It's hard finding good programmers regardless of the language.

PHP and Perl have a large foothold around the world, and being located in a nation other than the USA doesn't make a programmer less skilled.

So, with PHP, you have a higher chance of finding good programmers, though you'll have to sift through a lot more people who claim to know PHP. You'll be able to look in a lot more areas, and those areas can offer cheaper rates. And finding a Ruby programmer with ample experience is going to be difficult. I don't know many Ruby programmers who've been programming in the language for at least 5 years.

This is especially true where cost of living is lower. Put all of this together, and using Rails or Django makes little sense.</comment></comment>


Show HN: This is how GitHub 500 page looks like - <AUTHOR> https://www.dropbox.com/s/1h6of0fyqj1z66r/Screenshot%202017-01-12%2013.40.55.png?dl=0 <comment><USER2> It is neat, but this kind of content is not what "show hn" is for, unless you made the page I guess.

[https://news.ycombinator.com/showhn.htm](https://news.ycombinator.com/showhn.htm)

</comment><comment><USER3> Github's error pages have a fun parallax mouseover effect , which this screenshot doesn't capture!

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

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

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

<comment><USER4> Am I missing something on the 502 page? I don't see the same parallax effect. I'm just getting a static unicorn.

<comment><USER5> I don't think so. Presumably if they show that page when they are overloaded, the page must be extremely quick to load.

Notice how all of the assets (images, css) are all inlined in the HTML so your browser doesn't make multiple requests.</comment></comment></comment>


ACME Dashboard – Bootstrap Admin Template - <AUTHOR> http://clabs.co/projects/acme_less/index.html

<comment><USER2> Here's a link to buy it - [https://wrapbootstrap.com/theme/acme-dashboard- admin-templat...](https://wrapbootstrap.com/theme/acme-dashboard-admin- template-WB0JLR295)

</comment><comment><USER3> Cute! What are you using for the graphs (and the mini graphs)?

<comment><USER4> jquery sparklines & jquery flot

</comment></comment><comment><USER5> Really liking the layout of this.

</comment><comment><USER6> This is nicely pieced together.</comment>


Amazon Kindle e-book downloads outsell paperbacks - <AUTHOR> http://www.bbc.co.uk/news/business-12305015 <comment><USER2> There's one thing that scares me about the coming death of the physical books. When I was a kid there were a lot of books at home. Frequently, some book would catch my attention and I would read it (or try to read it, sometimes I was too young to understand some of them). It was not that I was always actively looking for something to read, it was just that books, being physical and visible all the time, were basically impossible to ignore. The fact that they _looked_ different was important, in my opinion, to make me want to look at them more closely.

I don't see how that experience can be replicated today with electronic books, for my kids. I have bought a lot of books for the kindle since I got one, and it kinds of ticks me that Im actually depriving my kids of the real bookshelf experience I enjoyed so much, by not buying the physical version.

(sorry for the poor english)

<comment><USER3> I wish I could pay extra when buying a paperback and get the electronic edition "on loan" until the paperback arrives. This would be the best of both worlds, for me.

<comment><USER4> sod on "loan" I would like the option to have both thanks, I don't mind paying a £1 or so more than the physical copy is on its own but at the moment if I want both I have to buy both the physical and the digital copy. Like the BluRay+DVD packs that are available.

</comment></comment></comment><comment><USER5> I think it's much easier to impulse buy e-books on the Kindle than it is to buy a paperback. You get instant gratification -- you see a book you want, pay for it, and you get it without having to travel anywhere.

This is especially potent if you're already reading a series; just go buy the next book in the series. Sometimes I'll find out about a book and then just grab my Kindle to get the book before I forget about it.

Instant purchase, instant gratification!

<comment><USER6> For me it is also a better delivery method. Living in Europe, it takes about 2 weeks for print books to arrive, then I need to go to post office to pick them up, I need to pay for the delivery, etc. It is all so much easier with the ebook. Moreover, I don't even own Kindle, and read my ebooks on the netbook or phone.

<comment><USER7> Here in the UK, and with Amazon prime, I find the opposite is true. Ordering paper books they turn up by courier at my office the next day, usually before 10am.

Ok, so the cost if £1 more per book but speaking personally it's worth it :)

(I realise I am an outlier, though, maybe not on HN; spending upwards of £1,000/r on books)

<comment><USER8> At least you own your books and can sell or pass them to others. Not so for eBook licences 'purchased' from Amazon: [http://zine.openrightsgroup.org/comment/2011/the- dummy%E2%80...](http://zine.openrightsgroup.org/comment/2011/the- dummy%E2%80%99s-guide-to-ebooks)

</comment></comment></comment></comment><comment><USER9> I would be sold on the Kindle if I could read technical books easily. Over the past few years I have built quiet a collection of (legal) books in PDF format, only for them to be unreadable on my Kindle and impossible to convert to another format without damaging code, graphs, equations, etc.

For novels, it's a fantastic bit of kit, but outside of that the dead tree format isn't so dead.

<comment><USER10> They're not "unreadable" on the Kindle, but the Kindle (especially the smaller models) are pretty non-optimal for using tech reference books in PDF format.

</comment></comment><comment><USER11> previous discussion here:

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

</comment><comment><USER12> While I always felt that this was inevitable, I think this went much faster than what I would have anticipated.

I guess the advantages of ebooks (immediate availability, much easier purchase process) have helped to convert people more quickly and made the converts buy more books in general (certainly happened to me).

Now let's hope that this success is seen by other industries too (Console Gaming, Movies) where they would still do everything possible to have you buy physical media.

<comment><USER13> Well, the transition isn't over yet. Amazon is comparing _their own_ sales of paperbacks to their sales of Kindle books. But Amazon's share of the ebook market is a lot larger than their share of the paperback market. The industry as a whole is still selling substantially more paperbacks than ebooks. Or at least they were, as of fourth quarter last year.

<comment><USER14> Exactly, as well, the book market is the combination of hardcover + paperback, so the comparison is lacking in that feature as well.

<comment><USER15> In July they announced that ebook sales had outpaced hardcover sales, so while sales probably haven't exceeded paperback + hardcover sales, it's certainly on pace to do so soon.

</comment></comment></comment></comment><comment><USER16> I hope this spurs publishers on to making electronic versions (not necessarily Kindle) as standard. I for one have no interest in dead tree books anymore. I read serial works (typically fiction) on an ebook reader or my iPad and my iPad is fantastic for technical books.

Sadly the range of Kindle books is still too small as the publishers (pretty much every content distributor actually) is stuck in the dark ages.

<comment><USER17> _Sadly the range of Kindle books is still too small as the publishers (pretty much every content distributor actually) is stuck in the dark ages._

They need to get their act together. If there is no good 'offical' ebook, people will easily turn to piracy. If that gets established as the norm for normal people, the book publishers will lose out.

</comment></comment><comment><USER18> I've been following this for some time, if you want more information on it this is one of the best blogs out there detailing numbers between paper/e-publishing:

<http://jakonrath.blogspot.com/>

</comment><comment><USER19> I don't understand this -- I buy ebooks because it's too complicated to buy physical books from my country. If it would be as convenient as the US I would buy mostly paperback and just for a select few the ebook version.

</comment><comment><USER10> I wonder if Amazon is counting all the free downloads? I know I've purchased one Kindle book, but downloaded maybe 20 free ones from Amazon.

I'll be more impressed when the e-book revenue catches paperbacks.

<comment><USER20> "Amazon announced that in the US since the start of the year it had sold 115 e-book downloads for every 100 paperback books, _even excluding its downloads of free books_." (highlight is mine)

</comment></comment><comment><USER21> Part of me doesn't want to believe it. Mainly because ebooks are too restrictive (can't resell) and overpriced for my liking.

Also, I might be nitpicking, but it seems like ebooks only beat 'paperback books'. In that article they make a distinction between 'paperback books' and 'hardcovers'. So ebook sales haven't surpassed all physical paper books yet. The title is correct, but could be misleading if you assume 'paperback' is just generic physical book.

</comment><comment><USER22> How could it be any other way? The Kindle starts with no books. People already own paperbacks. To fill up a Kindle requires buying Kindle books. To fill up a bookshelf requires nothing as most people who read already have full bookshelves.

<comment><USER23> If people are buying books _to fill up the available space_ then you're right. If people are buying books _to read them_ then you probably aren't.

I'd guess that most people are buying books to read them.

<comment><USER22> My own experience with devices that can be filled up leads me to believe that there will always be an initial increase in buying rate because of the newness and emptiness of the device.

The rate at which you buy books to read can vary. If it increases, that doesn't mean you're buying books just to fill up a device. You're still buying them to read, just faster. I would imagine people who get a brand new device for reading likely increase their reading time too.

</comment></comment></comment><comment><USER24> The problem for me is that e-books cost the same as paperbacks. And personally I like to have a copy to share. With the ability to share and lend books alleviates some of this issue. But I still think the publishers are holding it back.

</comment><comment><USER25> Interestingly, net sales increased by 40% in 2010. Amazon is still close to being a not-for-profit organization, but they appear to be growing faster than Google.

</comment><comment><USER26> what's the data? is this the pie growing or is digital actually eating into physical book sales in a zero sum game, and to what degree?</comment>


Ask HN: Freelancing - <AUTHOR>

Do you know of good places to find work that aren't flooded with people from india willing to work for $5 a day?<p>I'm in need of a healthy quantity of work-from-home. <comment><USER2> don't rely on the internet for finding clients. the good jobs are either never advertised through the regular channels or don't stay up for long if they are.

</comment><comment><USER3> Best place to find clients is through friends, referrals and people you meet in the real world. Time to get networking.</comment>


The 'Israelification' of airports: High security, little bother - <AUTHOR> http://www.thestar.com/iphone/news/world/article/744199---israelification-high-security-little-bother <comment><USER4> The problem with the Israelification goal is that while Israel's airport security method is second to none, it is not scalable, and therefore not applicable to the US (or many other countries), at least not without major restructuring. The problem of scale is manifested twice:

1\. Manpower - Israel has a huge pool of very talented young men and women who already received very good training in the army and the security services. It also budgets paying them well. Make no mistake, airport security in Israel is no McJob, it is a prestigious, well-paid position, manned by the top classes of society. America is relying on cheap, unskilled labour for these jobs, and transitioning to an Israeli employment profile will bankrupt the system.

2\. Volume - Israel has only one major international airport (and even that one is quite small). As far as airport security is concerned, it is a very local problem which can benefit from focused attention. The US has to protect hundreds of very busy airports, and they all have their unique weaknesses.

<comment><USER5> Hi, I'm an Israeli who is at least passably familiar with how the security apparatus works here. A few comments on your comments:

1\. Scale

Scale _is_ an issue, but nobody in the thread has touched on why. The Israeli security model is (as noted in the article) more about the passenger than their baggage. This approach is both effective, time-consuming, and "racist": the profilers have a conversation with each passenger; as I'm an Israeli Jew, I always get the abbreviated treatment -- focusing more on where my bags have been since I've packed them. As a foreigner, you get a much more in-depth grilling. As a Muslim? They want to know your shoe size, and then a whole 'nother screener comes over and asks you everything all over again, just to see that you keep your story straight. Like they say in the article, the conversations they have are not so much about what you say as how you say it. The screeners are taught to iterate a few levels deep into your story and see that it doesn't break down under scrutiny.

Naturally, this process supposes that A) the threat is foreign and mostly limited to one ethnic/religious group, and B) screeners have this sort of time.

In the US, racial profiling is... unpalatable, and if each passenger / family got even a perfunctory 1-minute Q&A session with a TSA security officer, the system would crash. The US is dealing with a larger threat profile, and a whole different order-of-magnitude of traffic.

2\. The security screener's job: manpower, training, history

Normally these are intelligent men and women, usually students or twentysomethings, who pass a series of exams and then pass a several-month course. The hours are craptastic but the pay is decent, and a lot of students prefer it to shiftwork or waitressing. Passing the course is difficult but not arduous, and in the end you are really being taught guidelines on interrogation and then set loose to use your judgment -- if you have a red flag to raise, then you just call over a senior screener who has more years of experience.

The reality is that there are few enough openings that the program can be selective. I'd say, as a generalization, screeners here possess above-average intelligence, whereas your average TSA screener seems to be a working stiff, blindly following some not-too-complex screening algorithm in a three-ring binder. The number of screeners requisite for staffing all of the US airports precludes the TSA from exclusively employing screeners with the ability to make "judgment calls". There just aren't enough smart people with the desire to work a screener's job in the US.

Also of note: screeners here can be idiot asses just like anywhere. I've heard stories from many business colleagues who traveled to Israel on business in the last decade. During the rougher periods of disquiet, they suffered from overzealous screeners who couldn't believe that despite "the situation," there were some businesspeople who had to come here with equipment to demonstrate. Just like the TSA, if a screener decides to make your life unpleasant, it is unpleasant, and there's nothing you can do about it.

Past "experience" in the army is completely meaningless for this job. Despite myths about the Israeli army, we are not all super-mossad-spies with extensive training in terrorism and interrogation techniques. Even combat soldiers aren't taught how to perform interrogations; they're taught tactics of battle. The generally security-oriented mindset is fostered at a much younger age with PSA's about unattended bags aimed at schoolchildren.

In the end, the system here relies on quality manpower, trained to employ their judgment of whether or not a given person constitutes a risk. In the US, "subjective" is merely a synonym for "pending lawsuit".

Amusingly, I don't think the system here would be as compromised by a "procedure document" leak like the recently-infamous TSA docs. Like any good security, it works just as well if you know how it works than if you don't.

<comment><USER6> "PSA"? Google suggest didn't have anything for "p security administration"

great comments btw, both your's and parent's (I have to post this b/c my upvotes aren't being counted).

<comment><USER7> Public Service Announcement?

</comment></comment></comment></comment><comment><USER8> Interesting article but it doesn't address the root issue. Israel has real threats to deal with on a weekly if not daily basis. They're forced to take security seriously and it shows in their procedures. Their security employees deal with regular, serious threats and one would assume numerous close calls have made them self-motivated.

On the other hand, North American countries only have one real threat every 10-odd years or so. In fact, the most recent attempt didn't even go through North American screening. Since we don't have real terrorists often enough to matter, I doubt American security will ever come close to the Israeli model.

What if you were building a software package that you knew would never have any users? Could you motivate your team to care enough to make the software great? Could you yourself be motivated to do a good job, or would you just go through the motions?

</comment><comment><USER9> Here's a question: how many terrorism attempts have there been against US airlines since 9/11? For that matter, what is the total number of US flights that have EVER been attacked by terrorists? I'm including both successful attacks and ones where the attack was foiled.

This is a serious question--perhaps this is a much bigger threat than I'm aware. But according to my risk assessment, airline terrorism is such a low- order threat that it's just not worth getting exercised about. I agree that the TSA accomplishes little or nothing, but I feel perfectly safe--the odds that I will be on a plane that is attacked by a hijacker are almost infinitesimal.

<comment><USER10> > But according to my risk assessment, airline terrorism is such a low-order > threat that it's just not worth getting exercised about.

Let me introduce you to a pair of concepts I like to call "symbolism" and "morale." Americans like to feel safe, and up until about 2001 they felt pretty safe flying in a plane. Then in a vast, symbolic gesture, terrorists flew the planes into buildings. The American people's morale was so damaged by this gesture that we subsequently allowed our government to drag us into two wars that will do us no good and only harm in the long run. It will be exciting to find out what we allow or even demand it to do next time.

So yes, it is a much bigger threat than you're apparently aware. Or are you asking if the percentage chances of you being harmed are high? Probably not. In fact, even if there were no security you'd probably still be safer than you are driving along America's roads. But that's not all you have to worry about.

</comment></comment><comment><USER11> That only works when you have a tiny number of flights at a handful of locations are willing to spend through the roof. It would never scale. Their largest international airport is tiny by US size--it wouldn't even make the top 20. And that's just the US.

Not to mention that the US public would never put up with it.

Update: this puts it into perspective--El Al (the largest and most well known Israeli airline) operates only 37 planes which would make it the size of a small regional airline in the states. Allegiant Air is unheard of to much of the US and operates 49 jets. Delta has a cool 449 and flies to more countries than El Al has flights per day. Ben Gurion International Airport, the airport mentioned and the largest in Israel, is roughly the size of Kansas City International Airport. There's simply not a valid comparison.

<comment><USER12> What about the isolation of the suspected luggage in a bomb-proof area or container? All that would seem to require is investment in the containers and/or blast-proof shell. Why instead is the 'best idea' to try and evacuate a bustling airport terminal with 100's or 1000's of people?

<comment><USER11> The part that wouldn't scale and that we would never put up with is the personal interrogations, highly armed guards covering entry points and all the searches.

Go ahead and put some blast containers in place, but it would likely be a waste since there are so few evacuations.

<comment><USER12> If these airports handle so much traffic that these methods won't scale than how in the world is "evacuate the entire airport" even seriously considered as a solution to _any_ problem?

<comment><USER11> It's much more work to have half hour interviews with every passenger than it is to evacuate a terminal every couple years.

<comment><USER13> Did you even read the original article? It's a goal to move passengers from parking lot to gate in 25 minutes. Half-hour interviews aren't a part of the process.

<comment><USER11> Perhaps if you're a local it's quick. But they also recommended to show up three hours early for a reason... Long interrogations are quite common. If you fit a profile they will drill you like you have Osama on speed dial. This was a puff piece for how awesome El Al is, but the reality is their method only works because of the small number of passengers (and their willingness to accept racism).

[http://www.elal.co.il/ELAL/English/AllAboutYourFlight/AtTheA...](http://www.elal.co.il/ELAL/English/AllAboutYourFlight/AtTheAirport/CheckInTimes.htm)

<comment><USER14> You're right it's a puff peace (the guy interviewed sells security services..) and that some passengers get grilled, but wrong about the race angle: People I know that got the longer question & search treatment include a French Indian woman, a Korean guy and an Irish American from San Francisco. The only thing they all had in common a certain profile - in their 20s, traveling alone, little luggage, staying for a short period.

I got profiled a few times in other airports - a random search in Pittsburgh, a less random one at Auckland, NZ, a few more I'm probably forgetting - all in all, I prefer that to the process that subjects _everyone_ to a full on search as they do in FRA and sometimes in LHR and US airports. That said, I suppose if I was consistently getting profiled I'd probably be less game.

As for "3 hours early", you'll find almost every airline has this in their website, to cover themselves. Except for very infrequent fliers, no one really shows up 3 hours early. It's a small airport and usually pretty quick to get through.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> The procedural aspects of this sound good - multiple rings of security, compartmentalization of risk, etc. - but I have to wonder how well systems so dependent on the intelligence and intuition of individual screeners would work in North America.

<comment><USER16> It wouldn't. How many planes is El Al actually flying? How many planes do the majors in the US fly? This idea does not scale. It puts society on the wrong end of the cost equation.

<comment><USER17> Also note that Shin Bet security levels require El Al to spend on the order of $100million/year to secure those 37 airplanes - and, when you are subjected to "Selective Screening" - you aren't dealing with the TSA and their seeming reluctance to actually _search_ you during a pat down.

[edit: I'd love to know what percentage of Muslims are subjected to "Selective Screening" on El Al flights. The TSA/United States can't get away with the same type of behavior that Israel can get away with. We have to treat everyone the same to avoid the taint of "Profiling"]

<comment><USER18> "The TSA/United States can't get away with the same type of behavior that Israel can get away with. We have to treat everyone the same to avoid the taint of "Profiling"]"

The TSA operating procedure manual specifies that ALL citizens of 12 countries (almost exclusively Muslim-populated ones) are automatically selected for secondary screening.

Even my American citizen friends with Arabic names get "random screening" the majority of times they fly.

<comment><USER16> For what it's worth, I don't think decorum is the problem with duplicating El Al for, say, UAL and AA. The problem is that we can't staff enough competent people to execute at El Al levels of sophistication against our passenger load. TSA screeners are close to the bottom of the law enforcement and homeland security food chain, and the people we need to do this job require more skills than the average metro police officer.

</comment></comment></comment></comment></comment><comment><USER19> Oh, yes, because the Israelis totally have their shit together.

<http://www.youtube.com/watch?v=ihXtbB-4GWw>

<comment><USER20> This seems like a relevant comment, why is it downmodded?

Clearly if Israeli security forces are putting bullet holes through laptops as part of standard procedure, that's not exactly the hassle-free friendly security process the article implies.

<comment><USER21> I didn't vote either way on it. That said, I can see a few reasons why it might be downmodded.

On the surface side, its use of profanity and the attitude that I read from the comment aren't useful for criticism. A more useful way of phrasing it might have been along the lines of, "Focusing on the intent of the traveler may help sometimes, but it can also lead to events such as this one where an innocent person's laptop is destroyed based on a feeling." NOTE: I can't actually watch the video because my laptop has no sound right now. The way one phrases something matters and, at least to me, it seemed like more of an emotional attack than a response to procedures that may or may not be good.

On the deeper side, one event does not a trend make. The comment author provided a video about an event. It's somewhat like linking to a video of an NFL game where the Chief's won and saying they're a good football team - <USER2> linking to a video of the Saint's loss and saying they're a bad team. Sure, it is evidence of badness, but it's one piece among 15 this season and the majority of evidence points the other way. Now, going back to Israel, I'm not making a claim that the majority of evidence goes either way. I am trying to say that Israeli security deals with hundreds of thousands (if not millions) of people every year and to judge whether they have their act together or not cannot hinge on one piece of evidence.

And, to be frank, that's part of the problem with your reading of the comment: it isn't part of Israeli standard procedure. If one has reports of it happening in a systemic way, that's important. Heck, it's important that it happened even once. However, an isolated incident can be tragic without being indicative of anything. It was a bad thing that happened. It was good that it got press (as I heard she got monetary compensation from the government). However, a report from an organization that looks into this stuff and spots trends is a more persuasive thing than one incident.

Although, if it were phrased more pleasantly, the author might not have been downmodded. Then it might be seen as someone offering alternative evidence arguing that the situation isn't as rosy as the original article implied and that it's a more complex situation. However, the phrasing makes it seem like the original author wishes for us to throw out all other evidence because of one piece they have chosen to present and have that one piece preferenced over others.

If I had wanted to bring that video into the discussion, I would have said something like:

"The article paints a rosy picture of the situation, but it's one that turns on human intellect and 'gut feelings' which isn't a great way to run a security system. People sometimes have gut feelings (conscious or not) that are biased on things like race, religion, gender, etc. and might single out people not because of what's in their eyes, but something else. Likewise, it could mean that sometimes people have gut feelings that are wrong - <USER3> might be legitimately nervous not because they are planning something bad - and that can lead to situations like [the video]. . ."

<comment><USER20> From the original story that the video is connected with: "Then they asked me to wait. Since they had asked for friends and families phone numbers I assumed they might be calling to verify my answers to questions or confirm I really had extended family in Tel Aviv. An announcement played over the sound system, interrupting my break in the sunshine. First in Hebrew, then Arabic, then in English. It was something along the lines of, 'do not to be alarmed by gunshots because the Israeli security needs to blow up suspicious passanger luggage.'"

Perhaps not entirely standard procedure, but sounds like it's not an isolated incident.

While I agree with you that the comment could have been phrased more effectively, the reminder that this article portrays perhaps an overly rosy interpretation of Israel's security practices was helpful, at least to me. It seemed odd it would be sitting at negative numbers just because someone didn't like the way it was phrased.

</comment></comment></comment></comment><comment> cool-RR I just want to note that flights to/from Israel happen to be more expensive than in other countries.

</comment><comment><USER22> Why not put close relatives of those who attempt terrorist acts on the "no fly" list?

<comment><USER4> That's a wrong thing to do for two reasons.

1\. It's collective punishment. Unethical unless absolutely necessary. 2\. It would be ineffective. In most cases in the west the relatives of people who ended up blowing themselves up didn't know about their involvement in terrorist organizations and didn't condone their actions.

<comment><USER22> Collective punishment with close relatives is better than racial profiling, massive inconvenience for everyone, etc.

And it would encourage people to be more alert about suspicious terrorist activity within their family.

<comment><USER23> >Collective punishment with close relatives is better than racial profiling, massive inconvenience for everyone, etc.

It's also better than a poke in the eye with a sharp stick. So what? We don't have to have _any_ of those things.

Also, collective punishment is not better than massive inconvenience. Convenience is never an excuse for doing something immoral.

</comment></comment></comment></comment><comment><USER24> hi i think about 2000 ameriacns die every day from heart disease righ why bother with the airlines? just eat right... and btw i'm from israel

</comment><comment><USER25> High security, little bother, totally worthless. Pick another country that doesn't have the services or pick a different target that is as spectacular and your security becomes worthless. Put in place a consistent security system that is consistent with the threat.

</comment><comment><USER26> The bigger tragedy is that Israel has been living in a state of war for 50 years.

A little more effort toward peace and less toward locking down society and we'd all be better off.

<comment><USER14> I was born in Israel and lived there all my life till 2006. Ironically, it was often the efforts towards peace that escalated violence: The 1992 Oslo Accords were followed by the suicide bus bombings of the 90s, the 2000 Camp David summit resulted in the suicide cafe/mall/club/etc bombings of the early 00s, the withdrawal from Gaza facilitated Hamas' rise to power and so on.

All this isn't to turn this to a yet another online Mid East flame war, nor to claim that Israel doesn't share the blame for what's happening or that Palestinians aren't suffering at least as badly - just to note that anyone from a conflict area will tell you life are _much_ more complicated than "a little more effort towards peace" ;)

</comment></comment><comment><USER27> Too much talk, too little action. Airport security is to be treated seriously by all countries.

</comment><comment><USER28> A sensitive subject to say the least.

I find it mind boggling that anyone would want to emulate Israel in any capacity concerning security. They've had suicide bombers in cafes, night clubs, school buses, etc.. and no matter what side of the fence you're on it's pretty obvious that whatever they're doing is _not_ working.

<comment><USER29> You are wrong, it is working. The controversy is over the cost. There are countless instances of identified and disabled devices. Who knows how many deaths the metal detectors/security check at the entrance to nearly every point of public gathering (malls, movie theaters, parking decks, etc.) have prevented. Their inconvenience would not be acceptable in the US but I'm just saying it does make a difference. Just last week, an explosive device made from a gas canister and fireworks was found on Highway 443. Its a major road between Tel Aviv and Jerusalem, a road I have used several times since my arrival here for my winter break.

Despite the record of suicide bombings in clubs et al, the Ben Gurion airport has experienced no such acts of terror. None.

Israel is a technology hub, it attracted Warren Buffet's first investment outside of the US, and its citizens live everyday normally despite the threats. Israel's defense forces do what they deem as necessary.

It _is_ working. But many ask at what cost.

<comment><USER30> +1 and that doesn't even touch it's added value as a deterrent.

</comment></comment></comment><comment><USER31> Yes, let's embrace the idea: adopting the stance of a country at constant war since its beginnings, a focal point of worldwide disagreement. A country which (from any perspective) seems nowhere near achieving stability or peace. Not such a great model, on second thought?

Or, maybe we should go further at "Israeli-fying" our borders: more walls and more military machines. Perhaps 'settlements' (er, um, neighborhoods) just inside Mexico's and Canada's borders...!?

This statement is what is so alarming to me: "Do you know why Israelis are so calm? We have brutal terror attacks on our civilians and still, life in Israel is pretty good. The reason is that people trust their defence forces, their police, their response teams and the security agencies. They know they're doing a good job.

Do we have such sweeping trust of our gov't/authority figures? Should we? Should anyone? If this is "Israeli-fication" of thought, then please count me out. Israel is a model of a worst-case security scenario (way of life) -- it's not an ideal.

<comment><USER32> I believe this is a DH1 argument. You are not refuting or event attempting to refute the main point at all.</comment></comment>


Yahoo Acquires Qwiki For Around $50 Million - <AUTHOR> http://techcrunch.com/2013/07/02/yahoo-acquires-qwiki-for-around-50-million/ <comment><USER2> My Twitter feed has been lighting up with this. Not because the acquisition is all that interesting in and of itself, but because the app was developed by Chaotic Moon, and they're saying they never got paid. For example:

[https://twitter.com/whurley/status/352201365910593536](https://twitter.com/whurley/status/352201365910593536)

Better start making popcorn.

</comment><comment><USER3> Does anyone know if these types of acquisitions are as simple as, "hey I like this company, let's email them with an offer price and see what they say", or is it more of "hi, we like your company, can you please send us your earnings, forecasts, expenses, etc..."?

For anyone out there that's had suitors/offers, I'd love to know what the process for this kind of thing entails.

<comment><USER4> Before they make an offer, they will perform a complete assessment of your company, it is called "due diligence".

They do not easily throw money at you.

<comment><USER5> Due diligence typically refers to the process after an offer is made and accepted to ensure things are what they are supposed to be.

[http://www.investopedia.com/terms/d/duediligence.asp](http://www.investopedia.com/terms/d/duediligence.asp)

[http://www.merriam- webster.com/dictionary/due%20diligence](http://www.merriam- webster.com/dictionary/due%20diligence)

I will note that this differs from what wikipedia says is due diligence.

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

Unfortunately most of the information that is needed for true "due diligence" is not going to be possible until signing a contract or perhaps a letter of intent (which means very little of course).

<comment><USER4> It looks to me that your references contradict you. How many companies have you sold?

I do not know whether the due diligence is supposed to be done after an offer, but when you are negligible to a company that will possibly acquire you, they just propose a due diligence and maybe a deal, or no deal. What would you choose?

<comment><USER6> larrys is correct; due diligence (as it applies in corporate M&A) occurs after a term sheet or letter of intent is sent and accepted, and is the process of verifying that everything the other party said was true.

Further, your question "How many companies have you sold?" is rude and irrelevant.

<comment><USER4> Sorry, I tried to look smart talking about things I did not know enough about. I sometimes do this because I am very frustrated, as I am your age and have not done anything significant with my life.

It gives me a huge amount of butthurt looking at people like you, as you are my age and a seasoned entreprenur, rich, happy and successful, and I am a miserable failure.

Sure you know how due diligence is done, probably you have had time to be good at knowledge and experience in business, while your employees whom you have made money from have been working barely seeing the sun.

Are all those people THAT worse than you to justify the income discrepancy, or are they worse than you at all?

Do you consider yourself superior to the people who are of your age or older and are still working as employees?

This seems so fucking unfair to me that people like you get THAT amount of money and life enjoyment. Are you really THAT good, that better than the people who are not entrepreneurs?

Looking at people like you, I suppose you believe you are extremely smart and special and the way you life turned was the only possible way.

The human world is so fucked up.

By the way, I do not think that the question "How many companies have you sold" is that rude, I was just trying to find out whether the person speaks from their experience or not. And definitely it is relevant. So go fuck yourself, smarty pants.

</comment></comment></comment></comment></comment></comment><comment><USER7> Yahoo is building a content engine. In a play on the 'chicken returning to the egg' strategy, Yahoo recognizes the negative regression of the Internet towards portal sites driven by Facebook. This is the original trend that got Yahoo going in the first place, and what is the thing that always wins in Yahoo land? Content.

Content is king in that land of Yahoo and summarization of a neverending stream of content is a faster way to get more people to see more content and thus more ads.

Yahoo is making a new portal, one built around summarization of personalized content.

<comment><USER8> >Yahoo is making a new portal

Yahoo already has a portal - that's what their homepage is and it's hugely popular. The nature of a portal though, is to transport the user somewhere - they are taking all their huge number of pageviews and sending those users on to _somewhere else_. Yahoo's acquisitions seem to be the opposite of making a portal - they're bringing more and more of the content onboard, trying to turn their portal into a destination. or rather, buying up enough actual destinations that the portal can promote their own products instead of lucky third parties.

</comment></comment><comment><USER9> <s>I'm sure Yahoo will become the true market leader of the internet by simply buying a few startups every month</s>

I mean, it reminds me so much of "trophy wives".

One does not simply BUY one's way into Mordor.

</comment><comment><USER10> Based on most of their recent acquisitions (Tumblr, Summly, Qwiki) I'm inclined to believe that they're working on some sort of an automated(?) product for the publishing industry (New Media, perhaps).

I just wish Yahoo's acquisition spree doesn't end badly with employees leaving, because the IP really doesn't seem to be worth anything (in the case of Summly, Qwiki, etc).

<comment><USER11> > I just wish Yahoo's acquisition spree doesn't end badly with employees > leaving

Right now it is just short term pump and dump. There is 0 strategy. It will only end up with employees getting fired due to Yahoo executives mistakes.

<comment><USER12> Without being present in the relevant board meetings, it's hard to say this with any realistic certainty... but it certainly does ring true given the hulking, festering mass of anecdotal evidence Yahoo keeps leaving in its wake.

</comment></comment></comment><comment><USER13> > In another display of their intent to buy the entire Internet

Sounds accurate to me..

</comment><comment><USER14> They raised $10.5m... probably at a $30-$40m pre-money valuation for their later stage, $8m round.

Not a great outcome, especially if the investors had liquidation preferences.

<comment><USER15> Not a great outcome for last round's _investors_. With a 1x liquidation pref, they just get their $10.5M back with some change on top.

Pretty decent for everyone else- especially founders, assuming they've got a significant stake in the remaining money.

</comment></comment><comment><USER16> How much cash does yahoo have and where do they get it? Are they profitable at all?

<comment><USER17> Yahoo has been (nearly) continuously profitable since early this century. It often surprises people given the general negative feelings toward them.

<comment><USER16> It really is surprising, but I'm glad they found their way to stay alive and profit as well. Hopefully they'll make some sort of a bigger splash in modern era as well.

</comment></comment></comment><comment><USER18> "Yeah, let's go shopping"</comment>


Lessons learned from the early days of Google [video] - <AUTHOR> https://www.youtube.com/watch?v=J-xZlyHnEoI

<comment><USER2> Slow news day?

</comment><comment><USER3> Are there slides available? Love to see the early servers Google used.

<comment><AUTHOR> Slides: [https://docs.google.com/presentation/d/13gDspOfYxB3z2_SIKne0...](https://docs.google.com/presentation/d/13gDspOfYxB3z2_SIKne0zE2uc7dCLTffDkF9DEBTETw/edit#slide=id.p) Blog: [https://www.mattcutts.com/blog/lessons-from-early-days-of- go...](https://www.mattcutts.com/blog/lessons-from-early-days-of-google/)</comment></comment>


Modern devices in pure CSS. The first are iPhone X and iPhone 8 - <AUTHOR> https://picturepan2.github.io/devices.css/ <comment><USER2> As a long time CSS dev here, I am happy that I am not the only one who has struggled with inner round curves!

<comment><USER3> I'm replying to your comment here: [https://news.ycombinator.com/item?id=15177898](https://news.ycombinator.com/item?id=15177898)

(since no other way to talk)

You mentioned, I think, correctly, that the list is for those who have their basics right and want to step their game up.

I'm assuming you have your basics right? If so, what resources did you use to get there?

<comment><USER2> I don't remember the exact beginner tutorials I used at first, but I do remember that I had many projects and stuff I wanted to make and googling like a madman, solving a problem after another one.

Always questioning what I was doing and searching for better ways of doing it led me to [https://html5doctor.com/](https://html5doctor.com/) and [https://css-tricks.com/](https://css-tricks.com/) for really understanding things, and w3school often popped up for basic syntax.

This way was quite hard at some points though, when I tried to do some stuff too difficult for my level at that point and I got frustrated (in exchange I learned how to manage that frustration!). If you can, definitely find someone who knows these stuff to at least guide you a bit.

</comment></comment></comment><comment><AUTHOR> More devices are coming.

</comment><comment><USER4> Would SVG not be a more elegant solution?

</comment><comment><USER5> Text styles used to do geometric layout.

A brilliant idea.</comment>


Colin Furze Flies a Working Homemade Hoverbike - <AUTHOR> http://www.colinfurze.com/hoverbike.html <comment><USER2> Colin could easily have lost his leg twice during the recording of that video.

</comment><comment><AUTHOR> hack until it works (3m50s) ~ [https://youtu.be/soxxPyaAT1k](https://youtu.be/soxxPyaAT1k)</comment>


Why Coconuts Could Be the Hydrogen Storage Material of the Future - <AUTHOR> http://www.technologyreview.com/view/531416/why-coconuts-could-be-the-hydrogen-storage-material-of-the-future/

<comment><USER2> This is hilarious! They're already using coconuts in ITER (the fusion reactor) [http://hplusmagazine.com/2009/10/27/coconut-futures-and- ther...](http://hplusmagazine.com/2009/10/27/coconut-futures-and- thermonuclear-fusion-power/) It seems coconuts are the hi-tech fruit of the future!

<comment><USER3> If we use the term drupe, it sounds slightly less crazy. Drupe enabled reactors seems like a phrase I could get behind. Fruity Reactors, or the Coconut Reactors do not inspire confidence. Though a bag of fruity reactors does sound tasty.

</comment></comment><comment><USER4> Sounds very exciting. MetalHydrides have been a "promising" material for hydrogen storage for decades now but haven't really proven to be a practical material. This entirely new direction of research is very promising.

From the original paper on arxiv ( [http://arxiv.org/pdf/1409.7219v1.pdf](http://arxiv.org/pdf/1409.7219v1.pdf) ), sounds like that desorption (release) of hydrogen gas from the material requires extreme low pressures to be created. I'd be curious to learn the energy equation there... that is, how much energy needed to be consumed to recover the gaseous hydrogen back from the material (say, as percentage of energy stored in H2).

</comment><comment><USER5> whenever i read about great new carbonized material and it great absorption/porousness and multiple cycles mechanical resistance the first question comes - have they tried it for batteries as current carbon electrode's limited ability to absorb lithium is among the main factors limiting the batteries capacities (and lifespan)

</comment><comment><USER6> We can use sparrows to import them from the tropics

<comment><USER7> I'm sure that we've got other means of transporting coconut that are less seasonally dependent.</comment></comment>


WSJ: Compare median pay across 1000 US companies - <AUTHOR> https://www.wsj.com/graphics/how-does-your-pay-stack-up/ <comment><USER2> Getting around WSJ Paywall: [https://www.wsj.com/graphics/how-does-your-pay- stack-up/](https://www.wsj.com/graphics/how-does-your-pay-stack-up/)

<comment><USER3> That didn't work ... the facebook redirect did though.</comment></comment>


So You Call Yourself A Salesmen? - <AUTHOR> http://coreyblinks.com/so-you-call-yourself-a-salesman

<comment><USER2> I do sales calls as well and I agree with what Corey says. It's not about the selling in the end, its about the prospect being able to remember you, you being able to figure out a way to offer something of value and ensuring that the person likes it after you offer it to them. Prospects who act irritated are probably going through a rough patch, and I usually make it a point to call back in a month and check for a tone change, and more often than not, they will talk.

<comment><AUTHOR> Thanks! Agreed-The follow-ups are just as if not more important than the initial call.

</comment></comment><comment><USER3> One thing I really hate is being sold something. I want to _buy_ things with my own will. My impression (as someone who know nothing about sales) is sales people focus on _push_ too much and the don't implement _pull_ at all.

What does hacker news reader think about this? Do you also get offended by people applying the techniques explained in the article?

<comment><AUTHOR> When I wrote this it was for people who are running start-ups or launching a new company with no prior or little sales experience.

I don't believe in lying to people or providing mis-information. As sales person, my goal is always to place all of my cards on the table and let my customer chose what they want.</comment></comment>