True Tales of High Adventure (2009) - <AUTHOR> https://jasonlefkowitz.net/2009/07/true_tales_of_high_adventure_wit/ <comment><USER2> Not got very much to add, except that one of the stories in July 1967's "For Men Only" is:

"Profits: $4 billion ... Taxes $0 | Sickening Scandal of our Fat 'Free Ride' Oil Companies"

which struck me as somewhat timeless.

</comment><comment><USER3> I love Mort Kunstler Civil War paintings; I have a giant coffee table book in the living room right now.

I also played thousands of hours of Sierra's Civil War Generals growing up, and all the menus and load screens of that game (and probably a fair number of the generals' portraits) are Kuntsler paintings.

</comment><comment><USER4> The website seems to be down; I'm sure this has nothing to do with the mention of boobs in the title.

<comment><AUTHOR> Sorry about that. It should be operating normally now, though by the time I'd finished bouncing the server HN seemed to have stuffed the submission down the memory hole (sigh).</comment></comment>


Are You A Facebook Startup? You're All Going In The Wrong Direction - <AUTHOR> http://www.thrsti.com/blog/you-facebook-startups-youre-all-going-in-the-wrong-direction-be-original/

<comment><USER2> Hard to get past a title that doesn't know your from you're. And when you do, there's not much there.

<comment><AUTHOR> there is the message is pretty simple everyone is building apps on top of facebooks data. Basically all these startups are just facebook with a twist, if you really want to make something good that has a chance to disrupt as much as facebook and twitter did you should start from scratch and invent a new category.

<comment><USER3> If you wrote an email to a VC without being able to demonstrate that you picked up basic writing skills in high school and college, you'd have a longer road to travel to convince them of your overall fitness for funding.</comment></comment></comment>


Alternative code styles - <AUTHOR> https://swalladge.id.au/archives/2018/10/15/alternative-code-styles/ <comment><USER2> Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.

<comment><USER3> Put another way... if the proponent of a particular (serious) syntax style guide can't be bothered to automate it, then they are pissing in the wind.

I laugh when I see those 50-page English-language documents describing how some institution wants code to be formatted. Ain't nobody got time for that.

<comment><USER4> Many programmers are still committed to manual formatting, or fixed width fonts would have been obsolete already.

<comment><USER5> Fixed width fonts let you quickly parse syntax. Syntax and semantics are equally important when reading code, whereas semantics are generally the only thing you need for understanding the written language.

That said, I haven't seriously tried programming using variable width fonts; maybe it's a well-kept secret to digesting code. Or maybe it's like Hemp Milk, there's a reason it hasn't caught on.

<comment><USER4> There is actually no evidence for that. Programmers in general seem to be faster with whatever they are used to. I personally have trouble parsing code in fixed width fonts versus proportional ones* because I'm used to the latter and the kerning of fixed width formatting annoys me. Keywords pop out easily with syntax highlighting in any case, making syntax pretty obvious.

* to be fair, I'd have trouble with a bad proportional font like Times New Roman, but I'm sure many would have trouble with Courier New on the other side, the specific font matters.

</comment></comment></comment></comment></comment><comment><USER6> Surprised nobody talks about the kdb codding style: [https://github.com/KxSystems/kdb/blob/master/c/c/k.h](https://github.com/KxSystems/kdb/blob/master/c/c/k.h)

<comment><USER7> That's Whitney's style. My preferred example is [http://www.kparc.com/b/b.c](http://www.kparc.com/b/b.c)

It looks obfuscated, but in fact it is just a lot of information. Many people would claim dividing it in 10 files with longer function names and less tricks would make it easier to understand, but after spending a long time studying (and partly rewriting) this code, I actually find the terse version better.

<comment><USER8> The problem with satire is that no matter how far over the line you think you've gone, someone will always wonder whether you _really_ meant that.

</comment></comment></comment><comment> dan-robertson The only style there that is actually used by a person is the Bourne style. There are other styles that people develop for themselves, for example there was some Haskell program posted to a mailing list with a warning about personal style. This defines:

      (.) :: a -> (a -> b) -> b
      x.f = f x

And then the author can write e.g.

      x.length

Instead of

      length x

I think this is really quite a natural operator (and other languages support it, eg in F# it is pronounced |> and closure has something like it with ->)

<comment><USER9> neat, I think D has language level support for this too

<comment><USER10> That's basically uniform function call syntax. D and Nim use it and a few others.

</comment></comment></comment><comment><USER11> The best coding styles are the ones that allow to be translated back and forth to another style.

It doesn't matter which style you prefer. As long as a computer can pick it up and translate it into the project standard style and back to yours again. You can simply setup git filters and live in you own style world.

<comment><USER12> Code is meant to be read first and foremost by humans.

As such, code should be written for clarity and presentation. To communicate intent. Automated tools destroy this human/code connection. They reduce your coworkers to simple cogs in a machine, rather than authors and communicators.

I'm not a fan of this cold, brave new world.

<comment><USER11> How code is styled doesn't distract from the main purpose to communicate intent. Most often humans are the ones mindlessly layering on the meaningless formatting/style on top of syntax and its then becomes the pivotal point of code reviews, burying the essence of the code.

I applaud companies like Google and Hashicorp for forcing formatting as compilation errors. As it lets you get on with the real tasks ahead.

</comment></comment></comment><comment><USER13> That Fibonacci based indentation might not be a bad idea after all. Especially when doing callback-style javascript.

<comment><USER14> I'd prefer something like 3^n. Would really make you try to avoid needless nesting.

<comment><USER15> Why should I avoid needless nesting ? Is there any other reason besides the holy 80 character limit !? Nesting can for example be used to limit variable scope and make use of closures, or to avoid creating more code paths, or just make the code more readable. You can however often break some code down to named functions and it will be easier to read, with the _added_ benefit of less nesting. But I don't see how avoiding nesting is a good rule by it's own.

<comment><USER16> You've given some good examples of nesting which don't introduce branches, but most nesting does and therefore, nesting is an approximation for the cyclomatic complexity of a piece of code. Reducing this complexity helps with testability and (moreso) with the ability of humans to understand the code [https://en.wikipedia.org/wiki/Cyclomatic_complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity)

Agree with you that reducing nesting is not in and of itself beneficial.

<comment><USER17> Cyclomatic complexity seems like a great example of Goodhart's Law [1]. I absolutely agree that on the whole, code with fewer paths tends to be easier to read. However, taking deeply nested code and arbitrarily pulling chunks of it out into functions which only have a single caller and don't really abstract anything that's ever going to be terribly meaningful on its own seldom makes it better in my experience -- and can force a lot of skipping around if you're actually trying to understand what the system as a whole is trying to do.

[1] [https://en.wikipedia.org/wiki/Goodhart%27s_law](https://en.wikipedia.org/wiki/Goodhart%27s_law)

</comment></comment></comment></comment></comment><comment><USER18> Putting every single item in this on my list of "reasons to kill a motherfucker".

Seriously though, I find myself oddly attracted to the Python-braces style .. if only I could use it without running afoul of my own list.

<comment><USER19> make your syntax highlighter show braces and semicolons in a faint color – similar effect, better editability!

<comment><USER20> Or just use Python or other languages that require fewer braces/semicolons in the first place? We have so many options now, we don't have to deal with the tyranny of overly precisely punctuated languages if we don't want.

</comment></comment></comment><comment><USER21> I followed the link to the OOPS source code from the comments: [http://people.idsia.ch/~juergen/oopscode.c](http://people.idsia.ch/~juergen/oopscode.c) (originally from [http://people.idsia.ch/~juergen/oops.html](http://people.idsia.ch/~juergen/oops.html))

Aaaand… "we're achieving levels of nerdery that shouldn't be possible."

</comment><comment><USER22> > Poetry... quite eye-pleasing

I disagree with this comment. That style makes the code extremely hard to follow, as there's no proper indention to identify scope.

<comment><USER23> Most of these examples are meant to be a joke, I'd assume.

<comment><AUTHOR> Yes, the whole article is semi tongue-in-cheek. I tried to bring it back to reality by mentioning my appreciation for the creativity of people who designed the styles. :)

</comment></comment></comment><comment><USER24> This has to be satire. Most of these are terrible and I'm pretty sure the fibonacci indentation originated on /g/.

<comment><USER25> I love the Fibonacci indentation. Deeply nested code then looks like the gravity well in a black hole, drawing a direct and clear analogy to where readability and understanding are headed.

</comment></comment><comment><USER26> Kevlin Henney gave a talk ( [https://vimeo.com/97329157](https://vimeo.com/97329157) ) that included an interesting idea for style:

Imagine every non-whitespace character in your code were replaced with garbage. Indent so that the reader could still understand the structure of your code.

</comment><comment><USER27> Braceless Rust does look very nice. I wonder if a python style syntax is possible?

<comment><USER28> [https://github.com/mystor/slag](https://github.com/mystor/slag)

<comment><USER29> I appreciate the honesty of the readme

</comment></comment></comment><comment><USER30> Wow! I've never heard of bournegol. That is really cool.

<comment><USER31> Sadly I have been asked to use it. Horror story time.

First job out of school, I joined a place with a lot of EE's writing VHDL tools.

So EE's--no offense--at that time viewed software as a solved problem if you did everything by a book (any book) and a spec and a waterfall.

So despite working in C, which was already plenty idiomatic with a fine K&R standard, they insisted that while( _p-- =_ p--) was verboten and instead made a bunch of FOOL/LOOP, WHILE/ELIHW, IF/FI and other abhorrences to hide the idioms they didn't like (such as braces) and make it more like algol/pascal. This was all less important than actual CS principals.

Then to make matters worse, there was a SPEC, a binder full of PAPER pseudocode mostly in algolish, some hand written. But every piece of code needed to refer back to its spec. Of course those things got out of spec quickly so any new feature was always about triple work.

Yes, and it was uphill both ways.

</comment></comment><comment><USER32> oh god no stop.</comment>


Open-Sourcing the Universal Package Manager - <AUTHOR> https://repl.it/site/blog/upm <comment><USER2> Repl.it is a super useful site for prototyping and running code in the browser. One of the best features is the package manager workflow, and I love being able to just import packages and have them be automatically installed.

I'm super excited that they released their package manager to the public! I've honestly been missing this workflow, I might work on a vscode plugin to implement similar package install functionality to Repl.it's online IDE.

Thanks, team :)</comment>


Alleged Screenshot Of Google Drive Surfaces - <AUTHOR> http://techcrunch.com/2012/02/16/alleged-screenshot-of-google-drive-surfaces/

<comment><USER2> Does anyone know (or have any educated guesses) if Google Drive will have an installed state like DropBox, or will it be entirely web-based?

It's funny, but I didn't think I'd like the fact that I had to install DropBox. Now, I can't imagine any other way it could work. Then again, I'm not paid to solve these problems.

</comment><comment><USER3> So someone has learnt how to use Developer Tools on the Google Docs page?</comment>


Paul Kedrosky on Y Combinator - <AUTHOR> http://paul.kedrosky.com/archives/2007/03/03/y_combinator_ne.html <comment><AUTHOR> That's how I found out about Y Combinator. Thanks Paul</comment>


The optional "else" in Python loops - <AUTHOR> http://shahriar.svbtle.com/pythons-else-clause-in-loops <comment><USER2> While in theory this is useful, it's one of the least intuitive parts of python for me. I avoid them whenever possible because I feel "else" conveys the intent very poorly. (And I've been writing python for years.)

<comment><USER3> Raymond Hettinger has suggested that instead of `else:` the keyword should have been called `nobreak:` which conveys intentions better.

<comment><USER4> What about using "finally," which if IIRC is already a thing in Python and encapsulates this idea pretty neatly?

<comment><USER5> finally blocks are always executed; this kind of else block is only executed if the for block exited normally (i.e. did not throw an exception).

<comment><USER6> How about a keyword such as "after"? I feel like that could have extensible potential in other areas of the language, and the name makes a little sense logically speaking.

<comment><USER7> or something like "then"?

</comment></comment></comment></comment></comment></comment><comment><USER8> Raymond Hettinger, one of the main Python devs, advises that the "else" in this situation should mentally be thought of as "notfound".

<comment><USER9> Glad you posted this. I came to the comments to post the same thing[1] because thinking of it as "notfound" makes remembering (and comprehending it) easier. :)

[1] [https://www.youtube.com/watch?v=OSGv2VnC0go#t=17m12s](https://www.youtube.com/watch?v=OSGv2VnC0go#t=17m12s)

<comment><USER8> Ah, I misremembered, "nobreak", not "notfound".

</comment></comment></comment><comment><USER10> This badly named else is reminiscent of the "result forms" in Lisp loops like `dolist`, `do` or `loop`.

        (loop for x below 10
                    finally (princ "iterated over everything, ") (princ "indeed"))

But, of course, these Lisp loops have a result value, and the result forms are an "implicit progn" which produces that value.

</comment><comment><USER11> Not only it is not very intuitive, I also find it to hurt the linearity of code. The code which will be executed after the loop ends depends on how the loop ended. break statement is usually a glorified but mostly harmless go to, but I think Python's go to statement isn't so harmless as it adds complexity but doesn't have big benefits.

But, I do think that the else clause on try\except blocks is less harmful. It is less harmful because the control flow complexity of exceptions handling is already there on the catch clause, so while exceptions _does_ add big control flow changes, the addition of the else clause causes a relative minor change on the linearity of code (as it is already broken by catch: clause.)

</comment><comment><USER12> I always strongly discourage the use of things like this construct in any language.

A language is meant to be read not just written. A non-expert python programmer who encounters this will be confused.

<comment><USER13> There will always be non-expert programmers of many languages. Avoiding language-specific constructs will not solve the issue.

As far as portability is concerned (if you port software by hand a lot, for example), this is indeed an issue; but if you work with people who write python code, you might as well use everything in your toolbox.

<comment><USER14> > There will always be non-expert programmers of many languages. Avoiding > language-specific constructs will not solve the issue.

This is a language-specific issue that occurs rarely in the wild. Yes, it's part of the language, but it's used rarely enough that it can trip up even experienced Python programmers.

For example, Perl (until more recently) allowed one to change arrays to be 1-indexed, rather than 0-indexed at runtime. Just because it's part of the language doesn't mean that it's a good thing to use it.

</comment></comment></comment><comment><USER15> Created an account to point out this gem by Guido himself that makes use of this and the fact that python variables are not scoped inside for loops:

[https://github.com/aosabook/500lines/blob/master/crawler/cra...](https://github.com/aosabook/500lines/blob/master/crawler/crawling.py#L100)

<comment><USER16> Oh my God! I would be so confused reading this code!

</comment></comment><comment><USER17> it clear to me that this notion is not maintainable at all after looking the comments though it is nice feature to have.

</comment><comment><USER18> For me, the optional else on for loops isn't nearly as mentally destabilizing as the optional else on try-except blocks. An ex-employee used to _love_ doing that:

        try:
            None.doit()
        except Exception as e:
            logger.exception('Nope')
        else:
            # now what?
            pass

<comment><USER19> try/except/else used to throw me, but I've grown to like the idiom.

All it means is the try clause didn't raise any exceptions. And a "finally" clause is ran whether an exception was raised or not.

</comment></comment><comment><USER20> Also known as "Dijkstra's loop" to give credit where credit is due. Only other language I know that has it though is Oberon (and that just introduced it in a pretty _recent_ update)

</comment><comment><USER21> Might be worth while looking at the video below for more Pythonic gems like this one.

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

</comment><comment><USER22> This is all in Jeff Knupp's Writing Idiomatic Python:

[http://www.jeffknupp.com/blog/2012/10/04/writing- idiomatic-p...](http://www.jeffknupp.com/blog/2012/10/04/writing-idiomatic- python/)

Many so-called Python Idioms are really non-intuitive and I don't really appreciate.

<comment><USER23> They are intuitive and very easy to understand and read the code.

If you use Python you should code in Python, not trying to translate C to Python.

</comment></comment><comment><USER24> I would choose `finally` keyword over the `else`.</comment>


Shortage of charging stations to become a bottleneck to mass adoption of EVs? - <AUTHOR> https://www.fresnobee.com/news/local/article215854560.html <comment><USER2> It's a fair point, if overdone.

My current employer has 16 EV chargers and they're all full by 8:45am. Even in just a few months here, I've noticed them becoming occupied more rapidly. People need to start rotating their cars off the charge mid-day to accommodate more cars. The 4 handicapped spots with chargers are often also poached with some regularity. (private garage, but still risky).

At former employers, I saw chargers go from nonexistent, to installed, to saturated, in a matter of 6 or so months. In a given site, so far, construction isn't keeping pace.

I own an EV and charge at home so it's not really an issue for me, but those with shorter range vehicles are more likely to have issues, and it is something that will have to be dealt with.

It's not insurmountable, but it's an issue. The massive increase in electrical demand from EV charging when rates go off-peak but solar generation is nonexistent is definitely something that'll have to be dealt with. My house used to consume maybe 1500w at 9pm. Now, when the charger flips on, bam, 13kW. It's impressive how much more load a neighborhood with even just a few EVs can put on the grid.

<comment><USER3> Surely it would be enough in most cases to put an ordinary domestic single phase supply to each parking bay. No need to have big fast chargers. My Tesla S 70D gets about 1 km per hour per amp at 230 V. So if it sits there for an eight hour work day and can get 10 A (common for a domestic circuit in most of Europe) it would get 80 km or about 50 miles. Surely most people commute less than 50 miles each way?

<comment><USER4> It's easy to commute more if you're on a highway, your range in Europe can be around 150 km given 1 hour commute. My father used to commute 120 km (less than 1 hour ride on a highway).

<comment><USER3> But nonetheless most people don't commute so far. The average commute time in the US is 26 minutes ([https://www.afdc.energy.gov/data/10801](https://www.afdc.energy.gov/data/10801)), so probably less than 30 miles (each way I presume). And that amount of charge is easily done in an eight hour working day on a normal domestic circuit, no special charging infrastructure is required just a pole with a normal socket on it at every parking bay.

<comment><USER4> Yeah, but the average is most probably skewed by people who live next to their workplace. And still, even if it was just a fifth of people who commute from a larger distance, it's still _a lot_.

Also, in the USA it probably works different than in the EU - the cities and rural areas look very different. Here it's extremely common to live in a village that's around 50km from the city where you're working.

</comment></comment></comment></comment></comment><comment><USER5> Article like this always seem to ignore/forget that you can charge your EV _at home_ , and that this is usually where you charge it the majority of the time.

It's an understandable thing to forget, since you can't fill up your gas car at home.

I own an EV and I only use public chargers extremely rarely.

<comment><USER6> Assuming you own your own home.

If you live in an apartment complex or otherwise only have street parking, you likely don't have access to electricity. Or at the very least, would need to negotiate with the landlord to have a new outlet installed -- which is going to depend on how much you get along with said landlord.

<comment><USER7> Not a problem in California at least:

"Assembly Bill 2565 would give tenants the right to install an electric-car charging station at their residence, provided the tenant submits a written request to the landlord and pays for the installation costs."

(Passed already)

<comment><USER8> At a cost of at least $1000 for a charging station and installation, I can't see many people wanting to pay for this if they are renting.

<comment><USER9> The demographic that would currently buy an electric car in California can easily pay for $1K for a changing station. If you're going to spend $30K on a Leaf or plug-in Prius or $50K on a Model 3 (vs. $18K for a Corolla or Fit), $1K is a drop in the bucket. It's also a tiny fraction of rent in Northern California, roughly 12 days worth.

<comment><AUTHOR> The new Hyundai Ioniq PHEV can be bought for $25k.

In any case, most people don't just shell out a random $30,000 they have burning a whole in their pocket, they finance the purchase over 5-6 years. Sudden out-of-pocket $1,000 is kinda a big deal, especially if one plans on moving out in a year or two.

<comment><USER9> I must be living in Silicon Valley too long, because a large number of people I know - amongst the tech crowd at least - do in fact shell out a random $30K they have burning a hole in their pocket.

(Lest I get accused of being way too out of touch, I do know people for whom affording even a $200 car repair is out of reach, and something they'll put up a GoFundMe over. _These people do not drive electric cars_. If you can afford the ~$5K in interest that financing a car over 6 years will cost you, you can afford the $1K charger. If you can't afford this, you buy a used Ford or Chevy rather than any of the cars we're talking about here.)

<comment><AUTHOR> The way I see it that with 0% financing deals aplenty there's virtually no incentive to pay cash upfront. Might just as well stick that $30k into some high-yield savings account and set up automatic payments from there. Builds credit history, too.

<comment><USER9> The last couple times I've been car shopping the 0% financing deals come with a jacked-up list price. You may get the loan at 0%, but the way that works is that they quote a higher price to begin with and then the 0% financing (assuming good credit) was their "concession" in the negotiation. We bought our cars for under dealer price, paying by cashier's check, so I assume that the _actual_ dealer price was even lower (otherwise they wouldn't be willing to sell us the car), particularly since the lowest price they would go with financing was a couple thousand higher (credit scores in the 800s).

<comment><USER10> This is exactly right. And i reiterate this often, TANSTAAFL. (There ain't no such thing as a free lunch).

No one is loaning you money interest free. You are just paying for it in the purchase price or through other fees.

I will admit there are rare cases where strange incentives may make it cheaper or the same price to buy with credit, but these are very rare, and are only applicable if you artificially limit your available selection of vehicles to brand new. Even though you could get virtually the same car with 10k miles on it for much less.

<comment><AUTHOR> For used cars there's always room for negotiating, but for new cars I felt the pricing was standardized through TrueCar (and their derivatives, like Costco Auto, Amex Cars, Overstock Cars). Is that not true?

<comment><USER9> There's the floor on prices that they will advertise to the public and then there's the actual floor on prices, and the latter can be significantly lower than the former.

Car dealerships have a number of incentives that can change their reserve price in strange ways. There's the advertising holdback and potential servicing cross-subsidies that sokoloff mentions, and then there are also monthly quotas and per-salesperson quotas. If the dealer is very close to their monthly quota and it's almost the end of the month, you can get a car below invoice price, because the manufacturer will give them a bonus for hitting the quota and so the _marginal_ profit on the one car they sell you can be positive (including the bonus) even though the car itself sold at a loss. Similarly, if an individual salesperson is close to hitting their personal quota, they will let you have the car for the lowest price that won't get them in trouble with the dealer, because it helps them hit their numbers and gives them a bonus.

It's entirely possible that similar incentives exist for financing, and that's why people get zero-percent auto loans with cash back, and they're cross- subsidized by people who end up paying thousands in interest because their credit scores weren't as good or they didn't get as good a deal. But _on average_ , the financing cost needs to be eaten by somebody, so _on average_ you're likely to get better deals paying cash than financing. The dealer can also book all the cash immediately when you pay cash, which makes them somewhat more amenable to offer deals and opens up some other incentives for them to sell cheap (like getting rid of old model years near the end of the fiscal year and converting it to cash so their numbers look good and they can order more new model years).

(There can also be strange situations that make buying new more economical than buying used - I bought my Fit in 2009 for less than used 2007 Fits were going for, because the bottom had fallen out of the economy and oil had gone from $100/barrel to $50/barrel. The used car owners had paid ~$2000 over sticker price for a fuel-efficient car in a booming economy, while I paid ~$500 under _invoice_ price because dealers were desperate to hit their quotas, and the dealer's beliefs about where the market is at adjusts faster than private owners' beliefs about where the market is at. Such situations are the exception rather than the rule, though.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The problem is the delivery mechanism. Charging is always going to be a bottleneck, unless we invent mass production supercapacitors on the order of what graphene promised (which is seems to be highly unlikely). Edit: even with supercapacitors, the amperage required seems unlikely.

Assuming self-parking as a baseline (although it's not strictly required), cars would be able to position themselves over an automated battery pack replacement station. Replacing the discharged pack could take less time than a petroleum refuel, so EVs could be _more_ convenient than petroleum vehicles (any replacement technology should offer more benefits than what it replaces).

The station could then move the pack underground for recharging. This underground area would have much higher density compared to cars (where batteries are, what, 10% of the volume?). In addition, dead packs could be identified and scheduled for pickup and recycling.

The first problem that most people would bring up is: replacing a worn pack with a new one. This problem actually turns out to be an advantage: disclose the mileage of the pack and allow the customer to pay less for it. I don't need a 300mi pack if I'm just going 5mi to work. This way, more useful lifetime can still be extracted from old packs while turning the recycling problem into a logistically simpler problem (no more complicated than delivering petroleum to fuel stations).

The only real problem with this is the clamping mechanism between the car and the pack. It would need to be standardized. Reliability: mechanical systems fail - it's the undercarriage of the car, there's dust and other particulate getting in the way.

<comment><USER12> Tesla originally had a demo of this 'replace the pack under the car' method (called "Fast Pack Swap"; see: [https://vimeo.com/68832891](https://vimeo.com/68832891)). But they seem to have backed off that idea, probably for a variety of logistical reasons.

I remember reading about an underground battery swap system in a 1980's electronics encyclopedia too, but it seems the barriers are too great for the size batteries needed for a good long-range EV.

<comment><USER11> Wow. I was convinced it was a foolproof solution. I wish I could learn more about the problems that they were worried about.

Thanks for the citation, it's nice to see the idea in action :)

<comment><USER13> Here's an article on Tesla abandoning battery swap [0]. There was also an Israeli company trying to do the same thing that failed to pull it off. [1]

[0] [https://www.businessinsider.com/teslas-battery-swapping- plan...](https://www.businessinsider.com/teslas-battery-swapping-plan-isnt- working-out-2015-6).

[1] [https://www.fastcompany.com/3028159/a-broken-place-better- pl...](https://www.fastcompany.com/3028159/a-broken-place-better-place)

</comment></comment></comment></comment><comment><USER14> People still don't get just how radically synergistic electric driving, self- charging and self-driving technology will be. All the drawbacks of electric driving such as low range and slow and cumbersome charging will just instantly disappear as soon as cars will just drive away and charge themselves. It will mostly solve parking problems, availability of chargers and even help absorb the (basicall free) excess energy produced by photovoltaics in the middle of the day. Just one or two of these technologies won't do much, but I suspect we'll see a massive tipping point once all three hit. If you ask me, we'll see this completely altering cityscapes and car ownership between 2020 and 2030.

<comment><USER15> Self-driving is expected to bring down ridesharing costs. As costs go down, ridership goes up. As ridership goes up, traffic goes up. Currently I can get around by bicycle, rideshare, bus, subway, trolley, and rail. With the exception of the subway, all of those are slowed down by increased vehicle traffic. The tipping point you're talking about may be city streets becoming gridlocked.

Then there's the bit rot problem. Most of this self driving tech is software. Over time, software becomes old, eventually is abandoned, and has to be rewritten. Assuming the cityscape was changed by 2030 (this is impossible, but just for argument's sake) we could have broken legacy tech by 2050. But we will either be stuck with it, or middle-aged people will have to start driving 30+ year old cars as taxis, as no young people will have gotten a drivers license, and all the self driving cars won't have steering wheels.

<comment><USER16> A vehicle miles added tax would, in smart policy districts, allow the curbing of excessive car use, especially for a company like Uber or Lyft. There's also congestion tax, which many cities are already implementing. Some cities just straight up banned non-electric past a certain year, so we're already moving slowly to deal with traffic. I think we'll have the tools we need by the time it's a huge problem. In Boston, the traffic is pretty awful, there are just many cars shoved into a small area with infrastructure based on cow paths from original settlements.

<comment><USER15> You don't think they'd just pass the taxes on to the customer in fees and then blame the local govt?

Personally I'm for banning cars altogether from city centers. Many cities are implementing that too, and not nearly soon enough.

</comment></comment></comment></comment><comment><USER17> Chargers have been getting noticeably more busy over the last year (bay area). It's pretty absurd at this point that we are relying on private companies like Whole Foods to build public transportation infrastructure. The state really needs to get on top of this and start building out more level 3.

<comment><USER18> >It's pretty absurd at this point that we are relying on private companies like Whole Foods to build public transportation infrastructure.

Most (maybe all?) gas stations are privately owned, how is this different?

<comment><USER19> Probably because gas stations and EV chargers have very different logistics and modalities. For example, you could realistically put an electrical outlet by every parking space, but doing that with gas pumps would be completely untenable.

<comment><USER20> A gas pump by every parking spot is probably easier at scale. Manufacturing costs would scale down significantly, and a plastic gas pipe is cheaper than a copper wire.

We don't do it because a gas car refuels fast enough that you don't need it.

<comment><USER21> How about the cost for the nozzle, the pump, and all the safety equipment you need to stop an oopsie from turning into a kaboom?

<comment><USER22> Let's not forget vapor recovery systems for all these gas spickets in California

</comment></comment></comment></comment></comment></comment><comment><USER23> I'm pretty shocked at the low adoption of hybrid cars. Why don't people want them?

<comment><USER24> BEVs are mechanically simpler, requiring less maintenance and expense (and they eliminate all use of fossil fuels). Hybrids and PHEVs are mechanically more complex than ICEVs, often requiring more things that need maintenance and repair.

PHEVs are the worst of all, in my opinion, because on top of everything else, they tend to clog up public charging stations.

BEVs with decent range (the Chevy Bolt, Tesla, and some upcoming models) are the real solution. Charge at work and home - and only use DCFC (high current) public charging for trips.

Background: I've had a LEAF for 4.5 years as my daily commuter car; it's got (32K miles). For trips last year we got a Tesla Model S (24K miles).

<comment><USER23> > Charge at work and home - and only use DCFC (high current) public charging > for trips.

As I essentially only use my car for weekend road trips, how is the long- distance experience hopping from charger to charger? How about country driving --is the density high enough you can check out some nature?

<comment><USER25> Previous generation Leaf? Debatable. I have one. I plotted a trip from the East Bay to Yosemite and the range seemed enough on paper, even accounting for elevation. But in at least one stretch there was a single quick charge station (ChaDeMo) that I could rely on. If that was out of service I would have issues, as even L2 were not plentiful. On Yosemite itself I could find only one L2. So I did not attempt the trip.

Current generation Leaf, Bolt, Tesla? The range would be pretty adequate and comfortable.

Not sure about long desert stretches, you could have an idea here: [https://www.evtripplanner.com/planner/2-8/](https://www.evtripplanner.com/planner/2-8/)

Also of note is that a major drawback in the US is the high highway speeds. Drag increases to the speed squared, so going 60mph vs 80mph makes a huge difference. We don't notice as much in internal combustion engines, because a gas tank has so much energy – we may notice in our pockets though.

</comment></comment></comment></comment><comment><USER26> Maybe they should start with a common-sized charging plug?

<comment><USER5> This has essentially happened. J1772 is the standard for "normal" charging, CHAdeMO is the standard for fast charging.

Even Tesla, the only company to not follow these standards, supplies a J1772 adapter with every car.

<comment><USER27> In Japan, Tesla supplies the adapters to use CHAdeMO.

</comment></comment></comment><comment><USER28> I've come to the conclusion that we need two cars. 1. an EV car for around town and 2. a gasoline powered car for when we are on a road trip to very rural places (which is quite frequent). I'm hoping that at some point even in the hinterlands of the US there will always be an available charging station, but we aren't there yet.

<comment><USER29> I road trip regularly with my Tesla Model S. You would be surprised at where there are charging solutions. Any RV park can charge you up over night. If you use superchargers, it's hardly slower than a gas car. A 600 mile day that would take roughly 9 hours of driving and 1.5 hours of stopping (getting gas, eating, bathroom breaks) in a gas car takes about 9 hours of driving and 2 hours of stopping (charging, eating, bathroom breaks).

To me that's totally worth the savings on fuel and the fact that the car does 90% of the driving for me. If you left at the same time, you'd beat me by 30 minutes, but I wouldn't feel like I'd been driving all day, and I would save $50+ on gas.

<comment><USER28> I'm not too familiar with how far an EV car can typically go on a charge. I looked at our typical trip on [https://chargehub.com](https://chargehub.com) and there are three sections where there is a 200 mile gap between charge stations. Can a typical EV vehicle carrying say 7 people with all their gear, kayaks, roof top luggage shell, etc. go 200 miles between charging stations? Two of the sections would be through mountainous terrain with steep climbing if that makes any difference.

</comment></comment></comment><comment><USER30> One point to consider if buying a condo, assuming you can get board permission, it can cost $8-10k for a licensed electrician to extend a 240V 50A circuit to a plug on the wall of your parking spot. It is definitely a consideration. Electrical loads in parking structures for 60+ cars are not usually designed to support electrical cars.

</comment><comment><USER31> What's the major impediment to installing new charging stations? My guess would be that tearing up and replacing pavement to run cables is the biggest expense, but maybe the charging electronics or the actual structural components are particularly expensive.

</comment><comment><USER32> Here in flyover country, Kansas City has 1600 public charging plugs. I reckon that is much more per capital than Silicon Valley.

</comment><comment><USER33> We need to improve the batteries/charging technology to make it possible to fully charge an EV in five minutes or less. That will make them more practical for long-distance travel and will also reduce the need for charging stations in parking areas and in homes. Instead they can supplement/replace fuel pumps at gas stations, and benefit from the existing built infrastructure, easing the transition and keeping refueling patterns the same.

<comment><USER16> Easier said than done, though multiple car companies and charging companies are stepping up the kW their cars can handle. It'll be a mixture of faster charging, more battery storage overall, as well as more efficient use of electrons, all three helping with range/recharge issues.

</comment></comment><comment><USER34> What are the obstacles to designing a new EV with a solar panel on the roof or hood?

<comment><USER35> Just saw this prototype in the newspaper today. It is covered with solar cells, and apparently, it recharges 18 miles of range if you leave it out in the sun all day.

[https://www.dn.no/nyheter/2018/08/09/0926/Motor/testkjorer-s...](https://www.dn.no/nyheter/2018/08/09/0926/Motor/testkjorer- soldrevet-bil-som-kan-lade-mens-den-kjorer)

</comment></comment><comment><USER36> Is it possible/financially doable to make charging mostly a thing of the past with a standard replaceable battery pack? Tesla 3 gets 9, Prius uses 5 etc. You got to a charging station and they swap your batteries out for fully- charged ones if available, and charge if not.

<comment><USER17> >Is it possible/financially doable to make charging mostly a thing of the past with a standard replaceable battery pack? Tesla 3 gets 9, Prius uses 5 etc. You got to a charging station and they swap your batteries out for fully- charged ones if available, and charge if not.

The problem with swapping is that switching out a battery is not at all the same as switching out a gas tank. Batteries degrade over time, and with various different usages (lots of fast charging, high heat) can degrade much more severely. You would have to have some kind of system that grades the battery being turned in and credits/debits the account based on its condition. On top of that it's just not necessary. A full charge from 20% is less than 30 mins at a 100kw charger.

<comment><USER37> Swapping a fuel tank is actually not a bad analogy to swapping the battery. Both are much more involved than a simple refill, the fitment is limited to a single model (or a few similar ones), and I wouldn't want to replace my known good unit with a random used one.

It just takes about 10x more time to refill a battery than a fuel tank. Eventually gas stations will start to be replaced with more useful establishments (grocery, coffee shop, offices) that happen to have a charger at every parking spot.

<comment><USER25> Yeah, if you can find charging spots with no hassle, then this becomes a moot point. Buying some groceries? Plug it in. Going to the movies? By the time your movie is done you'll be ready to go. Work, school, etc.

Then only actual need for quick charging is road trips. And given a decent range, it is no big deal to stop every few hours. People do that even today, as they need bathroom breaks and the like.

</comment></comment></comment></comment><comment><USER38> Oh hey, welcome to every news outlet that needs a quick "EV" article to get clicks over the last 10 years.</comment>


Ask HN: When do you use a library vs. implement something yourself? - <AUTHOR> At one end are single-function npm libraries that led to the left-pad fiasco[1].
At another end are things that you should only be implementing yourself in highly unusual circumstances, such as cryptography libraries.
Where on this spectrum do you usually implement the thing yourself, and what is your thought process?
What are the costs of importing a library, and how are those costs different for different projects? Are there security risks? What are the benefits?
Conversely, what are the costs and benefits of implementing something in-house?
Has there ever been a case where you've tried to roll your own and it ended in disaster? Or where you'd wished you'd never added a dependency on some library?
[1] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ <comment><USER2> I almost always opt for a library as long as

1\. It is still alive

2\. It is on GitHub so I can easily read the source and look for issues

3\. People star it

4\. It has traction ie >10k downloads preferably >50k

5\. It occupies a name that makes sense ie I'd rather trust using "redux- immutable" than "steel-porcupine", since it unofficially lends itself to the "vetted one true solution"

6\. Then I look at the source quickly and make sure it looks well done under the hood

7\. Finally, if it's particularly confusing, I might run a quick google check to see if there's blogs about it on the internet explaining how to use the advanced features and check the date on the blogs (1-2 years ago = good, it's mature)

If any of the above are too dicey and there's no good options, I put the relevant code in a top level folder called "modules" (or otherwise) with the intention that in the future I might get to delete it if the package ecosystem gets more mature in that space. Sometimes I even get to polish those files up and actually publish them.

<comment><USER3> > 1\. It is still alive

A mature project that just works does not need new commits.

<comment><USER4> That's true, but whether a project is alive or not goes beyond whether people are committing code. E.g.,

\- If you file a bug report does the bug get fixed? Do you even get a response?

\- If you ask for help from the community, do you get it?

</comment></comment></comment><comment><USER5> I try and stick to the my language's standard library whenever possible. Because I know that the stdlibs will be maintained and it won't be a waste of time to learn them.

If I really need to use some library (for example Graphic toolkits etc.) I tend to try to understand it by looking at its source. I try to make some modifications in it, try to make them run. That way I get somewhat an understanding of the library and the problem domain itself.

Usually you only need a small part of a library. You can look at the implementation at that library and then incorporate it in your program and slowly improve it. That way your dependencies won't get bloated, you'll get a customized solution with little effort and if you encounter problems you'll know where to fix them. That's a trick I've learned over the years.

<comment><USER6> You must be a native programmer. I have found that collegues using managed languages are much less conservative compared to collegues who program using native languages (primarily C/C++).

<comment><USER7> Or she is a programmer working with a sensible programming language with sensible standard library (e.g., Python). I would really like to like NodeJS, JavaScript is not that bad language in itself, but missing standard library is a problem for me.

<comment><USER8> Node has a pretty big standard library really (in fact that's all node.js is; a module system and a ton of modules built on top of a JS engine). What do you find is missing compared to Python's standard library?

<comment><USER9> The fact that there was a need for the left-pad module is pretty telling on how comprehensive the stdlib in js is.

<comment><USER10> Which programming language are you using that has left-pads functionality in the standard library?

<comment><USER8> Well, python's strings have the ljust and rjust methods which left- and right- pad, and javascript has the padStart and padEnd methods (since ECMAScript 2017).

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> If I on-the-fly estimate that implementing x feature takes too long* and if this seems like a problem others might have solved, I go for a library pretty fast. Basically I don't want to implement and maintain something if others have done it for me.

Example: I need to parse excel-files in python => straight to looking for a library, I don't even want to start looking into excel-format specs.

Example2: I need to parse JSON in Java. First look if Java have this natively (I don't write too much Java) and then go look for a lib. Others must have had this problem, and they most likely solved it as good as or better than me - the surely devoted more time to it, if the bothered to publish a lib.

I review if the library project seems alive and being updated. I review if it is super easy to use. Then I include it, no more fuss. Most time I end up checking out 2-4 libs to compare ease-of-use and liveliness etc.

I admit that I could do a lot more on security review. Most of the time I fallback to the thinking that this is OSS and/or a widely used lib, and if there was a security issue that I would be able to find, others would have found it by now.

*: What too long is varies I guess, but you always have a gut feeling of how troublesome something is to do. Maybe compared to the value of x feature.

Thats how it is for most all hobby projects. If it is projects for a client, I worry a bit more about security, but the primary driver for decisions are that others must have solved the same problem and most likely better.

And of course in some organisations you'll find it-policies, security policies, dev guidelines etc. that you just need to follow. Then you do that - the client is paying for slow then, by their own choice.

</comment><comment><USER12> I use the standard library and not much else.

If I want some functionality that's difficult to implement, I'll see about including it verbatim in some branch of the source tree.

If it's a large amount of code, or not license-compatible, or needs to be updated apart from the program, then I'll resort to using a library.

Library updates are the number one reason for code rot, in my opinion. More dependencies is more chance for pain later. I try to pick mature platforms and lower-level libraries which change less frequently.

</comment><comment><USER13> This is no different to any other "build vs buy" thought process.

Is this a utility-like function for you, or is it defining competitive advantage for your project? Do you need to own the roadmap for this functionality, or are you happy for others to define the roadmap for you? Are you genuinely innovating in this functional or non-functional area - if not, why are you spending time/money/effort on it? What is the TCO of the given solution vs building _and maintaining_ the functionality yourself?

As developers we think the solution to any problem is to develop. It often isn't. If you need something to serve stuff off port 80 at scale, would you build a web server, or install one? If you need crypto, same question.

Spend your time where it counts, be grateful for the decades of work that has gone into the stuff you can take for free out there, use it wisely.

</comment><comment><USER14> It's just a judgement call. For existing options you have to score based on: maintainedness (frequency of upkeep, issues answered, etc), invasiveness (cost of removal, definitely a big one here when choosing a framework vs a library), dangerousness (trustworthiness of maintainer), weight (itself and transitive dependencies), quality (quick code review, license, etc), and reimplementation difficulty. That score is weighed against your requirements (e.g. building a lib for others might have stricter dependency reqs than an in-house app). But you can take these metrics and apply them to even broader things such as lang/ecosystem choice, general software choices, and even life choices. No different than entering into any other relationship.

While I try to avoid premature abstraction, on libs that have high volatility or otherwise don't score very high, I'll put a thin interface layer between my use and the true impl. This saved me recently as I had a Scala trait abstract the async Postgres client lib I was using, then I hopped from one to another to another over a couple of years until just recently writing one because the others sucked for various reasons. Just make sure you have integration tests and you'll feel comfy in your choice.

<comment><USER15> I'd add consistency to the benefits: when I need leftpad and declare a dependency on "big bag of string stuff" for it, chances are high that codevelopers will pick it up when they need rightpad. Because the very first step in every library decision is "do we already have a dependency for that". Bespoke implementations would tend to end up all over the place.

</comment></comment><comment><USER16> Answering such questions is probably 50% of the job for a senior-level software engineer. And it's 99% context-dependent.

</comment><comment><USER17> For me, it's whatever I believe would take less time. I can write a left-pad function in less time than it would take to find the npm package, install it, import it and integrate it.

With more complex systems, how much integration/customisation is needed vs building something yourself?

Often I'll look for a library, find a few candidates that don't really suit well and 'resort' to committing to writing something myself. Similar to planning a project, it can take time to work out how much time something is going to take.

</comment><comment><USER4> I'm a library by default kind of guy, but it's always a series of trade-offs. For example:

\- how value adding is this functionality?

\- how well does the library meet my need?

\- is the library still under active development?

\- how stable is the library's API? (Building against an unstable API becomes a tedious waste of resources, fast.)

\- how good is the documentation?

\- is it popular/well-used? If so, this makes it easier to get help on Stackoverflow, or wherever, when I have a problem.

There are times where we've started out with a library, but moved to a homegrown implementation, or vice versa.

For example, we work with a lot of CSV input data. We started out with a library, because properly parsing CSVs is, well, not exacly tricky, but there are a pile of nuances and edge-cases you need to take account of. It was just much easier to use a library for this so that we could focus on adding business value elsewhere.

Anyway, the size of the files we needed to work with grew, so we swapped the original library out for a different, faster, library.

That worked well for a while, but then the size of the files we needed to work with grew again, and the library was too slow, so we swapped in our own faster CSV reader implementation for working with these large files.

We still use the library for other CSVs because our implementation makes certain assumptions about the content of the files that don't hold for the smaller files we work with.

</comment><comment><USER18> I'll use a library if it's at the extreme end of: mature, actively maintained, not buggy, general, and 'standard' for lack of a better word. Anything else I treat as a debt, to be avoided unless I'm desperate. And yes, I absolutely consider it a worse debt than anything I write myself, unless it meets the criteria above. Experience has taught me this a hundred times over.

<comment><USER19> Huh. Experience has taught me the opposite, that any code written in-house is more likely to be undocumented, untested, or buggy than a library used by many others. Especially in the case of a small team that has grown over 5+ years, where things devs write early on quickly become technical debt that few others can understand without the original context. Contrast that to using an import to a documented library where any new dev can quickly go and read the docs & examples and know exactly what it's for. The few cases where a package upgraded something which broke our code have always been easy to resolve by just downgrading the package.

<comment><USER18> If this hypothetical library is that good, then it probably meets your version of the general criteria I sketched. One problem is that it isn't always obvious what the quality is at the time you make the decision to take the dependency. I use size/complexity as a proxy for how much trouble it's likely to be.

</comment></comment></comment><comment><USER20> I don't think this can ever be totally cut and dried. There is a heuristic when either using external or developing one inhouse is obvious, but if neither applies then finding the best solution requires careful thinking.

The obvious place to develop a library inhouse is when there is no compatible third party solution available.

The obvious place to use a library is when one is available that a) Implements a feature that would requires weeks of work b) implements the specific feature one requires c) on the technology platform of the product d) is compatible financially and licensing wise

If a,b,c and d hold then third party library is a pretty good option. Depending on the complexity of the problem one might be really lenient on c) and do whatever to integrate a MagicalPixieDustGenerator no matter how badly it fits the current tech stack.

Code reuse is one of the silliest arguments ever for librarization. It's totally fine to replicate few lines of code, it's just typing. If you don't have tests to verify functionality you are screwed anyway.

</comment><comment><USER21> (1) I am writing a new React web-based LaTeX editor for CoCalc, and needed a PDF viewer. I first tried using the [https://github.com/wojtekmaj/react- pdf](https://github.com/wojtekmaj/react-pdf) library, which builds on top of Mozilla's pdf.js. It's useful code, but the library is designed in a way that is fundamentally very inflexible for my use cases. For example, it is critical for me to easily have multiple views of the same document, to easily be able to cache recently loaded PDF's, and to be able to reload a modified PDF with no observable flicker. I found trying to get any of my core requirements to work with this library to be a constant battle involving horrible hacks. So I had to sit down for a very long day and write something similar from scratch directly using pdf.js itself. So my answer: sometimes, at some levels, you have to implement yourself instead of using a library, when the library is not flexible enough and trying to use it gets really hackish.

(2) Another experience I had was when I started the SageMath project. I began with the plan to look at other code and implement everything myself, rather than use existing libraries. That lasted about an hour, since it was way, way too much work (to put it mildly). So I switched to using Python as the user language, then using as much as possible existing C/C++ libraries (like PARI/GP and GAP and Singular) to provide functionality. The result was again a combination of using libraries but also writing a new library.

</comment><comment><USER22> This is a complex issue that takes days of careful analysis to take a decision.

Long story short we implement something ourself if:

1.It is a differentiator for our company because 2.

2.We can make it better than available libs and 3.

3.Making it better represents a real change on our company or the world, changes like "It will make possible what was not possible" or "will halve the cost of X, because Y".

4.We need to parallelize-make it on hardware.

Implementing something inside is extremely expensive as requires salaries of highly paid people, makes those people unavailable for doing other things, and takes always more time than planned.

On the other hand with your own code you could do magic. You can hardware accelerate(with electronics and FPGAS) it to use 10.000, 50.000 less energy, or GPUs to make it 100-200 faster. You control everything to suit your needs.

We normally start using standard libraries and replace then slowly with our own code if it will make a difference.

We do the same with parallelization: we start with multiCPUs, then GPUs, then FPGAS. Then we can even think on offering investors the option of making ASICS if functionality is proven and very well tested.

Disasters? Yes of course. It is part of experience, they happen like great successes. When you risk you risk disaster, but you give yourself the option to success greatly too.

When I was a kid I learned to ski probably faster than anyone around. But it was because I did not play safe like most did and keep falling(at great speed) until I did not.

In life you could do the same.

</comment><comment><USER23> Use a library when:

1\. It would take a significant time (> a few days) to write yourself.

2\. The library is widely used.

3\. The library has a history of supporting major versions, you don't want breaking changes to come with security and minor fixes.

4\. The library is open source. Not always a complete deal breaker, but you need to think of long term costs.

5\. You're going to use a significant chunk of the library, don't import a big complicated library for a single function.

</comment><comment> V-2 The question is too vague. In what environment? Web? Desktop? Mobile? Embedded? Backend programming is a completely different world than mobile apps when it comes to build size concerns, for instance. As an Android developer, I have to deal with the infamous 64K methods limit imposed by Dalvik. The _" I import TONS of libraries"_ approach (to quote one commenter) is very bad practice here.

</comment><comment><USER24> I am not sure if there would be cut and dry rules regarding this. The rule of the thumb for my startup is to always use libraries for major functionalities and for minor functionalities we either lookup the source and use the required function or we implement it ourselves.

What works best for you might not be the correct answer for someone else.

For us, we initially used libraries for all lat/lon and distance calculations and then refactored to move the functions to our internal code and get rid of the libraries. For algorithms like DBSCAN , even if it's straightforward, it didnt make sense to re-implement it.

I guess it boiled down to the effort required to move inhouse vs the benefits

</comment><comment><USER25> I implement business apps for the business. Usually, I organize those apps into libraries.

Beyond that, if it's not core business logic, it gets downloaded.

</comment><comment><USER26> I think it depends on how long you want the software to last for.

At one end is a client wanting a quick mock up - yes use libraries.

At the other end is a surgically implanted heart monitor - please dont use a library that depends on an API call.

Using libraries certainly gets the job done quicker (in the short term), but it adds technical debt and brittleness to any project.

</comment><comment><USER27> Meta, but, things like pad-left and the other npm things are IMO an issue with the standard library of in this case Javascript. A lot of languages have a richer utility toolbelt atm. (this is also a problem in Java imo, where you basically need a few libraries for convenient string or collection utilities)

</comment><comment><USER28> Predict whether or not it will save you time. Note that while complexity is a part of it, it isn't everything. If it goes unmaintained and at some point you need to rip it out because your product needs to stay alive, it was unknowingly technical debt to begin with.

</comment><comment><USER29> Python use a library as they are well built.

Javascript build my own as they are not.

(Joke with a hint of a more serious problem).

</comment><comment><USER30> If I'm fine with supporting the library when it stops getting developed then I'll usually just use it.

I like this metric because it means I'm saving time just writing the same thing I would have written anyway.

</comment><comment><USER31> Opportunity cost: Can I spend my time on something more important ? Plus the cost of maintaining the code. Sometimes the module is not good enough though, and patching it would take longer then rewriting it.

</comment><comment><USER32> When the task at hand requires more than an hour or so of work.

But that is not the rule i work after, It just seams like that is how i work when i work now that i think about it.

</comment><comment><USER33> for things like security, storage, encryption, deployment&operations: use libraries

For everything else usually I have a simple flowchart: is it a core feature and a businnes advantage of the platform? Implement. Otherwise, if exists a library, use the library.

</comment><comment><USER34> Interesting question. As you mention, there seem to be a spectrum of potentially valid answers, depending on which individual, team, or even platform you ask / talk about.

Personally, I try to make an informed gut-feel decision about the short term and long term benefits of pulling in a library for anything. The main inputs to the decision are how difficult rolling my own would be, whether there are any complex risks (such as security implications I'm not well versed to handle, or other such topics), and how much use / mileage we will get out of the dependency. Very often this comes down to whether you've done something similar before, and are confident that you can handle it well enough. I think I tend to lean towards rolling my own, or "NIH syndrome" a bit more than the average developer, but this is for a few reasons. Take this with a pinch of salt, and for context, I would of course agree with not rolling your own crypto, etc - I'm mainly referring to the gray area in the middle.

1) It's usually quite difficult to find a library that nails the level of complexity vs pay-off that I want in a solution. Most of the time, libraries that I find are a complete overkill for my usage, or have large surface areas that I don't need / want. If I can roll a custom implementation in under 50 lines of code, I will generally do so.

2) While you often get immediate payoff for pulling in a dependency, that payoff very often turns around and becomes a net loss of time the moment you run into a complex problem. Pad-left is a silly example, but I think we've all encountered situations where we pulled in some library only to run into a strange edge case. Having wasted a day, you're then thinking "I honestly could have done this better, given a few hours".

3) This point tends to depend a lot on the exact environment you're working with, but managing dependencies can be pretty painful. As a simple example, I've had a number of Angular and Ionic projects with a large number of dependencies become extremely non-trivial to upgrade. If you're talking about a small number of such projects which are frequently worked on (say, flagship apps of a startup), I suspect this is not much of an issue. When you're dealing with dozens of apps for a large corporate, some of which may only get attention in a year or so, this can be a painful burden. A hilarious parody of pad-left is "is-thirteen" [1], which drives the point home for me.

4) Rolling your own also tends to architecturally firewall your implementation (if you've done it right). I.e. it is easier to take your custom implementation and just point it at a 3rd party library, than it is to migrate from library A to library B, if you haven't firewalled them nicely.

The number of times I've regretted rolling my own has been far outweighed by the number of times I've pulled in the wrong dependency.

In summary or as examples, I would never willingly pull in "pad-left", would always stick with a well known UI framework rather than roll my own (primarily for various security reasons), but have written simple templating engines, markdown parsers, etc, without regret. On the other end, I would never roll own crypto, and would be highly hesitant to even come up with my own crypto schemes involving well-implemented crypto, as those can be just as weak.

[1] [https://github.com/jezen/is-thirteen#is- thirteen](https://github.com/jezen/is-thirteen#is-thirteen)

</comment><comment><USER35> Always, always use a library unless you can't.

</comment><comment><USER36> I import TONS of libraries and try to write the fewest lines of code possible.

<comment><USER37> Not sure why you're being down-voted, but if done intelligently, and assuming good-quality libraries, the goal should be as few lines of code that you are directly responsible for.

</comment></comment><comment><USER38> I've been thinking about this a long time[1][2]. At the moment, I think "build or reuse?" is the wrong question to ask.

* Reusing someone else's implementation gives you the benefit of an initial kickstart. It also can give you future benefits: a library may contain improvements that you may need in the future, at which point you get them for free. Infinite productivity!

* Building your own implementation has an initial cost, but it reduces your maintenance burden to only the features you actually use. It also insulates you from counterparties whose interests may not align exactly with your own, or who accidentally introduce security risks.

If only we could magically unbundle the benefits of other people's code from their limitations, have features magically appear when we need them, and be magically robust to security holes in features we don't use. Here's the closest I've been able to get so far:

 _Use libraries by copying them._

Let's see why this is good. For starters, it makes you robust to the leftpad failure mode. The library is literally copied into your repository. Who cares how small it is anymore?! It could literally vanish off the face of the rest of the earth, and your code would continue to work.

A less obvious benefit is that copying a library puts you on a trajectory of _taking responsibility_ for your dependencies. You don't need to understand all of it on day 1, but as you use it and run into issues you should be gradually understanding its internals better, gradually resolving features that you use, and features that you don't. That then gives you the option to rip out stuff you're sure you'll never need. Or to rip out stuff you may need in future, but is easy to put back (this is analogous to deleting code without fear because version control).

I consider an example of exemplary library use to be how I copied the termbox library into Mu ([https://github.com/akkartik/mu/commit/5f1285238b](https://github.com/akkartik/mu/commit/5f1285238b)), periodically merged commits from upstream ([https://github.com/akkartik/mu/commit/9ba313ab7f](https://github.com/akkartik/mu/commit/9ba313ab7f)), gradually cleaned it up to fit better with my project ([https://github.com/akkartik/mu/commit/9a31c34f0f](https://github.com/akkartik/mu/commit/9a31c34f0f)), and gradually stripped out code from it that Mu does not require ([https://github.com/akkartik/mu/commit/c04baba4f2;](https://github.com/akkartik/mu/commit/c04baba4f2;) [https://github.com/akkartik/mu/commit/8e7827dfcf;](https://github.com/akkartik/mu/commit/8e7827dfcf;) [https://github.com/akkartik/mu/commit/547ec78bf2](https://github.com/akkartik/mu/commit/547ec78bf2)). In the process I made some wrong turns, deleting features that I later decided I wanted ([https://github.com/akkartik/mu/commit/10a3b8cca2](https://github.com/akkartik/mu/commit/10a3b8cca2)) and created bugs for myself ([https://github.com/akkartik/mu/commit/3315a7d3bb;](https://github.com/akkartik/mu/commit/3315a7d3bb;) [https://github.com/akkartik/mu/commit/0c0d1ea5cd](https://github.com/akkartik/mu/commit/0c0d1ea5cd)). But when it did things I didn't want, I was now empowered to change them ([https://github.com/akkartik/mu/commit/ee1a18f050](https://github.com/akkartik/mu/commit/ee1a18f050)). One of my patches was useful upstream, so I submitted it: [https://github.com/nsf/termbox/commit/0730826a07](https://github.com/nsf/termbox/commit/0730826a07). I would be in no position to submit that patch if I hadn't taken the trouble to understand termbox's internals. And that shows a final benefit of copying and privately forking libraries: it makes you a better citizen of the open source world, because open source depends on _eyeballs_ , and using a library _blindly_ helps nobody except your (extremely short-term) self.

Now you may say, this sounds like a lot of work. I can't do it for all the libraries I use. Start small. Pick one dependency that is pretty central to your project, bring it in. See how you like it. As you gain experience come tell me what you discover. (My email is in my profile.) I didn't have all this thought out when I copied termbox into Mu. Benefits gradually became apparent.

[1] [http://akkartik.name/post/libraries](http://akkartik.name/post/libraries)

[2] [http://akkartik.name/post/libraries2](http://akkartik.name/post/libraries2)

(Past versions of this comment: [http://arclanguage.org/item?id=20213;](http://arclanguage.org/item?id=20213;) [https://lobste.rs/s/w4auk6/more_shell_less_egg_all_this#c_nv...](https://lobste.rs/s/w4auk6/more_shell_less_egg_all_this#c_nvhdaq))

</comment><comment> cup-of-tea There are a couple reasons I can think of to use a library:

* The code is the best in the world and would take anyone years to compete with its speed. Libraries like gmp, fftw etc come to mind.

* The API is good. A good API extends the language in a way that makes your code better and more enjoyable to write.

I usually try to avoid dependencies where possible because it will always make life easier later on. Introducing a dependency for a single function should be a sackable offence imo. At that point you're just too lazy or incompetent to do your job.

<comment><USER39> Why waste time rewriting something like leftPad?

<comment><USER40> leftPad is an exceptional case because 1° it should have been part of the standard library and 2° it is a library that only contains one function.

<comment><USER41> Calling it a library is a stretch.

The whole leftPad controverse makes a pretty good case for rewriting. It would have saved many people a lot of trouble.

Also, if you know your langauge, rewriting it is probably faster than finding, installing and using a package.

<comment><USER39> The trouble with leftPad was a flaw of NPM which could have happened with any package.

</comment></comment></comment></comment></comment><comment><USER42> > Has there ever been a case where you've tried to roll your own and it ended > in disaster?

As far as I remember, it's always the other way around. But I have enough sense to not implement my own cryptography library and use it in production.

> Or where you'd wished you'd never added a dependency on some library?

That happens a lot, or more frequently it's some library already being used that is overcomplicated and won't work with something else I need it to work, like a build tool, or is in a cross platform language like node but doesn't work on one particular, major OS. But when this happens it's maybe never the case that it would have been reasonable to write it myself. I just have to find a less shitty alternative library.

In general, it's blatantly obvious when you need to do which, you have more much bigger other problems, the chance of this issue even popping up is pretty low, and the resolution is probably fairly straightforward.

</comment><comment><USER43> The NPM ecosystem is on the extreme end of micro-libraries, so sometimes I will just inline a library's code into my project when the indirection of using a library isn't worth it.

For every library you use, you are now trusting everyone that has publish rights to that library and all of its transitive dependencies, so libraries aren't free.

Also, sheepishly, it's so easy to publish on NPM that I'll sometimes just re- implement a library with my creature features and publish it instead of making a case for them in the existing library's issues. Awful, I know.</comment>


People Choose News That Fits Their Views - <AUTHOR> http://www.livescience.com/culture/090608-media-message.html <comment><USER2> Yes. To have all my beliefs challenged by every piece of news I read would be exhausting. Most of the time I want to read news written by someone who shares my basic worldview.

In fact, the perfect news item is one that is indistinguishable from the one that would have been written by me, had I been there. That's the perspective I want.

That's not to say I don't welcome learning about opposing viewpoints, but for something that challenges me deep, I'd prefer to read a book, than a bunch of news items.

</comment><comment><USER3> And with the advent of the internet, that has become so much easier. We can find whatever niche we want and create our own echo chamber.

Before the internet, newspapers had to operate somewhat similarly to how our political parties operated. You had to offer enough to all people in your area that you'd be financially sustainable. Jonathan Sarna (a professor at Brandeis) has talked about this as to why US politics doesn't have the fringes that Europe does. Because American politicians are elected locally (for the most part), it becomes suicidal to be fringe. Sure, maybe 10% of the country agrees with you, but never 50% in any given area - no matter how liberal or conservative. By contrast European countries generally give a party representation in proportion to their take at the polls - even if they don't win a single district.

The internet is like that European system. There might not be enough in one area to support niches, but there are across a larger population.

And, to be honest, I find this a little troubling. On the positive side, there are more beliefs able to be published and heard. But really, what seems to happen is that the beliefs aren't heard wider - just more often by a sub group. And there are such things as wrong beliefs. Things that are scientifically inaccurate or something we might deem terrible for society (for example, I fell very comfortable saying that Nazism is a wrong belief). Before such echo chambers, there were at least buffers where one would have to hear wider (one could criticize, mainstream) views and wouldn't have people backing up their view constantly (or at least not exclusively).

It's quite the double-edged sword. I can understand why people like reading HuffPo or Fox News, but it can be somewhat dangerous. There's a great sorting trend happening in America where we surround ourselves with those who think only like us. Lack of contact with people who think differently both makes us demonize them (even if it's only to the "how could they think that" extent) and makes us very vulnerable. The second part needs some explanation. This makes us vulnerable in the same way that genetic engineering (or lack of bio diversity) would. Are we so arrogant (on all sides) to think that we have _the_ answer (to life, the universe, and everything) that it wouldn't be good to hedge our bets?

I'm not saying that it's terrible or anything, just that one has to be careful about only thinking one way. If we aren't careful, we'll become people analogous to hammers and miss the solutions that aren't nails.

</comment><comment><USER4> I wonder if there's a potential web app here. Something like Crossfire was for TV, just less "fueling the argument" and more "getting both sides of the story."

<comment><USER5> Microsoft Research has developed an interesting experiment along those lines, which unfortunately remains offline, although someone has registered the domain: <http://research.microsoft.com/en-us/projects/blews/>

</comment></comment><comment><USER6> I can't say I'm surprised really, surely it's just another example of confirmation bias?

<http://en.wikipedia.org/wiki/Confirmation_bias>

</comment><comment><USER7> I think this study is flawed based on their sample which was college students. Anyone who has read something they don't agree with realizes it creates an emotional response. At the same time people tend to be more emotional when they are younger. Paticularly in College where most people see politics as a way to "change the world"

So a conclusion based on college students doesn't really impress me. Of course very emotional people are going to avoid things that cause a negative emotional response

I guess it does tell us that the emotional side of us seeks out like minded people but that seems like common sense to me. Part of being an adult is realizing your emotions shouldn't dictate what you do and seeking out thoughts you might not agree with. Not every adult does it but every adult should.

<comment><USER8> We can use our emotions as a shortcut to save on processing time. Whether or not that shortcut leads us to the correct answer is a different question. Emotions are not _bad_ , they are just often dangerous when dealing with situations outside of our evolutionary context (groups of at most 160 hunter- gatherers, etc.).

</comment></comment><comment><USER9> I've just read "The People's Choice" by Lazarsfeld et al. which was published in 1948. It's about the US presidential election of 1944 – really old and a social science classic.

By repeatedly interviewing 600 people in Erie County, Ohio, they wanted to find out how and why opinions change (and don't) during a presidential campaign. What they found out was surprising: mass media had very little influence and generally didn't change opinions. It activated voters (with predispositions). It reinforced them (after they made up their mind). If anything changed votes then it was interpersonal communication.

If such a old study already looked at whether people pick media according to their views I find it very hard to imagine that this is really news.

</comment><comment><USER10> A more quantitative look at this same thing. Basically saying that people pick what interests them. This is pretty technical, but by some pretty smart people:

<http://home.uchicago.edu/~jmshapir/bias.pdf>

And, my own experiment with media influence. This counteracts both the master link and the link above. My short experiment has correlation to show that the media has more influence on public perception. Though, this was just a proof- of-concept and not a vetted research project:

<http://publicthoughts.com/media-affects-opinion/>

</comment><comment><USER11> The Economist had a feature article a while back, which cheekily said _IIRC_

"[The British] like newspapers, especially those they agree with"

</comment><comment><USER12> If this article is true, than what kind of people would choose to read this article?

<comment><USER5> Elitist jerks who like to believe they're superior to the great mass of people. I, on the other hand, didn't bother because in my infinite wisdom I already knew this fact to be true :-)

</comment></comment><comment><USER13> This just in, the sky is blue!</comment>


Frequent, Intense Mature and Suggestive Themes - <AUTHOR> http://www.marco.org/2012/03/03/frequent-intense-mature-suggestive-themes <comment><USER2> Uneven enforcement and a lack of transparency are (to my mind) the two leading causes of a perception of unfairness. If Apple is going to continue with a relatively low level of transparency (which seems to be almost a given, considering its corporate culture to date), it is even more beholden than most to try to stamp out uneven enforcement.

<comment><USER3> While the lack of transparency is a leading cause to the perception of unfairness, I'd say the uneven enforcement is actually unfair.

As long as you can submit apps and not be able to fairly accurately predict how it will be rated it won't just be seemingly unfair, it will be unfair.

<comment><USER4> Every rating system is like this. Censorship is arbitrary. Check out the MPAA giving an R to Bully, a documentary about high school bullying targeted at high schoolers. Well, not anymore.

</comment></comment></comment><comment><USER5> I couldn't agree more with Marco. The App Store rating system is confusing and down right ineffective. It consistently hurts developers and does little to help consumers. Apple really needs to bring some clarity and common sense into the rating system.

</comment><comment><USER6> "You never know who could be lurking on ping". Classic. This should also apply to FaceTime, Messages, phone calls and text messaging right?

<comment><USER4> I am fairly certain that nobody lurks on Ping. They don't even visit for sightseeing.

</comment></comment><comment><USER7> Yeah, it's essentially meaningless to give content ratings for apps that can access the entire web. If you're a parent, you either do or do not think your kid can cope with _all_ user-generated content from outside the walled garden. Which suggests a business opportunity for whitelisting sufficiently heavily moderated services for fundie parents.

<comment><USER8> This exists. It's called proxy filtering.

<comment><USER9> But does it exist in an easy-to-use app that a non-techno-geek parent can understand and hand to their child confident that the kid can then visit the "safe" (and only the safe) parts of the web? If not, then creating said app is a business opportunity. Parents would pay for it.

<comment><USER10> Yes and no. It's relatively easy to set up an HTTP proxy (and I can think of several ways it could be made plug-and-play for non-geek parents). However, _enforcing_ the use of the proxy on the client is basically impossible. Mandatory group policies come close, but if the kid can get admin they can just turn it off (and lets face it, they've got physical access to the client, if not the proxy server).

Probably won't stop parents paying for it, though :)</comment></comment></comment></comment>


Triangle Startup Factory is returning - <AUTHOR> http://trianglestartupfactory.com/2011/06/accelerator/

<comment><USER3> Consider incubating a startup providing PR services: [http://en.wikipedia.org/wiki/Triangle_Shirtwaist_Factory_fir...](http://en.wikipedia.org/wiki/Triangle_Shirtwaist_Factory_fire)

<comment><AUTHOR> Interestingly enough, I'm probably more likely than most people to draw that connection, having been a firefighter for a very long time... and something of a fan of the history of the fire service and related topics. I've read many accounts of the Triangle Shirtwaist Factory fire... and the similarity between the two names never crossed my mind.

Obviously it does for some people... after all, you picked up on it. But I strongly, strongly suspect that very few people will look at Triangle Startup Factory and make any sort of connection with that incident. Hell, I doubt most average folks off the street even know about the Triangle Shirtwaist Factory fire.

<comment><USER3> My impression is that it's a historical milestone for anyone with a strong belief in labor laws, union politics and so forth. At least, it was from such people that I heard about it in the first place - I'm not American so I would not have come across it in school.

It strikes me that you're likely to receive some extremely hostile publicity if someone thinks you're leveraging the (perceived) familiarity of the term as a branding mechanism - you'll be demonized as a stereotypical callous capitalist milking the suffering of the helpless workers for a quick buck and so forth. That this isn't your intention at all would be beside the point if someone chooses to get worked up about it.

<comment><AUTHOR> _My impression is that it's a historical milestone for anyone with a strong belief in labor laws, union politics and so forth. At least, it was from such people that I heard about it in the first place - I'm not American so I would not have come across it in school._

It is, but emphasis on _historical._ That happened 100 years ago, and - <USER2> historical events go - it doesn't seem to be one that's at the forefront of the average American's consciousness, at least not that I've noticed.

 _It strikes me that you're likely to receive some extremely hostile publicity if someone thinks you're leveraging the (perceived) familiarity of the term as a branding mechanism - you'll be demonized as a stereotypical callous capitalist milking the suffering of the helpless workers for a quick buck and so forth. That this isn't your intention at all would be beside the point if someone chooses to get worked up about it._

Well, it's not my project and I don't have any say in it; so I guess they'll have to take their chances. But I really don't think it will ever be an issue.</comment></comment></comment></comment>


She Won Athletes' Hearts. and Robbed Them Blind - <AUTHOR> https://www.si.com/nba/2019/09/19/athete-financial-advisor-embezzlement-fraud-scandal-peggy-ann-fulford <comment><USER2> This article is super long, doesn't get to the point and the banner image alone must be over 5MB.</comment>


Ask HN: Did you quit your full-time job? - <AUTHOR>

A lot of us on HN toy with the idea of leaving full-time work for more freedom. Be that freedom part-time work, consulting/contracting, a start-up, or what have you, for many of us it remains but a dream (with all the rosy characteristics of a dream too).
I would love to hear more personal stories from people who have taken this path. I'm equally interested in successes and failures. I'd love to hear from young and old, single and married, no kids and multiple kids.
Thank you in advance for sharing! <comment><USER2> I left work in a way that I believe is less cold turkey and helped ease the transition. Instead of quitting, I told my supervisor that I would like to work as a contractor. My reason for doing so was to live elsewhere and be more flexible with my schedule.

Since I was so valuable to the company at the time, they were just happy I wasn't quitting. After a few months of contracting I told them I was done and by then I had other opportunities come my way. It worked out very well.

</comment><comment> atom-morgan I may be able to add more later this week. Right now, I'm planning on leaving my job this Friday with no job offers lined up. Not sure what I'm going to do just yet. I've submitted my resume to a few places in town. Perhaps I'll try freelancing if things get too bad.

</comment><comment><USER3> \- Yes. 3-4 years ago. Do you mind doing a poll?</comment>


SemanticMerge now supports Java - language-aware merge tool - <AUTHOR> http://www.semanticmerge.com/java.html <comment><AUTHOR> We first launched C# support, a few weeks later we went for Vb.net and now we step out of the .NET framework to release Java support.

Semantic is a free beta and we're giving unlimited licenses to coders sharing feedback.

We're now starting to work on C and then C++ (both using libclang) and hopefully able to handle the Mac OS GUI request soon too (<http://plasticscm.uservoice.com/forums/196398-mergebegins>)

Thanks!</comment>


Show HN: EventControl, jQuery timeline control with support for stacking events - <AUTHOR> http://www.kri.gs/eventcontrol/ <comment><AUTHOR> I created this simple timeline control for use in Hawk [1]. The existing timeline controls I could find didn't quite do what I needed, and they were all much larger than I found acceptable. For example vis.js [2] does do what I need, but even stripped down to just the timeline control, it's still over 600k. My control is about 14k and compresses to 2.5k.

[1]: [http://hawk-ui.github.io](http://hawk-ui.github.io) [2]: [http://visjs.org](http://visjs.org)</comment>


Show HN: KAPTL – Three-Tier Web Apps in Minutes - <AUTHOR> https://www.kaptl.com/

<comment><AUTHOR> KAPTL produces an MSSQL/Entity Framework/Web API/Razor app on the fly and lets the user download the source code. We're considering adding an optional AngularJS frontend as well as offering a NodeJS and Python backend alternatives to ASP.NET MVC. Would love any feedback!</comment>


Transformation - <AUTHOR> http://www.oreillynet.com/ruby/blog/2006/03/transformation.html

<comment><USER2> I can admit that Ruby completely sidesteps a lot of the problems you might see in Java--but that doesn't mean you can't write bad code in Ruby.

The meta-programming tricks, continuations, and dynamic calls to private methods are rife for abuse by mediocre programmers. While Ruby has a great syntax and libraries, it seems easy to use and read largely because the current leading-edge crop of Rubists that write the libraries we use are great programmers with discipline and taste.

</comment><comment><USER3> Great article, but it seems to point out the flaws in some languages and how to avoid or go back and fix them ...

Isn't it better to start with a language that naturally helps you avoid those problems and reduces the need for re-factoring in the first place?</comment>