31–40 of 123 posts
This type of article is like politically targeting citizens, their purpose is not to unite but divide... Hack, I started as a FE intern in Amazon, originated Amazon Kinesis, built tools for managing google's data center network software, Borg core and user library, and now other stuff. My work as a programmer constantly change. Am I in any tribe then?...
I would say you're not a poet though.
OK, here's a problem. Read a file of text (the name is to be passed in as a command-line parameter). For each line, if it begins with a number, print out the number.
I'd use Perl, and it would take me one or, at most, two minutes. It would take me seven lines, only because I put my curly braces on their own lines.
Now, I picked a problem that is a better fit for Perl than for Haskell. But that's kind of the point - there are problems that are a better fit for other languages than for Haskell, and when you hit one, you're better off writing the program in a language that fits better.
* Source Code: Your code is clean enough for you. Your top priority is thorough documentation and intuitive API design.
* Execution: Critical around bottle necks, like large batch processing and build times, otherwise it doesn't matter. Iterate and optimize based on feedback from your devs.
* Correctness: The program should function exactly how it's described to function in documentation. If something unexpected happens, the error is clearly and concisely exposed to the developer so that they can understand what they did wrong.
* UI: Usually not a thing, but when it is, your users are developers and they should be able to figure it out ...
Personally, I'm a gamedev, super in Camp 3. I've worked with a lot of folks who could care less about product and polish, but love making their colleagues lives easier. It's pretty similar to Camp 3 in the sense of "making for your users", but the skillset and priorities are very different.
Favorite languages: TypeScript
Hangouts: npm, github, anywhere open source code is distributed
> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right? OK, here'…
mapM_ putStrLn $ filter startsWithNum $ lines $ readFile (args !! 0)
where startsWithNum = ...
> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right? OK, here'…
> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right? OK, here'…
Actually, that problem sounds fairly well-suited to Haskell, because it's essentially a series of pure transformations. My Haskell is quite rusty, but I imagine the program would look something like: mapM_ putStrLn $ filter startsWithNum $ lines $ readFile (args !! 0) where startsWithNum = ... Still, I agree with your point -- no language can be optimal for every problem.
To use an example from the article, I think Jonathan Blow would absolutely argue that he wrote his own game engine because it was best for his user. Whether you agree with him or not, he is whole-heartedly convinced by his assertion that it could not be done in Unity trivially. Having listened to him a fair deal, and his feelings on games (vs. programming of games), I very much believe that he cares a tremendous amount about the experience of the game above quite possibly all else. So, while you can certainly argue that the way he chooses to implement that goal is misguided (I don't believe this, but an argument exists), I don't think its fair to give "The UI is more important than anything else" to the third camp and not his. I think he agrees with this statement, and feels that what gets you the best UI in a game happens to be low level work (to avoid frustrating lag, etc.).
Similarly, I think Bret Victor might take issue with this as well. Much of his work is centered on creating innovative UIs to help people think, and often against the (current) abstract ways of representing knowledge. In particular, from the maker perspective, he cares deeply about empowering people to make things -- less so I would say than some sort of mathematical purity.
All this to say, I think there may be less difference in goals than we think, and more difference in what we believe influences those shared goals.
I think this is a good article, but ironically I think all three tribes would actually describe themselves the same way many times (whereas this article implies they'd describe themselves, or what matters to them, differently). To use an example from the article, I think Jonathan Blow would absolutely argue that he wrote his own game engine because it was best for his user . Whether you agree with him or not, he is w…
This is fantastic and surprisingly close to how I tended to explain computer science to students and graduates: In Computer Science, there are 3 kinds of problems: 1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutio…