Hacker News Reader

staticinton Poor kids who do things right don't do better than rich kids who do things wrong

He works his ass off to be wealthy. He didn't suggest that is the only way to be wealthy.

staticinton Bay Area wages soaring but still can’t keep up with housing prices

The modern American Dream, perhaps. The historic American Dream was a marketing campaign centred around enjoying the long commute in your American made automobile.

staticinton Everybody Thinks They're Middle-Class

~$400k is the threshold for household[1] income. ~$200k is the threshold for individual[2] income.

[1] https://en.m.wikipedia.org/wiki/Household_income_in_the_Unit...

[2] https://en.m.wikipedia.org/wiki/Personal_income_in_the_Unite...

staticinton TV’s Dwindling Middle Class

But we are still bound to supply and demand. If everyone was a coder, price would plummet. Programmers are only currently able to do reasonably well because they are relatively limited in numbers compared to the demand for them.

It is very much impossible for most Americans to be coders while maintaining high incomes. The industry isn't anywhere near that big, currently employing less than 1% of the population. Even if it could grow by an order of magnitude, it still wouldn't absorb any meaningful portion of the population.

staticinton TV’s Dwindling Middle Class

Class represents how income is accrued.

The working class, as the name implies, earn their money by working. The upper class make their money through investments. The middle class fall in between. They make part of their income by working and part of their income through investments.

The practical implications are that if the working class stop working, they can no longer make ends meet. The middle class have the opportunity to stop working for periods of time, but not indefinitely. The upper class can survive without ever lifting a finger.

staticinton Building Web Apps in Go

While I completely agree that the standard library is all you need in quite a lot of cases, the parent seems to be asking from more of a "how do I structure my application" perspective. A tool that generates the boilerplate necessary to use the standard library effectively in a complete application. Not just http handlers, but think of the persistence layer, for example. The standard library does not assist much with the engineering aspect of the job.

staticinton Building Web Apps in Go

The issue with that is that anyone invested in Rust or Scala have no reason to want a better type system in Go. Fixing Go is as important to them as fixing COBOL, and I don't see HN full of threads on what needs to change in COBOL.

What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).

staticinton Building Web Apps in Go

What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them?

Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.

staticinton 2015 “smashed” 2014’s global temperature record

> the only clean at scale power solution for peak load is nuclear power

Nuclear is fantastic for base load, but peak load? Steam bypassing costs as much as generating electricity does, but with nobody wanting to pay for power they didn't use. Technically a good solution, but falls apart economically.

staticinton The Rails Doctrine

Having used Rails seriously since it was originally made available as an open source project, I find myself agreeing with you less and less. It has really failed to stand the test of time, in my opinion.

I agree that it nailed the needs of web applications in 2004. If you are still building web applications like they did then, perhaps it is still the best tool. In the circles I find myself in, there is a push for much more Javascript heavy applications and Rails starts to become a large hinderance more than a help in that environment, when compared to other tools.

We've built a log of great software together over the years, but I can honestly say that I'm not going to rush into using it in future projects.

staticinton Before I Can Fix This Tractor, We Have to Fix Copyright Law

Case IH and New Holland are both under the CNH (Fiat) umbrella, so at least you don't have to choose between them.

staticinton In the Works – AWS Region in Canada

I imagine it is being primarily driven by the recent vast decline in the Canadian dollar. Just about all of the costs involved are going to be about 30% cheaper compared to a couple of years ago.

staticinton Getting ahead vs. doing well

> The concept of a salary is to pay someone in return for work performed.

Not necessarily. Having someone retained for future needs, for example, is worth paying for in some cases. Value isn't limited to work performed.

Pay is, of corse, just the point where the buyer and seller agree. There is no fundamental reason why a janitor position cannot pay the same or more than a manager, if janitors refuse to do the job for any less.

staticinton Everything You Need to Know About Your Son and Daughter’s University but Don’t

Additionally, while I do not know in which country you reside, generally countries who fully subsidize higher education have much more stringent requirements to entry, allowing only those who are completely serious about receiving an education access.

In America, if you are willing to pony up the cash, you're pretty much guaranteed a spot. Combine that with the common idea that you will not be able to find a job without a degree and you end up with a lot of people who aren't really in it for an education, but feel like they have to be there anyway.

staticinton U.S. predicts zero job growth for electrical engineers

Also, H1B workers get paid the same as local workers... So if you buy the allegation that wages are being depressed by H1B workers, why don't you take a peek at the bulletin board of your break room

The idea usually is that the presence of an H1B means that someone local does not exist to do the job, which means that a company would otherwise have to pay more than the going rate to poach someone else from another company. Then the company losing the employee has to pay more to poach from somewhere else, and so on, until eventually everyone who is suitable for such a position is making more.

The fact that H1Bs are paid what the locals are paid is exactly the issue people have when they talk about wage suppression. It is in much the same vein as when Apple/Google/et al. agreed to not steal each others employees. It is not like those employees were exactly hurting for compensation, but they theoretically could have made more without that treaty between companies.

staticinton Accounting for the Rise in College Tuition [pdf]

> Most exceptionally high earners have college degrees.

Interestingly though, most exceptionally high earners have post-graduate degrees, according to Gallop[1]. When you exclude that group, the non-college graduates make up the largest portion of the highest earners.

If there is causality here, it seems one has to be mindful to continue their studies long enough to see the benefits. Simply getting a degree does not seem to pave the way to a better income.

[1] http://content.gallup.com/origin/gallupinc/GallupSpaces/Prod...

staticinton The first person to hack the iPhone is building a self-driving car

I take that to mean that for the first time in his life he read the papers and fully understood them without needing additional background, not that there isn't more to learn outside of those papers.

staticinton Real talk from real computer science teachers

> Most students of history in high school won't be historians; most students of literature won't write great novels or screenplays; and so on.

But by the same token, the economic effects are quite apparent. It takes a very special individual to rise above the pack in history and literature to turn that into a successful career. For most, with so much competition, it will never be more than a hobby. Anecdotally, I have a couple of friends who are published authors and I would be surprised if they are ever able to recoup the cost of the time they put into it, let alone sustain their costs of living.

Programmers are fortunate right now that the skill is relatively rare amongst the general population and when demand exceeds supply, prices rise. The concern isn't so much with everyone being a programmer, it is that only a few will be able to make money at it when the supply starts to exceed the demand, much like careers in history and literature today.

staticinton Pricing Programmers

As always, prices are determined by supply and demand.

A price is too high if the buyer can find the same thing (another programmer considered to be an equal hire, in this case; people are not commodities so this can be difficult to evaluate with absolute accuracy) for less. A price is too low if the buyer cannot find the same thing for even an equal amount.

The price is just right, at that moment in time, if there is a mutual agreement between a buyer and a seller.

staticinton Avoiding Reflection (And Such) in Go

> Well, sure. Hand-written assembly is also identical to compiled code

I mean when you convert the template<type> statement to the #define statement with the hypothetical preprocessor, it would be the same as if you had written the same code using #defines originally. They are functionally interchangable. If this satisfies generics in your mind (I don't think this describes you, for what it is worth), then standard C macros are more than sufficient to cover all the cases you would want, albeit less pleasant to type.

> I don't think macros are a satisfactory replacement for generics, no. I don't know how I seemed "excited" about it.

Consider your previous post misinterpreted then. It read to me like you thought the hypothetical code was theoretically different and solved problems with the previously provided macro, even though it was the exact same macro in both cases. The only difference was the slightly different syntax. Which, I might add, anyone can fairly easily add something similar to their Go code if they really wanted to.

staticinton Avoiding Reflection (And Such) in Go

I think you may be reading too much into the hypothetical implementation. It was highlighted as nothing more than syntax sugar, after all. If all you do is translate:

    template<type> max(...) into #define defmax(type) ...

and

    max<int>(...) into defmax(int); max(...)

The resultant code will be identical once it has gone through the preprocessor. All you are gaining is prettier looking code, which shouldn't be discounted, but generics are about more than that. Yet this example would be quite satisfactory to many regardless; curiously even you seemed excited about it.

staticinton Avoiding Reflection (And Such) in Go

Good example. Thanks.

> Which is a shame because C macros just aren't good enough.

No disagreement here. However, that still perfectly satisfies what may people claim they want in generics, especially those who most frequently trumpet that Go is lacking them. If we took that exact macro and added a little hypothetical syntactical sugar:

    template<type> type max(type a, type b) {
        return a > b ? a : b;
    }

    max<int>(1, 2);

a lot of people (not everyone) would be very happy, even though there is no theoretical difference at all. I've seen countless proposals for Go generics that do nothing more than that, but have been rejected for obvious reasons. That's where I'm coming from.

staticinton Avoiding Reflection (And Such) in Go

Okay, macros. Either way, it provides what most people are asking for in generics (not you, perhaps), even if the implementation isn't exactly pleasant. From a practical standpoint, there really isn't a whole lot of difference in utilizing max (other than the ugliness):

    # Common pattern in other languages
    max<int>(1, 2)

    # Similar pattern in Go
    #go:generate gofmt -r 'T -> int' -w max.go
    max(1, 2)

But yes, "true" generics are much more complicated (and arguably impossible in Go without major changes to the language), I realize. A number of languages that even claim to have generics fall short on that front, which is a path the Go authors have said they do not want to go down.

Although you do have me curious how you'd implement max in C in this type-safe way using standard tooling:

    #define max(a, b) (a > b ? a : b)

...obviously wouldn't fit the bill since it doesn't enforce types like to Go version does.

staticinton Avoiding Reflection (And Such) in Go

> It doesn't have generics, at all.

The provided tooling provides templating, which isn't dissimilar to where many other languages stop in their generics journey. The interface does leave a lot to be desired, granted.

      func max(a, b T) T {
      		if a > b {
      			return a
      		}
      		return b
      	}

      $ gofmt -r 'T -> int' -w max.go

staticinton Silicon Valley Is Not Driving Jobs Growth

For comparison, software developers make up about 0.7% of the labour force (2012)[1]. It is always surprising to me how small the industry actually is.

[1] http://www.bls.gov/ooh/computer-and-information-technology/s...

staticinton Swift is Open Source

> this could form the core of yet another cross-mobile-platform development framework

Why not bridge the "yet another cross-mobile-platform development framework(s)" that were written for Objective-C, the same way Apple did with their frameworks? There is no need to restart them all over again in Swift to access them in Swift.

Perhaps you were attempting to suggest that no quality cross-platform frameworks ever materialized for cross-platform development under Objective-C? (there were certainly attempts, including from big players) But if that is the case, I'm not sure an arguably better, but not dramatically different, language is going to change anything.

staticinton Robot gets rid of weeds automatically and without herbicides

Zero years for the first one.

* https://www.bosch-garden.com/gb/en/garden-tools/indego-home....

* https://www.deere.com/en_INT/products/equipment/autonomous_m...

staticinton Working remotely is hard

Wouldn't it be more accurate to say that on-site work was just a temporary regression? Back in the time where almost everyone worked on a farm, the farm was also your home, and mirrors a lot of what remote workers experience again now.

staticinton Interview by a 15 Year Old

It seems unlikely to me that future generations will be able to benefit from programming understanding and ability the way the programmers of today have. Economic value lies in scarcity, and as we are now pushing for everyone to have those skills, it will not be scarce anymore.

The programmers of today have been lucky because the thing they loved to do anyway just happened to explode as an industry in a short period of time, leaving only a small supply of labour ready to fill the ballooning demand. There is no reason to think that will hold for the future. As every good investor will tell you, when everyone starts looking in the same direction, it is time to run the other way.

Some suggest that programming is something that only a small group of people can innately do. Others suggest that it is a task that the majority of the population detest. If these are true, then perhaps it will remain a viable career as most cannot or refuse to do what work needs to be done. I'm not sure I agree with either point. Programming tools like Excel are widely used already by the general population, demonstrating that they can program, that they are willing to program in some capacity, and that it doesn't meaningfully improve their economic standing when outside of a very narrow spectrum of programming – specifically what we seem to call software engineering.

I, personally, think programming related work will eventually trend towards what we see in entertainment, agriculture, etc. A small group of people will do very well, more will do the work for practically nothing just to do what they love, and everyone else will have no direct opportunity whatsoever, with, at best, passing relevance in what they do end up doing.

staticinton First chapter of Kernighan and Donovan's new Go book [pdf]

I am afraid I am not entirely sure of what you are trying to get across here. Your mere mention of go generate indicates to me that you do understand my point about computers being able to free the programmer from doing the drudgery of implementing the same generalized function twenty times. And since you are familiar with go generate, I expect you also realize there are seemingly endless tools that exist to solve this specific problem.

I _think_ what you are trying to say is that templates in Go are less convenient than in some other languages. That is a completely fair assertion. But the idea of having to type `go generate` occasionally adding significant man hours to a project seems a little far fetched. You could even:

  alias go='go generate && go'

I completely understand the appeal of templates/generics being a first-class language feature. Not even the Go authors themselves discount the usefulness. I don't understand why the lack of them is adding so many more man-hours to your projects? The overhead of working around the lack of them should not be that significant, even if less pleasant.