I think HN just has a low tolerance for willful incompetence, especially when charging gigantic fees to the consumer. As has been pointed out by other articles, despite many warning signs that this festival would be impossible to pull off as advertised, the organizers continued to crank the hype machines into turbo mode while slurping up cash from consumers till the last minute. It's a scam.
Well if you think about the fact that almost every startup that goes through YC raises probably $1M+ after demo day, and 9 out of 10 investments likely to lose, but hey move fast and break things as long as it's not a concert for rich people.
In fact your comment could just as well be about many "unicorns" in tech who seem far more than willfully incompetant (e.g. Theranos; Uber); or according to who you ask Etherium (for being hacked and/or forking); and from the sound of press maybe MagicLeap the billion dollar startup who cant seem To launch a product may end up fitting the mold.
Well, Theranos and Etherium are met with frequent criticism on this board with good reason, but the issue isn't about losing out on an investment - which is obviously a risk with any company and clearly not applicable in the case of Uber - but rather, negligent, reckless or fraudulent behavior dressed up in tons of marketing buzz and obfuscated by insane levels of hype that functions only to inflate the ego and perceived prestige of the founders while simultaneously fleecing consumers of their money. The bigger the hype to inevitable-reality gap, the bigger the schadenfreude payoff when the scammer house of cards finally collapses in on itself.
> negligent, reckless or fraudulent behavior dressed up in tons of marketing buzz and obfuscated by insane levels of hype
Sounds like Uber to me.
Yes people got rides and it's a good product, but they still took operations to cities/counties all over the world illegally. Drivers are the ones who are stuck holding the with damaged driving records, and in some cases criminal records, for nothing more that operating under Uber. For example in Miami alone there are still $3.5M worth of outstanding fines from drivers when they were illegally operating as rides for hire.
Multiple that by how many cities? Then extend that business model for to any other illegal activity: drugs, prostitution, murder for hire, etc... but you know hype ($50B unicorn) and marketing buzz (disrupting, sharing economy).
> Just because something has no cultural value doesn't stop someone, int he country, from having the right to say it.
Nobody is denying them that right. You don't have a right to a twitter account. If someone won't allow you to post on their website, you're free to post it on your own website. That's free speech.
And? I don't have a stake in the integrity of twitter or any other private business. If I don't like the product, I don't use it, same as any other business. Frankly, my default assumption regarding any business is that its integrity only goes as far as it affects the bottom line, and that has proven to be true with pretty much every business I've encountered. None of this has anything to do with free speech.
> Human life is the most advanced creation of evolution
Arguable. It depends on how you define advanced. There are many organisms that live longer, are more numerous and can survive in more extreme environments than humans. It is also conceivable that humans might completely destroy all habitable environments, which would certainly disqualify us from the subjective qualification of "pinnacle of evolution". More importantly however, evolution has no pinnacle or direction.
Even if we grant that humans are "the most advanced creation of evolution", it does not necessarily follow that this causes it to be inherently precious.
> The most successful companies all use whiteboard interviews
Not much evidence to demonstrate that this is a significant contributing factor in their success. The five companies listed are pioneering behemoths that transcend the boundaries of rote startup analysis.
Personally, I'm of the opinion that whiteboard interviews are fine, but I think programmers tend to dislike them because the physical act of standing up to write code on a whiteboard is awkward and disconcerting, especially in the context of a high pressure interview. The skill of using a large unwieldy marker to render text by hand on a vertical surface requires a significant amount of practice and I think many programmers just resent the need to hone this skill which is mostly useless outside of an interview setting. Something like a written test or questionnaire with pencil and paper is much more well received, or more ideally an offline workstation running something like notepad that's hooked up to a projector or big screen.
> There is no need to wire money anymore. In the US bitcoins can be purchased instantly with a credit card via Coinbase, as easy as signing up for Paypal.
The caveats being a 3.75% surcharge and the fact that many of the big banks will not authorize bank card transactions from Coinbase. You might have luck calling up your bank and getting them to release the hold on Coinbase transactions, but that's already more trouble and more expense than paypal.
I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason, and if your project is already functioning to specification without the use of these tools, you shouldn't be using them; doing otherwise is the developer's fault, not the tool's or the ecosystem's.
I've thought the same for a while, and now I'm looking to Nix[1] as a solution. Upside: strong fundamental design, extreme reproducibility, great Haskell support. Downside: small community, middling OS X support, essentially non-existent Windows support.
It's still squarely in early adopter territory and the documentation is woeful, but if you're willing to put up with that it really does feel like the "one true package manager" I've been searching for. I've been using it at work and while the setup was painful and some things are still awkward (ie statically linking Haskell executables), it's been incredible overall. The up-front work in learning the system and getting it running has paid off already, and it'll pay off even more as I continue using Nix for other things.
I know at least three reasons why makefiles are not working well for common use cases. Many people seem unaware of these cases, even though they seem to come up quite often.
• make(1) has a hard time rebuilding target files when source files have changed. The problem is that users have to declare the dependencies of a target before the build, but due to file search paths, it can be that dependencies are only known after building a target. To know about all dependencies, make(1) would have to build any target at least twice.
• make(1) by default does not rebuild a target when its build rules change. While this seems really weird to me, it seems to be a consequence of having a single makefile. When a build rule is changed, the makefile changes. So should all targets depend on the makefile implicitly? One could argue that they should – but then each change in a makefile would rebuild all targets.
• make(1) can not handle non-existence dependencies. Imagine a file foo.h being searched for by a compiler in directories bar and baz (in that order). If the header file baz/foo.h is found, then bar/foo.h should be considered a non-existence dependency: If at any future point in time it exists, the target should be rebuilt.
I think that all of these are limitations of not only make(1), but all utilities that expect dependencies to be fully known before a target is built. What makes you think they are not?
How would you solve all three problems I listed using make(1)?
A makefile consists of rules. Each rule contains a dependency line which defines a target and an enumeration of prerequisites. This means that the dependencies have to be known before the target is built. By design, it is impossible for a single-pass make(1) invocation to derive dependencies for a C program, as dependencies are output by the compiler.
By contrast, redo builds the target first and then records what was used to build it. For example, when compiling a C file with “gcc -M”, gcc will output dependency information. With redo, you normally record those dependencies after the target has been built. With make(1), that information has to end up in the makefile somehow, possibly leading to further builds.
I mentioned m4 before as a way of using more passes, and is how the Linux kernel approaches this, but looking deeper at make, I'm not even sure you need it.
Because you mention `foo.o' but do not give a rule for it, make will automatically look for an implicit rule that tells how to update it. This happens whether or not the file `foo.o' currently exists.
I do not understand. I know that make(1) has many implicit rules – but which of the problems I mentioned does this solve and how? Please be specific about your solution.
Because "limiting" has a broader meaning than what is merely possible with enough effort. The experience of practically everybody who hasn't already put in the effort to learn make is that they get much further much faster in more modern build systems - indeed, framework specific build systems often do exactly what you need them to do with no or very little configuration at all. That is a feeling of not being limited by the tool.
Different tools specific to their job, they wouldn't be good to combine together. apt-get only exists for linux, requires root and is designed for that, npm doesn't. apt-get installs the latest version, npm expects more specific verisons since it's for code. npm is built for node's ecosystem and apt-get is better for system packages.
Welcome to dependency hell! Working for years in different "php environments" I learnt that most (web) developers I met in this field tend to use as much new fancy tools out there without thinking about business value and longterm impact. At the end of the day you might end up with more than four dependency systems...
To respond to your initial question if we really need so much dependency systems: No, we don't need to!
As the author already needs to use composer to set up PHP dependencies why not use composer for the other packages required? It's not a problem to get the common needed libraries via composer which dramatically reduces dependency complexity, deployment and build scripts because you don't need that much tools.
npm advantage (or disadvantage depending on who you asked) is the project owner has direct control over release cycle. The owner can decide when to push an update and it will be available to everyone immediately regardless of their operating system.
Well yeah, why would you do anything else? When recruiters and job postings are mostly concerned with what languages and tools you know over software development ability and computer science knowledge why would you voluntarily make your life more difficult?
Exactly. In big companies there are architectural review boards to stop unstable platform usage. I agree those can go too far and sometimes slow things down. However, i've see too many startups use the platform du jour w/o any consideration to stability. Worse, some will fork a good platform, make slight changes, and market their fork as the next best thing. Since experience does not matter as much to keyword-driven recruiters, is it any surprise this all happens?
Might explain why I don't get many recruiters attempting to contact me. Back when AngularJS was the big thing, I'd get bombarded on LinkedIn. Now, having only non-commercial experience with React and refusing to list it on my resume, I'm mostly ignored.
Now are recruiters to blame or the companies that hire them?
The combination definitely seems overwhelming, but each tool is a solution to a real problem. That's where the "(real)" in the title is coming from. Yes, if you're only writing a hello world app you certainly don't need all that bloat, but if you're writing a real world app, here's a list of legitimate requirements you have to fulfill:
1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion.
2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework.
3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that.
4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework.
5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass.
6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline.
7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP.
8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks.
9. Wow, you need so many javascript and PHP libraries! Let's use a package manager.
10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up.
We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot.
Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices).
Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.
Nah, it's all about http://jsonapi.org these days. GraphQL seems neat. Cap'n Proto also seems neat but I'm unaware of anything actually using it. gRPC is also neat but AFAIK not supported in a browser, so you need some kind of gateway to have it work with browser clients anyway (think SPAs calling APIs which can normally service server to server over gRPC). CPNP has the same-ish problem in that it doesn't fully work in browsers (serialization works but not RPC).
The article is fallacious in that writing "hello world" (and then working your way up to printing the numbers from one to 10, then asking for your name and printing "Hello, $NAME", then checking the time and printing good morning/evening etc) isn't about building a fully-featured modern web application. You could argue that the example is criminally irresponsible because it neither considers the need for HTTPS and 2FA! And finally, you need to compare apples to apples. Setting up a similarly fully featured application in any language takes significant effort, and may well be easier than in PHP, but Hello World is still easier in PHP.
But that loses its usefulness if there's new tools every 6 months. Yes webpack gives me structure today, but there could be a new structure tomorrow. Look at Grunt and Gulp, NPM and yarn....
Not really, you'll still be able to follow what's going on if the project follows an old standard way of doing things, compared to a random or made-up way of doing things.
I had to update a project that used the Gulp-based workflow 2 days ago, and after 5 minutes I knew what I was doing again.
Even if you don't remember you can still look it up, while those who reinvent the wheel seem to never bother documenting their wheel.
Consider that 41% of those surveyed conclude that machines will never be able to "simulate learning and every other aspect of human intelligence". The next 41% conclude it is possible within an unbounded "more than 50 years". It seems to me that the vast majority of experts are pretty skeptical.
No. It's definitely 41%. Look at page 6 of your link
The earliest that machines will be able to simulate learning and every other
aspect of human intelligence:
Within 10 years 6 5%
Between 11 and 25 years 3 2%
Between 26 and 50 years 14 11%
More than 50 years 50 41%
Never 50 41%
Totals 123 100%
Can we just avoid sexual conversations at work? That's a pretty simple rule that negates all the complexities of determining what type of sexual discussion is and isn't sexual harassment. I've sometimes heard the argument that such a notion is puritanical and sterile but honestly I am just not at all interested in sexual banter at the workplace and I feel like nothing of value is lost if I don't have to overhear remarks about sexual escapades, desires, or jokes during the work day.
We can (and I, personally, do) but that isn't a practical standard. Healthy humans are sexual ones and especially when you have younger people working 60+ hours with a close group you will have people talking about sex. That should be expected but the current legal standard doesn't allow for that.
In the appropriate context, of which the workplace is not one. There are other places where individuals make an effort to curtail sexual discussion (church, the dinner table, around small children, within earshot of their parents), so I think it is well within the capabilities of healthy young professionals to generally keep sex out of the workplace.
> when you have younger people working 60+ hours with a close group you will have people talking about sex.
Well perhaps they shouldn't. Of course, sex or topics of a sexual nature might come up, just as say, the color of your last bowel movement might come up, but I'd argue that it shouldn't be a topic of regular discussion and that a culture that aims to defer such discussions to a venue outside of the workplace is a good idea precisely because it is impossible to manage the variable spectrum of comfort in sexual discourse among individuals, especially among a diverse workforce (and not just with regard to gender, but also age, cultural and religious background, as well as sexual experience, history and maturity).
> That should be expected but the current legal standard doesn't allow for that.
The current legal standards certainly allow for it, the bar for sexual harassment in a legal sense is generally pretty clear (proving what actually transpired is sometimes a different story), but what tends to be less clear is company policy regarding the fine line between what is permissible and what is inappropriate. I think the spectrum of what is considered over the line varies so wildly that the only sensible approach is "just don't bring it up".
And i'm positing that if we want diverse workplaces we need to graduate from "just don't bring it up" as the only sensible approach or we'll continue to have professions that aren't diverse. Which is most of them. Which is kinda sad.
Perhaps adding a way for users to tag a story as left or right leaning (or even more descriptive tags like anti-union, pro-life, anti-regulatory etc) might also provide some insight to your classifiers. How an individual classifies a story would only need to be visible to that user, but from a UX perspective it might encourage more honest input into the system that could be used to ground political viewpoints. You might find that a lot of partisans mark themselves as neutral, but most partisans won't be able to resist labeling a story in a manner that fits their partisan perspective.
That's a great idea - so great that it's already on my feature list!
Post tags are something that I'm planning on implementing in the near future, though I'll need to think a little more about the best way to do them. I was planning to use them as a way of identifying topics only (e.g. abortion, immigration, taxes), but I like your idea of tagging particular stances as well.
Well, the tagline on their front page does read "We don't assume you're stupid.".
I'm not calling you stupid, I think everyone has failed to backup something important at one point or another, just saying that the sentiment behind the business seems to be "services provided with minimum hand-holding"
