Why I vertically align my code - <AUTHOR> https://shkspr.mobi/blog/2014/11/why-i-vertically-align-my-code-and-you-should-too/ <comment><USER2> I've been programming for a couple of decades commercially, and for three decades overall, and I've found that whether you use or don't use a particular code 'style' matters little for readability and maintenance purposes compared to how well the source is architected and the system designed as a whole. The eye and brain can 'deal' with a lot of different spacing and alignment automatically; OTOH, working out how the code holds together, what data is changed and when, etc, takes real processing power. I'm not worried about expending tiny amounts of thought and processing energy, only lots of it.

In the general case, find a coding layout style that seems reasonable and go with it; if you are working with others this will probably mean looking at the established code base and extracting the important style elements. Time is short; spend it on more important decisions about software structure rather than deciding what bow tie it's wearing that particular day.

</comment><comment><USER3> This should be handled by a code formatter, such as "go fmt". Go aligns structure definitions that way. For C and C++, there's "artistic style" ([http://astyle.sourceforge.net/](http://astyle.sourceforge.net/)). For maintenance purposes, it's useful to have all the modules aligned the same way. Yes, somebody will whine about it being different than "their style". Pick one and go with it for the whole project.

<comment><USER4> Formatting -IMHO- depends on context. I have one convention I generally use which is chaining methods together on one line, but when chaining together builder method call I make one line per call. That means the semantics not the syntactics of the code determine my formatting. For this reason I abhor auto formatting code unless it is currently like an unrecoverable mess (ie NO thoguht put into it, not just "not my style"). Honestly, put your curlies wherever you like them, then don't effect readability as much as lacking comments or convoluted flow.

<comment><USER5> Thank you - go fmt sucks. I hate K&R parameter layout, and I hate long lines that scroll off to the right of the screen.

<comment><USER6> Yes, but it's nice to save my code and have it formatted "the official way". It gets old debating over which standard to use. Who cares what you like. Just pick a standard for every language and get used to it. It's really not that hard.

</comment></comment></comment></comment><comment><USER7> The appeal to needing better tooling is reasonable, but why should the results of the tooling be hard-coded into the text file? I don't have a great answer, but basically anything you want to do with the presentation of source code can be done anywhere in the stack. Your editor could non-destructively display a series of variable assignments with vertically aligned values like the author prefers. And of course, on the author's side of the argument, git can show diffs ignoring whitespace.

It seems like the best solution is for everyone on a project to agree to some canonical representation to be hard-coded in the source files and versioned. What that canonical representation actually is isn't super relevant, although I would prefer something easy to read in plain uformatted mono space, for places like GitHub where developers probably don't have presentational tooling in place. What's important is that the canonical representation is agreed upon. It could even be enforced by shared git hooks. Then each developer can use their client side tooling to display the code in any presentation they please.

</comment><comment><USER8> I find that vertical aligning is great if all the lines (variable names) are of similar length. If one is way longer than the others, then it actually gets harder for your eyes to trace from one (short) variable name to it's value (that is relatively far away because of the outlier), when the shorter ones are all next to each other.

I don't think the solution to this problem is adding spaces to the files, I think it's an IDE/text environment problem.

If you use a configurable text editor (you should be), then just download or write whatever plugin will subtly highlight the line you're on.

<comment><USER9> > I find that vertical aligning is great if all the lines (variable names) are > of similar length.

I agree that when a few variable names are very long that it can actually make readability worse.

I vertically aligned for about a year to see if it helped my code quality. In the end, I found that reading a value right next to a variable was easier.

The other think I did was to vertically align related variables/values, and put a blank line between unrelated vars so they had their own alignment.

In the end, I did not find any improvement in my code (just my personal experience).

</comment></comment><comment><USER10> Ah "readability" the favored haven of those with no clear objective criteria.

There is one clear justification OP can provide for this style element. HE/SHE/THEY THINKS IT LOOKS PRETTIER! Just say so, call a spade a spade. If OP is honest with themselves then they can seek help for their terrible editing choices. Otherwise you just end up with the the tired cycle below.

1\. Trot out your aesthetic preference.

2\. Speciously connect it with something that has merit(e.g. lining up numeric values in spreadsheet, which BTW has value because those numbers are in an nXn space delimited grid where position implies meaning.)

3\. Use the 2 steps above to make a pitch for forcing everyone to use your tool du jour or to shove this as a style guide element down your dev team/projects/friend/significant other's throat.

From my experience this silly style element serves one purpose making that one person with OCD feel better. For everyone else its a headache. It causes source control to lose its mind, it makes block editing trickier, all while simultaneously providing no tangible benefit.

<comment><USER11> Readability is a very worthy objective. And alignment has been used since before Gutenberg in text layout. Almost all code uses vertical alignment to some degree, whether its indentation, aligning braces or what have you. Aligning variable assignments in a grid is a natural extension particularly where those variables are interdependent (ie. changing one value is likely to require altering another in tandem) or where the variables are part of a formula where quick scanning of the values aids comprehension.

So it has its uses. Personally, I use it where it makes sense, organizing blocks of related variables together, and changing the alignment occasionally as needed to accommodate longer variable names. It's not OCD at all, and I for one find that developers who care about how their code looks end up producing better, more successful projects. Well laid out and highly readable code is, to me at least, one of the hallmarks of a truly skilled programmer.

<comment><USER12> Books don't have syntax highlighting. Why does adding a bunch of whitespace to a line make it faster to read than syntax highlighting?

<comment><USER11> Because syntax highlighting serves a completely separate purpose. Books that contain collections of related data points frequently _do_ use a tabular presentation. Syntax highlighting provides visual cues for the role that a particular keyword plays in the language syntax.

<comment><USER12> That was my point – syntax highlighting is suited for code. whitespace for readability is more suited for books.

</comment></comment></comment></comment></comment><comment><USER13> Has anyone tried to store/diff/share code as ASTs, and allow each individual user to apply formatting rules?

I guess (apart from the tooling effort involved) the problem would be that all rules have some exceptions, which you'd need to track somewhere as metadata, and that might scale with number of users.

I suppose it might also cause problems in pair programming / 'hey come look at this' reviews if you have radically different formats for the same code, but really, the only person who should care about your indenting style is you.

<comment><USER14> _Has anyone tried to store /diff/share code as ASTs..._

This is such an interesting idea I had to respond. To point out that it could go well beyond formatting, to variable and function names as well. With an AST-aware editor, I could even have multiple "views" on the same code; e.g., a crunched version with abbreviated names for a high-level view, personally styled library calls, curried functions, all sorts of things.

It wouldn't require too much bookkeeping to track that sort of information per-programmer. I think it's a fascinating idea. I haven't looked into the implementation of syntax highlighting in current editors; I wonder if the infrastructure is already part-way there.

</comment></comment><comment><USER15> I like to format my code in ways that make it more readable, too. Vertical alignment is one way. I'm familiar with the arguments against it, but it always seems to come down to the limitations of source control tools.

My half-fix: make functional changes in one commit, formatting changes in another, with a simple comment, "formatting".

<comment><USER10> Firstly, this doesn't solve any problems. It actually adds another a fragmented history.

Secondly, this is not a limitation of source control tools its a limitation of formal logic.

Vertical alignment's benefits are absolutely minimal. What is the ROI? How many bugs can be traced to "Lack of vertical alignment"? How many programmers have uttered the phrase "That vertical alignment really saved my bacon on that one"? Answer NONE! Its entirely aesthetic. I agree it looks nicer, but a Geo Metro modded to look like a Ferrari isn't any faster because it "looks faster"

</comment></comment><comment><USER16> I'm going to take issue with the given trivial example. So you've got this:

        int robert_age     = 32;
        int annalouise_age = 25;
        int bob_age        = 250;
        int dorothy_age    = 56;

And it's supposed to be easier to tell that bob_age is out of place because all of the numbers are in a column. Technically, that's so, but I don't think this is a good way to set things up in any modern programming language.

If you're defining as separate variables four different things, all of the same type but all typed as individual variables of a basic type, then you already have a problem, long before you decide how to align them. If they're that similar that you can easily notice that kind of inconsistency, then those numbers ought to be in some kind of data structure - an array, or they should all be objects or something holding the name and the age. Exactly how to set that up varies by the language and the problem domain, but I can't think of any language where there isn't a better way to do it than that

Meanwhile, things that actually should be separate integer definitions like that don't have any direct connection to each other, and so you can't trivially tell that something is wrong by looking at a column of numbers.

</comment><comment><USER17> There's a point in the article where the author calls me and others "poor condemned souls" who "argue for the eugenic purity of proportional fonts".

Obviously, I've never said such a thing, and at first I took some offense even though it was just a bit of hyperbole.

I wrote a fairly harsh reply here and I'm taking the opportunity to edit it to be a bit calmer.

Although I prefer proportional fonts, I've always been respectful of those who prefer monospaced fonts. I recognize that most programmers use monospaced fonts and I have no quarrel with that.

In fact, one of the explicit goals of my indentation and whitespace style is to be equally readable in monospaced _and_ proportional fonts.

Life is full of tradeoffs, and here one of them becomes apparent. If you use column aligned code, you give up readability in proportional fonts, and also, as several others pointed out in these comments, you give up ease of editing and diffing. And while the alignment makes vertical scanning easy, it makes horizontal visual scanning more difficult.

Column alignment has a strong appeal nonetheless. I used column aligned styles exclusively for probably 20 years or more. After all, my second language was assembler! But about 15 years ago I experimented with using indentation only without alignment, and I quickly found that the advantages of giving up alignment outweighed its advantages for me and the people I worked with.

I've noticed that hardly any of the developers I work with today use column alignment in their code, and they all use monospaced fonts. Now I'm curious to ask them if they just never used alignment, or if they used to use it and stopped as I did.

<comment><AUTHOR> As you can see from the article, I'm using dramatic hyperbole to demonstrate that fanatical devotion to _either_ side is ridiculous. While I prefer alignment, I have neither the inclination nor the power to force my personal preferences on anyone.

I'm happy to remove the link to your comment, if you would like. I've no wish to cause you distress.

I don't particularly care whether one uses proportional or monospace. Mind you, I'm sure we can all agree that anyone using Comic Sans should report to a re-education camp.

<comment><USER17> Ha! Yes, perhaps we agree more than we realize, at least on _something_. :-)

Sorry I overreacted. Tell you what, leave the link and the hyperbole, no offense taken. And I'm going to take the opportunity to edit my comment above to be a bit less over the top in the response.

</comment></comment></comment><comment><USER18> If you have effective syntax highlighting the benefit in his trivial example disappears. In cases like that you can quickly scan up a line of numbers because they appear very different from the identifiers and it does not matter if they are lined up.

Though such a solution has exactly the same edge case as vertical alignment: when the identifier lengths are very different things get hard to read. In which case it seems much more useful to be able to easily match identifier with value, rather than be able to scan values.

This is just me taking issue with the trivial example though. Even though it seems to be impossible to get a whole team to set up their formatters the right way, vertical formatting is pretty much a must for tabular data like 2D arrays.

(On a different note I am pretty sure that the kernel style guide is one of the most controversial in widespread use. It works because it is very strictly enforced. Not a good place to draw examples from)

</comment><comment><USER12> This runs contrary to the final bullet point under Pet Peves in the style guide for python.

[https://www.python.org/dev/peps/pep-0008#pet- peeves](https://www.python.org/dev/peps/pep-0008#pet-peeves)

<comment><USER15> This is one thing that has always bothered me about the PEP style guide.

<comment><USER12> From an OCD viewpoint, I agree. But with proper syntax highlighting you can easily parse through variables and their assignments visually.

Also, if you line up variables vertically, you should do the same with dictionary assignments, which is also a bad idea IMO.

</comment></comment></comment><comment><USER19> _I can easily see that everything there is an integer without having to slide my eyes around._

Doesn't this contradict his point that:

 _Reading code isn 't much different from reading prose._

since we're already used to reading both horizontally and vertically? I'm not saying that we should get rid of indentation and just write all code like prose - in particular, nested structures are clearer with indentation to denote the nesting level - but I definitely don't consider a series of variable declarations and values to be columnar data that requires vertical alignment.

 _If our tools make understanding those ideas more difficult, it 's the tools which need to change - not us._

On the other hand, the use of more advanced tools, particularly by beginners, tends to encourage a dependence on them and a more superficial "understanding" of the code (I'll argue that the understanding has been shifted to understanding the tool, and not what it works with.) Many of the most concise and elegant solutions I've come up with were the result of deep thinking and the use of pencil and paper, or a whiteboard, instead of an IDE or even a text editor. I am reminded of this article which has the same opposing view: [http://www.linusakesson.net/programming/syntaxhighlighting/](http://www.linusakesson.net/programming/syntaxhighlighting/)

</comment><comment><USER20> I guess the argument makes sense if the data you're aligning is actually tabular in nature, like a spreadsheet but in my experience, that's quite rare. Even then wouldn't right aligned numbers look more natural? Aligning might more often imply a relationship between data that isn't really there. I personally don't think its worth the effort. If you do like it, make sure to use spaces instead of tabs :)

</comment><comment><USER21> I have a coworker who sometimes vertically aligns code. It's frustrating having to edit his code because I have to choose between just making my changes and ruining his vertical alignment, or having to spend time realigning things. It's not a part of our coding standard.

<comment><USER22> Do you mean that it is contrary to your coding standard or merely not required. If it is contrary to the standard then he should stop doing it.

</comment></comment><comment><USER23> The author kinda contradicts himself by saying you should vertically align your code, but then says use proportional fonts if you find them more readable. (Not to mention, proportional fonts don't allow you to vertically align things well)

is it more common to align the values left or right with decimal places?

eg

      var foo =  1000;
      var bar =    10;

vs

      var foo        = 1000;
      var longerName = 10;

<comment><AUTHOR> (Author here) You're right, it _is_ contradictory. We'll never reach a perfect blend of universal readability an personal preference.

That said, I like the alignment of your first example. It depends heavily on the context of those variable, naturally.

</comment></comment><comment><USER24> I very rarely need to compare variable values to each other in a vertical list. I frequently need to read what the values of individual variables are.

Variable organisation should therefore make horizontal reading easierat the cost of vertical reading.

</comment><comment><USER25> This behaviour promotes scanning instead of reading. If you make assumptions that:

        var totalBi11 = apply_tax(initia1Bi11, taxRate);

actually does what it says, you might miss something obvious.

I also think if you have four temporary local variables:

        int robert_age     = 32;
        int annalouise_age = 25;
        int bob_age        = 250;
        int dorothy_age    = 56;

then you're missing a trick for a better data structure.

If you never _have_ a bunch of local variables, then you'll never need vertical alignment. I think it would be a lot easier to have a discussion about this with a less contrived example.

<comment><USER26> Why are you arguing against clear code that tells what you are doing? Imagine if you used a library with a function called sortAlphabetically that didn't sort items alphabetically, it wouldn't make sense.

Regarding the alignment, there will be situations where there will be multiple similar lines of code that would benefit from being blocked together with vertical alignment. Not only in the case of temporary local variables. Imagine a situation where a bunch of constants for an API are defined as such:

      #define kURLAPIBase      @"http://google.com"

      #define kURLAPIGetUser   @"/getUser"

      #define kURLAPIGetPosts  @"/getPosts"

There are numerous possible situations where things like this can occur. You seem to be arguing for the sake of argument here.

<comment><USER25> > Imagine if you used a library with a function called sortAlphabetically that > didn't sort items alphabetically, it wouldn't make sense.

And imagine if it used [binarySearch]([http://googleresearch.blogspot.co.uk/2006/06/extra-extra- rea...](http://googleresearch.blogspot.co.uk/2006/06/extra-extra-read-all- about-it-nearly.html)) as part of it's implementation? Then `sortAlphabetically` would be broken, and people might waste a lot of energy looking _everywhere else_ instead of just looking at the data and _reading the code_.

> Imagine a situation where a bunch of constants for an API are defined as > such:

Are really all of those definitions helpful?

If I want to search for `/getUser` in a program, I might do `grep -r getUser .` and then learn that I need to _repeat that_ with `grep -r kURLAPIGetUser .` -- was that really better?

If `/getUser` is being used in more than one place, then maybe we should talk about that problem of duplicating effort. If it isn't, then the define is absolutely worthless.

<comment><USER27> This is such a subtle problem that countless people implementing binary searches didn't think about it, yet you think reading an unlabeled blob of code will make people notice?

<comment><USER25> Yes, I think if programmers do not actually read code, they will not notice the bugs in it.

Considering the binary search more deeply, [http://comjnl.oxfordjournals.org/content/26/2/154.full.pdf](http://comjnl.oxfordjournals.org/content/26/2/154.full.pdf) is useful; De Angelos search (family 4) was a successful search, but it contains this bug. Implementations based on families 1 and 2 but perhaps trying to be less clever would not.

<comment><USER27> That's not what I asked. Do you think they _will_ find the bugs just because of rereading a standard algorithm?

Having to reread code when trying to accomplish something unrelated seems like a terrible way to seek out bugs.

</comment></comment></comment></comment></comment></comment><comment><USER28> Shouldn't it apply to everything, not just code?

</comment><comment><USER29> would a "pre-commit" whitespace condenser + "checkout" configurable code formatter be the best of both worlds?

Write it how you want it - commit a whitespace condensed version, have a formatter re-space it based on you're personal preferences/template?

I guess it would work for non-indent critical languages.

</comment><comment><USER30> The term "vertical align" confused me at first, as I assumed it meant the same thing that CSS does.

</comment><comment><USER31> I do this too, but I don't try and enforce it on anybody. I really enjoy working alone.

</comment><comment><USER32> Why you shouldn't: commit noise.

(NB I'm just giving one reason against, I'm not really advocating against this practise overall. I do it myself, to some extent, but I tend to find it pretty hard to be consistent, which is quite a personal failing! There always seem to be far too many edge cases)

</comment><comment><USER33> I wonder if there is Sublime Text plugin for this behaviour.

<comment><USER34> [http://wbond.net/sublime_packages/alignment](http://wbond.net/sublime_packages/alignment)

</comment></comment><comment><USER35> Code doesn't usually have numbers in it anyway.

</comment><comment><USER36> M-x align-regexp

<comment><USER37> Now consider the poor souls who use Notepad++ ... ;)

</comment></comment><comment><USER38> The correct term is "horizontal alignment", not "vertical alignment". It's impossible to vertically align code unless you're using a two-dimensional visual programming language.

[https://google- styleguide.googlecode.com/svn/trunk/javaguide...](https://google- styleguide.googlecode.com/svn/trunk/javaguide.html#s4.6.3-horizontal- alignment)

Google Java Style

4.6.3 Horizontal alignment: never required

Terminology Note: Horizontal alignment is the practice of adding a variable number of additional spaces in your code with the goal of making certain tokens appear directly below certain other tokens on previous lines.

This practice is permitted, but is never required by Google Style. It is not even required to maintain horizontal alignment in places where it was already used.

Here is an example without alignment, then using alignment:

private int x; // this is fine private Color color; // this too

private int x; // permitted, but future edits private Color color; // may leave it unaligned

Tip: Alignment can aid readability, but it creates problems for future maintenance. Consider a future change that needs to touch just one line. This change may leave the formerly-pleasing formatting mangled, and that is allowed. More often it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly triggering a cascading series of reformattings. That one-line change now has a "blast radius." This can at worst result in pointless busywork, but at best it still corrupts version history information, slows down reviewers and exacerbates merge conflicts.

[https://developer.mozilla.org/en-US/docs/Web/CSS/vertical- al...](https://developer.mozilla.org/en-US/docs/Web/CSS/vertical-align)

The vertical-align CSS property specifies the vertical alignment of an inline or table-cell box.

Values (for inline elements)

Most of the values vertically align the element relative to its parent element:

baseline: Aligns the baseline of the element with the baseline of its parent. The baseline of some replaced elements, like <textarea> is not specified by the HTML specification, meaning that their behavior with this keyword may change from one browser to the other.

sub: Aligns the baseline of the element with the subscript-baseline of its parent.

super: Aligns the baseline of the element with the superscript-baseline of its parent.

text-top: Aligns the top of the element with the top of the parent element's font.

text-bottom: Aligns the bottom of the element with the bottom of the parent element's font.

middle: Aligns the middle of the element with the middle of lowercase letters in the parent.

<length>: Aligns the baseline of the element at the given length above the baseline of its parent.

<percentage>: Like <length> values, with the percentage being a percent of the line-height property. (Negative values are allowed for <length> and <percentage>.)

The following two values vertically align the element relative to the entire line rather than relative to its parent:

top: Align the top of the element and its descendants with the top of the entire line.

bottom: Align the bottom of the element and its descendants with the bottom of the entire line. For elements that do not have a baseline, the bottom margin edge is used instead.</comment>


Spotify may delay IPO to 2018 as it rethinks licensing deals - <AUTHOR> https://techcrunch.com/2017/02/02/sources-spotify-may-delay-ipo-to-2018-as-it-rethinks-licensing-deals/ <comment><USER2> I work for Spotify and I can tell you the company's spending is completely out of control. Between throwing parties where they fly every single employee out to Sweden to party or purchasing Echo Nest, only to ditch the tech later for in-house tech (Discover Weekly), they really have no clue how to manage their capital. We have nearly 2000 employees and no roadmap for profitability. Talk of an IPO has been ongoing since 2013 and employees can barely invest in the ESOP since the share price is so ridiculously priced at over $1000 a share.

Spotify has postponed the inevitable by granting shares of the corp to the companies they license music from. However, the time will come when the larger institutions want their money back and it's not going end pretty. They need to reduce their liabilities and reduce headcount ASAP.

<comment><USER3> Not only that, you guys seem to have a big amount of techincal debt. The macOS client was writing like.. 100-200Gb a day just a few months ago, and that was going on for months already until the noise about it picked up in the media. Now the macOS client (somehow its always the macOS client..) regularly starts using 90% CPU at random and _doesn 't stop until you kill the process_. Again, has already been going on for some time and there's a forum post about it but no one is doing anything... do the Spotify guys not use their own client?

Then there's the myriad of obvious gaps in features that should be there.

1\. You can 'Heart' a track in 'Daily Mix', but you can't un-'Heart' it.

1b. If you accidentally dislike an artist in daily mix, you can't undo that, so that artist won't play anymore.

2\. You can like an artist for a certain Radio (and remove the like in the playlist 'liked by radio') but you can't remove an 'unlike'.

3\. You can have either a public playlist controlled by you, or a collaborative playlist that's secret. Why not a public collaborative playlist for which I can select which users can edit it?

With most of the above issues there's one overarching thing: counter- intuitivity. You can often do an action (heart, like, etc.), and do so by tapping or clicking on something, but tapping or clicking on the same thing doesn't undo the action (probably because you can't undo the action).. and wouldn't you want to have your friends be able to see/follow your playlist that you built with that one Techno-listening buddy _without_ granting them all editing rights?

I still like Spotify because you have the largest library and are available on the most platforms (Windows/Linux/macOS/Chromecast/Sonos/Digt.Amplifiers/PS4), but its a choice of 'sucks the least' rather than 'is the best'.

<comment><USER4> Not to mention the 10,000 limit on tracks saved to your collection. Which is insane considering that Spotify doesn't distinguish between saved albums and tracks — saving an album is exactly the same as saving all the tracks in that album. A 10,000-track "library" is not a very big collection!

Personally, I've been creating individual playlists for every artist I care about, organized in folders by genre, since those tools were always lacking. So when I ran into the aforementioned limit, I just un-saved all the tracks and went back to solely using playlists.

A few months ago I considered switching to Apple Music, which does this stuff correctly, but nobody has made a migration tool that works.

(Apple Music also has several features Spotify ought to have had a long time ago. A sane distinction between composer and performer for classical music is one. Another is the completely seamless syncing of downloaded music — purchased, encoded or whatever — between all devices. Spotify only supports "offline sync" if you have Spotify open on the machine that has the files.)

<comment><USER5> I transferred some stuff over from Spotify to Apple Music last week using SongShift[0] without any issues, but YMMV.

[0]: [https://appsto.re/us/MmCCbb.i](https://appsto.re/us/MmCCbb.i)

</comment></comment></comment></comment><comment><USER6> Why has Spotify not pushed harder to own their own content a la Netflix? That's the only reliable way to both have some control over margins and offer a non-commoditized product.

They have tons of data on user tastes, owning and operating a studio is cheap compared to licensing fees, so why not try to predict tastes (like Netflix), aggressively sign unheard of artists, and A|B test the hell out of the homepage with promoting different ones?

Apple has very deep coffers, which we have seen with the exclusive content they have acquired. Competing there seems like a loser's game.

<comment><USER7> The music business isn't just about the musical content. Popularity is also driven by artists' branding. Promotion, etc. there's a strong fashion element to popular music that is outside of the scope of Spotify's core competencies.

They'd have to either acquire this or build it from scratch. That takes time.

<comment><USER8> Agreed, but running a large production company was not originally Netflix's core competency either.

It does seem like Netflix's playbook would be more difficult to copy for music, but still an interesting prospect to consider.

<comment><USER9> Netflix doesn't run a production company though, and they should if they want to remain competitive and have complete ownership over their products.

All they do is buy shows/movies from other studios. It would be similar to when Kanye West having the Life of Pablo exclusively on Tidal for a period of time. Exclusivity is important and Spotify does have albums and live performances that are not sold anywhere currently. Maybe they should do a better job of showcasing this.

<comment><USER10> Platform exclusivity is a dark pattern. Content is what's important, the platform is largely irrelevant to users.

I'm perfectly happy paying for media. But if something isn't readily available, I'll probably end up pirating it or never listen to it.

<comment><USER9> Could you explain how platform exclusivity is a dark pattern?

When I think of dark patterns I think of misleading ways to get a customers information where not applicable. I don't see how it's a dark pattern if I can't watch Game of Thrones on Showtime or Orange is the New Black on Hulu.

Why is retaining rights over content creation a bad thing? Is it a dark pattern to have companies pay for licenses or copyright fees?

</comment></comment></comment></comment></comment></comment><comment><USER11> Are the subscription models by these streaming services really sustainable? It seems like the licensing agreements were made before the real value of the content, enabling generous promotions and even a free model. I imagine the reduction of costs brought about by digital distribution back when iTunes first launched made it a much more viable option, but now that those savings are baked into the modern music industry how much lower can prices get before it's unprofitable?

<comment><USER2> Not particularly when you consider that Spotify's contracts with content providers obligate a 70% cut. The skunkworks projects to capitalize on data/ads/listening behavior/etc. have not cumulated into considerable value for the company. The focus for the company has been and always will be GROWTH in the form of monthly active users. Streaming music will never be a cash cow. The margins aren't there.

</comment></comment><comment><USER12> Didn't they have a clause in their last round of financing, that if they didn't go public in 6 months, they'd lose a lot of money (per month)?

<comment><USER12> Yes, found it [http://www.digitaltrends.com/music/spotify- raises-1-billion-...](http://www.digitaltrends.com/music/spotify- raises-1-billion-dollars-ipo/)

"Investors, according to the Wall Street Journal, will be able to convert the debt into Spotify shares at a 20 percent discount if the company has a public offering in the next year, with that discount rising two and a half percent every six months Spotify doesn't go public.

Until then, Spotify will also pay a five percent interest rate on the debt. That's an amazing investment for those who were given the opportunity to make it — five percent on their money up front, and a huge discount on stock when Spotify goes public. Essentially, if Spotify doesn't immediately go under, they stand to make a lot of money on their initial investment no matter what happens."

<comment><USER13> _" if Spotify doesn't immediately go under, they stand to make a lot of money on their initial investment no matter what happens"_

I don't understand your logic; it's not " _when_ spotty goes public"; it's " _if_ Spotify goes public".

If, say, Spotify doesn't go public (yet) and goes down after X years, they will have received 5X% of their investment back in interests, and will have the rights to buy lots of by then worthless Spotify shares at an enormous discount. For X < 10, I don't see that as making money at all; X = 10 might sort-of break even.

I think Spotify had to give them those share options to get that 5% interest rate because investing in Spotify is risky.

</comment></comment></comment><comment><USER14> Its a failed model they cant win based on music industry - Apple to buy Spotify as loss leader eventually.

<comment><USER15> I don't see Apple buying them now, not after buying Beats Music and transforming it into Apple Music.

And considering that Amazon, Google, and Microsoft all have their own streaming services, I don't see anywhere for Spotify to go when they fail.

</comment></comment><comment><USER16> Earlier conversation: [https://news.ycombinator.com/item?id=13570021](https://news.ycombinator.com/item?id=13570021)

</comment><comment><USER17> Why IPO at all?

<comment><USER18> See resharker's comment: many of the licensing companies have been granted shares.</comment></comment>


Grunt 1.0.0 released - <AUTHOR> http://gruntjs.com/blog/2016-04-04-grunt-1.0.0-released <comment><USER2> Hey! Core maintainer here.

I see a lot of comments are basically saying our project is obsolete or sucks. That does not stop us from working on Grunt though.

We are still seeing record download numbers, even with the 2 year old releases. This is why we felt it was important to keep releasing this software and supporting developers.

For those who support and use Grunt - huge thank you! Pick up your free open- source copy made by volunteers on npm.

<comment><USER3> I don't get node and npm (although I was good with JS), but you seem to be cool.

Noted. : )

Edit: again, now that we have a bunch of people capable of understanding trendy JS here: Care to share a link to somewhere I can learn?

<comment><USER4> Here: [http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build- tool...](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/)

I don't hate grunt, I used to love it and used it for all my projects. And then I started using gulp.

But after reading this article I just use npm script 99% of the time. I don't know if it is better over all, I just prefer it over grunt/gulp.

</comment></comment></comment><comment><USER5> Obsolete before it hit 1.0. While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the tons of dev-dependencies.

Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.

<comment><USER6> The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time.

The docs are very basic and there are so many configuration params.

If you want to do something that's not covered in tutorials or boilerplates, be prepared to spend a ridiculous amount of time reading Webpack PRs, issues and the codebase.

Webpack does a great job and it's a nice concept but it has very bad documentation.

[1] Isomorphic apps, or multiple builds for i18n etc

<comment><USER7> > The problem with Webpack is that if you want to do something that's not > straightforward[1] or covered in the dozen tutorials that are on the web, > you're going to have a hard time.

I really hate systems that are built like that. Nobody should build software like that.

I just want simple tools with a clear API that I can combine together and easily replace by other tools, like in the Unix tradition.

I guess it is a case of "LEGO versus Playmobil". The former allows modularity, while the latter is just complex crap that allows you to do nothing other than what the instructions say.

<comment><USER5> Webpack does not glob-search against the filesystem like grunt/gulp/brunch/broccoli/make. If you look for that: Sorry, webpack does not "replace" simple tools like that.

Think of it as a tool executing require.extensions at build time. It's not operating on files as much as it's looking directly at the source-code AST. That makes it more complex to get into over the glob tools but it's worth it.

It's also just as modular as anything else: [http://npmsearch.com/?q=loader%20AND%20keywords:webpack](http://npmsearch.com/?q=loader%20AND%20keywords:webpack)

</comment></comment></comment></comment><comment><USER8> I don't see the hype behind build tools. I still use Grunt on just about any project because I can just copy/paste the entire build process from another project and never come back to it again. Don't see much point in switching to anything else.

<comment><USER9> Honestly there isn't much point. You can do the same stuff on grunt, gulp and apparently webpak. Personally, to avoid the extra mountain of dependencies, my newer projects just use scripts now to do building and I just simply reference the same depdencies grunt and all wrap. It's quite easy.

Honestly there is _some_ utility to using these build systems as they make it a _tiny bit_ easier than just writing a script...but that's about it. It's really easy to write your own scripts to do the same thing with barely any extra code.

<comment><USER10> > my newer projects just use scripts now to do building and I just simply > reference the same depdencies grunt and all wrap

Which is basically reinventing the wheel for the Xth time, but now with your spin on it. Don't get me wrong, I have nothing against spinning a script or two for building, but as soon as you share them with others there might be some problems. Modern build systems have pretty thriving ecosystems which means less time doing stuff which is out of the development time. Thriving ecosystems mean that many are already familiar with the tools, which means less time for them to get a grasp of your project. And so on and so on. There are many benefits of using commonly used tools besides just running few simple or complex scripts.

<comment><USER9> > Which is basically reinventing the wheel for the Xth time, but now with your > spin on it.

False. Do you consider calling a function versus setting a property, even if they use the same amount of lines of code, reinventing the wheel? I sure don't. It didn't take long at all for me to write and npm already provides a way to run scripts so I can still do `npm run build`, etc just as if I typed `grunt build`.

> Modern build systems have pretty thriving ecosystems which means less time > doing stuff which is out of the development time. Thriving ecosystems mean > that many are already familiar with the tools, which means less time for > them to get a grasp of your project. And so on and so on. There are many > benefits of using commonly used tools besides just running few simple or > complex scripts.

The vast, vast, _vast_ majority of Grunt and Gulp plug-ins simply wrap existing libraries, make a call to those libraries with the options you define in Grunt or Gulp and then move to the next step when it's finished. That's it.

When I moved a web app from Grunt to my own script, that still used the same dependencies, the amount of code was almost the same minus all the grunt dependencies.

</comment></comment></comment></comment><comment><USER11> I feel sorry for the developers after reading all these comments. Why would they continue with such a project that gets such little love?

<comment><USER12> The comments here are not indicative of the developers at-large. This is mostly posturing to validate decisions to use other tools.

I love Grunt, I understand the complaints but it's a great system that's easy to understand and work with. It's not unlike Makefiles but the learning curve is lower with Grunt.

</comment></comment><comment><USER13> I am so pleased I abandoned grunt/gulp. Life is so much simpler with simple build commands. Now I just run whatever I need using npm run.

<comment><USER14> For simple things, yes npm run is a better option. But with more and more Tasks i prefer cleaner and better readable solution.

Depending on the kind of project and tasks i use grunt / gulp or webpack.

<comment><USER13> I've not found anything that can't be accomplished with npm run. I mostly use browserify, the commands for which can easily be run from a single line. For more complicated things all I have to do is create a js file and add it to the scripts object. It is really much simpler than grunt/gulp make it out to be. AND I don't have to rely on plugins being available I can use any node module.

</comment></comment></comment><comment><USER15> Lately the decline in popularity of Grunt has been more and more noticeable for me. When adding new packages there are always usage instructions for Gulp, sometimes webpack and alternatives as well but Grunt seems to be notably absent. I'm contemplating switching to one of the more popular task runners, but that would mean having to rebuild a working flow.

The question also remains what happens when you have to revisit an existing site in x years. Will all the packages still be available, do I have to go back to node version x and will everything still work on Windows/Mac OS version y?

<comment><USER16> until the new shiny thing comes and replaces that. I still don't understand what's wrong with grunt (or whats better with gulp).

<comment> Jean-Philipe I never got what's so great about Grunt in the first place, and instead stuck to makefiles. Something like `cat src/*.js | uglify > build.js` would take me a lot more effort to do with Grunt (or Gulp).

<comment><USER17> You old curmudgeon you... ;-)

Make has it's foibles - before we talk about those we need to declare are we talking gmake, nmake, BSD make etc. - our build scripts can break in the wrong make. And how will windows users collaborate (they'll install cygwin). Etc etc

All that said though, I still find make to be lower barrier to entry.

If I need to start a watcher or something, I generally have that in my npm package.json but there's nothing stopping me having a make target to call npm start or whatever.

I forced myself to learn enough gulp to be dangerous (incidentally I see strong parallels between grunt / maven and gulp / gradle) and the faux pipes implementation is clearly influenced by make, it's just far more clunky an implementation.

So it could just be I'm wired up wrongly but I have to agree, neither grunt nor gulp moved the needle meaningfully.

Counter arguments like it's all one language don't hold much water for me, or for the designer who only really knows css.

I'm resigned to being labeled a curmudgeon in this one!

<comment><USER18> I had reservations about using make for node builds until I got berated by another curmudgeon on here, who kindly showed me all the tricks necessary to implement the rules I needed. I'm very very happy I switched to make.

I think part of the issue is that I (and I suspect many others) though I knew basically how make works, except that I had no idea about % patterns, the patsubst function, etc.

<comment><USER19> Can you share any of those tricks?

<comment><USER18> [https://news.ycombinator.com/item?id=10543908](https://news.ycombinator.com/item?id=10543908)

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I spent a minute scanning that website and I still don't know what it does. Is it that hard to have a link along the top leading to an ELI5 blurb

<comment><USER21> It's a build tool, written in node, so it was the first front end build tool that saw wide usage 3-4 years ago. Used for things like concatenating and minifying your CSS and JS for production.

It was succeeded by Gulp, which was succeeded by Browserify, which was succeeded by Webpack, and then I moved to the backend because fuck this shit.

</comment></comment><comment><USER22> I have yet to find a use for Grunt that would not be better served with either a more modern replacement or, more commonly/simply/pleasantly, an older replacement like plain old 'make'.

</comment><comment><USER23> I still use Grunt for small, one-off tasks that I'd like to be able to configure declaratively. For example, it's useful to wrap Webpack to make simple static deploys: [https://github.com/thomasboyt/monotron/blob/master/Gruntfile...](https://github.com/thomasboyt/monotron/blob/master/Gruntfile.js)

I imagine that if I was more comfortable with shell scripting I could just use that, but I do like declarative tasks a lot, and there's very little overhead to adding Grunt to a JavaScript project.

</comment><comment><USER24> People keep saying "every grunt package makes its own way of doing things." I have not found that to be the case at all. Grunt has a lot of ways to specify groups of files, and many packages only show example usage for one of them, but they are actually largely interchangeable.

I'm a little incensed at the speed of it. It is very slow, for no apparent reason. But now I'm also wondering if it's not grunt's fault and actually the NPM ecosystem's fault for being way too dependency happy. I got a complaint from Windows about file name lengths being too long. Not in 20 years of using Windows have I seen this error but on corporate copy-folder-as-version-control network drives and NPM packages. So I'm concerned it might be spending most of its time just crawling my node_modules folder, because I only just now thought of this wrinkle and haven't stopped posting long enough to go do anything about it.

<comment><USER25> The "file name too long" was an issue in npm v2, where each module installed its dependencies inside itself, recursively, leading to enormous node_modules/foo/node_modules/bar/node_modules/baz/node_modules/quux/node_modules/... chains.

npm v3 was an attempt to fix this so it now tries to install all modules and their dependencies in the top level directory, unless there's a version conflict, in which case it falls back to the old behaviour. npm v3 also got slower, because to fix the folder chains it changed how the packages are downloaded and installed.

It sounds like your node_modules were installed by npm v2 – you can try nuking your entire node_modules folder, ensuring you have npm v3, and letting it install your dependencies again. If your guess about grunt's performance problems is correct, this might improve your build experience.

<comment><USER24> It cut it some, but not enough. Only about a 33% savings, i.e. went from 15 to 10 seconds, meaning it's still too long.

Uuuuugh, extremely vexing.

</comment></comment></comment><comment><USER26> Well since this has seemly turned into a forum for build tool gripes, I'd like to note that no build tool is the best build tool. It simply comes down to what's maintainable for you and your team.

</comment><comment><USER27> you don't need grunt [https://medium.com/@julesbou/you-don-t-need- grunt-a486059153...](https://medium.com/@julesbou/you-don-t-need- grunt-a48605915319)

</comment><comment><USER28> brunch.io ftw. its been out there the whole time, way easier than grunt and gulp.

<comment><USER29> Brunch is great but last I used it there was no support for NPM modules. So I built Parched on top of Gulp to mirror the Brunch experience.

</comment></comment><comment><USER30> Versioning at it's best

</comment><comment><USER31> better late than never :)

<comment><USER32> Is it though? What's the point of a 1.0 release this far into a projects life? If it's utterly meaningless what's the point of versioning it at all?

</comment></comment><comment><USER33> Something I use daily, one of my favorite tools.</comment>


Ask HN: Exploring Hawaii with a sleeping bag and a camera. Ideas? - <AUTHOR>

Cousin, brother and I decided to get out of town and go explore O'ahu for 10 days. What are your favorite sights, sounds, tastes, views, hikes, beaches etc?<p>We love hiking and adventure. Done a bunch of research but what are your personal experiences and recs? Any HNs want to meet up? <comment><USER2> The hike up to Diamondhead was one of the highlights of our honeymoon. It's beautiful, both the views of the Pacific and the city from the top, and the park on the way up. It's modestly strenuous as a hike, probably less so if you're an active hiker.

The aquarium near Waikiki Beach was also quite fun.

Foodwise there exist lots of options which cater to tourists in the area we were. Those were mostly pretty good, but largely in the fashion that you expect for restaurants catering to tourists. I strongly recommend you get a recommendation or two from somebody local. (We did for a meal or two, but unfortunately I don't remember either of the places well enough to Google or name them.) The single best restaurant we went to was Roy's, which does Asian- fusion among other things. It was good enough to build a trip around, and Ruriko and I will probably do that at some point. There is also a Nobu, which is pricey, but offers really credible sushi. (I've had good sushi in the US, but Nobu is the only sushi which would tempt me to cheat on my local sushi joint in Japan.)

<comment><USER3> OT, but if you ever find yourself in London I'd be happy to introduce you to some places where my wife cheats on the whole of her native Iwate prefecture[0][1]. They're pricy, but nowhere near as pricy as the local chapter of Nobu.

[0]: Sakana-tei 11 Maddox Street, London W1S 2QF

[1]: [http://www.tajima-tei.co.uk/](http://www.tajima-tei.co.uk/)

</comment></comment><comment><USER4> [http://goo.gl/maps/rGv4F](http://goo.gl/maps/rGv4F)

[http://goo.gl/maps/vKuFr](http://goo.gl/maps/vKuFr)

[http://goo.gl/maps/w6ISr](http://goo.gl/maps/w6ISr)

[http://goo.gl/maps/bPHfh](http://goo.gl/maps/bPHfh)

[http://goo.gl/maps/NHbbn](http://goo.gl/maps/NHbbn) (Try the L&L and the Vietnamese place)

Take the bus around the whole island.

Watch for centipedes.

</comment><comment><USER5> email firstname.lastname@example.com if you're still reading comments</comment>


Another Reason To Avoid Diet Soda - <AUTHOR> http://www.getfitslowly.com/2010/05/12/another-reason-to-avoid-diet-soda <comment><USER2> These iodine deficiency claims are entirely pseudoscience and alt-med bullshit. Here's where they come from: [http://www.naturalnews.com/008902_hypothyroidism_thyroid_gla...](http://www.naturalnews.com/008902_hypothyroidism_thyroid_gland.html)

The whole pH thing is a lot of nonsense too, as many of the commenters on this article pointed out. Here's a thorough debunking: [http://sciencebasedpharmacy.wordpress.com/2009/11/13/your- ur...](http://sciencebasedpharmacy.wordpress.com/2009/11/13/your-urine-is-not- a-window-to-your-body-ph-balancing-a-failed-hypothesis/)

For the more real point about BMI increase being associated with artificial sweeteners:

\- The bloggers link to this 2005 WebMD article, which doesn't cite the reference for the study: [http://www.webmd.com/diet/news/20050613/drink-more- diet-soda...](http://www.webmd.com/diet/news/20050613/drink-more-diet-soda- gain-more-weight)

\- The real literature appears to be from 2008, so I don't know if the authors just spoke to WebMD ahead of their publication or what happened. I believe this is the study: [http://www.nature.com/oby/journal/v16/n8/full/oby2008284a.ht...](http://www.nature.com/oby/journal/v16/n8/full/oby2008284a.html)

There's also a critical response: [http://www.nature.com/oby/journal/v17/n4/full/oby2008623a.ht...](http://www.nature.com/oby/journal/v17/n4/full/oby2008623a.html)

And a response to the response: [http://www.nature.com/oby/journal/v17/n4/full/oby2008624a.ht...](http://www.nature.com/oby/journal/v17/n4/full/oby2008624a.html)

<comment><USER3> so instead of having to check and read every single link... is there a general consensus on the effects of artificial sweeteners and diet coke? Or is it still basically up in the air and no one knows for sure.

<comment><USER2> As far as I can tell, they're actually fine, but people who drink them tend to make unhealthy lifestyle choices. The majority of the really scary claims (like this video) are total bullshit about pH levels and aspartame conspiracy, but it seems like the literature is conflicted on if people who drink them do end up fatter for some reason.

</comment></comment></comment><comment><USER4> As bad as diet soda is, I have the feeling it's not as bad as the non-diet soda with the high fructose corn syrup (HFCS). So the point is, don't drink soda, of any kind, at all. It's poison.

</comment><comment><AUTHOR> Please do take one minute to watch the video.

<comment><USER5> It's blocked for me here at work (as I sit sipping my Diet Coke). What is the reason?</comment></comment>


Typed Properties in PHP 7.4 - <AUTHOR> https://stitcher.io/blog/typed-properties-in-php-74 <comment><USER2> Tons and tons of the web runs on PHP. It is a super easy language to learn and be effective in quickly. Especially if you are talking about open source content management systems, PHP is dominant.

Anything that improves overall code quality of this language should be welcomed with open arms. Types, especially if they are backward compatible (as these are) will do so.

I'd be interested in what kind of automated or ide support will be available, but I suppose that won't be known until this is released later this year.

<comment><USER3> PHPStorm has excellent support for types and version 2019.2 released last week includes typed properties already: [https://www.jetbrains.com/phpstorm/whatsnew/](https://www.jetbrains.com/phpstorm/whatsnew/)

Other editors (VSCode for example) can hook into Psalm or Phans Language Server to get type information from these static analyzers.

Typing support in PHP Ides is usually excellent.

<comment><USER4> at 199 USD yearly phpstorm is prohibitively expensive for small teams and independent devs

I don't know the state of the language server for newer php versions, but intellisense for vscode is too taxing on the CPU for relatively large projects (20k+ lines of code)

<comment><USER5> ~2-5 hours gross income per year is nothing for a good tool.

<comment><USER6> It's a little rude to assume how much people are earning. I think you might be surprised how little people earn in certain parts of the world.

</comment></comment></comment></comment></comment><comment><AUTHOR> I think that the biggest win with this feature, is not that PHP will do more runtime type checks, but that the syntax is valid.

The past years we've seen several static analysers become more and more popular in the PHP community. Tools like phpstan ([https://github.com/phpstan/phpstan](https://github.com/phpstan/phpstan)) and psalm by Vimeo ([https://github.com/vimeo/psalm](https://github.com/vimeo/psalm)).

Allowing this syntax is a great way to write cleaner code that can be statically analysed, which is far more superior than the runtime type checker.

<comment><USER7> Having them checked at runtime is still important (I say this as someone who was involved in scalar types getting declarations finally), because it means that the types can't end up inaccurate without being noticed, weak typing can be supported with certainty (you always get the type you ask for), and as a bonus the runtime can perform optimisations (elided type checks).

</comment></comment><comment><USER8> I'm really looking forward to this. After 10 years of programming in PHP and maintaining loads of legacy projects I've come to greatly appreciate explicit definitions and strong typing. IMHO being explicit always increases maintainability.

<comment><USER9> Agreed, better types for PHP on the backend and TypeScript on the front makes life much more pleasant.

<comment><USER10> Same here.

Using GraphQL in the PHP backend und frontend TS. The schema is exported to TS and thus everything is fully types. A blessing.

</comment></comment></comment><comment><USER11> I find the timing odd [0] that php since v5 ressembles more and more Java very explicit type system, while Java is going backward to more implicit and infered.

All in all in 20 years we'll all be writing ml ?

[0] technological waves diffuse differently across cultures

<comment><USER12> Type inference does not compromise on static typing. It simply makes it less verbose. IMHO type inference has removed a lot of the arguments against statically compiled languages. Which is why things like Typescript are becoming popular. Even Python has type annotations now.

<comment><USER13> Although some devs (and style guides) do tend to resist inference in favor of verbosity (C#). Subjectively, I love inference (like in F# or Crystal). I'm not sure if an objective winner exists for best strategy, or how to even measure that.

<comment><USER14> It is certainly subjective, but i am one of those developers who dislike inference in languages where it has them and prefer explicit typing out types - in fact i also go as far as to avoid type aliases (e.g. i prefer something like "const std::vector<some_template<some_foo>>" to "a_foo_vector" typedef for the former).

The reason is that i want to know "on site" what exactly is going on when reading and debugging code, especially outside a "smart" IDE, like when diffing changes via the command line, a web-based VCS frontend or some code review tool - especially since these tend to not show the entire code, meaning i need to switch back and forth. But even with an IDE that can show me the inferred types, it is almost always (while i say "almost always" i really mean "always" since i haven't seen any other, but there might be some IDE i haven't tried) done through some popup under the mouse cursor, meaning it is transient and slow.

For similar reasons i dislike features like operator overloading, placing non- self-initializing logic in constructors (and the equivalent in destructors), properties for anything that involves complex calculations (unless the language uses special syntax for properties that make them stand out when used) especially for getters, i prefer to use names that hint to what the code does (e.g. i'd use something like "get_foo" only if it doesn't do any calculations and give you a precomputed or cached "foo", otherwise i'd use an "action" verb like "calc_foo" or "find_foo" or whatever to hint that there is some calculation going on and isn't just a dumb getter), i avoid exceptions as they create hidden exit points for functions (and if the IDE/editor allows, i use a more visible - like bold red - font for "return" or the language equivalent so that explicit exit points are obvious), etc.

Yeah, these make code more verbose and you need to type more, but IMO the negatives are grossly overwhined against and while the positives way too overlooked.

<comment><USER15> > who dislike inference in languages where it has them and prefer explicit > typing out types

So you prefer

        std::vector<some_template<some_foo>> foo = new std::vector<some_template<some_foo>>();

Rather than replace the first one with var / let / auto / whatever your language does? Why? The type is already there.

<comment><USER14> In terms of "liking" it, no, in that very specific case where the type is repeated and very long, i do not like it and i think "auto" (or var or let or whatever) looks better. However in the interest of consistency (and to a lesser extent, avoiding 'slippery slopes') i'd rather type that than use auto.

And even then that this is only in the very specific case you showed, where the type is too long, it is repeated and the constructor parameters - if any - are visually dwarfed by the duplicated type.

In practice these aren't as common as other uses of types like loop iterators for member/obtained collections (where the use of 'auto' makes it impossible to know the collection type unless you check the collection declaration) or local variables you assign to the result of some function (the return type of which again you need to check the function declaration to see) and - at least in C++ - you rarely need to do "very_long_foo* bar = new very_long_foo" as a stack allocated "very_long_foo bar" is enough (so no need to double type the type).

</comment></comment></comment></comment></comment></comment><comment><USER16> I'm still not so convinced by PHP's runtime type checking system. It adds a little overhead, I guess that's not such a big problem, but it adds also new classes of runtime exceptions that can only be caught using tests, or with a good static analyzer. Especially if you now upgrade your application to 7.4 you can only do it with confidence when you have 100% test coverage.

If a static analyzer can detect these mistakes, why even add runtime checks for it? Think TypeScript/Javascript, after the compilation is done, most type checks are removed for performance reasons.

Or perhaps there is something I don't see...

<comment><USER3> If you upgrade your application to 7.4, all the code doesn't have typed properties.

Only when you then add them after the upgrade you should have tests for that or a static analyzer that tells you the changes you make are correct.

<comment><USER16> Yes that's true - it's a backwards compatible change.

Still, static analysis is necessary when you upgrade dependencies and for your own code. For example for seeing whether adding a type to a property breaks code somewhere else. Discovering type errors at runtime is often too late.

Luckily there are good static analyzers for PHP.

</comment></comment></comment><comment><USER17> "But, before you pounce on this feature and start porting all your existing model classes to use this feature, you should definitely read this."

[https://dev.to/mindplay/php-typed-properties-think- twice-382...](https://dev.to/mindplay/php-typed-properties-think-twice-3824)

</comment><comment><USER18> Slowly PHP is converging to what Java has been like 15 years ago.

<comment><USER19> True.

I'm also seeing that with JavaScript and TypeScript.

TS feels very C# like.

Luckily there seem to be counter movements with languages like Reason, ClojureScript and PureScript.

<comment><USER20> We're basically getting a huge Algol mono-language.

C is not really moving, but C++ is also converging towards this Java++ language.

Java itself is finally moving.

C# is a bit ahead of the curve, because it can follow the trail blazed by F#.

PHP started moving towards Java back from when PHP5 was introduced.

Javascript is moving towards Typescript which is following C#'s lead.

Python is kind of the only non-Algol mainstream hold out.

Did I miss any of the big enterprise languages? :-?

<comment><USER21> How is Javascript moving towards Typescript?

<comment><USER19> I don't know either.

TS was influenced mainly by C# at the start, then from FlowType and currently it's mainly influenced by ECMAScript.

So to me it feels like the other way around.

</comment></comment></comment></comment></comment><comment><USER22> Imo optional typing like this is the best trade-off for now.

Usually, statically typed languages is not expressive. There are a lot of abstractions are hard to express in statically typed languages. Even in Haskell. With optional typing, you can express usual ideas with types, and cheat with 'any' when not applicable.

Another thing is the language itself can possibly execute without compile or even type check. Making developing feedback cycle much smoother when running tests or just save and refresh.

<comment><USER23> What's the difference between static typing with an Any type and optional typing?

<comment><USER24> An "Any type" is optional typing if you don't need to downcast it in order to use it, like the "any" type in TypeScript and Flow.

If the "Any" type is just a top type but you have to downcast it to use it, like in Kotlin, then it's not considered optional typing, since you still have to talk about types ;).

<comment><USER23> That's very clear and interesting. Thanks :)

</comment></comment></comment></comment><comment><USER25> I love the idea, but the implementation is IMHO poor. It doesn't require non- nullables to be defined by the end of the constructor. Instead it moreorless adds a new type of NULL to the language (always a mistake) which causes parameters to throw runtime errors on _call_ if they were not defined.

This adds up to essentially making everything nullable, regardless of if the type is defined as nullable, and adding an entire class of runtime errors that could have been avoided.

<comment><USER7> The idea behind it was to avoid having every typed property be nullable. It's important to note that the undefined state of a property cannot be read as a value, and so can't be propagated anywhere.

<comment><USER25> Just do it like TypeScript though where they just have to be defined by _the end of the constructor_ or be nullable/have a default.

A new state was not necessary.

<comment><USER7> I think the problem is that doesn't work for cases where you have a minimal constructor and do the rest in a static method which wraps it, or where you construct the class while skipping the constructor (and probably some other cases). PHP allows more flexibility here than other languages, and these sorts of cases are not uncommon. Mocking libraries and databases interfaces do the latter, and using the former to simulate multiple constructors is a common pattern.

</comment></comment></comment></comment><comment><USER26> "Because uninitialized state is checked when accessing a property, you're able to create an object with an uninitialized property, even though its type is non-nullable."

This is going to result in a new series of run-time-only bugs that PHP is famous for. I love the language but it's 2019 and we should be past this. Also, where are the generics?

<comment><USER27> Ideally you'd get a compile error, but there is no compiler in PHP. Run time is the only time PHP can tell you there's a problem.

</comment></comment><comment><USER28> I'm pretty excited about the new "uninitialized" state. Back in my PHP days I also had the phase of writing my own framework and ORM, and it annoyed me that I couldn't distinguish between "not loaded" and database null. This seems like it would make the "not loaded" state possible!

<comment><USER24> Although isset() still returns false for null ;)

<comment><USER17> Which is a little weird, but cases where you'd want `isset` to treat variables intentionally set to null the same as variables that are entirely undeclared are considerably more frequent (just ran into one yesterday!) than cases where you'd need to carefully distinguish them.

<comment><USER24> It's also great at hiding bugs where you mistyped the variable name passed to isset(). ;)

</comment></comment></comment></comment><comment><USER29> > All types are allowed, except void and callable

Urgh. It baffles me that 10 years after their introduction, anonymous functions (closures) remain useless when assigned to instance properties.

        class Foo {
            public $var;
        }
        $foo = new Foo();
        $foo->bar = function() { echo "Hello World\n"; };
        $foo->bar();
        Uncaught Error: Call to undefined method Foo::bar()

Callables work perfectly fine when assigned to standalone variables or array members: e.g. $foo[0](); But they become nonfunctional when assigned to instance properties. I understand that using closures as instance properties would make them hard to distinguish from methods, but blurring that distinction is just so damn useful in JavaScript!

<comment><USER30> You can invoke an anonymous function assigned to an instance property using `__invoke()`:

        class Foo {
            public $var;
        }
        $foo = new Foo();
        $foo->bar = function() { echo "Hello World\n"; };
        $foo->bar->__invoke();

Not pretty but that's how I've always done it.

<comment><USER31> Certainly prettier than using _call_user_func($foo- >bar)_, so that's something.

<comment><USER32> even better, you can surround the class and method reference in parentheses and call normally.

Example:

        $c = new stdClass;
        $c->test = function() { return 'hello world'; };
        echo ($c->test)();

<comment><USER31> It's less obvious though, you need to know what's happening and why. Likely not a problem for somebody writing a lot of JS, but I rarely see similar constructs in PHP code.

<comment><USER32> I guess it's a little less known but you also have to use the same technique to immediately invoke a method on a constructed object, eg.

        $response = (new Response())->handle ();

So it's not completely alien in PHP.

<comment><USER31> That's true, and probably depends on the code base.

I don't know how these patterns develop - it's very common in JS, but somewhat rare in PHP. Maybe it has to do with the average level of the programmer in each? Or jQuery's noConflict() helped it along with everybody starting with (function($) {})(jQuery), thus integrating IIFE into their active repertoire.

I don't remember (and haven't found in quickly searching) PSR saying anything about that, but that could explain a difference in usage, too.

<comment><USER29> Most PHP codebases simply don't have much use for IIFE's. A well-maintained project will be neatly organized into namespaces and classes, and undefined variables don't automatically become global. Meanwhile, PSR-1 says that a file that defines classes and/or functions should not have any side effect. So you don't have to worry about accidentally interacting with other scopes.

Anonymous functions and classes are being used more and more, but PHP isn't fundamentally event-driven like JS so there's less need to hand them out like candy and nest them several levels deep. Most of the closures I do use on a daily basis are callback functions to things like array_filter() and preg_replace_callback(), not event handlers like every jQuery code ever written.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> I'm happy to see more languages with optional typing.

Prototyping stuff without bothering with types and adding them when your code matures to root out some bugs and make it more futureproof seems to me like the best of both worlds.

<comment><USER34> I will never undestand this argument. Bothering with types? How? In most cases you will need int, double or string - how this is difficult? It is more difficult to figure out types you heve to deal with if language doesn't provide such information. If by prototyping you mean Hello World like apps then ok, but anything more complex without types becomes mess very quickly and prototyping speed have to decrease.

<comment><USER33> If you really want to understand please find out why so many people prefer dynamically typed languages. Maybe start using one yourself...

<comment><USER35> And what if you are used dynamically typed language for years and still cannot understand why anyone would choose on if can chose freely?

Seriously I have noticed that static vs dynammic preference is quite sustainable thing for people. Even if you are have used lot of both most people prefer the one they are used when they 'got it' during their programming learning path.

I don't really understand that CSV example what's the problem but one concrete challenge I have noticed with static types is when you want do mutation which effectively change the type. Instead of setting just new property you have to potentially do dummy copy (including type) or some additional hashmap by id for this additional data.

(btw I am not your down voter)

<comment><USER33> I went back and forth between typed and untyped languages. The sheer drudgery of typing out and visually filtering out while you read the obvious type information is what makes typed language feel way less fun for me. When you cut things out move them around, delete them, retype them, throw everything away again and start over... I'd never choose Java for initial implementation of anything.

I'm not sure why other people like dynamic languages but there must be some advantages.

</comment></comment></comment></comment></comment><comment><USER36> Is most of the PHP ecosystem moving to static typing? Libraries, ORM, etc. When you're dealing with database objects, is everything a string?

<comment><USER37> This still isn't static typing, php type annotations are enforced at runtime.</comment></comment>


GelTouch: Localized Tactile Feedback Through Thin, Programmable Gel [pdf] - <AUTHOR> http://joergmueller.info/pdf/UIST15MiruchnaGelTouch.pdf <comment><USER2> This seems pretty cool. I'm curious about the viability of such a product in the marketplace, it seems like even at full scale production it would be radically expensive for an average consumer.</comment>


Google's Gmail Outage Is a Sign of Things to Come - <AUTHOR> http://www.businessweek.com/articles/2012-12-17/google-s-gmail-outage-is-a-sign-of-things-to-come#r=rss <comment><USER2> This article is FUD. Complete nonesense really. Continuous integration had nothing to do with the Gmail outage (which mind you was just for the web app, no emails were lost and since my phone/desktop clients kept working I only knew Gmail was down because of Twitter).

> The search giant reported that it conducted an update of its load-balancing > software from 8:45 a.m. to 9:13 a.m. U.S. West Coast time, and after the > problems were detected it managed to quickly roll back the buggy code. But > this didn't stop some people from questioning why Google would roll out a > software update during peak e-mail hours on the West Coast.

Perhaps because the update wasn't to Gmail, it was to the load balancing system? It's not uncommon to have issues arise in load balancing while under load. I'd say the engineers did a good job dealing with the problem all things considered--load balancing issues are notoriously tricky.

</comment><comment><USER3> When exactly is a good time for Google to release code? Facebook? Twitter? These are global markets. There are over 1 billion smartphones in the world, alone, and less than a tenth are US; I'd gander most are used to interact with one of these or similar big guys that do "continuous deployment."

<comment><USER2> The best time to deploy is the time with the best engineers at the ready. If you're updating component X, you should do so when the stakeholders of X are online. It sounds like Google was able to solve things quickly, I don't think deploying at another time would have been any better.

<comment><USER4> I'd even argue that the best time to deploy is during the best engineers' working hours. At least you guarantee they're around when/if things go bad.

And by "best", I don't mean all stars (a la Fitzpatrick, Norvig, Pike or other Google celebs), but the engineer who actually followed the whole project/patch from dev environment to production.

</comment></comment></comment><comment><USER5> in a nutshell: gmail went down for 18 minutes because of continuous deployment[citation needed], which they explain a bit of the rationale for. Then they come back to the headline, basically saying that as more companies do continuous deployment, we might see more breakages, though probably briefer.

Not the most focused article, but kind of cool that they wrote about such a thing. Though the headline feels like pure linkbait.

They also missed my personal favorite attribute of continuous deployment: isolated problems. If you deploy 10 features and something breaks, unless they're completely orthogonal you now have more than one place to look/person to ask/team to deal with. If you deploy one and it breaks, you know where the problem lies.

<comment><USER2> > Not the most focused article, but kind of cool that they wrote about such a > thing

Why? GigaOm writes about that sort of thing all the time. (BusinessWeek is just syndicating here, it's a GigaOm article: [http://gigaom.com/cloud/why- you-should-expect-more-online-ou...](http://gigaom.com/cloud/why-you-should- expect-more-online-outages-but-less-downtime/) )</comment></comment>


Ask HN: DigiCert is hiring, know any fantastic PHP developers? - <AUTHOR>

Position: Senior Developer
Description:
Great programmers and great companies deserve each other. You are an awesome programmer. DigiCert is an amazing company – one of the fastest growing companies in Utah, with fantastic employees and job satisfaction that is through the roof. Shouldn't we be together?
DigiCert is one of the largest and fastest growing Certificate Authorities in the world. We issue digital certificates that are used to secure websites with SSL/TLS encryption. Don't have a clue what that means? That's ok! We'll teach you everything you need to know about SSL.
About You:
-Back-end web programming skills. Your PHP and MySQL are off the charts -Security focus. You write code that is secure and have security at the forefront of your mind in all your programming -Debugging and troubleshooting.
About You (optional):
-You are good with Javascript/AJAX/JQuery -You write clean, standards-based HTML and CSS -You are familiar with version control systems -You have broad language experience
About DigiCert:
-We value individuals. We have built our reputation on excellent customer support, and we know that the only way our employees will take care of our customers is if we take care of our employees -We value our company culture and atmosphere. -We believe in security. We are a security company, and we believe that a secure Web is better for everyone
Job Perks:
-Fully-stocked kitchen. Like, REALLY fully stocked. Fridges and cupboards full of food and drinks -DigiTrips – Employees get an extra week of time off and a vacation bonus. You only get the time and the money if you use it to go somewhere awesome. (Don't worry, we let you define "awesome.") -Medical and dental insurance (company pays 80% of the premiums) -401(k) plan with 100% employer match up to 3.5% of salary -It's just a great place to work. It's like Olive Garden – "When you're here, you're family" – except the food is better <comment><AUTHOR> If you are interested, email a resume or cv to: email@example.com</comment>


Senate passes sweeping tax overhau - <AUTHOR> https://www.politico.com/story/2017/12/01/tax-bill-2017-senate-republicans-274453 <comment><USER2> Oh look. Not a word about what the bill contains, just gossipy reporting on the strife of getting it passed. I'm not surprised.</comment>


Beware of Icebergs in Software - <AUTHOR> http://blog.intercom.io/beware-of-icebergs/

<comment><USER2> Steve Yegge penned a similar discussion a few years back, "Have you ever legalized marijuana" - [http://steve-yegge.blogspot.com/2009/04/have-you-ever- legali...](http://steve-yegge.blogspot.com/2009/04/have-you-ever-legalized- marijuana.html)

A good read.</comment>


Show HN: Commoso | A Communications, Marketing and PR Marketplace - <AUTHOR>

Many startups need marketing help but can't afford a full-time employee/don't know where to find freelance marketers, so I built Commoso (my first startup).
I would love to know what you think about the idea and what improvements I could make. Thanks in advance!
http://commoso.com <comment><AUTHOR> Clickable: [http://commoso.com](http://commoso.com)

</comment><comment><USER2> I'm sure there is demand, but your site is basically just an email form. Why would anyone fill that in unless they knew you had insane marketing experience or some other reason?</comment>


Saudi Arabia threatens Russia with Chechen terrorists at Olympics (paragraph 8) - <AUTHOR> http://www.telegraph.co.uk/finance/newsbysector/energy/oilandgas/10266957/Saudis-offer-Russia-secret-oil-deal-if-it-drops-Syria.html

<comment><AUTHOR> If true, utterly despicable.

 _> As-Safir said Prince Bandar pledged to safeguard Russia's naval base in Syria if the Assad regime is toppled, but he also hinted at Chechen terrorist attacks on Russia's Winter Olympics in Sochi if there is no accord. "I can give you a guarantee to protect the Winter Olympics next year. The Chechen groups that threaten the security of the games are controlled by us," he allegedly said.

Prince Bandar went on to say that Chechens operating in Syria were a pressure tool that could be switched on an off. "These groups do not scare us. We use them in the face of the Syrian regime but they will have no role in Syria's political future."_</comment>


The collected works of F. W. Lawvere - <AUTHOR> https://github.com/mattearnshaw/lawvere <comment><USER2> F. W. Lawvere is the author of _Conceptual Mathematics: A First Introduction to Categories_, and known for his work in Category Theory.</comment>


Show HN: Unimersiv – A platform to learn through virtual reality - <AUTHOR>

Hello HN,
Since the first time I used my Oculus DK2, I've been convinced that virtual reality could disrupt education as we know it and some amazing experiences like Apollo 11 (first kickstarter I back) just proved that...
That's why I'm building Unimersiv, a platform dedicated to virtual reality courses on which VR developers will be able to share and sell their educational content. I envision a world where people will be able to learn anything faster (sports, sciences, history...) through their VR headset.
I would love to know what you think about this idea, is VR educational content something you appreciate? As a developer, would you publish/sell your content on Unimersiv? (btw, don't hesitate to contact me if you are currently working on a VR courses).
Thanks! <comment><AUTHOR> Link: [http://unimersiv.com](http://unimersiv.com)</comment>


Create a Highly Organized, Synchronized Home Folder with Dropbox - <AUTHOR> http://lifehacker.com/5678172/create-a-highly-organized-synchronized-home-folder-with-dropbox <comment><USER2> Just remember that on a Mac, which is the post's focus, Dropbox doesn't sync any metadata at all. This has important implications for Spotlight searching, preservation of text encoding formats, custom application bindings for documents, and many more things. You are in for a world of pain if you try to sync your entire home directory using this scheme.</comment>


Zuckerberg announces Facebook will now allow users to turn off political ads - <AUTHOR> https://www.businessinsider.com/zuckerberg-facebook-will-allow-users-to-turn-off-political-ads-2020-6 <comment><USER2> Ability to turn off all political content (not just ads) is the most needed feature right now. Once they start that feature, only then they will understand how many of us twats are really interested in consuming that toxic stuff!</comment>


Ask HN: Legal timeline for a successful web startup? - <AUTHOR>

I'm working on a webapp and there are a lot of legal things I'm confused about that am hoping you all can shed some light on:<p>- At what point after you launch should you consider forming a company? My understanding is that if you do it correctly with a lawyer this could cost several thousand dollars, so I'd like to wait until I know the startup is successful before I go through the paperwork. Is that the right way to look at it?<p>- What is that type of lawyer called?<p>- How does your timeline change if you're planning on charging your customers a monthly fee?<p>- Seems like a lot of people just throw a copyright symbol at the bottom of their work. Does that actually mean anything if there isn't any accompanying paperwork?<p>- When you launch a site what's stopping someone copying you idea and design and launching their own site? Is this what the Intellecual Property paperwork is for?<p>- On the flip side, what if your site is building a concept that someone else pioneered?<p>(For the last two I realize the answer might be "talk to a lawyer" but any general pointers would be helpful at this stage) <comment><USER2> I'm not a lawyer, but I have helped launch a couple companies:

* Form an LLC now, so that your business operates under limited liability, as its own entity that can invoice and be invoiced, instead of out of your bank account. Cost: $200-300. You don't need a lawyer to do this in a one-person shop; just fill out the web form and give them your credit card number.

* You want a business lawyer once you have multiple employees (whereupon you'll restructure the company, often to a C corp so you can issue equity) or before you sign your first complicated contract.

* If you charge money, you probably have terms and conditions, and you probably want those reviewed before you publish them.

* You don't need to do anything special to claim copyright in the US, or anywhere else the Berne Convention applies.

* Nothing stops anyone from copying your idea and launching their own site except for a contract that they actually sign that prohibits them from doing so. When you launch, the clock starts ticking.

* Regarding your next question: welcome to the Internets.

</comment><comment><USER3> They're called corporate lawyers, but many small firms and individual lawyers do corporate law along with other areas of practice.

There are tax issues on what you get to deduct before and after starting a company, but really I think your main concern should be the reason why you want to start a company. If you have considerable individual assets and your venture might be risky in terms of owing people money if it fails, then you would want the strong legal protection a company can provide. If you're doing something very benign, like starting a blog thats unlikely to get you into trouble, well, you can wait.

It also matters how much capital you have. If you spend it all on a lawyer you might end up with a nice document and not enough capital to carry on a real business. On the other hand, you can have a great business and get caught without legal protection.

This question was much more easily answered before the internet when people started businesses with real profit estimates and business plans. Its a little harder now with the "build first, worry about profitability later" attitudes because you might build a web 2.0 business and it never takes off, so you'll come away thinking your thousand dollar investment in a lawyer was wasted. It probably wasn't, but you'll think it was because the venture wasn't successful.

When actual money starts to change hands, the legal protections become more easily visible and the value they provide is clear.

If you're not sure you'll make money, i.e. you're building a website and hoping it will take off, my down to earth advice is to get a Nolo book, pay the $200 to incorporate an LLC somewhere, and live with that crappy legal situation until you start to make money. Its at least some protection at a cheap price.

</comment><comment><USER4> Mistake number 1 is asking hackers for legal advice. This is far worse than asking lawyers for programming advice, because at least lawyers will tell you they don't know. You're going to get 100 opinions here ranging from uninformed to semi-informed, and all answers will be based on their own experiences and not your specific legal needs.

Talk to a business lawyer immediately. They won't charge you anything for the initial consultation and will answer these questions.

</comment><comment><USER5> 1\. You can probably file LLC papers with your state (or another state) for ~$200. I did that for my first company and didn't hire a lawyer until 3 years later. I highly recommend doing this before you launch your startup. You really should talk to a lawyer before launch, but this is better than nothing.

2\. Nothing stops someone from stealing your idea, except: (a) patents, (b) copyright, (c) trade secrets.

You only have to file paperwork for (a), not (b) or (c).

3\. You can build on someone else's idea, unless it violates (a) or (b). (c) only protects you as long as it remains secret.

4\. Talk to a lawyer. :)

<comment><USER6> (RE: #1)

That's fine and dandy for LLC documents, but if you're working with partners and don't have a clear Operating Agreement written out then you're asking for trouble. I had serious issues with my first successful startup because our Operating Agreement was basically pieced together from little things my partner and I found on the Net with collaboration from a first year Yale law school student. Terrible, terrible, terrible idea.

To make a long story short: the company became wildly successful very quickly and re-doing the Operating Agreement wasn't really on the top of our minds -- it never is when you're doing well. Then three years later the two of us grew apart and wanted to take the company in different directions. Sadly, we had a poorly written agreement that made this a very difficult process with lawyers on both sides fighting to interpret it. If you do nothing else, I'd say get this done professionally sooner rather than later.

<comment><USER3> Yeah, my advice was definitely for a one person company. Two people should get it done professionally. With one person the focus is on protecting yourself from others. With two or more, the focus is not only protecting the principals, but regulating the relationship between the principals and the process by which that relationship might end. One thing a good lawyer will make you do is think about what will happen if your company breaks up, and they can advise you on how to structure your document to avoid a giant litigation mess.

<comment><USER7> The better then nothing bit still applies.

</comment></comment></comment></comment><comment><USER8> Just fyi the copyright symbol has nothing to do with being a company or not. The copyright law in this country basically says that if you made it, its yours.

As far as timeline, I would go with registering an LLC. Its cheap and will give you a form of legitimacy.

</comment><comment><USER9> Forming an LLC is cheap and easy, but be sure to keep up with paperwork. I showed our "books" to an accountant and he told me that if we ever went to court with that, our LLC status would be stripped away immediately and we'd be personally liable on everything.

<comment><USER3> Good advice Micah. A lot of people think once they sign the LLC document they're magically protected and can just ignore it until something comes up. One of the advantages of LLC's over C-Corps is that they get rid of a lot of the formalities, but that doesn't mean you get to ignore everything. There are a few things that can get you in trouble, but like you mentioned, mixing your books is a HUGE deal.

<comment><USER9> Yep, magically protected. That's what we thought :)

</comment></comment></comment><comment><USER10> Is this webapp a hobby, or a business? Are you serious about it being a start- up? If so, I'd definitely talk to a lawyer _before_ you launch, and get yourself organized.

Do you have a business plan? A budget?

</comment><comment><USER11> I'd be interested to know more about what people actually did versus what they should have done. And how did it work out?

There's more legal work than just incorporation. Do you need business insurance? Do you need to register somewhere for DMCA protection?

<comment><USER3> "You only need insurance when you need insurance" Ok, I just made that quote up, but its true. You can never really answer that question, because the people that paid for it and never used it would say it was a waste of capital, and the people that never bought it and needed it will say you should always buy it. Insurance is, and always will be a risk calculation that only you can do. A lawyer just reminds you of a lot more bad things that can happen to you than you probably had on your list, but ultimately, you need to decide the chances of them happening to you, and how much you're willing to pay to be protected.

With that said, some businesses are required to have insurance and bonds by law, but that's usually something you can easily find out by looking at a government website or Googling.

<comment><USER11> Actually, we just took on a customer who required insurance. So sometimes you need it when you don't need it. I was pretty surprised when the request came through and didn't know anything about how to get it or what to look for.</comment></comment></comment>