enkiv2

I was expecting this to be about the programming language called Church.

If you don't have ten years of experience with at least five very-distinct languages (i.e., C & C++ only count once, & Java and C# only count once), you're not really a developer yet -- just an apprentice.

Sorry to say, there's no way to cut the gordian knot there: you're going to have to wait until you gain the necessary experience before you're a benefit rather than a liability.

If it's any consolation, most people with entry level / junior software engineer jobs are in the same boat, & there are whole companies that are essentially doomed because of a monoculture of people who haven't yet reached minimum competence. If you're surrounded by peers that know twelve languages & have been working as a dev for twenty years, then you're in a much better place than most of your cohort.

Markdown was intended to be simple enough that everybody could roll their own code to translate to their "real" markup language of choice. Everyone did, but because markdown was a hack in the first place, the quality of implementations is pretty inconsistent. (Which is fine, because rolling your own markdown -> html translator is easy -- much easier than writing your own html -> anything translator -- and well within the reach of even beginner programmers.)

I avoid markdown because I don't like markup in general (and because I think styling of text is rarely useful), but if I need to work with it, I will whip something up to do the translation. A couple lines of sed is sufficient for handling whatever tiny subset of markdown is actually present.

The article makes the case of these technologies being positive for parties other than the end user, even when the result for the end user is a net negative. (I.E., automatic faucets save water by preventing it from running full-blast for hours, which saves money for the building owners, but it does so by annoying end users.)

In almost all cases, it's possible to optimize to make both parties happy; when this doesn't happen, it demonstrates a power asymmetry: the people who use these mechanisms (usually installed by an institution: public bathrooms, office coffee machines) matter less than the owners.

Any marketers currently working to manipulate public opinion on HN through the use of sockpuppet accounts, upvote this comment.

The copy is very unclear. If you can, get a native english speaker to edit it for you. (It's early here, but after skimming it twice I still have no idea what your program does.)

Looking like a good person and being a good person aren't the same thing. They often conflict.

Business is at best amoral & often actively immoral. For those of us with a conscience, we must sacrifice profit in the name of not being horrible people, or allow capitalism to turn us into horrible people.

It's not an easy decision.

Uber doesn't particularly need to be attacked. Their business model is basically to violate employment law; as a result, their days are numbered.

In BSD-style licenses, if you make changes you can distribute them with a new license. In GPL-style licenses, the source for any modifications must be distributed along with any modified binaries. In AGPL-style licenses, the source for any modifications must be available to users, even if no binaries are ever distributed. So, in some cases, I'm sure not contributing upstream is actually illegal.

I can understand why lots of companies would use open source software but not contribute changes: if you already have your employees sign away their IP to the company, then there are legal complications to figuring out how to contribute, and if the company is publicly traded then internal modifications to open source software in order to support features that have not yet been announced may constitute an information leak if contributed upstream (and thus give illegal trading advantage to maintainers, etc). It's a big can of worms.

The answer to this question depends upon what specific issues you have talking to people. If you merely have unfounded anxiety, confidence-increasing tactics like joining toastmasters will help (although that will give you experience in public speaking, which is very different from private speaking). If your fear of talking to people stems from poor social skills, I recommend reading the first half of the book Games People Play, because it explains in pretty concrete and procedural terms a model of communication that addresses some common mistakes people with poor social skills make (particularly, talking significantly more or significantly less than justified by the situation). (I don't really recommend the second half of the book, because those ideas are less useful for the purpose of keeping good relationships & have also spread much more widely.)

Prototype-based object orientation, while it's conceptually simpler & cleaner, violates a lot of the design assumptions taught (and mandated to be taught) by computer science programs. People who learned computer science in high school or college in the United States from mid-tier programs were learning material mandated by a couple accreditation agencies focused on the AP curriculum; this material was originally constructed for C++ and was adjusted to be about Java in the late nineties, and it focuses on object orientation in terms of encapsulation and inheritance.

Someone who is self-taught or who learned to code via a different curriculum (say, one based around scheme like MIT's, or one based around javascript) naturally will think of object orientation in terms of something that a programmer implements, and will see prototype-based OO as easier to implement and easier to predict, since inheritance (particularly multiple inheritance) can quickly get complicated. But, this mandated curruculum based around strongly-typed compiled languages with class-based OO and a nearly ideological focus on the (mostly imaginary) benefits of inheritance has mass-produced students who are primed to think of class-based OO as the natural state of things rather than as a tool that is only sometimes appropriate.

In any prototype language, adding classes is trivial (it's just a matter of treating some objects as inviolate), and adding inheritance and even simple forms of multiple inheritance (if you have access to metatables / can override member lookup routines) isn't terribly difficult. The opposite is generally not true. But, again, this focus on class-based OO is largely not based on strategic thinking, but instead upon mechanisms designed to make sure large numbers of entry-level programmers are part of a specific monoculture. (This has succeeded: consider the proliferation of Java -- a language that is only very rarely an appropriate tool for any job.)

Lua is better than JavaScript, sure, but this article doesn't make a convincing argument for that proposition. In fact, I might argue that it has a negative effect on any such arguments that may be posted, by virtue of association.

Airbnb hasn't been around for all that long. Why didn't they write their library with python3 support in the first place?

Yes, there are some python2 features that work differently in python3. But python3 has existed for a decade now, and there aren't real benefits to using forward-incompatible methods. Writing code that won't work in both is a mistake.

App stores are kind of nonsense, and I don't see how they are relevant. People install all sorts of software. Windows users have to go find a proper web browser and install it in order to use "modern" sites. Rather than having giant bloated web browsers that need to be found and installed by end users, why not have web browsers that just do web browsing and are a couple hundred kilobytes in size, and then let people decide whether or not they want to bother installing the rest of the nonsense?

A properly written python2 module will already be python3 compatible, in most cases. Occasionally, modules that violate existing best practices will do so in ways that limit python3 compatibility. They can be fixed with automated tools that ship with python.

Package systems like pip have separate repositories for python2 and python3, and you can have both python2 and python3 installed along with pip3 and pip2, and a whole package set for each; a package that is not compatible with python3 won't be available from pip3. But, most packages were already compatible, and those that weren't have had many years to become compatible.

Any python package that currently doesn't support python3 is either no longer being maintained or is acting as a political statement.

It's a slight overstatement for rhetorical purposes. Supporting python3 is not a difficult problem even for large libraries with single maintainers; as I noted, automatic translation tools exist.

This article lays out an argument that's clearly intended to be a strawman, but that I find completely reasonable. (Some elements are clearly exaggerated: there's a difference between a website "not working in Sudan" and a website not working on five year old hardware, and modern maximalist websites often don't work properly on the kind of slightly out-of-date hardware that most real users have.)

There's another take on this: that, while the web is being used to implement desktop-application-like behaviors and distribute drm-protected content, web technologies are incredibly ill-suited to performing pretty much every task outside of the display of small static pages, and that every attempt to force the web to perform this kind of trick is the admittedly impressive result of a pile of ugly hacks that waste enormous amounts of resources -- whereas performing these tasks using technologies actually suited to them would be simpler for everyone involved and make this content accessible to people using less powerful hardware or with lower-bandwidth connections. I don't think anyone who has worked both with web technologies & with building native applications can seriously disagree with the idea that using web technologies to perform native application tasks requires a pile of ugly hacks, and I don't think anyone who has used older hardware to access newer sites can seriously deny that this kind of over-reach produces systems that are unusable without expensive new equipment. (We can also make the argument that, because advertising is neither the only revenue model for web-driven content nor the best by any measure, there's little sense in trying to support the huge and mostly crooked ad ecosystem when we can easily avoid it entirely.)

It used to be that people didn't associate the internet solely with the web, and that if people needed to use ssh, they'd use ssh; if they needed to use ftp or gopher, they'd use ftp or gopher. The web later became a catch-all protocol, and people started developing big complicated wrappers to make existing software work via a web browser while simultaneously various organizations started setting up their internal firewalls to whitelist only port 80. This is a mistake: the web was never designed to replace all of computing, and will never be able to do so in an acceptable manner. We should be taking the huge variety of the software ecosystem back, instead of trying to force everything into web tech and ignoring everything that doesn't fit.

Lots of library maintainers can't be arsed to put parentheses around their print statements (and perform the occasional slight change to other behaviors), or to run any of the automated tools that perform these compatibility-preserving changes. As a result, libraries maintained by these stubborn lazy people are not usable on python3, which makes beginners (who don't have a clear understanding of how these libraries are written and how easy it would be for them to perform the conversions themselves, because they still believe that "professionals" have some magic power other than the willingness to be persistent) wary of doing anything in python3.

It's very straightforward to write code that works in python 2 and python 3, and anyone learning python for the first time should be learning to write in that way. Ultimately, many of the compatibility changes are making things that have long been possible but considered poor style / bad habits no longer possible when doing so made the language easier to understand and behaviors more predictable (think print statement vs print function), or streamlining things that were originally bolted-on (think unicode).

Direct neural interfaces have been on the market since the late 80s. Can't journalists fucking google before submitting stories like these?

Do you also want recruiter spam? I get tons of that.

The best way to encourage innovation is to "stifle" it by producing unusual and complex situations that require creativity to circumvent. Regulation, because it is at least theoretically a codification of the desires of a large population, forces whatever innovation happens into a set of forms that are expected to be in line with the good of the people, while simultaneously making anything achieved more innovative in proportion with how much more intellectual and creative effort was required to achieve it.

Having a ticket system like this and forcing reviews through the chokepoint of busiest person in the company is pretty stupid, and it's probably putting a lot of pressure on the CTO. If the CTO is under pressure, he will probably be more critical of things than he otherwise would be (even though it makes more work for him).

It's not abnormal to be better at working on tasks with a bit of leeway than on very specific tickets. That said, if you frequently solve problems in a way different from the CTO's preference, moreso than your coworkers, then it's possible that there are some patterns that the CTO prefers that your coworkers have picked up and started using; you might get less hassle if you're doing things in that way, even when that way is objectively worse, because it puts less cognitive load on the CTO.

That said, it's very possible that the company has just gotten into a bad state and everybody's being nasty and over-critical about everybody else. Structuring commits in such a strange and broken way is indicative of other problems, since nobody would make the CTO approve every commit outside of a real emergency situation with tons of broken code being pushed into the critical path. It may just be that the company is going in a downward spiral and you're an arbitrary target for blame for everybody who's feeling the pressure.

Not much would happen. Big chunks of what constitutes OS X is already open source. Nobody runs GNU/Darwin the same way nobody runs Plan 9.

Apple's market is primarily geared towards people who aren't interested in the tech and are paying for the logo. After all, anybody who wants an OS X equivalent system who knows what they're doing can buy a bog-standard PC and run some free unix on it with GNUStep. So, the licensing for Apple products doesn't matter because Apple's market excludes anybody who cares too much about licensing (or anything other than branding).

If you're going to code while walking on a treadmill desk, I'd recommend using a hand-held one-handed chording keyboard/mouse combo like the Twiddler or the Chordite, so that you don't accidentally jog the keyboard/mouse while walking.

It might take some time to get used to walking while typing, but it definitely can be done. It's probably worthwhile in terms of long-term increases in productivity.

Hashtable lookups are O(1). What are you complaining about? If they did this in plain C they'd probably end up using binary search trees and then everything would be slower.

I definitely feel like the author was trying to write a very different article.

An article about the way that Meier's western-centric view of history caused the system he implemented to have interesting systematic biases that limit the set of behaviors that can be simulated in interesting and unexpected ways, Zizek-style, would have been interesting. But this isn't that article; mentioning the lack of dark ages and the enlightenment grand-narrative view of progress as a game mechanic doesn't deliver, since it's crit 101 stuff that anybody would immediately notice.

The author should have probably recognized that the article wasn't the one she intended to write, & eliminated the points that didn't add to its organic form, rather than trying to force it into the intended form. But, its flaws don't detract enough to justify not posting it or reading it.

Freeciv seems pretty easy to patch. So, if you wanted to "disrupt" Civ, you wouldn't necessarily need to write much code.

Whether or not the complaint is legitimate is irrelevant.

If you're going to complain about somebody, you should expect people to complain right back about you. When they do so, writing a post whining about it ends up looking childish -- it's hardly "stalking" or "thought policing". People complain about each other's writing style on the internet all the time. Being butthurt about getting an email isn't so rare and precious that you should write a thinkpiece about it and post it to HN.

This guy should grow a thicker skin. If you act like a jerk online, someone will complain about it, even if you don't recognize their right to do so.

Also, "stolen intellectual property"? They should steal his pixie dust and unicorns too.