Wait, SlashDot is still around?
"My current theory is that programming is quite literally writing."
151–160 of 199 posts
Re: "My current theory is that programming is quite literally writing."
#152Earlier quoted context omitted.
> programming is a great way to have the zest for life sucked straight out of you Sounds like you're in the wrong field. Just because you find the thing a drudge doesn't mean others feel the same way, and personally I find the cynical 'well real-world programming is ultimately crap' specious and poisonous - to you it is, to me it is not. Why are you still doing it? And why are you stating it like it's some immutable…
Point taken. I wish I were you!
I don't mean to be overly harsh - I understand how it can be tough + draining sometimes.
I'm also not acting under any illusions here - there are times when it's miserable, the key is whether the overall thing itself outweighs those moments.
Also be cautious as to whether burn out is involved... that shit is pernicious.
:-)
Re: "My current theory is that programming is quite literally writing."
#153Earlier quoted context omitted.
I think you can check off everything on this list and still write inscrutable code. The worst code I've seen is code that was written so that only one person understands what's happening -- the author. Typically the code has too many branches and ridiculous call stacks. The writing analog is a run-on sentence. This usually happens when the programmer at fault is really smart but still hasn't learned that at some poin…
What you think code reviewing is for?
Code review might serve the same purpose (depending on how you do it) but I've had a hard time getting organizations to "buy in" to code reviews for various reasons (fear, pride, cost, etc.).
On the other hand having the Architect act as editor after the code is written not only provides the "code review" function, but it provides the additional benefit of providing the Architect with feedback on the original design, and how the abstract design ideas are translated during the construction phase.
I think it would improve communication on both sides (Architect and programmer) as well as overall quality...very nice...
Re: "My current theory is that programming is quite literally writing."
#154Earlier quoted context omitted.
I think you can check off everything on this list and still write inscrutable code. The worst code I've seen is code that was written so that only one person understands what's happening -- the author. Typically the code has too many branches and ridiculous call stacks. The writing analog is a run-on sentence. This usually happens when the programmer at fault is really smart but still hasn't learned that at some poin…
What you think code reviewing is for?
[deleted]
Re: "My current theory is that programming is quite literally writing."
#155Earlier quoted context omitted.
The value of Stanford, MIT, CMU, etc. isn't that the professors are so good at teaching; it's that they are smart student aggregators. Nothing motivates you like not being the smart one anymore.
That might be true of some people. For someone coming from a small town where everyone told him that he would go on to do amazing, wonderful things, it can be very depressing for him to learn that he is nothing special.
That's more of a feature than a bug.
The opposite can be true too, I expected to get tanked at CMU and did pretty well (3.65 gpa, senior thesis, going to Facebook). If I'd gone to Ohio State like the majority of my peers from High School (Hilliard Darby High School has sent a whopping two people to top tier engineering schools (CMU and MIT) and none to Harvard) and even gotten a 4.0, I never would have believed I was more than a "talented state school kid."
At the end of the day, it's on you to put yourself in the most challenging situation you can possibly survive so that you can learn the most. Sheltering one's fragile ego never did much for anyone in the long run.
Re: "My current theory is that programming is quite literally writing."
#156"We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation."
^ bingo.
Re: "My current theory is that programming is quite literally writing."
#157Earlier quoted context omitted.
The problem is that the language becomes virtually unknowable. Perl has a ridiculous amount of syntax. I am sure that I could find half a dozen lines of Perl code that the average Perl developer would not understand because everyone only knows part of the language.
Who is the average Perl developer? I'm a student. I should probably know less about Perl than a junior Perl programmer - and I know almost all the keywords. Is simple.wikipedia.org really better than wikipedia.org for the average English speaker? If your only argument is that simpler language lets more people understand, why bother saying words like "unknowable"? Why not say "not knowable"? Isn't it superfluous to ha…
Do you know all of the operators as well? All of the special variables? A significant portion of the regex syntax? The four different ways to call subroutines and the effects that each method has? The list goes on and on and on.
I work with about a dozen Perl developers and there are only a couple of us that know a significant portion of the language. Problems occur when someone uses a less common piece of syntax and no one else knows what it does. Everyone has their favorite ways to do things and people tend to have very strong preferences. This makes for code that is much more difficult to understand.
English is a far more complex topic. I am not sure where to even begin. I do think that it helps for a group of people to share a common set of language prescriptions.
Re: "My current theory is that programming is quite literally writing."
#158Earlier quoted context omitted.
Unfortunately, this metaphor breaks at the onset. Programs aren't primarily written to be read by people. They're primarily meant to enable functionality. Readability of code is important, but not the ultimate ends -- it is part of the means. But the important part of my post was that programming is about automation. It's not about weaving a story, even for the next programmer. It's about building abstractions for au…
The author argues that good code should be written for people. The metaphor doesn't break just because you disagree with the author's point. IMHO, any dolt can produce code that only works. All too often I have to sift through horrible code that works, and I think the author is right in that if the programmer who wrote that (sometimes that's me, sometimes it's someone else) had had the next programmer in mind when he…
The author argues that good code should be written for people.
If good code were written only for people there'd be no quicksort. No fast implementations of FFT. Probably no fast versions of memcpy. The reason is that coding is not primarily about writing for other people. Look at Donald Knuth's code. Extremely well-written, yet certainly doesn't stand on its own. And there are certainly design decisions that optimize for both asymptotic complexity and small constant factors.
My point is that analogizing this to books does no one any favors at all. We're having a conversation on the merits, w/o having to allude to neither haikus nor novels, nor gerands, nor foreshadowing.
Programming is difficult, even for code that "only works" (you'd be a billionaire if you could find a way to quickly produce code that "only works"). It has little more in common with writing than tarot cards -- which also are made to be read by humans.
Re: "My current theory is that programming is quite literally writing."
#159>We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
Does anyone have suggestions of some good code to read?
Re: "My current theory is that programming is quite literally writing."
#160Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. Let's get a little more specific... Most code sucks because the programmer: - didn't name his variables what the really were - didn't understand variable state - didn't understand variable scope - didn't understand the basic concepts of iteration - didn't understand any of the algorithms he needed - wrote the same lines of…
I think you can check off everything on this list and still write inscrutable code. The worst code I've seen is code that was written so that only one person understands what's happening -- the author. Typically the code has too many branches and ridiculous call stacks. The writing analog is a run-on sentence. This usually happens when the programmer at fault is really smart but still hasn't learned that at some poin…
I've taken the editor role in a couple of recent contract jobs. While the clients were both complimentary, I think I didn't do too well for one of them, where I came in to an existing codebase with a shortage of domain knowledge -- and this is going to be a general problem for a specialist editor, more so than with prose. I was more like a copyeditor. (For the other client I'd written the code they started with.)