following: 0
followed tags: 11
followed domains: 1
badges given: 0 of 0
hubskier for: 4377 days
If you haven't seen it yet, the Git man page generator is pretty amusing, and excellently lampoons the man pages.
I'm also seeing this when logged out. When logged in, there's only a single post. (Once I shared this post though, it showed up in my feed, so now there's two.)
Yeah, I find it a bit odd as well, but I agree with his justifications. I suspect that he did it to preempt all of the HN types who want to know why it's not written in the language du jour. As long as you know how to write clean modern C, it's a pretty good choice for these types of things.
I think the appropriate thing is to write the program as a whole cleverly, and to make each portion understandable, either through detailed commenting, or by making the code (and naming!) easily interpretable. Cleverly doesn't necessarily mean inscrutable, as briandmyers pointed out. I believe people mean several different things when they talk about clever code: 1. Written with the best abstractions to avoid duplication of code and make future extension easy 2. Optimized for efficiency 3. Optimized for size 4. Written in an "interesting", complex way When most people hear this quote, I suspect they immediately think of the 4th definition and conclude that code should be written in a straightforward, stupid fashion. In this article, though, I think the author is emphasizing us to concentrate on the first three situations. For example, if you're implementing a file system today, you need to be clever about it. You could go and create something like a straightforward S5FS, but unless you start taking into consideration how the physical disk works and the best ways to place your blocks, you're not going to get good performance. The same goes for many other applications: anything crypto requires cleverness and intelligence; anything related to performance requires a deep understanding of the problem and its contexts. Also, the clever solution isn't always the complex solution. Compare Raft and Paxos, two protocols for distributed consensus: Raft is very straightforward, clever, and easily (compared to Paxos) implementable. Paxos, on the other hand, is a beast unto itself. I think the key issue when this quote comes up is people interpret the word clever as solely meaning accomplishing the same thing as the straightforward solution in a way that requires a lot of thinking. But sometimes this is done because fully solving the problem actually requires some hard thinking. And this is the key part: does your problem actually require much intelligence? Is it of a large enough size that you need to be that concerned about performance? For most people and most problems, I suspect that the answer is no. But this doesn't mean you shouldn't think about it first. After all, sometimes the clever solution is the better solution, when the clever solution makes your life easier.
The best introduction to the lambda calculus that I have read to date is in Benjamin Pierce's Types and Programming Languages (Amazon). The entire book is really good, but the section on the lambda calculus finally helped me really understand it.
Something I've never really considered is what I would have to do if I somehow lost all forms of identification. Anyone familiar with the process of gaining new documents when you currently have none? Presumably if you've been in prison for years, the state knows that it's you.He’d gotten stalled for months, trying to track down a copy of his birth certificate, without which he couldn’t get other forms of ID, access to government aid or his learner’s permit.
Just realized that I think this never posted! Voice chat and e-mailing in Arabic. Maybe also, after some practice, reading books? I live in California, so the weekends might be the easiest time to talk by video. I'll look around and see if I can find us some online resources for learning. I'm sure that there are some good ones out there.
Adding on to this, it is also good to learn more than just your standard programming languages. Having a good, working Unix knowledge goes a long way in making your life easier. Tools/languages that I would recommend getting intimate with are awk, sed, grep, ack, make, and general shell scripting. These tools have helped make my life as a programmer so much better, and saved me countless hours of repetitive tasks. Also, keep in mind that you don't have to learn everything mentioned in this thread all at once. You can spend years learning them. :)
I studied Arabic my freshman year of college. I've forgotten a lot of what I learned, but I've been wanting to revisit the language and continue learning it. If you're interested in studying and learning it together, let me know! The book series we used was very good, so you may want to look into buying the first one or two. Alif Baa concentrates on teaching you the alphabet, and some basic words, and the others (Al-Kitaab Part One/Two) move onto teaching you how to hold conversations and grammar. Something worth considering is that "Arabic" actually refers to multiple dialects, but some of them differ enough from the others that they may as well be considered their own language, much like Spanish and Portuguese. The aforementioned book series concentrates mostly on al-fusha (pronounced like foose-ha), which is the type of Arabic used to write the Quran (see Classical Arabic). In terms of usefulness, this is considered by most a good place to start off, since: - It's the formal language used for things like news, lectures, books, etc. - Most of the Arabic-speaking world knows it (although from what I understand, you might get some odd looks for using it in casual contexts) - It's supposedly a good point for moving on to the other dialects once you know it You may also want to look into getting an Arabic dictionary after you learn the alphabet. The one I used in college was the Hans Wehr Arabic-English dictionary.
Things I like in languages, and miss in others: * First-class functions
* Lambdas (And I should be able to do the same with them as with a regular function, unlike lambdas in Python, which are restricted to one line.)
* Ability to define infix functions, like in Haskell or OCaml (although OCaml has some limits.)
* Pattern matching
* List comprehensions are nice, and could probably be implemented easily in the desugarer
* Things like Scala's `val`/`var` of the `final` keyword in Java are nice. They allow you to introduce a certain amount of purity into a language.
* Not quite a language feature, but if you're going to be generating executables, Tail Call Optimization is nice.
* The Dynamic Proxy pattern is cool. Something like java.lang.reflect.Proxy would be cool. Those are the things that I can think of right now that I often find myself missing in other languages that I can think of right now. That assignment calculus paper looks really interesting. I'll have to take a deeper look at it when I have the time to.