skysight-inc/HackerNews huggingface dataset:
If all human jobs are eliminated, that means you never have to hire a human to get something accomplished.

"But what about those who can't afford the super expensive robots?" you say?

If they are too expensive, you'll just have to trade with your fellow humans who also can't afford them, just like you do now. Millions of people all over the world do jobs that are already automated. The Amish even do it right here in the US, if you need a blatant example.

Of course, robots will become cheap just like every technology eventually gets cheap. They are only expensive in fantasies where only one variable is allowed to change and all logical consequences are ignored.

The reality is that building houses and growing food and transportation and medical care and many other things are all going to get much cheaper.

And so will writing code, prototyping new inventions, market assessment, manufacturing and distribution. Anybody that wants to dream up new apps or physical inventions all day will be able to sell to a global market. A global market of bots who filter the millions of new things for the exact needs and desires of their human masters.
> fewer shitty jobs building stuff

I agree that jobs involving manual labor and assembly have a higher risk of physical injury than desk jobs. But I don't agree that "building stuff" is categorically more shitty than, say, sitting in a cubicle farm trying to maximize the rate at which people click ads.
This benchmark feels a little lazy. While I am in no doubt that Go could match the 2M concurrent websockets of Elixir's Phoenix framework, a benchmark should aim to implement the same functionality to be considered useful.

The only interesting thing here is that with that 10M connections figure, each connection handler goroutine contained at least 2 channels (sub and t), and they seemed to scale (no mention of latency though).
Inheritance isn't terrible if you design your classes properly.
I concede the example is a bit of a straw man. But I'd challenge you to provide a similarly concise problem and solution where 1) inheritance is useful and 2) there isn't a better solution that doesn't use inheritance.
What part of parent has not been your experience ?

I have experience parent's woes and more. That includes having Oracle staff in house doing in-person knowledge transfer. Experience says that Oracle will not provide a qualified person if we call for one as well. Sourcing from their own consultant pool is also a black box crap-shoot.

We also involved Dell and their support team to provide feedback and second opinion on Oracle CBO, query optimization and overall needed knowledge to use their Toad for Oracle performance tools. They literally stopped short of saying: yeah, you need people smarter than us for that.

I still think Oracle is a great product, but it's only fit for large organizations with bottomless budgets. I think we spent something north of $100K on Oracle's E-learning and that was probably the cheapest item on the list.
I think what he means is that in school we are taught inheritance and nothing else, so many programmers only know it's "pros" and not why other techniques like composition can be beneficial.
I remember learning OOP back in the day. Personal projects from scratch took forever because I kept imagining more edge cases which required more and more abstract ABCs. And I felt the reason I couldn't work with all this OOP stuff was because I wasn't as smart or devoted to it.

I'm not saying I'm smart, but it's funny now that it at least seems like the whole "modern approach" is anti-inheritance and more about "interfaces" and composition, which essentially is what I did anyway because inheritance OOP got me nowhere.
Here's how I've experienced languages, technologies, and paradigms over the past 20 years of my professional career:

Step 1: settle on technology X because it fits in rather nicely for our requirements.

Step 2: The requirements change a bit. Mostly you can handle it elegantly, but there are some rough edges.

Step 3: More new requirements. Now things are starting to look pretty ugly in places. Evangelist B says "See? I told you technology Y was the right choice! Now look at this mess!"

Step 4: Go with technology Y on the next project.

Step 5: GOTO Step 1
Ok, but it surely can be known (and obviously was due to the get_price() interface stub) that every Item will have a Price, so I stand by my intuition that a Price object could be included in Item.
> I've yet to meet an anti-TDD zealot who has actually spent a month developing the art of TDD. The detractors tend to be people who write really brittle tests that are a pain to maintain.

I guess I loosely fall into the category of "anti-TDD". I don't generally go around badmouthing it, but I'm not really sold on the idea that it would save me significant time or effort. I certainly encounter things that TDD would likely catch earlier, but those are typically easy fixes and caught in QA or beta testing. The majority of my bugfixing hours are eaten up by things for which I don't even know what it would mean to write tests, such as:

- reproducing rare hardware-involved errors (often race conditions, often based on the variability of random-ish real-world events) in a way that allows getting relevant information logged/dumped

- clarifying product definition/spec, usually to resolve some inconsistency where the behavior isn't invalid per se but implicitly conflicts with some other requirement (i.e. we basically decide which behavior to call a bug and change that one)

- reverse-engineering undocumented design decisions of some third-party product that our product is expected to work with, because we foolishly believed that there was a standard (overlaps somewhat with #1)

So while I don't claim that TDD has no value, I admit to rolling my eyes a bit at the more fervent evangelists.
Inheritance isn't necessarily part of OO. Go has radically weaker inheritance mechanisms than classic OO languages, for example.
I'm hazarding a guess- I've never looked into the teaching of CS, just been taught a lot of it.

I think it's because people just starting out are able to grasp the concept of a duck is a bird is an animal AND you can reduce the code you write by saying all animals walk, birds fly, and ducks quack. So you are building on from the parent class.

With interfaces you are saying all implementations of animals walking can be different, so you're going to have to write code for each one to this contract. You're not nexessarily suggesting that you could reduce the code you write in that case. Then when you get to all other sorts of class composition it gets pretty hard to understand at first.

I think that's the main reason, it's easier to get started with. Also, CS teaching is nothing like real life development, as you stated, interfaces get used quite a bit more than the idea of concrete, or even abstract base classes but you just might have an abstract base class that implements part of the interface.
This story is remarkable and deserves not to have been buried :(

"But recent studies have shown that people who use GPS, when given a pen and paper, draw less-precise maps of the areas they travel through and remember fewer details about the landmarks they pass; paradoxically, this seems to be because they make fewer mistakes getting to where they’re going. Being lost — assuming, of course, that you are eventually found — has one obvious benefit: the chance to learn about the wider world and reframe your perspective."
This seems ridiculously good for a SysDE with that much experience. I had two years at a smaller company previously and was hired as a SysEng I for way less. Not in Seattle but still felt as though I got a raw deal underestimating myself.
Show HN: Replacing Your DVD Library (Looking for Feedback)
We have been looking into a new concept to replace your DVD Collection. We think it is crazy that in this day and age if you want to watch a DVD you have to dig out that disc, hope its not scratched and set up the DVD player.

Our concept is that you would scan your DVD's barcodes and then send the discs to us. We add a digital copy to your library on the site and then sell the dvd's and send you a cheque.

We are in the early prototype stages and looking for feedback on the concept and what people think maybe missing.

The link is http://www.streamlyapp.com

Any Feedback greatly appreciated.
Show HN: Diskache – Combine SSD with HDD on Windows
I'm seriously questioning their technical competence not just from support but also from development.

Have to agree with you there. I tried their online office apps a few times over the years (also recently) and was surprised how limited and kind of janky the software is. They don't seem to be improving.
Bootcamps could be useful if students just use them to get their foot in the door at a truly entry level job that is basically a learning experience.

If you pay cash for a bootcamp and then work for $30,000 a year for 4 years on real projects, you would be a much more attractive job candidate than many people with an undergraduate CS degree, and you might even have some savings instead of massive debt.

The problem with "bootcamps" seems to be that some people think that they can short circuit the learning/experience process, which is just not possible. If willing to keep learning after the initial program, seems like it could be a good option.
Yes totally agree.

The best way that I learned OO was when it was explained that, in most cases, its best to take objects as nouns (ie Item, Book, Prices etc) and the object methods should be verbs (ie do_something() or act_on_this() etc)
I think Samsung has a division that makes them for the ROK military (not being facetious, but possibly being incorrect)
The Amish are hardly the only endogamous group in the US. Many small immigrant communities engage in similar behavior, because due to cultural reasons, they tend to marry into the same group, it's only as they integrate into the greater society they become more exogamous. Now, the difference here, is that they remain voluntarily isolated after so many generations and they don't tend to "import" mates from over seas as some smaller immigrant communities might do.
Thanks jonty, looks like a fine resource, though it's a bit expensive to use ($25000)
You can specify poudriere which packages to build, it does not have to be all of them. This is in addition to the custom make.conf and options files. The resulting repository catalog will contain only the packages you specified, plus all their build- and runtime dependencies.

What it can not do is infer the list of ports from the custom make and port configurations.
C++ doesn't have interfaces, so it's quite understandable you wouldn't learn about them if you were learning about C++.

Java-as-taught is often ancient Java, from before enhancements like default interface methods. The only non-annoying way to inherit behaviour in ancient Java is inheritance. Even modern Java lacks automatic implicit composition ala Go.

Java also encourages large interfaces with many methods. Without any ability to inherit behaviour for those methods, it's often less tiresome to inherit from a class instead. Go, by way of contrast, encourages tiny interfaces with, ideally, one or two methods.

In this example, we might suppose that a quintessential "vintage" Java-esque design wouldn't have a single-method "Priceable" interface. It'd have a CartItem interface with hundreds of methods, all of which you'd have to implement - even if only to stub out with exceptions - in order to implement it. So you wouldn't actually use an interface, or else you wouldn't be avoiding all that typing.
Couldn't you have done it using Internet, books, video tutorials, etc.?
Spot on.

And chances are, you share the most intimate details of your life with your smartphone.
Assorted thoughts, in no particular order:

1. The speed at which you initially write your code doesn't matter that much. The time cost of a program plays out over months or, if you're lucky, years. Oftentimes, being thoughtful when writing a program at the beginning will lead to massive time savings later on.

2. If you're honest about your skill level and work for a well-run company, you won't be considered incompetent again. You're going to have to do a lot of extracurricular work, though. You should be upfront with prospective employers that, while you may have gaps in your knowledge, you're happy to do homework.

3. Drupal is pretty complicated. If you want to find a niche, you're better off with WordPress, which will be slightly simpler and provide better job opportunities.

4. If you can't find a job coding, you may want to look into doing QA or project management. Having the boot camp under your belt might make you more attractive in one of those areas, and then you can work on your coding skills in your free time and hopefully transition to coding.

5. People are going to hate me for saying this, but go learn Java (start with a Spring project). It's a pretty easy language to learn, and there are tons of Java jobs. PHP and Node are also good things to learn. Ruby (with or without Rails) is an absolutely tiny job market by comparison.

6. If you have any interest in frontend stuff at all, go learn React. I'm not going to comment on whether it's a good library or not, but it's popular and fairly easy to learn, and it works in the browser as well as mobile devices.
>What to Submit

Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.

A Show HN needn't be complicated or look slick. The community is comfortable with work that's at an early stage.

If your work isn't ready for people to try out yet, please don't do a Show HN. Once it's ready, come back and do it then.

Blog posts, sign-up pages, and fundraisers can't be tried out, so they can't be Show HNs.

https://news.ycombinator.com/showhn.html
After most furniture manufacturing moved overseas, it was impossible to find reasonably priced quality furniture for a while. I found an Amish furniture maker near Bird In Hand who filled that need for us.

The guy had no electricity, but did have a small PDA with a solar charger - many years before that became common and PDAs morphed into phones. He ran his whole business off of that, and what was in his head.
I don't necessarily think it's even TDD vs not... I'm not big on TDD, but always try to design my code so that it is very module, and as a side effect easier to test. At least beyond some cross cutting edge cases, which are usually easy enough to isolate.

The act of TDD, or test compliance is only that you've looked at everything twice. It doesn't guarantee quality. Writing modular code means less friction over time, and TDD encourages this, but it's not necessarily a requirement imho.
That's my experience with a bootcamp as well. I had the right mindset from attending an engineering school, but no degree / not living in the SF Bay Area / not having the structure and organization to put myself out there.

The faculty was also concerned about succeeding through the acceptance filters - if they couldn't make less prepared students successful, then expanding in order to accept more students is a really poor choice.
Basically CLOS (Common Lisp Object System) implements Flavors' mixins as normal classes. Example:

(defclass priceable-mixin () ()
(:documentation "we can calculate a price for something"))

(defclass standard-priceable-mixin (priceable-mixin)
((price :initarg :price)))

(defmethod price ((i standard-priceable-mixin))
(slot-value i 'price))

(defclass shared-priceable-mixin (priceable-mixin)
((royalty :initarg :royalty)
(markup :initarg :markup))
(:documentation "the price has two components: royalty and markup"))

(defmethod price ((i shared-priceable-mixin))
(with-slots (royalty markup) i
(+ royalty markup)))

; we want to sell books and movies

(defclass book (shared-priceable-mixin item)
()
(:default-initargs :royalty 2 :markup 8))

(defclass movie (standard-priceable-mixin item)
()
(:default-initargs :price 10))

; there is a cart with items and a total price

(defclass cart ()
((total :initform 0 :accessor cart-total)
(items :initform nil :accessor cart-items)))

(defmethod add-item-to-cart ((i item) (c cart))
(push i (cart-items c))
(incf (cart-total c) (price i)))
It's like anything in life. You have enthusiastic people that have this vision in their head about becoming a software developer and joining a startup.

When the realities hit and they realize that some of it is mentally taxing and boring work, they give up and quit.

I've been writing software for 20 years. I haven't gotten bored yet.

In any boring task, I can always learn something new that's interesting.
Researchers take small step toward silicon-based life
I like to think that software can actually be perfect, and that "good enough" is the mortal enemy of excellent. I agree regarding arrogance, though... I think it's insane to imagine that the insertion sort (for example) is somehow more innovative than the plane, train, automobile, or combine.

I think that you can actually get very far in terms of educating yourself with the materials and tools that are now publicly available. I'm currently spending a lot of time doing this, so I suppose it's an axiom that I've accepted.

https://github.com/hypoalex/machine_learning/blob/61d6729489...

For instance, I personally find Jupyter Notebooks many times more useful than traditional course notes. They're executable, they can be revisited and expanded upon, and they're actually used commercially... so you're killing many birds with one stone. It would be a very different world if the first thing you learned in high school was version control and Python, but it might actually be one worth living in.
I thought about this quite a bit. I don't think I want downvoting. And I don't want effectless upvoting. The way it is right now is that you can add a paper to your library, and it will then feed into your personal SVM as a positive example of papers you like to see more of. Adding paper to your library as a type of paper you like to see more of effectively counts as an "up vote", and is what is sorted by when you go to the "top" tab.
That's why I think its weak. It's driven by fomo rather than going for what you want. Throwing out the first number let's you anchor the negotiation. It puts you in control.
Interesting. I had read about Oberon (the OS) and probably Lilith in an old BYTE magazine issue years ago.
Haskell has interface based generics, just like the article wants people to write. It just calls its interfaces by classes, and has a more powerful implementation than Java, that deals with default code and makes incompatibilities impossible.

Haskell even allows interface inheritance, just like Java, but calls it by... well, no name that I'm aware of, but it's there.
I love reading things from 150 years ago that are more relevant than ever. Thanks for sharing.
The only way The Work Number has access to your salary information is if your employer has given it to them. If your employer is willing to give that out then yes a hiring company can verify your salary.

We are back to my original point that the only way a hiring company can verify salary data is by asking your employer (or having 3rd party ask for them) or forcing you to verify it.
Call me pessimistic, but I mostly expect myself, my children, and probably their children, to all be retired/dead before CS makes it into K-12 curriculum. That said, I really like this proposal. No language is named or suggested in the first few pages (and maybe the whole document)...as it should be, just like a proposal to teach reading and writing wouldn't specifically mention English and Hemingway. Rather, the focus is on teaching recognition and decomposition of computational problems, something that could feasibly be done by pen and paper (though it wouldn't be much fun, to be honest).

As someone who teaches programming in the digital humanities/journalism field...it's been hugely disconcerting to me how the word "algorithm" is used as a kind of de facto adjective to certify the correctness of a hypothesis/process, e.g. "I have a revolutionary algorithmic process that can tell when a politician is lying to you!"...In my opinion, it'd be a huge victory to be able to make the word and concept of "algorithm" so commonly understandable in mainstream thought, that the phrase, "You, using a pen and paper, can do anything a computer can" wouldn't have to be a concept stated explicitly in a publication written for business leaders and professionals.

[1] http://www.bloomberg.com/graphics/2015-paul-ford-what-is-cod...
> In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way.

Depends on the kind of TDD. I feel like TDD as Unit Testing driven design IS a waste of time (I'm talking about unit tests first here). However integration testing first is useful. Let's say I'm writing a library(a http router). The library will obviously have an API that will be consumed by the user, well for me testing will be like writing first how I think the API should look like. For a http router it would be like :

var router = new Router();
router.get("/{id}",someController);
response = httpClientMock.get("/34943");
expect(response.body).toBe("Hello 34943");

It costs me very little to write that , provided the language has all the facilities to test http servers[1], and check that the result of the operation is what I expect. I don't need to test the code that will parse the path for route variables directly, yet I did write the test first.

1 : that's often the problem , languages care about syntax but don't care about developer experience and the quality of tools around the language. It's not just "a compiler and the rest is your problem",no testing should be entirely part of the language or its standard library. Testing SHOULD be made as easy as possible.
You're kind of off-base. A formal computer science education doesn't really teach coding at all. You'll learn how to write code (hopefully) as a corollary to learning how computation works. At least in my program, there isn't any single course that's oriented around the act of writing code.
I agree with this sentiment. Frankly, govt. sponsored research is very hard to get right. The US Federal Govt. is probably the only instance of a government agency I know of that consistently delivers good value for all that investment (through NSF, DARPA etc.) which is why it pains me whenever Congress announces budget cuts for those agencies.
I would acually prefer that there were many more "getting started" posts in Rust-world, personally. I think it's a very under-served area.
Exactly. I can watch a movie on my own couch, with my own popcorn and soda, and my friends and family basically for free. With a 40"+ flat screen that costs about the same as four or five trips to the theater.

I've noticed in the last few years that there are fewer and fewer movies that I'm even vaguely interested in seeing. Maybe when I was living at home and near a theater that offered $4 tickets, and no ads, I might take a flier on a potentially bad movie, but at $12-15 a pop at the chain cinemas around here, when the movie doesn't start on time because they are showing 45 minutes of ABC commericals... Nope
Concise version, presented chronologically: https://en.wikipedia.org/wiki/Ames_Stradivarius
You are right, but there's a way around the argument that allows them to still make a bad decision. It's called management by committee. They don't need to provide a good fit-gap analysis, sound points for the plan or quantify why it's better. You will simply hear that a group of smart people have concluded that it's a "good plan" and that they consulted with Oracle and their own experts who are also absolved of any responsibility since lack-of accountability is built-in to their contract.

It will cost a lot in time and dollars to actually get what you want and you will not want to litigate Oracle.