Show HN: Learn Swift - <AUTHOR> http://books.aidanf.net/learn-swift <comment><AUTHOR> I've been learning Swift in recent months, and as part of that process I wrote a short book about the language.

It's aimed at developers (like me) who can already program in a language like Ruby or Python and are looking for a quick tour of Swift.

It's available to read for free online at [http://books.aidanf.net/learn- swift](http://books.aidanf.net/learn-swift)

I'll be adding stuff about yesterdays announcements in the next couple of weeks.

<comment><USER3> Great timing on the post. I'm a Python(2) user who is always on the lookout for the next language to jump to since I'm never moving to Python3. With Swift on the server and iOS, and being a very pleasing language similar to Python, this will be what I study next as I look to migrate off Python2 as it dies (which itself may take a while). Thanks for posting this.

<comment><USER4> Out of curiosity, why are you avoiding Py3? I've not touched python in a couple years. I was thinking of taking it back up, just to be more familiar with it.

<comment><USER3> As the other guy who replied said, there's nothing explicitly wrong with it. But it's not to be ornery. I think it only appears that way to people who haven't thought it through. I don't owe GVR or the core dev team anything. Certainly not thousands of man-hours to make their new, unnecessarily breaking version of Python3 to be successful. It's that going from Python2, it's mere technical churn. Python3 has zero technical innovation. It's just a different way of doing certain things, nothing more. Unicode was supported in Python since 2.6. Print was a statement rather than a function. Std lib cleanups. So what? Bigger fish to fry in the world than that. All of the new features, can, and do work on Python2 in the form of backports.

It breaks everything I've ever written, for no good reason. I also end up with a much smaller pool of libraries to choose from for new projects.

It makes no sense. In a microcosm of the universe where Python was the only game in town, Python3 would have worked out. Instead of moving to 3 and losing many advantages for churn, I can just go spend time with something else. Swift is pretty what I'd design if I could pick and choose features, so it's perfect for me- excited I'll be able to use it serverside while simultaneously learning the language for iOS.

Also, people frequently cite that moving from 2->3 is easy. It is. But they somehow forget that testing old, large projects is extremely labor intensive and always results in breakage. Unless you have 100% test coverage, which I know no one who does.

<comment><USER4> Interesting points, I'll keep them in mind. I don't really have to worry too much about making old code work, so I'd not be too concerned with that. I'll probably start with Py3 because I don't really expect to rely on too much library support for the things I'd cobble together in python.

As far as unit testing goes, you are absolutely right. I unit test everything....I mean, I was taught TDD right out of the door at Uni, and though I don't exactly follow the methods strictly, I am at my core, a functional programmer. I want every last bit of code I write to do one and only one thing well. I, therefore, test all of those functions, no matter how mundane. But you know what? Even then, my test coverage on a good project, where I'm not just dicking around probably hovers about 85-95% coverage. There's just always some flotsam and jetsam that escapes the tests. First time I worked on a project with a team, I stressed my head off because of that very fact, until we did our first metrics review and I saw that I was actually ahead of most people....

<comment><USER3> And also, you'll find more bugs in Python3 libraries. They're being used less than Python2 libs. That, and the long tail of libraries that may never get moved to Python3. There's really a lot of reasons to not use 3, or like me, wait to see if it ever really overtakes 2. A 3rd extra reason if you needed any more, is that almost all jobs in the field use 2.x. I tried to love Python3, but the technical reasons just don't make sense to migrate, and once you meet the coercion and vitriol of the Python3 community, you'll learn to resent its existence and them.

The future of Python2 is actually very bright, while 3's is in jeopardy. That's why everyone is so pushy about it, they lose their bet if it never gets over the hump. Being as 3.0 was released in 2008 and it's now 2015, I honestly think that answer is already here.

Using 2, then switching to 3 if it ever does overtake it makes a lot of sense and is the sensible bet. But 3.x overtaking 2 anytime soon is really unlikely, and library worth anything will be 2+3 compatible and dropping 2 support would just be asinine with the ~83% userbase it holds today.

Even if Python3's userbase _doubles_ in 5 years, it'll still be under 50% of the overall Python userbase. And I think doubling its current usage would be overly optimistic. Python3 will either collapse, or split the community (already has to a degree) with someone forking Python2 for good. Pyston may be that fork, or a couple other contenders.

The situation is a disaster all around. For Python and the community. Companies in some cases now aren't putting new product down in Python because of this. You'll be alright using 3, because no matter the final outcome you'll be able to go back to 2 without issues and vice versa. I only recommend 2 because you won't be missing _any_ libraries if you use it, and if you want to do it for a job you'll be using 2.x anyway.

Python3's biggest purpose is giving people a reason to hassle maintainers to port to it. They bite on the political propaganda surrounding 3, that it's the "newest version", which for programming languages is not always in best interests of the user unlike an up-to-date web browser. Then when they find out x doesn't work or exist in 3, they badger whoever wrote a library for 2 to port. Those people really need to port it themselves and maintain it afterwards. They don't, and it's just an ugly situation.

For example, you can build iOS/Android apps using Kivy. Guess what, can't build for iOS unless you use 2.7! Just lots of surprises out there for those who start off wanting the "latest version". It's not the latest version, it's a new, breaking language. If you end up doing much cobbling with Python, this may be of interest to you.

I have my doubts 3 will get over the hump, and just plan on waiting till the complainers turn into maintainers and 99% of everything is ported. Then I'll use Python3 if I don't find something else I like more before then.

</comment></comment></comment></comment></comment></comment><comment><USER5> I'd highly recommend Functional Programming in Swift for more intermediate topics. By Eidhof, Kugler, and Swierstra

[http://www.objc.io/books/fpinswift/](http://www.objc.io/books/fpinswift/)

No affiliation to the author/book.

</comment><comment><USER6> Shameless plug - I made a site that gathers resources for learning Swift. Will be adding this shortly :)

[http://www.LearnSwift.tips](http://www.LearnSwift.tips)

<comment><USER7> Cool. Bookmarked.

</comment></comment><comment><USER8> I like the style, brevity, and practicality of the book (at least the first few chapters; haven't read it all yet). Good stuff and good luck with it.

I did find the first few examples with the REPL to be a bit confusing. Were you using a function before it was defined?

<comment><AUTHOR> Thanks :) The REPL example with the error has a deliberate typo (int instead of Int) to show how multi-line editing works in the REPL - is that the part you're asking about?

<comment><USER8> I was referring to this:

$ swift Welcome to Swift! Type :help for assistance. 1> 3.14 * 2.5 * 2.5 $R0: Double = 19.625 2> println("The area of the circle is \\($R0)") The area of the circle is 19.625 3> 4> $R0 * 2 $R1: Double = 39.25 5> println("And double that is \\($R1)") And double that is 39.25 6>

What's Double? Trying to follow this (which didn't make sense to me because I didn't know the history stuff was there) simply caused error messages.

<comment><USER9> Isn't Double just a bigger floating point number?

<comment><USER10> Right. A double has twice the precision of a float (hence the name). It's also the default floating point data type in Swift.

</comment></comment></comment></comment></comment><comment><USER11> Slight tangent, but are there any recommended guides/books/videos for leaning the iOS frameworks with swift?

I have recently started programming on iOS with swift. I got my head around the language just not any of the frameworks, specifically UIKit.

<comment><USER12> I love the Lynda.com videos on Swift and iOS. The latest Stanford iOS course uses Swift and is excellent.

</comment></comment><comment><USER13> This is very helpful. Thanks for sharing! Great that it's free too :)

</comment><comment><USER14> This is fantastic, just what I was looking for, a very quick intro to swift that assumes I'm already a programmer.

The Apple docs, at least last time I tried reading through them, were like wading through treacle so this is a great alternative! I just read the first couple of chapters in 10 minutes and got all the key info I wanted with no fluff - great job!

One edit suggestion - I've noticed a couple of times so far that "it's" is used incorrectly, for example in this sentence:

> You can't change the type of a variable once you've declared it. It's type > is fixed at the time it is declared.

I assume you know the error here but on the off chance you don't:

it's = it is (it's a Bool) / its = the possessive of it (Bool is its type)

It's a little jarring so you might want to go through and fix these.

Cheers for the book! :-)

<comment><AUTHOR> Thanks for that - I'll fix the errors you've listed. I know how to use its and it's, and I've proof-read the book several times, but there's still a good bit of stuff like this that I've missed.

It turns out that it's really difficult to proof-read large blocks of text that you've written yourself :/ When your brain sees something it recognises it tends to speed up and skip over bits, seeing what it wants to see, thus missing stuff like this.

<comment><USER14> No probs, and great choice of model by the way, offering the web version for free.

For learning a programming language I actually prefer the web format to the ebook. Now I've figured out how useful this book will be by reading a few chapters, I'll certainly purchase a copy anyway, $12 is more than reasonable for the value this provides!

</comment></comment></comment><comment><USER15> In Chapter 4, you have a typo: "dynamicly" should be "dynamically"

<comment><AUTHOR> Thanks, fixed.

</comment></comment><comment><USER16> I love this. Btw, totally off topic : Is it possible to write iOS/OSX apps by learning Swift without the knowledge of ObjC ? My background : I know some Java/Ruby and do some Android apps.

<comment><USER17> It is, but you'll still need to learn about the memory management in objective-C (retain / release and such, although that's been made a lot easier over the years, pushing it back to being background knowledge) and - <USER2> more importantly than the actual language - the frameworks, environment and tooling (Foundation, UIKit, iOS application basics / lifecycle, view hierarchy, XCode, Interface Builder, and background knowledge like accessibility and such).

But yeah, go with Swift, it's closer to Java than Objective-C is.

</comment></comment><comment><USER18> Nice, I'm learning Swift from your site. The kerning for Chapter "10.4" is killing me though. Other than that I'm enjoying going through it. :D

</comment><comment><USER19> Have just started learning Swift. Have favourited, and will be sure to give some feedback once I've made my way through the whole thing. Good luck with it!

</comment><comment><USER20> Hi Aidan, your about Author section has a typo says'bulding' rather than building.

<comment><AUTHOR> Thanks, fixed.

</comment></comment><comment><USER21> Looks awesome! Thanks for your time I will definitely look into it deeply soon!

</comment><comment><USER22> Sorry, but this guide is not as comprehensive or updated as the official documentation [1]. Just compare the generics or memory management sections to see why you would want to read the official documentation. Maybe a high level tour of swift but you certainly are not going to learn swift with this guide.

[1] [https://developer.apple.com/library/ios/documentation/Swift/...](https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/)

<comment><AUTHOR> You're right - it's not as comprehensive as the official documentation, nor is it meant to be. It's a quick tour of the main language features, with a particular emphasis on the parts that I (as a ruby, python, clojure dev) found interesting.

For comparison, the Apple book "The Swift Programming Language" comes in at 334 pages. "Learn Swift" comes in at 128 pages.</comment></comment>


What Makes a Graphics Systems Paper Beautiful - <AUTHOR> http://graphics.stanford.edu/~kayvonf/notes/systemspaper/ <comment><USER2> Disclosure: Kayvon and I were office mates, and I've supported his research while at Google (and the wchrichton's research as well).

Amusingly, most of the papers highlighted come from industry experience / application. Part of this is self selection (Kayvon knows these people and these papers). But I believe an unstated component is one of the challenge of academic systems research: access to the seriously interesting challenges. Thus isn't specific to graphics, as many of my favorite papers from ISCA, NSDI, etc. are also industry-led backwards looking systems papers (though many, if not most, of the authors previously went to grad school).

Industry/Academia partnerships often produce the best systems work, precisely because industry can offer the challenge, while academics can step back and see how they might solve the problem completely differently. The natural tendency in most companies is to keep stringing along some small improvements that last you another six months. While it's true that every once in a while, someone does a big rewrite, they are often rare and for good reason. My favorite example came from a talk Jeff Dean gave at Stanford, where he explained you should design a system to scale 10x but not 100x, because by then it should be redone.

</comment><comment><USER3> I really appreciate these kinds of things because I think they help fields move forward in some cases.

Does anyone know of good ones for HCI papers?

</comment><comment><USER4> I was wondering how SIGGRAPH's "sexiness" paper criterion played out with all consequences, but never really sat down and looked into it, being satisfied with all the highlights and cool results.

Rejecting "systems papers" despite being valuable and novel definitely seems like an oversight this could produce. As "flashiness" is a key part of SIGGRAPH, I'm wondering whether there could be an alternative conference, or maybe a subconference that's as competitive/prestigious but is a bit more friendly to stuff like graphics systems?

<comment><USER2> Actually, that was one of the goals of High Performance Graphics. We explicitly merged the low brow Ray Tracing Symposium and Graphics Hardware, precisely so we could publish and discuss interesting systems-ey things that move the world forward but often aren't really broad or sexy enough for a general SIGGRAPH audience. I don't think there's a great way for it to be considered equally prestigious, but as an author you know (for better or for worse) that you'll have more sympathetic readership.

</comment></comment><comment><USER5> I read the title as "(Graphics Systems) (Paper Beautiful)" and was expecting something by Tufte or Knuth.

In retrospect, the plural on system should have collapsed that to "(Graphics) (Systems Paper) (Beautiful)" but I clearly wasn't awake enough.

<comment><USER2> Will (or the title submission adjustment system) removed the parenthetical around (Graphics) which would have been more clear.</comment></comment>


The general value of typed functional programming lies in leaving no edge cases - <AUTHOR> https://np.reddit.com/r/scala/comments/en89or/when_should_i_use_cats_scalaz_instead_of_standard/fdxer1k/ <comment><USER2> I came to a similar insight by the corollary: a sound type system makes the edge cases obvious. When we make the type of a partial function total by introducing an optional value as a result there's an opportunity to develop an intuition that this is going to make my code harder to reason about. Assuming I fix all the warnings about incomplete pattern matches I know that users of this code will have to handle all of the edge cases I'm introducing. Therefore I might take another approach and introduce a type as my pre-condition: the type of non-empty lists. You can't even call my function unless I can be assured there's at least one element in the input. I haven't even had to look at the implementation to reason about my code yet.

        head :: [a] -> a
        -- versus
        saferHead :: [a] -> Maybe a
        -- versus
        safeHead :: NonEmpty a -> a

The first function is _partial_ because we'll get an exception if we give it the empty list.

The second function is total but annoying to use because we're telling all the code that uses the result to check for two cases (it's an error not to).

The last one forces the responsibility on the _caller_ to provide a non-empty input.

That was probably one of the more frustrating aspects about learning to program Haskell as someone who has been programming for more than fifteen years when I started. It revealed to me in stunning detail all of the edge cases that almost every other language I've used actively hides from me.

It doesn't absolve you of having to think about edge cases: even Haskell throws run-time exceptions. However it does give you tools to think about many of those edge cases up-front and in a direct way.

 _Update_ Added a trivial example to demonstrate "partial," etc.

<comment><USER3> There's also another option in the middle which is a version that takes a value to return when the list is empty

        headOr :: a -> [a] -> a

which is similar to the Maybe solution but forces the caller to discharge the Maybe immediately rather than letting them potentially clutter up the rest of their code by proliferating the Maybe.

</comment></comment><comment><USER4> Forget the performance or the fancy memory management stuff, this is one of the best things about Rust: it makes you deal with edge cases by default (while allowing you to write code in a largely imperative or functional-lite style).

It's why I think it competes for market share with some of what is currently Java/C# and similar languages. A lot of people who use those languages care about correctness, and Rust is big step up in this regard.

<comment><USER5> This is also one of the problems with programming with exceptions. You lean on the fact that an exception will be thrown and just propogate up until it finds something, so the normal mindset of an exception-based programmer is to program for the happy-case and only vaguely think about what happens if it goes wrong. I know, I've written a lot of code in this style for many years myself.

In some cases, that's not a problem or it's even the best thing to do. However, you end up writing this way _all the time_ in an exception-based language, which is where the problem arises.

Non-exception based languages tend to throw the problems in your face and make them something you can't ignore. Which is not fun. But it is often what you need.

<comment><USER6> There's also the OTP model, where you have exceptions as well as a robust "something" up there. You don't have to deal with the minutiae, and the pattern (processes (aka, isolated processes) and restarts) lets you deal with known or unknown errors.

<comment><USER7> Right, but the OTP doesn't make you deal with the exceptions upfront, only to architect your app in the way that they don't crash or infect other parts of the system.

</comment></comment></comment></comment><comment><USER8> I am not sure this is the only value, but it is generally true. And this is one of the great advantages of haskell.

By the way, now that I know some haskell, I see this edge case sloppiness all the time and it is really annoying. For example, here is something that annoyed me just recently. You go to yahoo finance and there they will show you the revenues of a company as well as the revenue growth from past year. But sometimes this revenue growth number is not available. For example, the company may not have existed past year, or perhaps it was not public past year and thus it did not publicly disclose its revenues. When they cannot compute revenue growth for these reasons, yahoo finance will helpfully show revenue growth as "N/A", i.e., not available.

That seems all nice and logical, but I noticed that yahoo finance tended to show that revenue growth was not available for many established public companies for which they should have the data. I looked at it more closely and noticed with shock that if the revenue growth of a company was about 0%, yahoo finance would still show it as "N/A"! So some programmer just decided to use 0 as not available and just erased a lot of useful information from their system. Now when I see a company that has N/A as revenue growth on yahoo finance I have to go and check whether the revenue growth was zero, or it was truly unavailable. As I said -- really annoying.

This is of course a textbook case for Haskells Maybe concept. You can have a type that is a Maybe Int, and that means it have a value or it can be Nothing. Thus, you encompass the edge case of not having the value available, without using an embarrassing hack that deletes real data. But of course Haskell gives you more power than just using Maybe. You can create a type that can encompass all kinds of edge cases and information about them. For example, you can embed a reason why the revenue growth data was not available, if that is the case.

<comment><USER9> Ive noticed other languages with this feature, they call them optional types, you can pass in a null or a type value.

/s slightly, maybe more snarky, but seriously, optional types are way overhyped. Null objects are far more useful than optionals. Optionals tend to leak all over the show.

<comment><USER10> Nulls leak exactly as badly as optionals, except it's additionally impossible to tell where nulls have leaked to.

<comment><USER11> Actually, nulls leak worse than optionals, _because_ it's impossible to tell where nulls have leaked to (so you end up forgetting to filter out a null at a interface where you _would_ have decided to filter out a maybe).

</comment></comment></comment></comment><comment><USER12> They say that, and then turn around and show an example using IEEE-754 Doubles. You've got two infinities and two "not a number" values. What your type system thinks is a number isn't even necessarily a number. Maybe.

Better be sure to call the "isNaN()" and "isInfinite()" methods all over the place, because those are the worst edge cases of all and your language provides no help in detecting or avoiding them. It's like having 3 or 4 other None values, where they don't even use the same system as your standard Option type.

If I had a nickel for every time I saw "NaN" appear on a webpage or a web browser console log ... We throw up our hands and say, yeah, well, JS is terrible -- but no _static functional_ language I know of is any better.

<comment><USER13> Haskell is so much better, and you would learn that with about 5 minutes learning about the number types

<comment><USER14> Haskell's intro page starts with the infamous minimalist quicksort, which mishandles NaN!

[https://wiki.haskell.org/Introduction#Quicksort_in_Haskell](https://wiki.haskell.org/Introduction#Quicksort_in_Haskell)

<comment><USER15> How _should_ it handle NaN? It's not clear where an incomparable value should go when sorting.

<comment><USER12> Why is NaN even a concept in modern languages? We don't have a special "not a string" that all string functions return when they have no useful value to return.

<comment><USER15> Because it's part of IEEE 754.

<comment><USER12> So? There's lots of old standards that don't fit well with modern programming languages, so we abandoned them, or only use the parts that still make sense.

<comment><USER15> IEEE 754 is one of the standards like two's complement arithmetic which are widely used and have a number of clear advantages, so we continue to use them.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Paul Snively (the author of the linked reddit post) also gave a great talk entitled 'Typed FP on the Job - Why Bother?' at LambdaConf a couple years back, that spoke strongly to me:

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

> _And now you can do the most important thing you can do with any piece of > code... stop thinking about it! Go home! Pet the cat! Watch House with the > wife! ... I love Friday deployments ... you know why? Because I know what my > code is going to do before it runs!_

<comment><USER17> Interesting talk, but does that retry logic really provide me with more confidence about its correctness than equivalent impure code?

<comment><USER18> Thanks, and good question.

I deliberately didn't go into the specifics about the various typeclasses at play and their laws, and how those are tested. Part of that is just for reasons of time, but the more salient reason is that I wanted to show how those of us who do purely functional programming do it in practice. So if you watched the presentation, you saw that most of my thinking was about "OK, how do I elaborate from the most trivial transformation (do nothing at all) to the one I really want?" And that proceeds compositionally: I transform this value to that value. OK, does that value have the right type? No? What do I need to do to ensure that it does? And the transformation steps have some important properties, like their scope being entirely local. I really tried to emphasize this at the end with `attemptRepeatedly`: my description of each line of the whopping three lines is exhaustive. When I say there's no point in writing a test for it, I mean that literally. There certainly are typeclasses at play, and I briefly talk about the `Catchable` typeclass, and show the ScalaDoc for it, which documents an important law: the relationship between catching ambient exceptions and the algebra provided by `Catchable`. I rely on the other typeclasses and other laws in a similar fashion.

The other thing I think is pretty important is the part where I say "Let's look at cases," because the point there is that I can reason about the code by reasoning about the shape of the data it's manipulating. So if a `step` is an `attempt` of `p` that, if successful, `kill`s the retry `schedule` or, if unsuccessful, logs the exception, I'm still dealing with a `Process` of one element (by assumption that `p` will emit one element). Then `retries` will be a `Process` of 0 to infinity elements, because we put no constraints on `schedule`. So `(step ++ retries)` will be one or more elements, and because `step` `kill`s `schedule` on success, because `retries` is derived from `schedule`, `retries` is also `kill`ed. So `(step ++ retries)` is a `Process` that will emit one or more elements, with the last element being the first successful one, or the last failed element if none of the `retries` succeeds, so we take `last`. Then we just `fold` the failure or value back into a single effect, and we're done.

As I discuss in the presentation, there certainly are questions. What happens if the `schedule` is empty? What happens if the `schedule` is infinite? An attendee in Q & A asked a really good question: was I sure `retries` would wait before the first retry, or was the semantics "try, then wait?" (It really is the former, but that wasn't clear from my recorded REPL session.)

Of course, this isn't very impressive for a three-line example, although I think it's pretty striking that it only takes three lines, each of which can be completely reasoned about independently, to achieve a pretty significant operational goal. The point, though, is we can build entire systems this way, and in fact `attemptRepeatedly` is part of a distributed monitoring system I worked on at Intel Media/Verizon Labs, which is written entirely in this way apart from the monitoring types themselves, which present an imperative API for familiarity's sake (and which we later came to regret).

I hope this helps!

</comment></comment></comment><comment><USER19> Most languages rely on coding patterns for code safety. This is merely a _best practice_ , usually involves writing multiple lines of code, and is merely a convention.

Functional languages have many of these patterns already encoded into common functions, like map and fold. As functions their correctness can be considered mathematically proven. Would you rather rely on _convention_ or the compiler?

Consider adding on top of functional safety/correctness type safety with a functional language implementing a strong type system, like F#. Sure, F# is only functional first, not purely functional, and probably all type system have some sort of implementation edge issues. For most practical purposes you can consider the added level of type safety imposed by the compiler also to be mathematically provable.

<comment><USER20> What kind of mathematical correctness are you getting by using FP? The same kinds that the Rust compiler offers?

<comment><USER21> Different, but related. If you call 'map' then you know you're not mutating the values, and you get an output the same size as the input without dropping values, and...

It means you operate on a higher level of abstraction, and that inherently makes reading code faster. Not per line of code, but certainly per functional unit.

Idiomatic Rust tends to use a lot of functional code, and provides all the tools to make that safe. Its map function _could_ mutate the input -- it would be unidiomatic, but certainly possible -- except that, if you don't pass a mutable reference, then you're safe to assume it won't.

</comment></comment></comment><comment><USER22> I worked with Paul at a previous job and really enjoyed it. Such a great mind and passion for functional programming. Would love to work with him again (maybe in a different context).

<comment><USER18> That's unbelievably kind of you. Hopefully our paths will cross again!

</comment></comment><comment><USER23> Edge case removed:

       for i=0 to 10 {print(a[i])} vs for x in a {print(x)}

With functional programming it gets even better:

a.filter {}.map{print}

Pseudo code, of course. I list several "functional" examples in Swift here:

[https://github.com/melling/SwiftCookBook/blob/master/functio...](https://github.com/melling/SwiftCookBook/blob/master/functional.md)

Functional programming is also a higher level language. map, reduce,filter, flatten, flapMap, drop, take, zip, ...

Learn the concepts in one language and they can be used in another functional language.

<comment><USER24> While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

<comment><USER25> It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code that I need to stare at before I understand what it represents.

This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.

<comment><USER26> The problem with loops is that they are too powerful. They can do almost anything.

The functions map and filter are nice and restricted. If you want more power, you use eg a fold. And if you need even more power, you write a new recursive function.

So a quick look at the code will tell you what to expect.

<comment><USER27> Personally I've found that although this argument sounds good in theory, in practice I don't find loops harder to read than chains of combinators.

<comment><USER26> Which languages are you reading them in?

For me the argument holds in practice as well. I'm mostly reading my combinators in Haskell, and the loops in Python or some curly brace language.

If you use a general purpose combinator like mapAccumL that has almost as much power as a loop, you don't get that much extra readability compared to the loop.

It's still a bit better, because that combinator still has to process one element of your list for each run through it's "body"; and it clearly warns you by it's very name that it's not just a filter or map, so there's less possibility of confusing it for something simpler.

And, of course, not all loops are created equal. When applicable, for-each loops are much cleaner than classic C-style for-loops for example.

</comment></comment></comment></comment></comment></comment><comment><USER28> For me the value of typed functional programming has been it's ability to encode business logic in to the type system and thus validate some of my logic at compile time.

<comment><USER29> What's specifically functional about this advantage. Can't you encode the buisness logic into types in non-functional languages as well?

<comment><USER30> The word "type" has a fairly different meaning in functional programming compared to object oriented programming. At a very shallow level, they have some similarities. But the way they are used is vastly different between the two paradigms.

</comment></comment></comment><comment><USER31> OTOH it's nice to be able to do:

        try {
            // 500 lines
        catch (e) {
            return 4;
        }

<comment><USER32> Often, even functional languages have something similar, whether it's call/cc or something more cutting-edge like algebraic effects. All of these essentially augment the execution environment in various interesting ways, and are _enhanced_ by other features of functional languages like immutability.

(More pithily: try/catch is not inherently non-functional.)

</comment></comment><comment><USER33> I wonder, aren't there problematic edge cases that depend on the data? For example, if you are computing a plane from a given set of points, there may be an edge case where the points are collinear. Assuming you always need to produce a valid plane, this would require some numerical analysis and regularization. Or is the answer to define some new type system that captures the non-collinearity? If so, it seems like the costs of enforcing that could overwhelm things...

<comment><USER34> The answer doesn't necessarily have to be statically known, just ensure that the edge case _is_ handled. computePlane() can return Maybe<Plane>, where Nothing is returned in the colinear case.

This seems not that different from throwing an exception, except the caller can't accidentally forget to deal with the colinear case, there must be code to handle the Nothing case.

But perhaps the question you're asking is "but how can the writer of toPlane() know THEY did the right thing". There's of course no solution to logic errors (function subtract(a,b) { return a + b } will get by most type systems, short of having the type system re-encode the function itself, at which point it's just correctness through redundancy — unless both the type AND function are wrong!).

However, you COULD protect against future people breaking your implementation by doing something analogous time weak_ptr's implementation and flipping the Maybe to the input vs the output). So for example, you could make a type NonColinearSet, and have the "constructor" take a PointSet, but return a Maybe<NonColinearSet>, so asNonColinearSet takes a PointSet and returns Nothing if the PointSet is colinear, or NonColinearSet if it isn't. Now you computePlane() function can take a NonColinearSet and return Plane (not Maybe<Plane>) since it "knows" the input must be valid, so it can ignore edge cases internally, at the cost of the _caller_ having to deal with toNonColinearSet returning Nothing before calling it, since you won't be allowed to transparent pass the result of asNonColinearSet(pointSet) to computePlane since the types Wong match (Maybe<NonColinearSet> vs. NonColinearSet).

        maybeNonColinear = asNonColinearSet(pointSet);

        case Nothing: alertUserBadDataOrWhatever();
        case Just<NonColinearSet>: return toPlane(maybeNonColinear.value)

Notice in both cases, ultimately the caller must do something in the edge case, which is what you want.

</comment></comment><comment><USER35> Conversely, it's also one of the biggest pain-points when throwing together a quick prototype.

<comment><USER36> Then here's where typescript shines. To be able to move fluidly between no static checks of JavaScript and strong-ish type safety of typescript without too much work.

Then again, it's not always without hiccups.

<comment><USER37> That is where I think Flow really shines. Seems to be less hiccups, but that is just my anecdotal experience.

</comment></comment></comment><comment><USER38> Isn't that what also makes it hard to use __without __relying on the mathematical laws? While the math part is hard, it is what provides the strong guarantees in the form of laws.

</comment><comment><USER39> The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements.

I've seen this over and over in my career; tools can make people lazy in certain areas, it can put them on auto-pilot. Often, this can be a bad thing.

I like coding with dynamic languages because they get out of my way and shift the full responsibility for correctness on me. This creates a certain mental tension which helps me to perform. Keeps me alert and mindful.

I particularly try to avoid languages that make me wait for code to compile (which is more common with statically typed languages); this is for the same reason why don't like it when someone distracts me while I'm "in the zone" while coding.

<comment><USER40> Isn't this akin to saying I don't like wearing seatbelts because it makes me more complacent in my driving?

<comment><USER39> It could actually be the case that seat-belts make drivers more complacent but the key difference in the case of coding is that you won't die if you make a typo in your code. If designed correctly, your tests will catch it anyway.

<comment><USER41> Therac-25 [1] disagrees with your statement. Although to be fair, the programmer didn't die. The patients did.

[1] - [https://en.wikipedia.org/wiki/Therac-25](https://en.wikipedia.org/wiki/Therac-25)</comment></comment></comment></comment>


Most Company Culture Posts Are Fluffy Bullshit  - <AUTHOR> https://medium.com/evergreen-business-weekly/most-company-culture-posts-are-fluffy-bullshit-here-is-what-you-actually-need-to-know-1cf8597a5c2c#.flunkxjnw <comment><USER2> As opposed to this one :-)

Well it has some good points, I particularly resonate with the assertion that if you don't want to be like the CEO when you "grow up" you probably won't mesh well with the culture.

The other point was that if you are a leader, you _are_ the culture. Simply put, people will consciously and unconsciously follow your cues for how they should behave in "cultural" situations.</comment>


A $300M IT flop - <AUTHOR> http://fcw.com/articles/2014/07/24/it-flop-at-ssa.aspx <comment><USER2> You'd have leaner, smarter firms that could actually deliver something getting involved if the bidding process wasn't so obtuse and opaque.

When I was consulting, I responded to a few RFP's but they were always either (a) obviously tailored to the capabilities of a single firm so there was no way to win unless you were them or (b) so ridiculously vague or out of this world impossible ("We need you to basically rewrite GitHub for us and the budget is $30k") that it wasn't even worth the time. Even now where I work, we have to deal with government agencies literally telling us they can't tell us any requirements at all because that would give us an advantage over other firms somehow. We just have to pitch our product to them and hope that it fits, even though at this point in our development cycle we could (and really, want to) make adjustments, feature additions, etc. to fit them if we were allowed to.

Government contracting in IT, from my point of view, is nearly 99% about "playing the game" and about 1% actually delivering something. Especially since it seems that even if you fail spectacularly, you still get paid (possibly paid even more to fix your stupidity).

<comment><USER3> I worked for a company who provided a SaaS to a few private entities but also some very large state agencies, including an entire branch of the government. I remember sitting in a meeting with my boss and the owner of the company, while we _sat on the phone_ with someone from the procurement department of another agency while they crafted the bid to only allow us to compete. It was disgusting and they did nothing to hide it. The state employee (who knew the company owner socially) even mentioned the competition by name, along the lines of "if we require ______ then ______ won't be able to bid, right?"

<comment><USER4> Competitors _can_ bid, but will have generally worse answers for the specially crafted requirements. The competitors can either say "no, we don't do that" and hope that the committee doesn't mind, say "yes, we could do that" and see if the agency will pay extra for that special req, or say "yes, we do that" and build out that feature if they win the bid.

<comment><USER5> Eh, once i was at a startup where we were selling our mostly COTS software to a government agency, but they had to put it out for a bid. They basically lifted our marketing material into the req and said "software must do all <X> and cost $<Y>."

We had a competitor who had copied a bunch of our stuff, including our typos, but they were missing one essential feature. Yet they still got the bid somehow. A mystery for the ages.

</comment></comment></comment></comment><comment><USER6> Interesting quote from the article:

> 'You have companies like Lockheed Martin -- they're not web development > companies, they don't do work in the private sector, they're not building > start-ups,' Gershman said. 'There's very little in the market that forces > them to adopt new technologies.'

All of these are true, but I think this glosses over some fundamental structural problems with government contracting. The SSA has almost 60 million beneficiaries, and deals with distributing an entitlement that is extremely sensitive and protected by layers of legal process. 8,000 Social Security checks get lost,[1] and its not a blog post, its national news.

Moreover, a lot of lean and agile processes just aren't consistent with political reality. There's no minimal viable product, there's no invite-only beta testing, there's no iteration, there's no A/B testing, etc. Technical decisions ("let's just roll out to northern Alabama first") become divisive political ones. Purchasing decisions ("we've had good luck with this vendor before") become the basis for accusations of favoritism and corruption.

Perhaps most importantly, there's no failing fast. The private sector accepts the fact that many engineering projects will fail.[2] Good companies take care not to punish failure unreasonably. But in the public sector, failure is just license for those opposed to project to crow: "we shouldn't have been doing this anyway!" If you fail fast, it's easy to pin the blame on you. This creates a perverse incentive to drag a project along so failure happens over years if not decades.

[1] [https://firstname.lastname@example.com/how-bug-in-dropbox- permanently-...](https://email@example.com/how-bug-in-dropbox-permanently- deleted-my-8000-photos-cb7dcf13647b)

[2] Most big IT projects fail: [http://www.computerworld.com/s/article/9243396/Healthcare.go...](http://www.computerworld.com/s/article/9243396/Healthcare.gov_website_didn_t_have_a_chance_in_hell_). Most startups fail. Most internal prototypes never amount to anything. This is just how engineering works.

<comment><USER7> >>Perhaps most importantly, there's no failing fast. The private sector accepts the fact that many engineering projects will fail.[2] Good companies take care not to punish failure unreasonably. But in the public sector, failure is just license for those opposed to project to crow: "we shouldn't have been doing this anyway!" If you fail fast, it's easy to pin the blame on you.

This is not unreasonable. After all, projects in the private sector are funded by private funds. If you fail, you only waste your own money. Whereas public projects are funded by the taxpayer. When they fail, what's really happening is that taxpayer money is going into the pockets of some private company, but there's only a failed project to show for it. So yeah, of course the backlash is going to be much stronger.

<comment><USER8> In the private sector, investors provide capital that companies (and employees thereof) use to pursue projects. When the company fails, the employees are generally still paid (while some companies have employees who participate in profits / share risk with investors, it's rare for it to be a dominant form of compensation). Thus, the situation is more similar than you describe: if the projects fail, the investor/owner has paid out a lot of money to employees and vendors and is left with nothing.

The difference is that smart investors/owners are aware that the possibility of failure is inextricably tied to any attempt to excel, and allows people to try things that might fail in the pursuit of success.

In our current political climate (and probably in other climates as well), governments are dumber, and tend to drive their staff to manage towards over- safety and covering of asses rather than towards best outcomes.

</comment></comment></comment><comment><USER9> I have actually worked on the DCPS product as a former LM employee, so here's what I saw: there are two sides to the problem. The biggest problem is the number of stakeholders. Currently, each state has their own system to process disability cases, and each system has its own way of doing things. SSA & Lockheed are trying to consolidate these 50+ systems into one national system. Every state this product is rolled out in creates some new challenge to make it work the way the state's SSA office expects. Hopefully this new exec will have the power to make some decisions and say "no" once in awhile.

Lockheed has their own set of problems, mostly hinging on the contract they've signed with SSA. They are forced to hire a certain number of subs per their contract - hiring a percentage of subs is not unusual, but the level in this contract is very high. As such, the subs know they can force feed trash into LM. The resumes coming from the subs were complete bullshit. Things like "10 years of experience administering X", but then in the interview, you find out they know next to nothing. Especially bad with databases when you even try to ask them how to write a join. One meeting we had while I was still there was a "skills assessment" \- from 1 to 10, how well do you know X? There was no negative to this meeting, we just wanted to know who knew what. The number of "10s" in that meeting was beyond belief.

So sure, Lockheed may not have a lot of experience here, but that problem is exacerbated by the stakeholders and the contractors they are forced to hire.

<comment><USER10> Why are the forced to hire subcontractors, and a certain # of them? Do you know what the thinking is behind that?

<comment><USER9> The overall idea behind being "forced" to hire subs is that it helps promote smaller, local businesses. In the past this worked out very well, because the subs brought in some very knowledgeable people. I believe the old number was 25% of the people, and you could pull from anywhere. If you had a 20 person team, you could have 15 LM, 2 from Company X, and 3 from Company Y.

On DCPS, the problem is that LM is forced to hire 45% (FORTY-FIVE) of the subs through _one_ specific subcontractor. That company had a previous contract with SSA, and SSA liked them. Since the sub essentially lost their work with SSA to LM, and they know LM was contractually obligated to hire through them, they stuffed us with a ton of below average folks.

On the face of it, I agree with the idea of a large contractor having to sub out some of the work to the smaller players; it's just that LM overplayed their hand trying to get this contract, and got screwed for it. But that's another story on how LM management is trying to make revenue numbers for bonuses...

</comment></comment></comment><comment><USER11> It's still got nothing on the NHS £10bn IT flop...

I always wonder when I hear about these projects, where exactly has the money gone? It can't possibly be in hardware, that would make some of the biggest data centres in the world just for the NHS. I can't even see how it can be manpower, how many IT people can you get for £10bn? And surely if it were corruption, someone would notice so much money being squirreled away...

There's just no logical explanation behind these things.

<comment><USER12> gov.uk which had a great success, was done by hiring their own people to work on it. I don't see why anyone would think outsourcing is good for public projects.

<comment><USER13> I worked on a high profile government project that had five different vendors involved. FIVE. The inter-organizational management problems were astonishing. I'm pretty sure that by the time I left, managers actually outnumbered technical staff.

The biggest problem, though, was the lack of pushback. The government officials would ask for the moon, and the vendors would promise to deliver it. There was almost no one saying NO - the word that project most desperately needed to hear. Features outweighed core infrastructure reliability, so configuration management was a nightmare.

</comment></comment></comment><comment><USER14> _> 'The project was conceived to replace 54 separate components used in the SSA's disability determination system.'_

This is the bit that jumps out at me as clear indicator of the sort dysfunction that dooms projects like this more so than anything else.

It's indicative of a the classic exploding scope and fragmented responsibilities leading to an overall lack of accountability that unfortunately characterizes IT in and around Government.

Gershman seems to agree.

 _" If there's not strong leadership, problems arise with coordinating work between contractors, and there's no one person looking at the system as a single entity -- everyone is making sure their piece is done, and fulfilling their responsibility up to a certain point,"_

However, I'm not wholly keen on the the start-ups as a solution direction taken later. It's not that it's wrong, just beside the point unless the start- up savior is specifically targetting culture and process change as opposed to technical implementations.

The 54-armed kraken of a defined by committee project will drown and devour a fleet of confused start-ups lost in the mist of *BE requirements and contract mods just as readily as the Lockheed leviathan.

<comment><USER15> What I meant by startups is that in that world, there's market forces driving you to do things better, faster and cheaper. Not necc. that we need startups to solve the IT problems of government (although that could help), but that we need to create an environment where there's market forces pushing government contractors to do things for less people/less money and better results (which are all very, very possible).

</comment></comment><comment><USER16> This is business as usual in government contracting. The goal is not really to deliver working software - instead, it's multiple companies working together to figure out how they can maximally extract income from an entity with unfathomably deep pockets. It's layer upon layer of red tape sprinkled with the occasional sociopath just to spice things up.

The filthiest part is that nobody but the taxpayer is interested in things being more efficient. The government agencies don't really care because there is no real financial accountability. Besides, if they use up all their budgets, they just get to ask for more next year. And contractors generally have their profits limited to a percentage of the project cost, so their goal is to balloon the cost as large as possible.

For several years I worked on a very large government project. When you're sitting in a two-hour, 100 person, sprint review every two weeks and everyone is fucking off on their phones the whole time, it literally makes you question your sanity.

</comment><comment><USER17> The sad thing is not that the government pissed away $300M on this project; but that the prime, LMFS, will continue to get away with it because there are no penalties!

But the system is rigged that way: if you do decide to hold them accountable, you'll find that they have documented every little specification change that the SSA put in after the project was awarded. So now the blame comes back to the SSA. Both sides will point fingers at each other; the consultants on this project will laugh (on their way to the bank), and things will remain the same.

In other words: the system of contracting in place today is broken. From labyrinthine requirements to bid for one, to obtuse specifications to lack of oversight; it's one huge mess.

And the system is corrupt to boot. Primes like LMFS, etc. employ former employees of these agencies (and vice versa), so it's very hard for an outsider to break in.

</comment><comment><USER18> Pennies in an ocean:

[http://www.theguardian.com/commentisfree/2011/aug/03/nhs- dat...](http://www.theguardian.com/commentisfree/2011/aug/03/nhs-database- digital-disaster)

> ...final cost to be as high as £20bn, indicating a cost overrun of 440% to > 770%

</comment><comment><USER19> "For past 5 years, Release 1.0 is consistently projected to be 24-32 months away."

I have worked on project like this. Usually it's the sign of management failure (poor communication, poorly defined requirements, bad governance, inability to retain knowledgable employees) rather than technical feasibility. It's not like the software is pushing technical boundaries.

"Echoing McKinsey, Gershman said that without a strong leadership element, IT projects of this magnitude are almost doomed to fail from the start."

This is a big problem. Because employees know these problems will fail, the smartest avoid them like the plague.

</comment><comment><USER20> It's amazing to me how consistently government IT projects fail and how widespread the problem is. A simple google teaches us that this has been and still is a consistent problem for quite a lot of countries. Some with an incredibly strong tech sector (the US is obviously a prime example). Surely there must be a way to organize/orchestrate government IT projects in a way that improves delivery and risk management. And...300 million USD?

<comment><USER21> Scratch out "government" above - the overall failure rate of IT projects in _general_ is crazy. The difference is that private project failures don't get news coverage (barring utter disasters that bankrupt the company).

</comment></comment><comment><USER22> For more like this

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

[http://www.reuters.com/article/2012/03/14/us-manhattan- saic-...](http://www.reuters.com/article/2012/03/14/us-manhattan-saic- idUSBRE82D14B20120314)

</comment><comment><USER23> No wonder taxes are so unbelievably high. The FBI did the same thing a few years ago. [http://www.cnn.com/2005/US/02/03/fbi.computers/](http://www.cnn.com/2005/US/02/03/fbi.computers/)

<comment><USER24> Yes, it's not at all programs like the absolutely-crucial F-35 program costing $399B up front.

</comment></comment><comment><USER25> Feeding from the government trough is where people REALLY get rich. This is why Palantir is pretty successful, because getting in bed with the government means being able to feed off our tax money much easier at elevated prices.

<comment><USER24> > This is why Palantir is pretty successful

Ahhhh

</comment></comment><comment><USER26> McKinsey and Co probably charged the government a couple of million dollars to get some of its junior partners to write that report which eventually a senior partner signed off before golf and took the credit.

Says the cynic in me...

</comment><comment><AUTHOR> > Throughout the past six years, the project has been stuck in the beta phase. > According to McKinsey, "for past 5 years, Release 1.0 is consistently > projected to be 24-32 months away."

</comment><comment><USER27> Rather offtopic, but does anyone else find the dollar glyph in the header font jarring?

<comment><USER28> Now that you mention it, yeah it is... It looks like a lot of the symbols and punctuation characters in Garamond Pro are slanted with no logical pattern or reason. Would drive me nuts if I were using it.

[http://i.imgur.com/Cbd74Gq.png](http://i.imgur.com/Cbd74Gq.png)</comment></comment>


New genetic test can predict your chances of living to 100 - <AUTHOR> http://www.guardian.co.uk/science/2010/jul/01/genetic-test-living-to-100# <comment><AUTHOR> Interesting quote:

 _One intriguing finding in the study was that gene variants that raise a person's risk of disease may matter less than genes that protect against disease. The scientists found that centenarians had roughly the same number of high-risk genes as the rest of the population, but had more protective genes to cancel them out. The finding is important, because commercial genetic tests look only for genes that raise a person's disease risk, rather than reduce it._</comment>


Paul Allen's Living Computer Museum - <AUTHOR> http://www.king5.com/on-tv/evening-magazine/The-living-computer-museum--197366031.html

<comment><AUTHOR> The relevant section of the video is between 0:30-3:30. <http://www.livingcomputermuseum.org/></comment>


An interesting scroll effect - <AUTHOR> http://shtick.be/ <comment><AUTHOR> I am neither the owner of the site nor trying to promote anything, a colleague showed me the effect and wanted to share it here.

</comment><comment><USER2> Cool effect. Now let's hope no one will use it.

</comment><comment><USER3> This scroll effect is poor. There are better on the codepen.

<comment><USER4> There's always a hater; why not share instead.

</comment></comment><comment><USER5> I like it!</comment>


Night owls and early birds have different personality traits (2014) - <AUTHOR> http://www.cbsnews.com/news/night-owls-and-early-birds-have-different-personality-traits/ <comment><USER3> The description of night owls seems to be in agreement with my experiences.

It's also fucking hard to be a night owl. For me, this is the single biggest issue my bosses had with me in every job - because they can tolerate someone coming at 12:00 to work only for so long. I tried everything I could think of - sleeping longer, not sleeping, drinking shitton of coffee, not drinking any coffee, melatonin before sleep, adrafinil in the morning, winding down early with alcohol, winding down early with sedatives, etc. and none of it works - <USER2> can maintain the "early bird" schedule for at most few days, any longer and I'll be feeling miserable and sleeping on the keyboard - _and then_ my body will force me back to night schedule anyway, by means of sleeping through even loudest of alarm clocks, or suddenly crashing in the late afternoon and waking up at 1 AM, or something.

BTW. it's 04:17 for me right now, and I'm supposed to be at work in 5 hours. Wish me luck.

#HNTherapy

<comment><USER4> There are workplaces that can tolerate people coming in at noon. Took me years to find one, but they do exist. Keep looking :-)

<comment><USER5> In my experience, they are easy to find in the US:

Get a job at a company with East and West Coast offices at the East Coast office. Always offer to help on the projects and areas that have mostly West Coast resources and leadership.

</comment></comment></comment><comment><USER6> > In the study, researchers looked at the lifestyles and personality traits of > 700 Spanish psychology students from two universities. The subjects ranged > in age from 18 to 32 and included slightly more women than men.

This is a big deal - college students are not a representative sample of the general population when it comes to behavior. There are going to be confounding factors galore here; I can only hope the researchers took care to untangle them.

<comment><USER3> This may actually work for their benefit this time; college is the single time besides pre-school when a person is basically free to arrange the time however they feel like. Before college you have to be at 0800 in school, after it you have to be at 0900 at work.

<comment><USER6> That's a relatively reasonable critique on the face of it. On the other hand, work schedules tend to vary dramatically, particularly around social classes.

</comment></comment></comment><comment><USER7> Personally I've had periods in my life where I've went to bed at 9 PM and been up at 5 AM, but also periods where I've been awake til 5 AM and slept til 4 PM. So I don't really believe there is any such thing as morning or night persons, just excuses to not change your habits.

<comment><USER8> Isn't it possible that you are just more flexible to changing your cycle than others?

I need a lot of sleep - I'm very jealous of my coworkers that can stay up until 1-4 am and still be at work at 9. Meanwhile I need 8 hours of sleep minimum, or after 3 days I'm a zombie. Just last night I slept for 11 hours (no exaggeration) because I crashed after too many nights short of sleep.

I'm also a night owl - I wake at 7, and come night time I force myself to bed at 11 - I could be up for hours, but not if I want to wake on time, and while waking earlier would be great for my schedule, I can't just shift my 8-hour sleep window - I've tried.

It's possible that I and others with similar situations are just making excuses (and presumably that's true for at least some), but it's also possible that you are using your single experience to denounce others.

Please don't assume that because something is easy for you that it must therefore be easy for everyone, and that others that claim otherwise are just lazy.

<comment><USER7> > Please don't assume that because something is easy for you that it must > therefore be easy for everyone

But I didn't say changing my sleep cycle has been easy, and I didn't even say I've managed to do it by my selves. Or that I even would have healthy sleep habits at this moment. But depending on mental health, diet, exercise, employment vs studies. These things have made me have all sorts of sleeping habits, and my personal belief is that these outer circumstances has had much greater impact on my sleep then anything in my genes. And that's why don't like this idea of morning and night persons as it only enhances thee feeling that you can not change your ways.

</comment></comment></comment><comment><USER9> "Night owls" as defined by staying up late are more likely to suffer from insomnia. Groundbreaking research here.

<comment><USER10> Being a night owl is a matter of preference. Having trouble winding down and sleeping is a problem. You can have insomnia whenever your day ends.

<comment><USER11> If your day ends in the middle of the night, and your job doesn't cater to that, you have insomnia for sociological rather than physiological reasons, but it is insomnia just the same.

<comment><USER10> I don't have jobs with such requirements.

</comment></comment></comment></comment><comment><USER10> My wife and I just had a great laugh over this. The descriptions of night owls and early birds fit us perfectly. I gotta say that I love being a night owl :) And she loves being an early bird. But she's picked up some bad habits ;)</comment>


Climate Change: Rail Companies Sign Up to Flight Shame Movement - <AUTHOR> https://www.bloomberg.com/opinion/articles/2019-10-29/climate-change-rail-companies-sign-up-to-flight-shame-movement <comment><USER2> > Meanwhile, Deutsche Bahn AG hopes to attract 200 million long-distance rail > passengers by 2030, an increase of 35%.

Good luck with that. DB neither has the rolling material [0], nor reliable companies to build that rolling material [1], nor the infrastructure [2], nor the personnel [3] to provide reliable service for the passenger numbers of _today_. It remains a complete mystery how they will solve problems that have been decades in the making since the privatization _and_ increase their passenger numbers by 35% in just 10 years. To anyone who regularly travels with DB (and to much of their own, frustrated [4] personnel) these plans sound preposterous. It's exactly the same kind of growth- and revenue-oriented MBA daydreaming that brought the company down to the alarming state it is in today.

[0] [https://www.spiegel.de/wirtschaft/unternehmen/deutsche- bahn-...](https://www.spiegel.de/wirtschaft/unternehmen/deutsche-bahn-warum- es-der-deutschen-bahn-so-schlecht-geht-a-1247468.html)

[1] [https://www.wiwo.de/my/unternehmen/dienstleister/bombardier-...](https://www.wiwo.de/my/unternehmen/dienstleister/bombardier- fuer-bombardier-wird-die-lage- ernst/24372184-2.html?ticket=ST-66062673-KQbwmtQ2HyptCT2hbbYb-ap5)

[2] [https://www.handelsblatt.com/unternehmen/handel- konsumgueter...](https://www.handelsblatt.com/unternehmen/handel- konsumgueter/infrastruktur-der-sanierungsstau-bei-der-bahn-waechst- auf-57-milliarden- euro/24062516.html?ticket=ST-61031932-ajQNy40QZvHCtyfM1Z0g-ap4)

[3] [https://www.spiegel.de/karriere/deutsche-bahn- zugausfaelle-w...](https://www.spiegel.de/karriere/deutsche-bahn-zugausfaelle- wegen-lokfuehrermangel-werden-anhalten-a-1281562.html)

[4] [https://www.derwesten.de/wirtschaft/70-prozent-der-bahn- mita...](https://www.derwesten.de/wirtschaft/70-prozent-der-bahn-mitarbeiter- sind-frustriert-id4968216.html)

<comment><USER3> Those problems are solvable. If they focus on them all now they can get there.

There are several companies in the world making good rolling stock. There is a fairly long leadtime, which means they better be making orders today to get the rolling stock they need in time. Good rolling stock is of course a requirement to increase passenger count.

Infrastructure can be built and rebuilt. The know how exists in the world, it just needs money and a bit of time (the more money the less time)

These two need to start today. However some smart planning and priorities the places where the most gains can be had. Doubling ridership in a small but busy section is often easier than doing the whole system and can add up to 35% overall increases even though the rest of the system is slightly down. This could be doable in 10 years. (then you focus on the next small part of the system and bring that up, while continuing to keep service high on the first, and soon your network is useful)

People can be hired and trained. The right people will make it work. That is management, and maintenance, and operations.

They have 8 years to do the above: it typically takes 2 years for riders to respond to better service once it exists. It is a hard problem for sure, but if they have the money and will it can be done. That is a rather large if though, and I don't know if they do)

<comment><USER4> On the surface it seems like such a simple thing to make - a box on some metal wheels. Why is it such an accomplishment to make "good rolling stock?"

<comment><USER5> A house is a simple thing, being a wooden or brick box? A car is also a box on wheels? A rocket is just a metal cylinder? </sarcasm> \- could we at least try to think or research before posting the middlebrow dismissal?

A passenger rail car is more like a house or very large caravan. In addition to all the engineering below the body (wheels, suspension, vacuum brakes, coupling), you've got a large superstructure with windows, plumbing, electrics, HVAC, power-operated doors, and design considerations of accesability and crash safety as well as comfort.

They generally need a special site to be built on (unless you want to ship them by road, which can be done but is inconvenient) and some heavy capital equipment.

The UK built bus-on-rail conversions to cover a period of national poverty; the notorious "Pacers". They were uncomfortable and unpopular.

<comment><USER4> A house IS a simple thing - it is not the case that you only have a few companies in the world that make a "good one."

To me the thing that separates rail from cars or other vehicles is that they have the advantage of having railroads, and so I would think that they can make additional assumptions that cars can't. They don't need the steering column for example, or make too much fuss about differentials.

And yet, the fact that cars are commoditized, but there are only a few good rolling stock companies in the whole world makes me wonder what I am missing. Maybe the demand/volume is just so low that there is no opportunity to commoditize or create a huge market.

<comment><USER3> There is limited demand. Rail cars are expected to last for 30 years (with a couple significant refurbishments), and carry hundreds of people at a time over limited routes. Road cars last about 12 years (average as I recall), and carry only a couple people just about anywhere.

The result of this is society buys a lot more road cars than rail cars, and so there is a lot more scale and a lot more companies making them.

</comment></comment></comment></comment></comment></comment><comment><USER6> The emotions most people associate with environmental action seem to be shame and guilt.

I propose paying more attention to emotions and leading with different ones since emotions motivate.

The more I act on my environmental values, the more I feel joy, then community spirit and connection with people around me -- including taking the train to L.A. and back from New York. I see that joy in hundreds of conversations with world-renowned people on my podcast [http://joshuaspodek.com/podcast](http://joshuaspodek.com/podcast) when they act too (before they act they tend not to show joy or community -- action creates it).

I was more than successful when I lived contrary to my environmental values and felt happy then, but these emotions reach another level of depth and connection. They motivate me to act more, and achieve more of value.

Meanwhile, guilt and shame seem to disengage people who aren't yet acting -- that is, the people most important to influence.

Another emotion I find rising up with experience acting on my environmental values is disgust, the emotion I feel at the thought of a kindergarten teacher smoking in the classroom. It started from my picking up at least one piece of garbage from the ground each day and has spread to fast fashion, factory farming, flying, industrial food, and more.

I don't like feeling disgust, but if my environment merits it, I'd rather feel it to motivate me to act. I think it would motivate those not yet acting, as with smoking before, more than guilt or shame.

I propose working to connect environmental action with joy, community, and connection, and inaction with disgust. This is the first I've mentioned this idea so I welcome feedback.

<comment><USER7> Disgust feels close to shaming for me...or might lead to it. How do you keep those two separate?

</comment></comment><comment><USER8> This is valid for rail travel in Europe if the energy for electrified intercity rail is not sourced from hydrocarbons. The energy efficiency in MegaJoules per passenger-kilometer are about equal between rail and air. For freight, rail is much more efficient in MegaJoules per ton-kilometer, but passengers are a small percentage of a very heavy rail car.

In the US, other than the Boston-Washington corridor, intercity rail is diesel powered and travels at 90 mph max due to grade crossings of roads and streets and due to track curvature. To fix US intercity rail requires removing all grade crossings, realigning the railways to straighten curves and redesigning the roadbeds to support high speed operation.

<comment><USER9> Do you have any articles or studies where you can see the CO2 output pr passengers with train on diesel vs electric (sourced from various hydrocarbons) vs air travel?

It would be interesting to see actual numbers and you seem to have studied this a bit.

<comment><USER8> See page 14, 15 of "Energy Efficiency in Air Transportation" by Arturo Benito, Gustavo Alonso. Table 2.3 gives MJ/pkm for the US. Fig 2.8 next page gives ranges of efficiency for both passenger and freight.

[https://books.google.com/books?id=jJGZDgAAQBAJ&printsec=fron...](https://books.google.com/books?id=jJGZDgAAQBAJ&printsec=frontcover&dq=energy+efficiency+by+transportation+mode&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjrt9nIucblAhWEpFkKHRfvBFgQ6AEwAHoECAUQAg#v=onepage&q=energy%20efficiency%20by%20transportation%20mode&f=false)

Back when "peak oil" was a thing, I was in several discussions about what it would take to electrify the US transportation networks, both passenger and freight, but I have not worked in transportation planning. Hydrogen-fueled intercity buses will be much easier to implement than anything else, especially if they are autonomous to reduce driver costs.

<comment><USER9> Thanks for the source.

It only lists raw energy use and not greenhouse gas emissions though. I'm a bit surprised since the tables I've seen have train emission at the very bottom, but most of what I have seen is from Europe but we run diesel trains here in Norway too (in the north) and the tracks are not straight at all!

</comment></comment></comment></comment><comment><USER10> The greatest impact would be if the ship companies would join in. Imagine the carbon output reduction of a large chunk of air travel moved to the sea instead.

<comment><USER11> How long would a passenger ship take to get from Europe to the US today? Not like a lux cruise ship, but like a ship who main purpose is transportation. Does anything like that even exist anymore? I know cargo ships are an important part of world infrastructure, but those don't really do "civilians"

<comment><USER12> Current record is 2d 20h 9m for a passenger catamaran: [https://en.m.wikipedia.org/wiki/Hales_Trophy](https://en.m.wikipedia.org/wiki/Hales_Trophy)

</comment></comment></comment><comment><USER5> [http://archive.is/gQ7wY](http://archive.is/gQ7wY) to bypass the signup and private mode walling.

</comment><comment><USER13> How much does a transatlantic rail bridge cost?

<comment><USER14> Not really cost effective when you can just build a much shorter one across the Bering sea

Travel time from the British isles is a bit longer I admit but the route has been valuable for longer.

</comment></comment><comment><USER15> (In Europe). This doesn't have anything to do with the mostly freight and nearly passenger-useless rail network in the US.

<comment><USER16> In Europe private rail firms are eager to attract customers. In USA the government agency that is mandated by Congress to screw up rail travel is not so eager.

<comment> sneeze-slayer All of the European rail companies I can think of off the top of my head (Germany, France, Spain, UK) are owned by the government, so it is possible.

It seems like only in the USA is there the notion that the government is completely unable to function on its own.

<comment><USER16> Most European nations, and certainly the ones under discussion, are more democratic than USA. It isn't as though Amtrak is failing in the mission assigned to it by those who control Congress and the long-term bureaucracy. It is only failing to do what most USA residents would like it to do: make USA rail travel better, more convenient, less expensive.

I'm not saying that private firms in USA don't suffer the authority of TPTB, but they suffer it much less directly than most state-owned enterprises.

</comment></comment></comment></comment><comment><USER17> Funny since most electricity powering trains is made with CO2 generating processes worldwide. The only exception being maybe France because of very large nuclear power presence. For the rest, it is basically coal, gas and burning hydrocarbons to power trains.

<comment><USER18> This assertion is reductive and somewhat false.

Rail is the most energy-efficient method of hauling freight over land (where no water route is available), and electric trains are powered, on average, by whatever powers the regional grid. For countries besides France, such as the USA, Germany, or Norway, which get a sizeable portion of their energy from carbon-free sources, electric rail is a reasonably low carbon compared to trucking, and perhaps even compared to barge.

<comment><USER8> In the US, electrification of rail is very expensive, since bridges were not built to allow installation of overhead catenaries. Third-rail electrification is inefficient for freight and it interferes with operation of container well cars, e.g. in the Long Island Rail Road.

<comment><USER19> The usual solution for streetcars is to install a battery big enough to power the vehicle over the longest gaps. Is that unfeasible for trains?

<comment><USER20> Traction units throughout the trainset would mean only a subset of locomotion units are unpoeered at a time. Only very long bridges would require catenary refits.

Freight rail would require immense batteries.

</comment></comment></comment></comment></comment><comment><USER21> What a stupid fluff piece...

Meanwhile, somewhere in the 'Ruhrpott':

[1] [https://de.wikipedia.org/wiki/Kraftwerk_Datteln](https://de.wikipedia.org/wiki/Kraftwerk_Datteln) [2] [https://www.uniper.energy/de/datteln-4](https://www.uniper.energy/de/datteln-4)

a new coal generating plant for 'Bahnstrom' is being built against the law, the moving off of coal, with much corruption, while having a defective boiler, which cost them 210 Mio € so far.

Ha! YEAH! Paint it _GREEN_!</comment>


Tenzorum ripping off YC brand for ICO - <AUTHOR> https://tenzorum.org/<p>These guys aren't even in YC, but they happily put YC's logo on their website for ICO. Where can I report this? <comment><USER2> Probably best to email email@example.com. Thanks!

</comment><comment><USER3> I swear these ICOs now a days are getting even more scammy by the month.

</comment><comment><USER4> What, do ICOs scream "integrity" to you?</comment>


Revive the Postal Service by making it a bank - <AUTHOR> http://www.newrepublic.com/article/116374/postal-service-banking-how-usps-can-save-itself-and-help-poor?utm_content=bufferca014&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer

<comment><USER2> Most European postal services operate various degrees of banking services, and many operate full banks.

European postal services also have their own payment system - post giro. In some countries, post giro is or have been (being gradually supplanted by electronic payments) one of the most common ways of paying bills.

</comment><comment><USER3> The UK Post Office used to operate a bank - [http://en.wikipedia.org/wiki/Girobank](http://en.wikipedia.org/wiki/Girobank) \- it was reasonably good to start with (apparently, it was estabilished well before I was born) but a lack of investment and a terrible brand image sank it eventually and it was sold.

</comment><comment><USER4> As with most policies...sounds great on paper. Let's think about implementation....

1\. Who runs this bank? Ever deal with USPS workers? Yea...not great. What about the senior USPS leadership's management abilities? Oh yea that track record is borderline criminal. So we give them more responsibility and budget?

2\. Loans for reasonable amounts to high risk people. Why dont larger banks or startups setup operations to serve loans to the folks who rely on payday loans. Do you _really_ think that smart entrepreneurs have not thought about the $89B dollar payday loan industry? Of course they have and guess what -- they cant beat payday loan rates. Why are they so high? It's not gouging as much as it is matching the risk of non-payment to the loan. Low income folks already taking loans on their current paycheck are not the most reliable to repay the loan (for a larger amount) at a later date.

Overall, I am not against banking services to under served. I just have no confidence that the government can effectively become a (rather large) bank. Other government banking forays have not done too well (Fannie Mae/Freddie Mac anyone?)

Comparing other countries is hard as well...different cultures, scale, and needs muddy the water to do a real apples to apples comparison

</comment><comment><USER5> I'd rather we turn some banks into postal services, personally.

</comment><comment><USER6> This is working quite well for the swiss postal system. Amongst other services (notably: public transport and a business solutions division), PostFinance provides financial services. Out of 6 divisions, the financial one accounts for about a tenth of manpower, a quarter of revenue and 60 percent of profit.

Such a combination opens up awesome opportunities for supply chain and working capital management: merchants in e-commerce can offload great parts of their business: Goods are received and shipped by mail anways. If you throw payment in the mix, as a merchant, all you have to do is guide customers to your electronic checkout. Let the postal service worry about payment, storage and fullfillment.

</comment><comment><USER7> Same thing happened to the French postal service in 2006, with high hopes for _" a bank with the ethics of public service"_, but it quickly became exactly like any other bank: profit, profit, profit.

<comment><USER8> Completely disagree with nmc. They offer only basic (useful) services, don't touch investment banking at all, and in terms of success already contribute to a fair share of La Poste's overall revenues. Which doesn't mean they don't have room for improvement, to the contrary. To me, pegging a bank to postal services is a no brainer given synergies etc.

<comment><USER7> _> They [...] don't touch investment banking at all_

Disagree all you want, but please get your facts right. Yes, La Banque Postale is technically forbidden from directly speculating on the open market. However:

\- they can buy and own banks which are, in turn, allowed to speculate (cf. the Dexia bailout)

\- they offer revolving credits at extremely high rates (more than 15%), which is known to push people further into poverty

\- they can speculate on markets like the covered bond market (and actually need to, because the deposits are currently not enough to provide all services)

\- they can speculate on side-effects (eg shift by one day the payment date for social benefits)

(This list is not exhaustive. If you are too clumsy to find references by yourself, just ask, I will add some.)

</comment></comment></comment><comment><USER9> Italy has also slowly morphed its Postal Service into a financial institution. The Italian Postal Service allows to open accounts and issues credit and debit cards.

I can't judge the quality of the service as I do not live in Italy any longer, but I know that they have an advantage over 'normal banks': they stay open on Saturdays!

<comment><USER10> I live in Italy, and I would avoid anything and everything to do with Le Poste Italiane. I don't think their financial services are all that great either - the same long lines and unmotivated employees from what I can tell.

</comment></comment><comment><USER11> There used to be Postbanken in Norway too, absorbed into DnB with all operations shut down just a few years ago. Started in the times when it made sense, but rendered obsolete in online banking era.

</comment><comment><USER12> The Belgian Postal Bank is like that too: [http://www.bpost.be/en/index.html](http://www.bpost.be/en/index.html)

</comment><comment><USER13> We have a Postal Bank here in Israel. It's generally considered the most honest, but simplistic, bank in the entire country.</comment>


When will be the result out for Y Combinator? - <AUTHOR>

When will be the result out for selected teams for Interview @ Y Combinator?? <comment><USER2> <http://ycombinator.com/apply.html>

"2. On April 16, we'll invite the groups that seem most promising to meet us in Mountain View between April 26 and 30."</comment>


Mobissimo Has 1/223 The Capital Of Kayak (And Out Executes Them) - <AUTHOR> http://www.techcrunch.com/2008/05/23/mobissimo-has-1223-the-capital-of-kayak-and-out-executes-them/

<comment><USER2> I've tried Kayak and most of its competitors has always found me the lowest price except for last-minute flights where I was forced to use Priceline's name-your-own-price mechanism.

These were flights between Thailand-Chicago, Japan-Iowa, Iowa-Houston, and Houston-San Francisco. Maybe Mobissimo works better for European destinations?

</comment><comment><USER3> Kayak at least doesn't have a terrible name.

<comment><USER4> Kayak has a MUCH better name. Not only is it a plain english word, but it is also a palindrome.

<comment><USER3> It's pretty much perfect. What the hell is mobissimo?</comment></comment></comment>


The surprising, stealth rebirth of the American arcade - <AUTHOR> http://arstechnica.com/gaming/2012/08/the-surprising-stealth-rebirth-of-the-american-arcade/ <comment><USER2> I disagree, those are not arcades, they are bars and nightclubs that happen to have retro games spread throughout. I'm not taking my kids to a nightclub to play arcade games but one or two they mention would be worthy. Although it is nice to see interest in having arcade machines in some form so maybe it'll kick off interest in proper arcades.

From my experience, being someone that spent a great deal of time in arcades as a kid, that the arcade industry practically killed itself. True, consoles were a big competitor but there was nothing like getting in that line to put your token on the machine. Consoles is just friends having fun, arcades were friends and strangers competing. Totally different experience. But the arcades started dying when somebody had the silly idea that people wanted to play cockpit games or big interactive games for more than double the price. The next thing you knew those were the only choices you had. I stopped going at that point. This interest in the retro games that are classic standup machines seems to suggest people just wanted what they had in the first place.

<comment><USER3> I disagree with your arcade death reason by the 2x price. According to [1], arcades had started costing a $.25 USD since 1966. By standard rate of inflation of ~3.4% [2], that means it should cost approximately $1.50 USD today. One argument to this is rather the starting basis of $.25 is the right price. According to the same source, the golden age of arcade is ~1980. So for the sake of finding a lower optimal basis, let's assume that $.25 is the optimal pricing in 1980. Which means arcade games should cost ~$.75 to play today. Now the question becomes rather games should accept coins other than quarters so the pricing isn't such a steep step function, or game creators needed to start making games to justify 2x pricing. I guess they decided on the latter.

So I totally disagree with this assessment. I would say the consoles offering an alternative to arcade games at a reasonable price is the main reason. Yes, I agree with you that it's a totally different experience, but maybe not enough to stop going to the arcades when one can play for "free" at home or friends' house. This is the first step in killing the arcades. The second step is the internet and portable gaming/mobile as an alternate pastime for kids.

[1] <http://en.wikipedia.org/wiki/Arcade_game> [2] [http://inflationdata.com/inflation/inflation_rate/long_term_...](http://inflationdata.com/inflation/inflation_rate/long_term_inflation.asp) (not sure the credibility of the site, but I'm sure the average inflation rate in US isn't too much different)

<comment><USER2> I'm sure your right in many ways, but I'm talking about the day that I had a choice between a 50 cent game (up from 25 which I was fine with) to a $1+ game in the same arcade on the same day, not over time. The $1+ game did not seem to be twice the fun. Then one day the 50 cent game was gone and all I had to choose from were the more expensive machines.

At that point I stopped going.

Granted, this is my experience and should be taken as such.

</comment></comment></comment><comment><USER4> A bit sad that a reporter talked to the Insert Coin(s) guy, who's sort of a newcomer to the space but very successful, and didn't get a chance to chat with someone who's an expert in a similar space in the same city: visitors seemed to be coming in at a nice pace on our recent weekend trip to the Pinball Hall of Fame (<http://www.pinballmuseum.org/>). I don't see how they make any money, but they've got a great set of hardware and they obviously love their craft.

It would be awesome to see places like that and, say, Funspot Arcade grow financially so they could expand their offerings. Can you imagine how much fun it would be to hang out at the venue from "Hackers" (1995), but in real life? With a giant Wipeout game and stuff?!

<comment><USER5> I just visited Funspot in Laconia, NH a couple of weeks ago:

<http://www.funspotnh.com/>

It was great. All of the old games are lovingly maintained with a sign above them telling when they were introduced and how many copies were sold.

I was able to show my 6 and 8 year old daughters the original Pong game that I played when I was about their age as well as my later obsessions: Battle Zone, Asteroids, and Tempest. I guess I had a thing for vector graphics

</comment></comment><comment><USER6> This reminds me of a place near me Galloping Ghost (<http://gallopingghostarcade.com/>). If you're ever in the Chicagoland area, check it out. They charge an entry fee of $15 but all their games are on free play. Better yet, they let you come and go as you please for the entire day with that one purchase (so 11 hours of potential play time). They find and restore beat up arcade games as well as have a few PS3 in an arcade box with newer games (Mortal Kombat as well as Street Fighter). There is nothing like playing Mortal Kombat II for hours on end with a friend and then going to play NFL Blitz 99, NBA Jam and then back again. The best (and also worst) part is that there is no risk to play new games since they are all free (it is bad because you'll occasionally walk up to a game and have to either wait for the time to expire in game or just kill the character because somebody walked away mid game).

</comment><comment><USER7> One phenomena I've observed in some modern video arcades is the advent of homebrew or "faux" cabinets. An official Street Fighter 4 cabinet costs around $10,000. However, because the most recent home console version of SF4 is identical to the arcade version, it's possible to simply buy an Xbox 360, a display, and a pair of fightsticks (input devices with parts identical to what you would find in an arcade cabinet) and build a wooden shell to house them. Total cost? Less than $1000 for parts, plus labor for assembly. Most people can't tell the difference, and even those who can tell the difference won't care, because the software and input hardware are identical. This makes it far more economical for establishments to offer these options--at $1000, you might not even worry about turning a profit from usage fees, and could offer the game mainly as a service to patrons.

The other benefit of the homebrew cabinet is that it allows you to run any console game you please. Marvel vs Cacpom 3, one of the two most popular fighting games in North America, is actually home console only--there's no official cabinet, so homebrew is the only way to go if you want an arcade setup.

<comment><USER8> In the case of SF4, the official Arcade version of the game is just a PC running Windows XP embedded ([http://en.wikipedia.org/wiki/Taito_Type_X2#Taito_Type_X.C2.B...](http://en.wikipedia.org/wiki/Taito_Type_X2#Taito_Type_X.C2.B2))

</comment></comment><comment><USER9> Gaming is huge and growing. There are ways to make arcades work, it's just not a straight rehash of the 80s arcades.

Take gamecenterarcade.com in san mateo. You might not know it's there but it's full most days for various game specific meetup/tournaments. Turns out their niche is giving the community a space to exist. They mostly charge on entry instead of play, and it seems like most gameplay is done on consoles not coin- op.

<comment><USER10> I agree. Personally, the locations that I find really fascinating about the arcade revival are the ones like GC, Southtown, and Super Arcade that are primarily focused on being community centers.

</comment></comment><comment><USER11> Article doesn't mention it, but I think a lot of people were reminded of Flynn's by Tron 2, and thought to themselves, hmm, what a good idea...

<comment><USER12> Watching Tron:Legacy certainly made me want to open an arcade! I just don't have the capital lying around to do it. But, yeah, it sure seems that with the right touch, the arcade could be revived as a business model. I sure hope so anyway, I miss arcades.

I actually found myself wondering if Disney would be willing to license the "Flynn's" name to somebody... how cool would it be to walk into an actual _Flynn's_ arcade sometime? :-)

<comment><USER13> I think Disney uses "Flynn's" at one of their parks, so I doubt they would license it.

</comment></comment></comment><comment><USER14> Don't know how they managed to miss talking about Baby Castles in NY :

<http://www.nytimes.com/2011/02/13/nyregion/13joint.html?_r=1>

[http://kotaku.com/5670738/visit-a-place-where-it-is-ok-to- hu...](http://kotaku.com/5670738/visit-a-place-where-it-is-ok-to-hug-arcade- machines)

</comment><comment><USER15> I worked in an arcade as a young man and must admit that this exact thing is a back-burner dream of mine. As mentioned in some other HN posts, certain scenes from the Tron movies only fuel the fire.

Coincidentally, if you ever find yourself in Portland, OR stop by Ground Kontrol. 4 player Ms. Pacman, good beer, live DJ and the whole upstairs is wall to wall pinball machines. When I die, this is my idea of heaven.

</comment><comment><USER16> Is this all an American thing or is Europe seeing a similar revival?

<comment><USER17> Funland, in the Trocadero off Picadilly Circus (very much the geekiest place in London), closed fairly recently. I find it hard to believe there'd be a better place for an arcade in the UK, possibly anywhere in Europe, so it seems like a pretty bad sign.

The one big success story here is the namco center, which I think works on a pay-for-the-day basis; I've only known corporate days out there rather than people going on their own.

</comment></comment><comment><USER18> I'd like to think Caine's Arcade has picked up steam.

</comment><comment><USER19> Hah, we have a place near where I live called Dorky's Bar Arcade. It's no Dave and Busters, but it is fun.

</comment><comment><USER20> Arcades are cool, but they're too damn expensive. Make each game 5c and I'll play all the time.

<comment><USER21> I suspect that one of the major reasons why arcades are still viable in Japan but not the US is because each play costs 100 yen, well over a dollar.

At 25 cents a play, I suspect that most of these places make the majority of their profits from beer & food. If you're too cheap to pay 25 cents for a game, I suspect that you're too cheap to buy your food & drink at the arcade. If so, the arcades are probably glad they don't have your business.

<comment><USER22> Maybe I'm just going at all the wrong times, but any Taito Station pretty much hovers between 1-10% capacity (maybe 20% on weekends). I think they could certainly benefit from cheaper games, if only to give the kids on the way back from school a quick thrill with any spare coins they've got. Even making them 50円 would go a long way, since a 100 would get two games. I don't know about others, but I would never start a game if I only had one shot. Two tries, especially if a friend could go as well, would be good enough to draw me in to even the lamest pinball machine.

Note: I'm in Yokohama. I don't frequent arcades much so don't know about Tokyo, though I'll be in Diver City tomorrow to check out the ROUND1 (I heard it has a set rate for the facility).

<comment><USER23> I was just in Tokyo. Even during the daytime, the Taito Stations (at least in Akiba and Shinjuku) were over 20% capacity. And on weekenights and weekend evenings, particularly in Sinjuku, it was well over 50% of the machines in use. It felt more full than that, though, because there are lots of observers for whatever that 8-on-8 online mech game was and the new Hatsune Miku/vocaloid rhythm game.

Even the crane games are pretty heavily packed. My only major complaint, as an American, is that they reeked pretty heavily of cigarettes (though not as badly as pachinko parlors). It was like being taken back in time 5-10 years, back before major cities started mandating non-smoking environments.</comment></comment></comment></comment>


Drop.js — The most powerful dropdown library yet - <AUTHOR> http://github.hubspot.com/drop/docs/welcome/?hn

<comment><USER2> Could just be me, but the animation on the Share button feels like it takes a really long time which is making my OCD cringe.

<comment><AUTHOR> Thanks for the feedback!

It uses a lot of `transform: translate`s so it can jitter if your GPU is taxed (or if your CPU is taxed and your browser doesn't accelerate).

The duration is supposed to be 500ms though. I agree that's a little slow. I dropped it down to 360ms: [https://github.com/HubSpot/drop/commit/10d1b0b324c1538bc46ee...](https://github.com/HubSpot/drop/commit/10d1b0b324c1538bc46eef6efecc014905f37547)

Let me know what you think!

<comment><USER2> No problem. But I recommend you don't take my feedback too seriously. I rarely know what I actually want, and I change my mind all the time.

Also I was glad to see that your library knows how to handle quick successive mouse-hover/unhovers. That's an easy one to neglect.

Overall, pretty cool. Glad you're doing what you can to make the software world a better place :)</comment></comment></comment>