Why I Prefer Dynamic Typing Over Static Typing (2017) - <AUTHOR> http://www.smashcompany.com/technology/why-i-prefer-dynamic-typing-over-static-typing-the-speed-of-adapting-to-change <comment><USER3> > For the programming that I do, I am often creating new architectures. > Therefore I need dynamic typing.

He seems to consider static typing equivalent to "locking down" an architecture, that when you use static typing you're locked in to a certain way of doing it, and you're stuck with it. In my experience of working with large codebases with both dynamically and statically typed languages, the opposite is true.

Static typing frees you up to make changes to interfaces in a way that dynamic typing does not. For instance, if i want to add or remove a parameter to a function in a statically typed language, it's trivial. I just do it, and the compiler goes "ok, this function is called from these 4 places, so just fix those" and you now are assured that everything will work.

That doesn't work in dynamically typed languages. There's no reliable way to change an interface and be confident that you haven't broken anything (+/\- extremely good linters, but those aren't perfect in the way a compiler is). This leads to a "never change this function, you can break all sorts of things" attitude that simply doesn't exist with static typing, where the compiler can just tell you what you need to fix.

There are perfectly valid arguments in favor of dynamic typing (it's arguably easier, often faster to work with etc.) but this particular one is extremely silly. The exact opposite is true.

<comment><USER4> Good test coverage and test-first philosophy _can_ make this problem go away, but it always requires that you didn't make an error in your tests. I always found this argument bizarre: I write tons of tests but I know that I'm fallible, and writing such tests is time-consuming. Why not let a static type checker do the work for me, with less chance of error?

<comment><USER5> That's another reason I like (good) static types, it's a bunch of compiler- included documentation and testing that I don't need to write!

<comment><USER6> Also a good reason for defining and using the most specific subtypes possible. In some domains, "this arg is a string" is useless for validation or documentation because _everything_ is a string. Is it really a URL? a UUID? a serialized timestamp? a property name?

<comment><USER7> That's called something being stringly typed, and it's a code smell. You make URL classes, UUID classes, timestamp classes, enums, etc to replace the strings.

</comment></comment></comment></comment></comment><comment><USER8> > Static typing does not live up to its promises. If it did live up to its > promises, we would all use it, and the fact that we don't all use it > suggests how often it fails.

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

<comment><USER9> What a bizarre argument. You could replace "static" with "dynamic" and you would have an equivalent argument that would just as strongly (i.e., in fact, weakly) argue against dynamic typing. This logical hole is obvious enough to drive a bus through. I don't understand how the author wouldn't have noticed it.

<comment><USER10> The logical hole is not obvious. If it were obvious, we would all notice it, and the fact that the author didn't notice it suggests it's not obvious.

<comment><USER11> I guess this is what happens when everyone gets a trophy.

</comment></comment></comment></comment><comment><USER12> Written on chalk board:

I will not participate in Hacker News Static vs Dynamic typing debates.

I will not participate in Hacker News Static vs Dynamic typing debates.

I will not participate in Hacker News Static vs Dynamic typing debates.

I will not participate in Hacker News Static vs Dynamic typing debates.

I will not participate in Hacker News Static vs Dynamic typing debates.

Stay strong, Me

<comment><USER13> The problem with the debate is that it's all based on personal preference and anecdotes, all of which are subject to cognitive biases. What we really need is a proper study, but they are notoriously hard.

The debate fundamentally comes down to 'under what circumstances is the extra cost of working with a static type system worth it for the benefits'.

For a 15 line helper script of the sort I've just written, Python with its dynamic typing is (to me - a proponent of static typing) the fastest thing to work with due to the low overhead. To me there is a threshold of project complexity where the cost-benefit ratio flips. Is that actually true? Does that vary for all people?

<comment><USER14> > _What we really need is a proper study, but they are notoriously hard._

Here you go: " _A large-scale study of programming languages and code quality in GitHub_ "[0]. I've only read the abstract (are we OK on sharing sci-hub links? [1]), spoiler alert, according to this research some languages are more defect prone than others but the effect is small.

[0] [https://cacm.acm.org/magazines/2017/10/221326-a-large- scale-...](https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study- of-programming-languages-and-code-quality-in-github/abstract)

[1] sci-hub.se/10.1145/3126905

<comment><USER13> I'm aware of this study, and a couple of others. They are all only looking at one area of productivity though, because that's the available data. In this particular case, there's no indication of development time required to achieve that level of bugginess. Maybe in practice all projects do enough work to reach an average level of reliability, but then what's interesting is how much developer time is required to get there.

It's a total cost analysis that's interesting - and there's a lot of costs. Cost of development, how that varies depending on required time to market, cost of bugs (fixing them, and loss of sales due to customer reliability concerns), cost of complexity as software has to be maintained over time.

<comment><USER14> > _but then what 's interesting is how much developer time is required to get > there._

Yeah, good point. I read an old research where they tried to test the "productivity" offered by different languages, but then it became difficult to asses the experience of the different developers...

</comment></comment></comment></comment></comment><comment><USER15> > In a dynamic language I could simply work with a deeply nested data > structure of maps and lists, and I'd handle the casting at the very end of > the process. In a dynamic language, I could treat everything as a string > till the very end, and then cast to integers or dates or floats or strings > as needed. In a dynamic language, I could write the code faster, with less > errors, and with less code.

Nothing described is impossible, or even hard, for a statically typed language to do.

Perhaps I misunderstand them, but author seems to be under the impression that static typing doesn't allow for type conversions.

> In static-type languages such as Java, I'm forced to go with either #1 or > #2, and they are both bad options.

That's simply not true.

</comment><comment><USER16> I have experienced the same pain as the author many times, and, though I mostly work with Java by day these days, when possible I would much more happily reach for Python when I'm needing to hack on a REST API.

But I don't think this particular issue has much, if anything, to do with dynamic vs. static typing. It's mostly about how clean and elegant Python's way of handling JSON is compared to the black hole of viral enterprise-y overdesign that is Jackson, Java's _de facto_ standard library for dealing with JSON.

With Python, JSON is deserialized to, in essence, a dictionary that maps keys to values, where the values are either strings, arrays of values, or dictionaries.

With Jackson, it's exactly as awful as TFA describes.

But I can easily imagine a Java library where JSON deserializes to some "JSONEntity" type that can act as either a string, a list of entities, or a string->entity map. And then I could interact with that in the same loose, don't-force-me-to-worry-about-details-I-don't-currently-care-about way that I do in Python. Perhaps one even already exists. It doesn't seem a far-fetched dream - I've used similar libraries for other static languages.

TBH, I haven't looked, because, even if I found one, I'd still be compelled to use Jackson, anyway. Because Jackson has been around forever, and Jackson is now so deeply entrenched that nobody working in the Javaverse can even fathom life without it. Suggesting such a thing would be heretical.

<comment><USER17> Jackson supports a workflow like you describe.

[https://fasterxml.github.io/jackson- databind/javadoc/2.2.0/c...](https://fasterxml.github.io/jackson- databind/javadoc/2.2.0/com/fasterxml/jackson/databind/JsonNode.html) and related classes/functions.

</comment></comment><comment><USER18> I saw a talk by an npm developer who dismissed type checking as "just another kind of unit test" for your code (and advocated instead dynamic typing and manual unit tests). It bothered me enough to think about what was wrong with what he said long after the talk. I realized the difference is type checking takes the place of infinite numbers of unit tests: unit tests only assert an "exists"; type checking proves "forall".

The linked article, however, is a whole other level of incorrect thinking and drivel.

</comment><comment><USER19> "Static typing tends to be used in areas where legal regulations create needs that outweigh programmer productivity."

This is rather a broad generalization that doesn't seem accurate to me. It's at least misleadingly phrased if it's not intended to imply that this is the main reason or primary domain where static typing is used. Performance is a major reason static typing is preferred in many domains like games development for example where legal regulations are largely irrelevant.

<comment><USER20> I mostly use static typing because I don't want the intended behavior of the program to be described solely in my head.

<comment><USER21> That may be asking too much of a programming language not intended for AI.

What I see between each approach is tradeoffs. Which one has the net benefit may ultimately depend on personality, domain, and shop practices. It's one of those architectural holy wars that may never end.

<comment><USER20> I do the vast majority of my programming in Rust and Python. I love both of those languages, but the fact is, the problem that static typing causes me in Rust is that I have to write a lot more code, but it is all pretty much rote. The problems that dynamic typing causes me in Python is that I have to evaluate large chunks of the program to figure out what it means. These are totally different kinds of frustration, but I can put up with the rote stuff because it doesn't distract me from thinking, but having to question what the code I'm looking at can do requires much more creative thinking and detective work that leaves me less able to passively think about anything else.

They're both manageable, really.

</comment></comment></comment></comment><comment><USER22> Static typing is fantastic in a closed system. It's predictable and reliable.

My problem is nearly every type system breaks down when you try communicate with something outside of the closed system (e.g. API calls, 3rd party integration, etc).

An API returns an unexpected data type, Missing a field that's supposed to be required, Starts returning a number as a string because they changed their ID system, etc.

It always seems to end up in types where every field is optional - <USER2> the purpose of having types in the first place.

<comment><USER4> The API problems you cite aren't prevented in dynamically typed systems. If anything they are worse, because they could lead to silent failures, whereas a statically typed API statically checks and guarantees the contract. Contrary to what you imply, a statically typed API _can't_ return an unexpected type. That's an advantage.

> It always seems to end up in types where every field is optional

"Always"? Not by a long shot. These situations where this is the case can be isolated and dealt with explicitly. You may object to the explicitness but — again, for reasons of robustness — proponents of static typing prefer this.

<comment><USER23> > whereas a statically typed API statically checks and guarantees the contract

I didn't work much with static typed languages lately, so I'm really puzzled by your comment. If I expect an int in the age field of a JSON response and the server suddenly sends me a string, maybe with value "NaN", how do you check for that at compile time? I expect the program to either crash or manage the error at run time (try/catch, die-and-restart a-la-Erlang, etc)

Maybe JSON doesn't count as "statically typed API", but how many of them do common Internet services expose to the public? And how to we make sure that the server or any in between proxy doesn't misbehave and violates the contract?

<comment><USER4> There are different kinds of APIs. You seem to be talking about inherently dynamic ones, such as your JSON blob example. Of course you cannot statically guarantee their contents, which is why statically typed JSON layers provide ways of asserting a schema. Using such schema checkers is best practice even in dynamically typed languages.

Either way, you _need_ to handle such failures, both in statically and in dynamically type-checked languages. The only difference is whether the handling happens explicitly throughout your code or automagically by an API that gives you back a well-behaved object. And both of these ways are possible in both static and dynamic languages (but static languages tend to go for the latter, whereas dynamic languages tend to make you do the former).

</comment></comment></comment></comment><comment><USER24> It's a fallacy to think that all statically typed languages are the same, and all libraries in the statically typed languages are the same. It seems the author is making these fallacies. My experience programming C, Java, and Haskell---all statically typed languages---is vastly different.

</comment><comment><USER25> I parse a lot of JSON in surprising and inconsistent formats and what works best for me is to immediately sanitize the object (option 1 that they describe) so that the rest of the code that operates on it can stay consistent

I'm interested in what an implementation of option 3 would look like. Is it just some regex to find the relevant characters in the string?

<comment><USER26> If I'm lucky, for web stuff, I can just write a typescript interface definition or 5 to describe the JSON format, and suddenly I have working intellisense, protection from typos (after the first), etc.

<comment><USER27> That doesn't protect you from inconsistent input. You still may have to sanitize.

</comment></comment></comment><comment><USER28> I'd paraphrase as "for the case of consuming an external API, using generic maps and arrays is more useful than strictly 'decoding' the data to a type earlier than necessary". That kindof makes sense.

It seems a bit flame-y to see this as "dynamic typing is better than static typing", though. -- It's more of a suggestion that a technique like "cast to a type" where you don't need all the info in the type risks breaking when it doesn't need to. It's better to make fewer assumptions when relying on things you don't control.

If the external API changes, code breaks whether you were "dynamic" or "static". "Just change the code" is as applicable to code in either case.

That said, it's kinda weird that an API can be both unreliable enough as to not conform to a schema, but still reliable enough to trust the data you want to get out of it.

</comment><comment><USER29> > I have dealt with terrible APIs that were outside of my control. When I > worked at Timeout.com, we had to pull in data from Ticketmaster and also > Booking.com. These APIs were inconsistent, and they would change over time. > They also left out fields, so all fields had to be treated as an optional, > which it made it difficult to enforce a meaningful contract.

Wait what? Why would you ever work directly with the data that you grab in some foreign API? You map the data that you actually need into some datastructure of your own making, that you have control over, and that hardly ever changes - unless you want it to. So when the API changes (or even worse, you have to exchange it for whatever reason - it's foreign after all and not under your control), all you have to do is change the mapping process, and voilà, you're back in your own safely typed world.

</comment><comment><USER21> One thing that annoys me about static typing is that most of the CRUD programming I do merely martials data back and forth between the screens and database. Only a fraction is processed, or should be processed by the application.

Things like null-ability, base-type, and max length should be supplied by the database and therefore not echoed in source code per the Don't-Repeat-Yourself principle (DRY), unless a custom deviation is necessary.

If the screen validation needs to know such info, it can get a majority of it from the database dynamically. But, our stacks don't typically do this for unknown reasons, and thus we reinvent the field attribute wheel in app code.

I posted a question similar to this on HN recently: [https://news.ycombinator.com/item?id=19146439](https://news.ycombinator.com/item?id=19146439)

</comment><comment><USER30> All of your data structures have types, whether you declare them or not. Your code expects things to be a certain way, and if it's not, things break. Static typing just means that you annotate you code with your expectations so you can get some automated error and consistency checking.

Automation is good, right?

With dynamic typing, you need to _manually_ write more unit tests to get the same level of confidence. That's just not worth it for anything important.

<comment><USER31> > All of your data structures have types ... Static typing just means that you > annotate ...

 _Programs_ have (static) types, data does not. Static typing removes correct programs from the language. Try this in some ML-like language:

        let selfapply f = (f f) in
        let identity x = x in
        selfapply identity 42

If you transcribe this to (e.g.) Lisp, it will return the number 42. The program is short, simple, and safe, but well-regarded static type systems can't cope.

<comment><USER6> Any static constraint is likely to rule out good and bad programs. The tradeoff is how irreplacable those good programs are vs. how dangerous those bad programs are. "endofunction over either integers or endofunctions over integers (or over endo…)" is cute but I wouldn't lose a lot of sleep from underconstraining that domain.

</comment></comment></comment><comment><USER32> It's pretty obvious what you do if a field in a JSON object is optional, you use an optional type. Any good statically typed language has that.

</comment><comment><USER33> If real world API is as chaotic as he mentioned, how can he even know the data is trustable?

From his Java's example, I can't see how he can fix with dynamic language. He still needs to validate the API response and throw exception even he uses dynamic language. Unless he uses something like functional "Maybe", so he can safely process the response.

<comment><USER16> I think the crux of the issue is that the way formats like JSON and XML are typically handled in Java forces you to validate more than you need to, earlier than you need to.

It makes it very difficult to comply with Postel's Law.

<comment><USER4> > It makes it very difficult to comply with Postel's Law.

Not really, since "handling" doesn't mean "throw errors". But regardless, Postel's Law is often seen as a failure in hindsight. See the "Criticism" section on its Wikipedia page. In general you _don't_ want to comply with Postel's Law.

<comment><USER16> Handling _shouldn 't_ mean "throw errors".

But the whole process of creating Beans or immutable POJOs and then decorating them with annotations seems to invariably lead you down a path where, if you're dealing with a particularly hoary API, you've either got to create a ridiculous number of single-use DTOs to handle all the edge cases, or define a manageable number of DTOs that unfortunately also place more stringent requirements on the input data than are strictly necessary.

<comment><USER4> Well Java is just an incredibly bad poster child for static typing. But even in Java you can do better by using modern sum types. Defining a "ridiculous number of single-use DTOs" isn't actually a problem in languages that support this well (e.g. by allowing you to create anonymous tuples). But as you've said yourself: this only applies to "pretty hoary APIs". Why not take the opportunity to create a better API (through a wrapper, if you have no control over the original API)?

</comment></comment></comment></comment></comment><comment><USER34> Dynamic language proponents make the case about programmer productivity being better with dynamic languages. That may be the case but I have found that integrating systems where one system is coded in a dynamically typed language and others are written in statically typed languages is a nightmare.

</comment><comment><USER21> One thing that annoys me about static typing is that most of the CRUD programming I do merely martials data back and forth between the screen and database. Only a fraction is processed, or should be processed by the application.

Things like null-ability, base-type, and max length should be supplied by the database and therefore not echoed in source code per the Don't-Repeat-Yourself principle (DIY). If the screen validation needs to know such info, it can get it from the database dynamically. But, our stacks don't typically do this for unknown reasons, and thus we reinvent the field attribute wheel in app code.

(I posted a question similar to this on HN recently: [https://news.ycombinator.com/item?id=19146439](https://news.ycombinator.com/item?id=19146439) )

<comment><USER27> I am a big friend of static typing but I agree that there should be a better connection between the types in the database, the types in the programming language and the UI validation logic. Some ORMs help but I think this could be simpler.

<comment><USER21> ORM's have a big learning curve, especially troubleshooting, and tie your stack to an ORM brand. But the worth of ORM's are probably another topic.

I'd like to see a data-dictionary-driven approach where most of field info comes from a data dictionary, and only deviations need to be defined locally. (Or perhaps create and mark dummy columns in the data dictionary that are slated to be used for local customization.)

I suppose one could push a button and have static classes or definitions generated for the source code from the data-dictionary, and thus still have a statically typed system. It's still duplication of field attribute info, but at least it's systematic duplication.

I used to use systems/tools that integrated the database, business logic, and UI; and they reduced the amount of typing and code rework by a large amount. The multi-layered approach may give us cross-vendor flexibility, but at the cost of more code diddling to wire up the interfaces between all the layers. Layer independence seems to increase duplication of field-related info. Back then I could spend more time on requirements and analysis and less on code wiring and re-wiring. Now we waste too much time dealing with low-level repetitious grunt work.

</comment></comment></comment><comment><USER35> There is a good talk I just watched a few days ago on this topic: Static Versus Dynamic Typing [1][2], which listed the pros and cons of different typing systems, using racket and ocaml as examples:

[1] [https://courses.cs.washington.edu/courses/cse341/18wi/videos...](https://courses.cs.washington.edu/courses/cse341/18wi/videos/unit6/captioned/120-static- vs-dynamic-one.m4v)

[2] [https://courses.cs.washington.edu/courses/cse341/18wi/videos...](https://courses.cs.washington.edu/courses/cse341/18wi/videos/unit6/captioned/121-static- vs-dynamic-two.m4v)

</comment><comment><USER27> The best I can make of these discussions is that there is no oneand true answer. Some people prefer dynamic typing and some prefer static typing. I myself prefer static especially while I am developing something new because I feel I can be more aggressive in making changes because the compiler tells me immediately what broke. But other smart people feel the other way.

So I guess both sides are right but it's good to think about what suits you best and then embrace that.

</comment><comment><USER36> I type with two fingers. Would that be dynamic typing? :)

<comment><USER21> Only if you've had too much coffee.

</comment></comment><comment><USER37> > _Why I prefer dynamic-typing over static-typing: the speed of adapting to > change_

Funny, that's the same reason I prefer static typing.

> _In How ignorant am I, and how do I formally specify that in my code? I said > that I liked to add run-time contracts to a function as I better understand > it. When I first write a function, I may not know for sure how I will use > it._

Which is irrelevant. You still know that the "customer_name" argument to it will be a string and the "age" will be an integer, no?

> _For the programming that I do, I am often creating new architectures. > Therefore I need dynamic typing._

Non seguitur.

> _Consider dealing with JSON in Java. Every element, however deeply nested, > needs to be cast, and miscasting leads to errors._

Another bad argument. First, if you don't cast, and expect an integer like 55 but get a string like John, your program has an error. The difference is that in a dynamic language your program will continue to run doing stupid things instead of crashing in the miscast.

> _Given JSON whose structure changes (because you draw from an API which > leaves out fields if they don't have data for that field) your only option > is to cast to Object, and then you have to guess your way forward, figuring > out what the Object might be._

You can trivially have a JSON parser that returns a list of map of the 6-7 valid JSON types (maps ("objects"), floats/"integers", strings, booleans, null, arrays).

You don't need to deserialize to specific object structure/schema as is the default mode in some parsers, if that's what you want to avoid.

If you dislike the verbosity of getting nested elements in Java, that's a Java thing, not a static typing thing. Heck, it's very easy in Haskell (what with lenses and stuff).

With a language that supports Optionals and try or has a map index operator and list/map literals, it's more like JS or Python than Java.

If you just want to extract a deeply nested element, and not care what it is, but still use it, I'm not sure how that works.

Do you expect the object at e.g. resp["x"]["y"]["z"] to change types randomnly?

> _Static typing does not live up to its promises. If it did live up to its > promises, we would all use it, and the fact that we don't all use it > suggests how often it fails._

"Proper weight does not live up to its promises. If it did live up to its promises, we would all be on it it, and the fact that many are obese suggests how often it fails"

How about some uses of dynamic typing are for specific, constrained, use cases (e.g. glueing, quick scripts) and it increasingly breaks down with larger codebases and multi-developer projects?

Larger codebases and multi-developer projects either don't use dynamic typing (most huge projects the world relies on, from compilers to browsers, and from OSes, to all kinds of embedded hardware, games, desktop apps, etc, are done in one of C/C++/Java), and others (e.g. large websites) are moving towards some kind of types (e.g. Typescript and Flow).

<comment><USER23> > You still know that the "customer_name" argument to it will be a string and > the "age" will be an integer, no?

I've seen integers sent as strings and others as integers in the same JSON. Datetimes stored as strings in three different formats by the same application in the same column of the same table, etc. The real world is really messy. Writing a new program is definitely quicker with a language like Ruby or Python for me (especially Ruby.) Working with Java is like walking with a cast on a leg.

But you know, every project and every developer is different, that's why we are using so many different tools. The OP accounts for that in the "There are many arguments in favor of static-typing" paragraph.

<comment><USER37> > _I 've seen integers sent as strings and others as integers in the same > JSON._

You still need to know what they are in each case, regardless of dynamic vs static typing (it's a matter of whether the language has weak vs strong typing or overly accommodating coercion).

If you get an integer value as string for example, Python won't let you add it to another integer you got as integer. So you'll need to know what they are to treat them accordingly in your processing even in a dynamic language.

In such case, you can also read them as a variant type on a static language, that's eg. one of the 7 allowed types in JSON (you don't know whether a JSON primitive might be int or string, but you know it wont be suddenly a Date type or a Foobar instance).

</comment></comment></comment><comment><USER38> > The widespread use of PHP, Ruby, Python and Javascript suggest that dynamic > typing is useful. [...] If static typing lead to greater programmer > productivity (via a reduction in bugs) then corporate America would only use > statically-typed languages. But it doesn't.

Yes, that is why Java and C++ are such tiny unknown little used languages

<comment><USER21> JavaScript is mostly forced via Web "standards" and probably would fade into oblivion if not for browser ties. Thus, I wouldn't include it in such a list. (Not an argument for or against either typing party.)

<comment><USER39> Same for PHP. It owes its popularity to early 2000s webhosting providers where only PHP was supported for server-side processing.

<comment><USER21> All languages that have been around a while have warts. One learns to work around the rough spots.

</comment></comment></comment></comment><comment><USER40> Dynamic typing is great for partially implementing solutions to problems that you don't fully understand.

This isn't always a bad thing, because sometimes "any implementation of a product" is vastly superior to that product not existing, and works well enough, often enough, that any edge cases can be ignored safely.

</comment><comment><USER41> Maybe this should be called "Why I Prefer Dynamic Typing Over Java"

</comment><comment><USER42> I love both for different reasons and pick my flavor according to the size and complexity of the project.

Seems fair enough?

</comment><comment><USER43> I have three personal reasons to prefer static compiled over dynamic interpreted

1\. Refactoring. In, say, c++, you change a signature, or a member name, and your IDE provides you with a neat, comprehensive list of errors to fix, if you're even performing the change manually. Contrast that with python, for instance, and I have to rely on what appear to be heuristics if I use an IDE to propagate a change, or otherwise repeatedly hit run to change everything that I've broken, and pray I didn't miss any code paths that'll bite me later. Maybe I'm just not writing pythonic code, but I find it rather difficult to maintain large codebases in python for this reason.

2\. Focus. I realized that having a constant stream from a trusted linter makes it really easy to stay on task. I can throw out a bunch of scaffolding and then fill in the blanks based on the constant stream of errors, pre compilation. Sure, in pycharm I can run code analysis to get a list of probable errors, but given the nature of dynamic languages, there'll be plenty that's missed and plenty that isn't necessarily right, and not having a project wide linter in real time isn't the same.

3\. Understanding APIs and library internals. There is a TON of use information that comes for free with explicit static typing, especially for scientific/numerical code. In python I frequently find myself having to look up simple function use because arguments, names, and returns can be ambiguous. In a typed language, I know exactly what goes in, what goes out, and how to structure my data appropriately. The difference in coding speed is huge, and I don't have to run the code nearly as often to make sure I'm doing things right.

Why anyone would choose python for large projects eludes me!

<comment><USER44> > Why anyone would choose python for large projects eludes me!

"Mypy is an experimental optional static type checker for Python that aims to combine the benefits of dynamic (or "duck") typing and static typing." [0]

[0] [http://mypy-lang.org/](http://mypy-lang.org/)</comment></comment>


Greenpoint's Growing Taxi Graveyard - <AUTHOR> http://gothamist.com/2015/08/21/why_yellow_cabs_are_taking_up_all_o.php#photo-1 <comment><USER2> "When street cleaning ends at 1:00 p.m. dispatchers, mechanics, and body men pitch in to help Kiouvas get all of the cabs back onto the street—quickly, before neighbors' cars fill in."

That's just evil. Rushing out to fill public parking spots. I feel sorry for any retail business in the area who's customers are now blocked out by this yellow tide filling the street. Nobody likes parking meters, but this is why they were invented.

</comment><comment><USER3> > Asked if he's tried to rent a second lot for his empty cabs, Kodogiannis > said he hasn't been able to find one within walking distance.

If only there were some technology by which he could travel a greater distance quickly - perhaps something with wheels, or a conveyance of some kind that could meet him at a more remote lot, and carry him back to the dispatcher's office.

Sarcasm aside, here is a business dependent upon the common good of free curb- side parking, and saying, in effect, that they do not use the transportation method they provide to others to meet their own needs.</comment>


Reddit's Database Has Two Tables - <AUTHOR> http://nosql.mypopescu.com/post/30827026223/reddits-database-has-two-tables

<comment><USER2> No it doesn't. <http://news.ycombinator.com/item?id=4469092></comment>


How to Change Someone's Mind - <AUTHOR> http://blog.guykawasaki.com/2008/07/how-to-change-s.html

<comment><USER2> Marketing? How to win friends and influence people?

What's next on HN, dating advice? No, scratch that. It'll be how to 'hack' the perceptions of people so you can take advantage of them. I expect to see spam for Mystery Method here in short order. Swiftly followed by NLP and hypnosis courses.

Guy Kawasaki is undoubtedly a very bright individual, and I have even personally benefited from some of the advice given in his writings. But...not this. Not here.

<comment><USER3> I actually went to the site the read it. It is interesting. I saw the item about friendship. and it is in fact relies on citations from psychology to explain why people form friendships. Then it suggest if the observation from psychology is correct, then how can readers to use it as a double edge sword.

Sometime I feel even I know how to write code and build stuffs, but if I need to build something people wants, I need to gain insight into human psychology.

<comment><USER4> That may be, but this isn't the place.

<comment><USER5> Who made you the arbiter of taste and decorum on this board? This is a user- driven website; what is popular is what we want to be popular. Of course PG can do things like block Valleywag but if he gets too cavalier about it the users will go elsewhere.

<comment><USER4> earning the right to vote made me an arbiter of taste. this post is a link to blog post that is just a collection of links to actual content. if one of _those_ links contain an interesting proposition and research to support it, well then that might pique my intellectual curiosity.

</comment></comment></comment></comment></comment><comment><USER6> On a related note, what's happened to Guy's site? There was a time I treated it as a reference for its useful advice on pitching VC's, public speaking, avoiding stupid mistakes... today it's all short-form, link-heavy posts, at least half of which are explicit self promotion.

I like Guy, but it's sad to see the way things have changed. Where's the meat?

<comment><USER4> steak/sizzle

</comment></comment><comment><USER7> Theories about persuasion: <http://news.ycombinator.com/item?id=249087></comment>


The antidepressant reboxetine: A headdesk moment in science - <AUTHOR> http://www.scientificamerican.com/blog/post.cfm?id=the-antidepressant-reboxetine-a-hea-2010-11-30 <comment><USER2> Well all they did is discard all the results that showed it didn't work in order to make billions in profit while causing life threatening side effects. No harm, no foul.

Not as bad as that guy Wakefield, who mentioned that one of the patients had an odd formed head, but didn't make enough of a deal about it.

<comment><USER3> This isn't being taken lightly as you seem to imply, the scientists responsible for this are a bit screwed career wise. Wakefield got more attention because of the massive damaging effect he and his ilk had on immunization rates.

<comment><USER4> _the scientists responsible for this are a bit screwed career wise_

What, the companies they worked for are just going to hang them out to dry? Not likely, not if they want scientists to keep distorting results for them. The scientists responsible for this might not have the admiration of their peers, but they'll be securely employed.

<comment><USER5> A bit of a nit, but once you distort a result, I think you lose the right to call yourself a scientist.

<comment><USER4> And yet they will look like scientists to us unless and until someone happens to shine a light on them. Something to keep in mind.

</comment></comment></comment></comment></comment><comment><USER6> Since no one else has mentioned it: it's not just this antidepressant whose effects have been (at best) exaggerated, but pretty much all of them.

[http://www.huffingtonpost.com/irving-kirsch- phd/antidepressa...](http://www.huffingtonpost.com/irving-kirsch- phd/antidepressants-the-emper_b_442205.html)

(Apologies for linking to huffpo, but the article is by the guy who did the definitive survey of the research.)

<comment><USER7> In addition to Kirsch's book, I'd also recommend Anatomy of an Epidemic. It does a really good job explaining the biological reasons why SSRI's _can't_ work. (Plus it also outlines all of the different reasons why the science behind them is fraudulent, same as Kirsch.)

<comment><USER8> I'll recommend Whitaker's book, too.

You can check out some of the original scientific studies he cites on his website, though it of course makes more sense with his context <http://robertwhitaker.org/robertwhitaker.org/Depression.html>

<comment><USER7> Good call. His blog is also phenomenal, but it would probably be difficult to fully understand unless you've read his book first.

</comment></comment></comment></comment><comment><USER9> Questions I don't see being asked:

* Can/should we be testing anti-depressants on animals at all?

* Is it possible that depression in animals is different than depression in humans? (i.e. animal tests are useless)

* Is it possible that lab conditions affect the psychology of the animal? (i.e. who won't be depressed spending your life in a cage, especially for larger animals like chimps, but also for social animals like rats which are undoubtedly caged individually)

Some of these are fundamental questions that call into question the validity of _any_ tests, yet it seems like the community in question is more concerned with 'finding the right tests' within a framework that they assume to be correct.

<comment><USER3> > _Can/should we be testing anti-depressants on animals at all?_

Would you prefer we test these things on humans? Scientists must put everything pass an ethics committee, testing on animals isn't ideal but the alternatives are far worse.

I have a vegetarian friend who works on vaccines, he doesn't like it but every now and again he injects a couple of hundred mice with something and a period of time later does them in for testing. He does it for the greater good, and it is done as humanly as possible.

This whole thing has been done to death (pardon the pun) and there isn't an alternative. If we want to save human lives we have to accept sometimes some small furry creature is going to lose it's squeak.

Cosmetics on the other hand . . .

> _Is it possible that depression in animals is different than depression in > humans?_

Mentioned in the article that the tests on animal models of depression need re-evaluating.

> _Is it possible that lab conditions affect the psychology of the animal?_

See above.

<comment><USER10> _Would you prefer we test these things on humans?_

Yes. I would prefer we test all drugs on humans as soon as volunteers can be found and the researcher thinks it would be beneficial.

I am assuming a volunteer free from political or even financial pressure, doing it out of desire to help. And possessing great and detailed knowledge of the side effects and both the known and potential dangers. I admit this is a bit of a straw man.

There are two reasons I want this.

1\. Political. I am a libertarian and and thus think that if an adult wants to jump off a bridge they should be fully within their right to do that. The same goes if they want to test completely unproven or even fully known to be unsafe drugs.

2\. Practical. This would speed up research tremendously, it would speed things up by years. We would save more lives.

<comment><USER11> _And possessing great and detailed knowledge of the side effects and both the known and potential dangers._

How, precisely, would you propose that the participants in the first ever test of a drug obtain such knowledge?

<comment><USER10> Just assume there is a 99.9999% chance it will kill you. Many people would still take the chance to make a difference.

</comment></comment></comment></comment></comment><comment><USER12> Tests referred to in the article:

Forced Swimming Test <http://en.wikipedia.org/wiki/Behavioural_despair_test>

Tail Suspension Test [http://www.stoeltingco.com/stoelting/productlist13c.aspx?cat...](http://www.stoeltingco.com/stoelting/productlist13c.aspx?catid=2592&home=physio)

<comment><USER6> I can't help feeling that there must be ways for us to find our way in this world without torturing other living things.

<comment><USER13> Indeed,

 _"Wait, and ponder how there is noting quite so cute as a mouse swimming..."_

It seems a little disturbing that the model for which drugs humans should receive should be "how well does it make animals seem to perform when we torture them"...

</comment></comment></comment><comment><USER14> This is not directly related to the post. But gauging that this topic will attract readers knowledgable about antidepressants, I figured I might get an illuminating response.

I often read that a side-effect of a antidepressant is heightened suicidal feelings. That completely mystifies me. Isnt it exactly what it is supposed to be working against ?

<comment><USER15> Antidepressants motivate people to improve their lives.

One obvious way to do this is suicide. If your every moment of existence is painful, suicide is an immediate improvement.

It's the motivational aspect that seems to increase suicide - motivation turns people's lethargic depression into a more active form of depression where they find the will to carry out their desires.

A common desire among the depressed is the desire for death. Your typical depressed person however is too depressed to even exert the energy or thinking necessary to end his life.

<comment><USER13> This may be one explanation of the phenomena but there are others.

For example, some anti-depressants disrupt REM sleep, creating a phenomena akin to a waking dream and thus making individuals less sensitive to finality of their actions.

<http://en.wikipedia.org/wiki/Antidepressant#REM_Sleep>

Also, the most dangerous time for suicide for a person on anti-depressant is when they suddenly stop taking them - as happened to a good friend of mine. It is hardly the motivational quality that gets people going at that point.

Edit: suicidal _AND homicidal_ feelings are "rare" but all-too-common responses to anti-depressants and _especially to withdrawal_ from anti- depressants. I've had friends who had both responses in fashions that are at least very unexpected. Anyone with loved-ones taking such drugs, be on your guard.

<comment><USER16> Seconding the sentiments on withdrawal. I went off Citalopram cold turkey due to an incompetent doctor (who incidentally had not informed me that it was a dependency forming drug). I have never, ever felt that shit in my entire life, and hope I never do again.

If you ever launch into a profanity-laden tirade at the top of your lungs in public because a car was inching forwards at a red light, you might also be going through withdrawal.

Tip for those who want to avoid this: Fluoxetine. Switch to it before quitting, it has a really long half-life so you can just stop taking it, and the levels in your body slowly tail off. Much nicer.

</comment></comment></comment></comment><comment><USER17> Reboxetine never helped me with depression, but I excelled on the forced-swim test after my doctor prescribed it for me.

<comment><USER18> You're joking - but that's actually an EXTREMELY interesting question.

Would humans on Reboxetine do better on a forced swim test? Because if they do, but they are still depressed then that's clear evidence that the forced swim test is worthless.

On the other hand if it has no effect, then humans are different from animals and don't react the same way to drugs, but the test may still be good.

<comment><USER19> There is no way you could ever do a forced swim test on a human. You would be sent to prison for a _long time._

You'll have to go back to the earlier half of the 20th century to see research like that.

<comment><USER20> Perhaps not a forced swim test, but having a human swim in place (or tread water) for as long as they can. In a swimming pool, with people around to rescue them if they stop swimming and start drowning, and being removed as soon as they give up by ... I don't know, going over and grabbing the edge of the pool? Or making some unambiguous hand gesture, or yelling a safe word, or whatever. I'm not entirely sure how valid the results from this would be, but there's also controversy over forced swim tests with rats and mice, so it would probably be just as accurate.

</comment></comment></comment></comment><comment><USER21> I have experience with all kinds of antidepressants, targeting serotonin, dopamin and norepinephrine.

The norepinephrine one isn't directly changing my mood, or reducing my fears, but it's definetly increasing my drive, in a kind waking me up.

Perhaps my depression isn't "typical", because it seems mostly originating from an affection of the pituitary.

</comment><comment><USER14> Ineffective modification of an existing drug as a means of extending the validity of a patent is a widespread practice. This was possibly not the case here. But given that we are tolerant of such practices and defend them, it comes as no surprise to me that an established drug on the market has no effect on the symptom that it was meant to address.

<comment><USER22> How does it follow that _questionable patents derived by making small changes to existing drugs_ leads to _drugs that have no effect_? I think that's begging the question.

<comment><USER14> I think you got me wrong. I didnt say that questionable patents lead to drugs that have no effect. Infact if you read it again you will find that I explicitly pointed to that possible misinterpretation.

My point was that in an environment where it is possible to extend the duration of a patent by adding modifications to the parent molecule that are known to have no benefit, it does not surprise me that a marketed drug has no benefit either. My point was about my lack of surprise, not a cause and effect relation.

<comment><USER22> The entirety of your comment:

" _Ineffective modification of an existing drug as a means of extending the validity of a patent is a widespread practice. This was possibly not the case here. But given that we are tolerant of such practices and defend them, it comes as no surprise to me that an established drug on the market has no effect on the symptom that it was meant to address._ "

I only see your explicit admission that the first situation ( _questionable patents derived by making small changes to existing drugs_ ) might not even apply in this case. You do not "point" to a "possible interpretation", you were breezily suggesting a lazy and fallacious connection.

Privileges granted that you disagree with are a different matter than scientific dishonesty. We could remove the whole issue of chemical-tweak patents on drugs by allowing perpetual drug patents, or by ruling that new drugs must be chemically different to some particular _degree_ to not be covered by a patent (expired or not), or by abolishing drug patents entirely, and none of those solutions would imply _anything_ as to the efficacy of future drugs or the trustworthiness of drug research.

<comment><USER14> I still dont see where I made the connection that you ascribe to me. Nevertheless if such a connection is indeed visible in my comments, thats probably my lack of native english skills showing. Suspecting that my comment might be misinterpreted, I attemped to prempt that. Apparently not very effectively. So let me try again:

We are tolerant of, or inadequately vigilant of ineffective drugs. One such sign can be seen in a particular apect of the patent system I described. Given this environment, it does not surprise me that a particular drug was found to be ineffective.

Your downvotes came with an explanation, which is better than silent downvotes.

</comment></comment></comment></comment></comment><comment><USER23> Fuck antidepressants. I was on 'em, and I went off 'em of my own volition because I _knew_ they didn't bloody work (and made me tired besides).

Wanna cure your depression? There are two ways.

1) Change how you think. Most of the time it requires conscious effort on your part, sustained over months or years; although if being poor has you depressed and you win the Powerball, that can give you an instantaneous new outlook. Cognitive behavioral therapy has proven vastly more effective than any drug.

2) The route Bill Zeller took. For some people that's their only way out of misery and suffering, and the rest of us need to learn how to respect their choice on an individual and societal level.

</comment><comment><USER24> > Whereas drugs like citalopram and fluoxetine primarily target the > neurotransmitter serotonin, reboxetine targets the neurotransmitter > norepinephrine.

I'm curious if this might be effective as an ADHD drug. This is essentially what Strattera does: <http://en.wikipedia.org/wiki/Atomoxetine>

</comment><comment><USER25> I think I was prescribed Edronax in 1999 for a very short while. The side- effect was knocking me out and caused me to sleep for 20 hours a day... I stopped very soon with them.</comment>


An Interview with the Mad Fientist: Programmers and Early Retirement - <AUTHOR> https://triplebyte.com/blog/refactor-your-finances <comment><USER2> Some quotes that didn't make the final edit (but that I liked):

 _On being extreme with finances:_ Personally, I'm pretty extreme. Every time I spend money, it's like the worst case scenario. So much thought process has gone into it beforehand. It's like, "Could I get it used? Could I borrow it? Do I really need it? Do I really want it?" And then, if all those things happen, then it's like, "Okay. I'll buy it." And then, I try to find it for the best price.

 _On the new iPhone:_ You don't need a new iPhone every year because, guess what? That iPhone 9 only made you happy for what, maybe a few weeks? And then, it was just a phone again until the iPhone 10 came along and you were like, "Oh, that's gonna make me happy." What's important is realizing that about yourself and looking at past purchases, thinking, "Oh, I spent a lot of money on that thing. Did it actually make me happy for very long? Could I have gotten it used instead? Did I need it at all?"

 _On favorite languages /frameworks:_ Ruby on Rails, definitely. I just fell in love with it, it was so much easier to get something built that was actually robust and it didn't feel like it was just gonna break, compared to all the .NET stuff I was doing before. It just made me love programming again, and I still use it to this day. I've built all my custom Mad Fientist stuff with Ruby on Rails, and it's just so easy to put something together, deploy it to Heroku, and then you've got something that's usable. That's exactly what I did for the FI Laboratory. I just threw that together and threw it up on Heroku over a couple of weekends. I always expected to make it nicer and better, but I just never touched it and now it's got 60,000 users, and it's just absolutely crazy, and I'm still hardly paying anything: $29 a month I think.</comment>


Parse Live Queries - <AUTHOR> http://blog.parse.com/announcements/parse-server-goes-realtime-with-live-queries/ <comment><USER2> Wait. Wasn't Parse shutting down?

<comment><AUTHOR> The hosted Parse server was deprecated, but it's all now open source so you can host it wherever you want. [https://github.com/ParsePlatform/parse- server](https://github.com/ParsePlatform/parse-server)</comment></comment>


Do VCs really add value?  Founders say sometimes - <AUTHOR> https://medium.com/@fritjofsson/do-vcs-really-add-value-founders-say-sometimes-f27bb956eb8c <comment><USER2> I think it changes a whole lot based on _who_ you work with.

In my experience it seems like 75% of VCs are neutral. They try to be helpful, aren't really, but don't get in the way, and their cash is green. They can email me two times a day if they want, it won't help me any more (and will be annoying).

10% are actively harmful. Either they have really bad advice, are a distraction, or try to lead your company down bad paths.

15% are incredibly helpful (maybe the 10% and the 15% should be switched), and you should do whatever it takes to work with them. They can think through problems instantly, see 15 steps ahead, understand where you are and what you should be focusing on, know everyone, and actually put in the work. I've been _shocked_ at how helpful some VCs can be in eliminating most of your biggest problems. It's just rare that happens.

That's why I'm surprised to see how little "track record" was valued. With few exceptions that's my #1 consideration when deciding who to take money from, or perhaps #2 begind "reputation."

<comment><USER3> The big question is whether the 10% that are bad and the 15% that are good are consistently bad and good. If for some companies the bad are good, and vice versa, then it pretty much boils down to speed and terms. The rest is a crapshoot.

<comment><USER4> I was part of a YC company that died due to our CEO following well meaning, but bad advice from VCs and advisors - it was a consumer _technology_ play, but all the advisors had made their money opening online shopfronts. So, we burnt time trying to find consumers, and the product and service languished.

<comment><USER5> I suspect it's mostly not a matter of some VC/advisors being good and others being harmful across the board, but rather the appropriateness of a particular VC/advisor for a particular business. The Dunning-Kruger effect is probably very much in play: someone who has been successful with one kind of business may tend to overgeneralize the applicability of what they learned.

</comment></comment></comment></comment><comment><USER6> One interesting thing I've learned as a technical founder is that the difference between lame business people and great business people is actually just as big as the difference between lame engineers and great engineers, if not bigger. Great business people and investors will give you actionable insights, lame business people will give you generic business advice that will waste your time.

<comment><USER7> Financials/execution/governance are surprisingly similar to programming. You have to have a solid overall design, and a bug-free implementation.

A great architect creates frameworks and structures that enable less- experienced people to be productive as well, while simultaneously making many of the typical errors impossible.

In a typical startup, the "business guy" is responsible for both the business insights, and the actual running of the corporation. On the other side of the fence, the technical finder is responsible for the product ownership and implementation. Both parties would benefit from reflecting on the similarities.

One of the big ones for me was realizing a "business visionary" who can't create a cash flow forecast is about as useful as an enterprise architect who can't code fizz buzz. It's not exactly in the job description, but being useless at the implementation almost always makes you useless at the design too.

</comment></comment><comment><USER8> Speed is one of the most underemphasized traits of a great VC for founders. While fundraising, a quick yes is the best answer, but a quick no is the second best. Investors who follow this are truly founder friendly: it's easy to stall and wait for more data, but it's actually helping the entrepreneur to just say no. Those are the investors I want to pitch again later.

It's no surprise founders rank speed highly while investors don't. Find investors who care about speed and you'll find a great partner.

<comment><USER9> _> It's no surprise founders rank speed highly while investors don't._

There may be some nuance missing in the slide.[1]

Based on the article's text, that right column should actually be subtitled _" what VCs think the founders rank as most important"_ instead of _" important to VCs"_.

The left side is self-reporting (founder's ranking). But the right side is a "Theory of Mind"[2] exercise (what VCs think founder's ranking would be).

I'm not a VC but it seems to me that that "network/rolodex" should be higher rank than "speed". I wonder if founders rank speed above "rolodex" because many startups' bank accounts are near zero and they can't make payroll next week if the VCs drag their feet. Financial duress scenarios like that during fundraising may make founders overemphasize "speed of a deal" to the detriment of other more important factors.

[1] [https://cdn-images-1.medium.com/max/800/0*VvTVys39uVMHqtbZ](https://cdn- images-1.medium.com/max/800/0*VvTVys39uVMHqtbZ)

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

<comment><USER10> At least anecdotally, I don't hear much from founders who are that close to zero. In my experience, speed is important because slowness drastically increased cognitive load and somewhat increases risk during fundraising. And also because fundraising is a distraction from why they got into it.

One way to think about it is in terms of a graph of number of VCs they have to think about/deal with at once. They're going to start the fundraising process with a list of firms, people, etc. Let's say that each week they take on n new items. If it takes 4 weeks to get an answer, they're juggling n*4 balls, many of the conversations in different states. Complexity goes up and/or throughput goes down. It's painful.

I suspect for entrepreneurs speed it also code for clarity, in that the "vc no" (and specifically the "California no" [1]) often present as slowness when it's really about something else inside the VC.

[1] [http://ross.typepad.com/blog/2005/04/the_vc_no_and_t.html](http://ross.typepad.com/blog/2005/04/the_vc_no_and_t.html)

</comment></comment></comment><comment><USER11> There is severe bias in this study. Are entrepreneurs going to really come out and say what they really think? After all they need the money.

Why weren't the institutional investors/LPs surveyed to see what they think of VC/GP value add? I think this would be more telling about who the good/bad VCs are ..... who's bringing home the bacon across the board consistently. A bad VC may do well with one investment, get great feedback from that founder but yet destroy investor capital on all other investments..... meaning the LPs are down on the money they put in.

The Kauffman foundation produced a great study of return performance from VC/GPs back to LPs several years ago. The conclusion was that investing in VCs produced very poor returns. The Russell 2000 index was a superior investment alternative.

</comment><comment><USER12> The problem with this study is that there are only two agents: founders and VCs. And whatever credit does not go to VCs implicitly goes to founders.

They did a study of married (heterosexual, this is an old study) couples and asked them what % of the housework each did. The percentages always added up to over 100%, and in some cases a lot over.

There were many reasons why people attribute their own contributions to be greater than that of others.

This just seems to be the same phenomenon on steroids.

They should ask the founder how helpful the VC is compared to the banker, or the advisor on the board. They should perform other sorts of comparisons to add context.

Consider that VC may be performing functions that are useful but are not properly appreciated, for instance, signalling.

Edit: Also consider the VC contribution of raising money and then staying out of the way.

</comment><comment><USER13> My perspective from the VC side is similar to Austen's ([https://news.ycombinator.com/item?id=17284114](https://news.ycombinator.com/item?id=17284114)): a lot of VCs are neutral, some are very helpful, and others are destructive. I've seen this dynamic from both talking to founders about whether they find investors helpful, and from sitting in on board meetings where other investors are present. The best way to understand what kind of investor you're talking to is to reach out to a handful of founders they've worked with and ask them about their experiences.

A few other observations from my 5-6 years so far in VC:

* Founders spend 3000 hours/year focusing on their business and domain while investors spend 3000 hours/year learning about hundreds of business and hundreds of domains. As a result, >95% of the time founders know way more about their specific business than their investors. On the other hand, >95% of the time investors know more than founders about cross-business strategies and ideas. So investor advice is best when it's related to their broader perspective: what kind of recruiting channels work best for the 50 companies they work with? What are tips for negotiating a contract? What are good pricing strategies? How early do companies typically hire a VP of Eng? Most investors won't be helpful for domain-specific questions like "will power plant operators really want this feature in my SaaS product?" or "what's the best marketing channel for reaching power plant operators?"

* Even for a single investor, their helpfulness will vary company to company. My guess is that if you polled the founders I've worked with, 1/3 would say I'm very helpful, 1/3 would say I'm somewhat helpful, and 1/3 would say I haven't helped much. I hope/think none of the founders would say I subtract more than I add. Sometimes it turns out I can help a lot, like if you're looking for a VP of Eng and I know a great candidate who is looking for a job. Other times I can't help at all, like if you want to be introduced to power plant owners and I don't know a single one. I do my best to help when I can and stay out of the way when I can't.

</comment><comment><USER14> I've seen both sides of it now, and can definitely attest to having a great experience with the Flybridge team. From intros that have turned into sales, letting us crash in their office multiple days a week to save on office space, or sharing their WeWork credits so we could book some conference rooms for free. They do things the right way, and are just a really enjoyable team to be around. They've been instrumental in helpful us grow during our first year of existence, and we wouldn't be as far along had we not chosen to work with them.

But, the point of "sometimes" is still a valid one. So, be selective if you are looking for someone who will be more than just a check.

</comment><comment><USER15> I regularly go from hating VCs (DHH style) to thinking that they are pivotal in creating categories that didn't exist before. A charismatic founder with a strong vision and supporting VC can indeed change the world (hopefully to the better)

<comment><USER16> I have a hard time understanding why capital is needed.

For apps, a single person can build a major app in a year.

For products, tooling is often between 50k-1M. Everyone here is a software engineer or similar, so that money isnt hard to make/save.

Can anyone explain? Advice + support is extremely valuable, but I dont quite understand why so many startups go this route.

<comment><USER17> _" a single person can build a major app in a year"_

I believe this is false by at least two orders of magnitude. Particularly if _major_ means high scale, with properly researched and designed to your customer, with proper support for users/customer, with proper infrastructure technically, financially and legally wise.

I am all for bootstrapping business and have as role models the likes of DHH more than VC-funded founders. But that doesn't mean I don't understand the need of capital.

<comment> barry-cotter WhatsApp is proof that they're off by at most one order of magnitude. I'm sure others can come up with solo founders who made really impressive things. Plentyoffish and Minecraft come to mind as not necessarily immensely technically complex but having created huge amounts of value as one man shows.

<comment><USER17> WhatsApp raised VC capital. I dont know about Minecraft

</comment></comment></comment></comment></comment><comment><USER18> VCs (and investors in general) in my experience are money and a headache, but the money is super useful.

<comment><USER19> Hmm... I will disagree there. Yes it can be challenging but the thing to keep in mind is that a good VC will come with a lot of experience and a lot of contacts that he/she will leverage in an attempt to make you successful.

</comment></comment><comment><USER20> For me, the value I'd get from an investor would be industry contacts. I'm self-taught, haven't worked anywhere big, and grew up in a not-very-techy part of the country. For the side-projects I have brewing that would potentially be businesses, the value of investment capital pales in comparison to getting my feet in the door to show off my work to people who might be interested.

That's a data point of one, and VCs are dealing with . . . uh, everyone but me. So I'm not making a blanket statement about what value should be. But that's what I would find useful.

</comment><comment><USER21> "Founders rank speed as their 3rd most important criteria and VCs, in fact, ranked it as the least important one."

This disconnect represents a significant opportunity for new VC firms.

</comment><comment><USER22> The article says this

"VCs ranked top 3 criteria they thought the founders evaluated them on."

Then the supporting chart is labelled "most important factors for partnering or making investments"

Which is it? Were VCs asked about what they believe founders value, or what they find important in making investment decisions?

Because the article points out track record is rated low. Which makes sense for the former but makes zero sense for latter, so I'm guessing chart was just mislabelled.

</comment><comment><USER23> Most VCs are running a lifestyle businesses (ironic). I'm going to guess that some of the larger platform VCs are pulling the numbers up so remove those and the picture becomes much more bleak.

</comment><comment><USER24> Ohh, yeah!!

The value they add is called "money". They give you it every single time(you work with them), not sometimes.

If you expect them to babysitter you, mentor or friendship, from my point of view it is your expectations that are wrong.

You should find emotional support elsewhere. I recommend masterminds.

I am friend and colleague of old VCs of mine. But I did not expected from them in the past more than a professional relationship.

This is probably what makes a good friend or a lover , not being too much needy and dependent.

</comment><comment><USER25> This doesn't seem that surprising, most of these companies are "failures" - seems to stand to reason that many of these founders would cast some blame on the VCs (perhaps for not continuing to support the business when it was clear that it was not working).

Also not surprising is the that VCs overestimate their value.

Lastly founders probably have a much more diverse (and perhaps incorrect view - probably fostered by the VCs) of actual value add of VCs.

</comment><comment><USER26> It's a broad mix. My unscientific (small) sample has been that the best advice came from the most famous VCs from the largest firms. (It surprised me, but I guess their fame and fortune were well earned)

I've also seen extremely helpful late stage strategic investors who brought great customer introductions.

My view is that things deteriorate when the CEO ceases to be honest with the investors, or when the investor is out of their natural element.

</comment><comment><USER27> I wonder what the value of the Personal Chemistry factor is.. it sounds like just a meta-feature in this study that would be highly correlated/anti- correlated with the other features. I.e. if a VC isn't as strong on the Deal Terms as the entrepreneur would like, it would negatively impact the Personal Chemistry. The link between Personal Chemistry and value add isn't clear to me here

</comment><comment><USER28> I have to wonder, about the different levels of reported contact, how much is actual VCs over estimating how much they contact they have with companies, and how much is that the VCs who actually responded to the survey were possibly atypical, like the ones who contact the companies less frequently are also less likely to fill out a survey

</comment><comment><USER23> If a founder focus on terms instead of value add VCs then we shouldn't be surprised that most VCs are not all that helpful.

</comment><comment><USER29> What would the value add be of getting the money faster or with less stress vs. the value add talked about in the article? I'm thinking that perhaps security tokens may change the dynamic in the future because they allow a founder to raise seed money faster with less unfavorable conditions.

<comment><USER30> Fundraising is a distraction. A founder who is engaged in fundraising finds it difficult to focus on their actual business. Being able to get back to the business quickly therefore provides a very obvious value proposition for the founder.

VCs have the rather different requirements. People looking for their money is an ongoing activity for them, so there is no particular advantage in ending that dance with any particular founder. Indeed, not being in a hurry to make a deal when the other side is improves their bargaining position. (Unless someone else is faster.) And the more likely they are to hear about a showstopper that would make them decide to not invest.

The result is that VCs want to drag negotiations on as long as possible..right until the moment that it is clear that some other VC is leading the investment and their possibility of getting a piece of the action is slipping away.

This is why what YCombinator does works so well. They decide very fast on whether you're in a batch. They standardize terms, which makes it harder for investors to drag their feet. And on demo day, every investor knows that they are competing with other investors in an investment round that will close quickly. This forces them to make a go/no-go decision.

Interestingly, the fact that founders get to raise money quickly and get back to their business improves their businesses odds of survival. Which improves the prospects for investing in them.</comment></comment>


Just finished reading Rework by 37signals, here's what I think - <AUTHOR> http://narekk.com/post/448844146/just-finished-reading-rework-by-37signals-heres-what

<comment><AUTHOR> Wow, did not think people would get offended by that. Amazon link has been removed :)

<comment><USER2> The rule says you're gonna hear more feedback when people are unhappy than when they're happy. So I thought I'd pipe in and say that I was totally aware of the affiliate link, and didn't mind it at all.

<comment><AUTHOR> Yup! I think most people are in the same boat. My original intention was "OK, if my 2 cents about this book motivates someone to go out and buy it, I guess Amazon could share a few cents with me" but now I see that this lumps my review into the "sales" and "ad pitch" department.. and that is not what I intended.

In any case, as you can see from my tumblr blog (narekk.com) I do not write or post much. I may, however, post meaningful things in the future. HN readers gives great feedback.

</comment></comment></comment><comment><AUTHOR> Would love to here what others thought about the book as well.

<comment><USER3> I was surprised by the lack of intellectual rigor. It reads like a cross between "Chicken Soup" and "Dr. Seuss".

Examples: the book is 288 pages but only 30,000 words; every other page is an illustration, and most pages are only 3/4 full; footnotes are rare, and usually reference some pop-biz online piece from Forbes or BusinessWeek.

The final chapter (on culture) was very good. It's a topic that doesn't require any rigor to be effective. But the rest of the book was actually one of the more disappointing reads of the last 12 months.

Edit: I'm sorry this is so negative. I really like 37sigs and Jason in particular. Maybe I had too high expectations?

<comment><AUTHOR> I agree on the lack of rigor, but I think this was intentionally written this way. I think one of their goals is to disrupt the reader's assumptions on what comprises a business.

</comment></comment></comment><comment><USER4> Off topic, but wow I was surprised to open this link up and find that the author and I sat next to each other in 9th grade Physics :D

<comment><AUTHOR> I think that physics class was the highlight of our freshman year :)

</comment></comment><comment><USER5> Would love to read an review without a referral link at the end.

</comment><comment><USER6> That's just a thinly veiled amazon partner ad, including the 'bait' about page 241 and the 'get it today' link at the end.

<comment><USER7> I agree, but I think it's worth noting that there's nothing inherently wrong with using referral links (if your review is honest and includes a disclaimer).

<comment><AUTHOR> Jfornear, my review was well intentioned. But I've removed the link anyway.

<comment><USER7> I don't doubt that, just keep in mind how sensitive "geeks" are when it comes to advertising, affiliate links, etc. :)

You could just add a disclaimer like: "I use Amazon Affiliate links to link to books I like."

<comment><AUTHOR> This is true. The last thing I want to do is offend the community.

I would use your disclaimer suggestion, but the few dollars that my Amazon link would generate is not worth offending HN readers. Getting feedback, creating discussions, and contributing to the community is more important here.

Thanks for the suggestion.</comment></comment></comment></comment></comment>


Hints of Trigonometry on a 3,700-Year-Old Babylonian Tablet - <AUTHOR> https://www.nytimes.com/2017/08/29/science/trigonometry-babylonian-tablet.html?rref=collection%2Fsectioncollection%2Fscience&action=click&contentCollection=science&region=rank&module=package&version=highlights&contentPlacement=2&pgtype=sectionfront&_r=0 <comment><USER2> This has been posted a bunch before and one should be fairly skeptical that of Wildbergers interpretation of Babylonian tablets that happens to coincide with his quirky method of doing trigonometry that he came up with because he doesn't like real numbers.

<comment><USER3> A healthy amount of skepticism is fair, especially since Wildberger is a fairly odd duck. But the kind of trigonometry Wildberger proposes does work: you can use it to figure the height of a ziggurat. So it's conceivable that the Babylonians discovered it and used it.

</comment></comment><comment><USER4> Posted 4/5 days ago.

An ancient Babylonian tablet may contain the first evidence of trigonometry[0] (sciencemag.org)

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

[0] [http://www.sciencemag.org/news/2017/08/ancient-babylonian- ta...](http://www.sciencemag.org/news/2017/08/ancient-babylonian-tablet-may- contain-first-evidence-trigonometry)

</comment><comment><USER5> To clarify, the article is about a new interpretation of a previously discovered artifact.

</comment><comment><USER6> Fantastic discovery</comment>


Solid – A set of conventions and tools for decentralized social applications - <AUTHOR> https://solid.mit.edu/ <comment><USER2> I think these "open web" movement people are mistaken about what made the web successful.

The web succeeded because it let people connect more easily by removing friction.

Of course the "openness" part was important in gaining initial adoption, but today "adoption" is not a problem anymore. Most of these open web movement people just want to make things open without any immediate, clear, and tangible benefit to end-users. Even if they did, these always come with caveats--inconvenience.

Introducing inconvenience for the sake of making things more open is going backwards, and that's why it never gets any traction.

I'm not saying being open is stupid, I'm just saying it's not gonna happen if all these guys think about is "how are we going to make the web more open?", they will keep building the same shit that no mainstream user cares about.

If you want to make the web more open, build something that provides a unique unprecedented benefit, important enough that people will use it no matter how inconvenient it is, like Bitcoin, or Bittorrent.

<comment><USER3> >build something that provides a unique unprecedented benefit, important enough that people will use it no matter how inconvenient it is

As much as I like Tim I have to agree. My mom doesn't give a shit about controlling her data, much less know who has it or how it's being used.

HN, What would be a killer user-experience that Solid could facilitate with it's data-silo'ing?

=> Enable 3rd party apps that use Solid's login to offer hyper-targeted onboarding and pre-fill more account creation inputs

=> Enable background cross-app communication to app's you've given permission to in order to facilitate great user-experiences? Eg. Spotify tells your Ticketmaster app what musicians you listen to, Ticketmaster gives you notifications when said musicians are coming to your town

=> ???

<comment><USER4> For me, interoperability is the killer feature of being in control of your own data as opposed to having it locked up in some private silo.

If you are in control of your profile, contact list and message history data, for instance, you can switch between any chat app that has access to this data at any time and continue conversations without missing a beat. Everyone can use their own favorite chat apps to communicate without having to worry about what everyone else is using.

Lock-in is suddenly no longer a thing.

I think this is the only way to achieve a truly robust marketplace of apps and services that can compete on the strength of their value proposition to users, rather than relying on the strength of their network effects to lock out new players.

Of course, most profit driven corporations aren't going to be eager to adopt this open ecosystem, at least until it gains enough traction that they no longer have a choice. So the burden is on independent and open-source developers to first create experiences on top of this open ecosystem that could be compelling enough to draw users away from the proprietary silos.

I'd love to see this happen, and do plan to build apps that leverage open data systems like Solid myself, but it's definitely going to be an uphill battle, unfortunately.

P.S. replikativ [1] is another lesser known project that has similar ambitions, though it only provides the decentralized data piece of the puzzle at the moment.

[1] [https://github.com/replikativ/replikativ](https://github.com/replikativ/replikativ)

</comment></comment></comment><comment><USER5> Some relevant things:

Solid on Github: [https://github.com/solid/](https://github.com/solid/)

Solid server on top of the file-system in NodeJS: [https://github.com/solid/node-solid-server](https://github.com/solid/node- solid-server)

Plume[1]: [https://github.com/deiu/solid-plume](https://github.com/deiu/solid- plume)

[1] _Plume is a 100% client-side blogging platform, built using Solid standards, in which data is decoupled from the application itself. This means that you can host the application on any Web server, without having to install anything -- no database, no messing around with Node.js, it has 0 dependencies! It also means that other similar applications will be able to reuse the data resulting from your posts, without having to go through a complicated API._

</comment><comment><USER6> I feel like the description of this is either so high-level that it doesn't make sense, or too close to the ground to really get an idea about what it is.

Is it an alternative to HTML? To http? Is it a set of guidelines for data handling? Is it a web-framework like Django or a framework like react?

<comment><USER7> Ah, from their github repo:

Specifically, Solid is:

A tech stack -- a set of complementary standards and data formats/vocabularies that together provide capabilities that are currently available only through centralized social media services (think Facebook/Twitter/LinkedIn/many others), such as identity, authentication and login, authorization and permission lists, contact management, messaging and notifications, feed aggregation and subscription, comments and discussions, and more.

A Specifications document that describes a REST API that extends those existing standards, contains design notes on the individual components used, and is intended as a guide for developers who plan to build servers or applications.

A set of servers that implement this specification.

A test suite for testing and validating Solid implementations.

An ecosystem of social apps, identity providers and helper libraries (such as solid.js) that run on the Solid platform.

A community providing documentation, discussion (see the solid gitter channel), tutorials and talks/presentations.

\-- [https://github.com/solid/solid](https://github.com/solid/solid)

</comment></comment><comment><USER8> > Solid is modular and extensible and it relies as much as possible on > existing W3C standards and protocols.

That's great! A good place to start would be here -- [https://validator.w3.org/nu/?doc=https%3A%2F%2Fsolid.mit.edu...](https://validator.w3.org/nu/?doc=https%3A%2F%2Fsolid.mit.edu%2F).

It's a nitpick, I know. I view source. I always view source. There a lot of things that made the web a success (the REST principles underlying the architecture, the "a" tag, the non-draconian "error" handling, right-place-at- right-time), and one of them was "view source." And I always view source. And then I pick at nits.

This one advertises "[relying on] existing W3C standards", so I brought it up. I usually keep my mouth shout.

</comment><comment><USER9> Protocol for data sharing requires also a good product. I wish they get one, but I'm afraid this could end up like "Semantic Web", there is very little business incentive to make data sharing between services easy. Data after all is one of the most important assets for companies.

<comment><USER10> IMHO thinking of data as assets is what kept many company out of crowdsourcing opportunities.

Wikipedia and OpenStreetMap for instance are wonderful example of successful open datasets.

And what are social network if not personals public datasets. Now is maybe just the right time to make them more open.

<comment><USER11> _> Wikipedia and OpenStreetMap for instance are wonderful example of successful open datasets._

Wikipedia definitely has a nice dataset, but they don't seem like a successful _business_.

They always have the ads at the top of the pages asking for donations and talking about how poor they are.

</comment></comment></comment><comment><USER12> I think the issue Solid attempts to address is ownership of your data, but as people suggest below if the data is readily available via API how much have you really gained? Facebook will simply write a web crawler that downloads all your data because it's public anyway.

What seems to be missing is the web-of-trust component that controls who sees what data and in what context; i.e. your data shouldn't really be public but protected and limited by roles you control. The wedge will then of course be Facebook paying Facebook customers to mine data by subverting trust relationships.

There doesn't seem to be a simple fix for sharing of data once it leaves your system. You can't tag it and encrypt it so only friends / family / whomever may read it, and if you could there's no way to prevent the unencrypted data's use. The only way to retain your privacy is never sharing the data in the first place.

 _You may substitute_ __Facebook ___with the name of the datamining and marketing company of your choice._

<comment><USER13> The idea is that with Solid like in Facebook you can define how much each group of people get to see. Your close friends can see a lot, acquaintances can see a little, and the general public can see not much or none. So companies would need your permission to be able to scrape in the manner you described.

<comment><USER12> Among other things the reason I quit facebook is because of people who have no problem trading my information for their gain. I got tired of blocking requests from an aunt addicted to farmville, for instance. She's exactly who I had in mind when I said people will subvert controls I put in place for their own benefit. She'd happily click a button that downloaded all my data shared to her with Facebook if it meant an extra in game reward. But do I want to block her from all my updates? Not really. However given the choice of doing that and sharing my data I quite facebook. I realize not everyone is the same.

</comment></comment></comment><comment><USER14> I love this idea. Imagine you have a bunch of emails and a bunch of contacts that you'd like to preserve. You're using Gmail and for some reason they've put a bad taste in your mouth. If Gmail were built upon these open foundations then you could simply download your solid archive, and hand it to someone else to take care of.

Regarding the complaints about trust; that should be the realm of litigation. We put trust in our licencing of source code. Your data should be licenced in a similar fashion, and if the handler of your data fails to comply then they shouldn't be allowed to operate.

<comment><USER15> ? I did exactly this with an entire Google account the other day: [https://takeout.google.com/settings/takeout](https://takeout.google.com/settings/takeout)

It's all standard formats. Not sure what else you could want aside from a literal Gmail clone.

<comment><USER14> You're right, but that doesn't include licencing. There's no guarantee that Google won't retain any of your data.

Additionally, there aren't many online services which you can just expect to work after handing them that data.

<comment><USER15> Fair point, it's not "the open web" or whatever. But they do, practically speaking, do everything you need-- and it speaks to other comments about whether "the open web" is really offering something people _want_. (I certainly do expect any service I'm likely to use to import .vcf or .mbox files without much grief.)

</comment></comment></comment></comment><comment><USER16> How does this prevent developers from still copying your data and storing a copy on their own servers for faster access?

<comment><USER17> That's a feature of the Web, which allows applications like Google and the Wayback Machine.

If you don't want it copied all over the world and archived forever, don't put it online.

<comment><USER18> Bah. This project was pitched as a alternative to free-for-all data access. So your answer is silly

<comment><USER19> I don't think that's the point of the project, rather decentralization and breaking free from proprietary data silos.

The point is that you decide where your data sits and who has access to it, not that it's free-for-all.

Unless I misunderstood your point completely...

</comment></comment></comment></comment><comment><USER20> Cool. Would like to see more! Also wondering how this might relate to or complement a project like IPFS ([https://ipfs.io/](https://ipfs.io/))

</comment><comment><USER21> How is this different from sandstorm.io?

<comment><USER22> As I read it this is about data formats, sharing and reusability.

sandstorm.io is about running apps on shared hosts safely.</comment></comment>