677 karma · joined March 29, 2013
It knew to put The Holy Mountain at 100% based off me loving the new Mad Max, feeling ambivalent about the Star Wars prequels, hating the 2007 Tranformers movie, and thinking Anchor Man was good but not great. Like, how the hell? It's spot on, but how did it get that from my input? Is there more info on how this thing is getting its results? I would love to see even a sketchy outline of the algorithm.
With that out of the way... I'm firmly in the "but" camp here. I've been doing web programming for 17 years now. I remember the bad old days. Things were simple if all you wanted was HTML and images (CSS was still pretty iffy). But the moment you needed more than a static page? The complexity of getting up and running ballooned really quickly. And worst of all there were so few resources to really learn from. And it was expensive. Granted I was a teenager back then so anything more than a few dollars a month was pricey to me, but if you compare the kinds of hosting offerings of two decades ago to something like Digital Ocean or AWS today then the amount of possibilities is staggering (no more shared environment!) and for prices that are almost too cheap to believe.
My recollection of getting anything up and running that used a database back then was that it was not for the faint of heart. Compare that to today and the process of getting everything set up and connected with Rails, Djano, Express, etc. Yes there's more stuff you "just have to know" in terms of code you write and yes you have a box you have to stay within because of the framework but I'll take that any day over gluing together some Perl scripts and hoping you've got CGI configured correctly.
Maybe I'm conflating two separate things here: actual programming and operations. But I strongly contend that with web programming you can't disentangle those two things in any practical way. You will always be bound to the context of your environment. Anything that makes getting a sane environment easier leaves much more time to focus on the problem you actually care about. And it's not like you have to use all of the shiny new toys if you want to keep your code simple.
The tl;dr:
> And all this wouldn’t really matter if not for the fact that The Big Bang Theory targets nerds as part of its fan base. We’re used to being ridiculed on TV but it’s usually by shows which aren’t aimed at us. The Big Bang Theory goes to Comic-Con, it sells its merchandise at Forbidden Planet. The fact that it sells merchandise at all says that wants part of a cult nerd following. The Big Bang Theory is the worst kind of bully – the one that pretends to be your friend and then takes the piss out of you behind your back. It will take your viewership, it will take your money and it will laugh in your face as it systematically puts you down.
[0]: http://butmyopinionisright.tumblr.com/post/31079561065/the-p...
C was my first programming language and several years ago I became acquainted with ALGOL 68. I'd never seen BCPL before a few months ago. It's rather interesting how, from the perspective of someone born well after its creation, it is very clearly the link between the ALGOL family and C. I'm sure that's rather obvious to programmers who were around in the mid to late 60's but for me personally it was a lot like discovering a missing link.
[0]: http://www.cl.cam.ac.uk/~mr10/BCPL.html
[1]: https://gist.github.com/seaneshbaugh/e09abd748ccc07c5463f253...
A few years ago I started a simple RPG game engine that uses Lua[0] as its scripting language. I never got very far with it but considering I had zero clue how to even begin approaching the problem when I started I'm pretty happy with how far I got before I lost interest.
* Pattern matching: http://elixir-lang.org/getting-started/pattern-matching.html
* Guard clauses in function definitions: http://elixir-lang.org/getting-started/case-cond-and-if.html...
* Macros: http://elixir-lang.org/getting-started/case-cond-and-if.html...
* The |> operator: http://elixir-lang.org/getting-started/enumerables-and-strea...
For me those really are the killer features for Elixir. I know most people will point to Elixir's support for concurrency and the whole GenServer thing that it gets from Erlang when discussing why Elixir is interesting. And those aspects of the language/ecosystem really are awesome. But being able to nearly eliminate explicit conditionals with guard clauses is just so damn cool I can barely stand it. And the |> operator is something I desperately wish Ruby had. I like Elixir a lot because it seems to put a huge emphasis on making my job as a programmer suck less without sacrificing other things in the process.
My last job, however, I gave my employer three weeks notice. I cried when I had to tell my boss I had taken a job elsewhere. It wasn't the hardest thing I've ever done, but quitting that job definitely cracks the top five most emotional moments of my life. I'm happy where I am now, but I was happy there too, surrounded by good people and working under a manager I not only respected but admired as a person. I am keenly aware of how rare a thing that is. The only reason I left was because of the company policy that allows people to leave and then come back no questions asked if they left on good standing. I needed to take a personal risk and they actually encourage that.
The point of my anecdotes is: you reap what you sow. Treat people like shit, pay them poorly, humiliate them publicly and they will quit the moment they can with spite instead of hesitation. Show people kindness, pay them what they're worth, and give them chances to learn from their mistakes and you will routinely have people work for you for decades. If more people are quitting without notice then employers need only to look at how they treat people to see why.
I often see lamentations about people not being friendly to strangers in big cities. I've never quite understood it. It's one thing to not greet or acknowledge a person if you're already having some sort of interaction with them, i.e. holding the door for someone as you leave a store. Of course you should say something or at least smile and node politely, perhaps making brief eye contact, in that case. But, outside of situations similar in nature to that I actually think it's pretty rude to accost strangers in a crowded public place. People are going about their business and you're attempting to force them to give you attention, even if that's not your intent.
Experience has taught me that above a certain threshold of crowdedness the only people who are greeting me want something from me in at least one of the ways you mentioned. Everyone else is out and about because they have something to do. When I go to the middle of nowhere Kansas from time to time things are different. There you wave to passing cars and say "hi" to everyone even if you've never seen them before. The odds that some random person is going to try and sell you a watch at the intersection of Main St. and State Highway Whatever is pretty much zero. And, there aren't a hundred other things attempting to distract people so demanding a brief bit of their attention isn't rude at all.
Whenever I attempt to learn a new language I find that static analysis tools and linters, if available, help me get over any initial confusion about what constitutes good idiomatic code. Guides like OP help too, but nothing beats a good linter. The thing is though, I've been writing Bash shell scripts for going on 15 years now, and I still overlook little details [0] all the time.
I've been mulling in the back of my head for a while a theory about the need for style guides and linters: if a language makes them a near necessity for reasons other than aesthetics then the language is probably best avoided. I'm not sure if agree totally with that. However, I think the most frustrating experiences I've had while programming are the result of languages which allow for multiple ways, in terms of syntax, of doing the same thing which behave the same most of the time.
Frankly, the people in the agency world making the kinds of decisions about which ad network to use are not the most tech savvy people. They're typically two or three layers removed from anyone who actually understands the difference between HTTP and HTTPS. Until that changes (hint: not for another 20-30 years when the current crop of middle aged account executives is retired or dead) then ad networks won't receive any major pushback from the people who are their largest most reliable customers.
Even if every person in the agency world understood the harm of poorly made ad units tomorrow it would still take ages for any changes to occur because of existing relationships and contracts.
In my free time over the last several years I've been working on a chrestomathy that collections solutions to Project Euler problems in various different languages [0]. I'm currently up to 39. It's certainly far from "every" language and in most languages I've only written solutions to the first handful of problems. I've learned it's hard to not learn a lot about a language if you do the first 7 or so problems in it.
My advice to anyone who has any desire to use iTunes is: acquire your music from elsewhere as actual mp3 files, tag them using something like Mp3tag[0] and then drag and drop them into iTunes. Make sure you check the "Keep iTunes Media folder organized" and "Copy files to iTunes Media folder when adding to library" options in the advanced settings. The only control you're really giving up then is the exact naming scheme of the files in the folder. But "<library directory>/Artist Name/Album Name/01 Song Title.mp3" is a pretty sane convention in my opinion. I have close to 18,000 albums in my iTunes library that I've added this way over the last decade and a half. It works pretty well and I have no problem reasoning about what music I have.
I totally agree with his complaints about Apple Music though, it's pretty inscrutable. But I wrote my own music streaming server with Sinatra and iOS app to go with it so I always have access to whatever is stored on my hard drive at home in a way that makes sense to me. If I'm not at home that's what I'd rather do, no syncing or anything weird.
"The universe is a dark forest. Every civilization is an armed hunter stalking through the trees like a ghost, gently pushing aside branches that block the path and trying to tread without sound. Even breathing is done with care. The hunter has to be careful, because everywhere in the forest are stealthy hunters like him. If he finds other life—another hunter, an angel or a demon, a delicate infant or a tottering old man, a fairy or a demigod—there’s only one thing he can do: open fire and eliminate them. In this forest, hell is other people. An eternal threat that any life that exposes its own existence will be swiftly wiped out. This is the picture of cosmic civilization. It’s the explanation for the Fermi Paradox."
Obviously there's no right or wrong way to use Twitter, but I generally don't follow people who do more than post inane status updates like "i love tacos lol" or links to mildly interesting news articles. For me at least, that's all I want Twitter to be, and it does that admirably. If I want discourse theres room for that pretty much anywhere else on the Internet.
I suspect the majority of the problems people have with Twitter stem from expecting it to be something that it just fundamentally isn't and can't be. If you use Twitter with a desire for serious engagement with others you're almost always going to be disappointed. If you treat it as a place to put silly 140 character messages out into the world whenever you feel like it then it's much more fun. And weirdly, much more useful.
int foo(int a, int b) {
int c = a + b;
int d = a * b;
return c + d;
}
int main() {
return foo(4, 5);
}
clang -O0 -S -f-no-asynchronous-unwind-tables foo.c
Start off with very very simple programs and examine their output. Change the source slightly and observe how the assembly changes. And as usual when learning new stuff, google everything that doesn't make sense. If you come across an instruction you've never seen before then google it, odds are just knowing what it does will make its purpose obvious for simple enough programs. Starting with simple stuff really is the key. Eventually you can even try writing your own version in assembly first and then compare it to what the compiler gives you for an equivalent C program. Sometimes the results will be very surprising and you'll learn something interesting.
One thing I will say you should read up on first is the System V ABI (http://wiki.osdev.org/System_V_ABI). Assuming you're on Linux or OSX. It's the function calling convention used by modern systems. You don't have to use it yourself necessarily, but when you examine compiler generated assembly or if you want to know how to call libc functions understanding it is crucial.
I'm by no means an expert on assembly, but this is what I did and I'm at a place now where I'm comfortable looking at most pieces of assembly code and following along. Writing it is still hard, but mostly because it takes so damn long and higher level languages have spoiled me.
I would argue that that would in fact be the source code for the program!
I know that sounds flippant, but - civil engineers and architects will correct me I'm sure - a blueprint to me is a set of pretty clear and hopefully unambiguous instructions, just not necessarily in a chronologically ordered list format. To torture the metaphor even further: the act of building the building from the blueprints is the same as running the program.
The key difference is that in the case of building a computer program the hard part is writing the instructions and in the case of building a building the hard part is execution of the instructions. Building designers have the advantage of centuries (millennia, even) of knowledge and some pretty hard limitations set by physics. Money and time aside, computer program designers are more or less limited by hardware and imagination.
I really do hope someday programmers will look back at conversations like this and think not that their counterparts of the past just needed to deal with it and be more professional but that we just didn't know any better way, yet.
This is more or less what I've been using it for at work. My general "rule" is that if I've got a form and any other field or set of fields depends on what's happening in another field or set of fields I try wrap both parts up into a React component (with as many subcomponents as necessary). I'm using react-rails[1] and creating custom form builder modules which I include in my main form builder class. The custom form builder methods just call react_component and pass in the form object as a property to the component so I get server-side rendering of the component and the same code gets reused client-side. Obviously it can be used for much more than dynamic forms, but for what I'm currently doing this is all I need.
> React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code.
I've found that > 90% of my front-end bugs around forms involve fields that are somehow linked. Handling that with unstructured jQuery goes from easy to a horrible mess at a nearly exponential rate as the number of interacting parts increases linearly. React makes it really easy to keep track of state and have it flow downwards as properties to subcomponents. Obviously you can go way overboard with it and I wouldn't recommend it for everything, but the ability to use it in just one troublesome spot and nowhere else if that's all you need is really cool. It's the opposite of all-or-nothing. I have a very large application that uses it in about a dozen tricky places like dynamic lists of things. The rest of the application is just plain old server-side rendered HTML.
This article in particular has made me realize just how long it's been since I listened to Ten Yard Fight.
STARTLOOP
KEYPRESS F1 // client macro key for hiding skill
WAIT 1000
MOVERANDOM 4 // move 4 times in a random direction to get around server checks for using a skill in the same spot
WAIT 8000
ENDLOOP
It's really hard to have a discussion about UO without the urge to talk about how important it was to me (I've noticed I'm not the only one).
So rather than resist that urge... Ultima Online is directly responsible for me being a programmer. I was 13 when I got a copy of the game and an account thanks to my parents. It wasn't the first game I'd played where I'd wondered how it had been made but it was the first game I'd played where I couldn't even conceive of how it could possibly work. It was so different from anything else that I'd played before, including the first 8 Ultima games. Trying to figure that out led me towards programming in general and to SphereServer, the UO server emulator. The scripting system for SphereServer allowed me to change the game (for me and my friends only, but still) and really explore what's possible. By the time I was 16 I knew what I was doing for the rest of my life, even if it wasn't necessarily anything related to games.
For example take Shrewd Hatchling[2] and Coral Reef[3]. Both are fairly different cards, but notice the wording of the first part of their respective card text:
> Shrewd Hatchling enters the battlefield with four -1/-1 counters on it.
and
> Coral Reef enters the battlefield with four polyp counters on it.
Cards with that sort of ability are (almost) always going to have it phrased in a way that fits the pattern of "<card name> enters the battlefield with <n> <type> counters on it."
Lots of other sorts of common mechanics are the same. Additionally, there are the so called "Golden Rules"[4] which are important to take note of when parsing the text of a card.
While Googling for links for this reply I found Gleemin[5], a "rules engine that aims to fully and correctly implement the game's tournament rules, an AI player programmable with expert knowledge and an interpreter for the game's language (the rules text on the cards)"! Seems you're not the first person to think about this!
[1]: http://archive.wizards.com/Magic/Magazine/Article.aspx?x=mtg...
[2]: http://gatherer.wizards.com/Pages/Card/Details.aspx?multiver...
[3]: http://gatherer.wizards.com/Pages/Card/Details.aspx?multiver...
It's exactly like you said, "a strange mix between violence and friendliness". I'm usually friends with nearly every single person in the room but much of what happens would constitute assault in any other context. People still pick each other up when they fall, even that person just punched them in the back of the head. I suspect you'd find very little has actually changed.
On a semi-tangential note: It's always so amusing trying to explain this sort of thing to someone who has never been a part of punk. Another commenter in this thread said that it's self regulating. And that's what so many people don't get. There are rules. Unspoken ones, but they are there. Everyone in the room knows when something is actually out of hand. It may look like total mayhem at times to the untrained eye but if you've been around long enough you see the same sort of organic patterns of behavior at every show. Sometimes I'm inclined to think you've never really connected with others until you've been to a punk show with a hundred other like minded people crammed into a tiny dim smelly space with terrible music playing as loud as the speakers will allow, all the while loving every moment.