Everybody's free()
May. 16th, 2006 02:06 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
maradydd(to use smartpointers)
Ladies and gentlemen of the Computer Science department Class of 2006 ... use smartpointers.
If I could offer you only one tip for the future, smartpointers would be it.
The long-term benefits of smartpointers have been demonstrated by the Boost developers, whereas the rest of my advice has no basis more reliable than my own meagre hackery.
I will dispense this advice now.
Enjoy the power and beauty of functional programming. Never mind. You will not understand the power and beauty of the functional idiom until you have forgotten what anything else looks like. But trust me, in 20 years you'll look back at procedural and object-oriented code and recall in a way you can't grasp now how weird functional programming was at the time, and how much easier everything else would have been if you'd just broken down and learned it.
Your code is more bloated than you imagine. But it gets better with time and practice.
Don’t worry about optimization; or worry, but know that premature optimization is the root of all evil. The real troubles in your code are apt to be things that you never predicted would bottleneck; the kind that show up in gdb and make you say, "Why are there 10,000 calls to std::less?"
Learn one new technique every day. And actually use it.
Sing. But be prepared for people to look at you funny if you're wearing headphones and they can't hear the background music.
Don’t be reckless with other people’s code repositories, and don’t put up with people who are reckless with yours. A commit bit is a privilege, not a right.
Floss. Your co-workers will thank you for it. And don't forget the deodorant, either.
Don’t waste your time on flamewars; sometimes you’re right, sometimes you're not, sometimes there's no way to tell. Prove it with code -- or math -- if you can, and if not, forget about it; in the end, it's the software you write that matters, not the mailing list posts. (Except as warnings to later generations. The time you save may be that of the next poor bastard who googles the topic.)
Archive the compliments you receive, delete the insults; you will probably remember the insults anyway, but that way you won't re-read them and make yourself feel bad.
Keep your old patches, throw away your old programming assignments.
Stretch. That expensive chair is not as good for your back as you think it is.
Don’t feel guilty if you don’t know what you want to work on. There are a lot of great open-source projects in the world, and contributing to one is a terrific way to gain experience, pick up street cred, and come up with ideas for something else cool. Or think of a problem you have in your own life, come up with a solution for it, implement it, and release it. Release it even if you don't think anyone else in the world is going to use it; packaging software is a valuable skill in its own right, and you never know who else might desperately need the exact widget you just developed.
Get plenty of sunlight. You'll be amazed what it does for your mood.
Be kind to your wrists. You’ll miss them when they’re gone.
Maybe you’ll found a company, maybe you won’t, maybe you’ll do an IPO, maybe you won’t, maybe you’ll tank before you get VC, maybe Google will buy you out for $100 million. Whatever you do, don’t congratulate yourself too much or berate yourself, either. Your choices are half chance, so are everybody else’s. Enjoy your brain, use it every way you can. Don’t be afraid of it, or what other people think of it, it’s the greatest instrument you’ll ever own.
Dance. Even if it's just Stepmania.
Read the documentation, even if you don’t understand it. You'll learn something.
Read journals, as well. Yes, they will make you feel stupid, but remember that everyone with a published article has felt like all his or her colleagues are the competent ones, too.
Get to know your professors. You never know when they’ll take a job elsewhere and leave no forwarding address, which sucks if you need a recommendation letter.
Be nice to underclassmen; they're a good link to the department you're leaving, and you might end up hiring them in the future.
Understand that colleagues come and go, but some small few will be collaborators for a lifetime. Work hard to bridge the gaps in opinion and expertise, because the more of an expert in one area you become, the more you need the people who are experts in their fields and already know how to communicate with you.
Live in Seattle once, but leave before it makes you bitter; live in Silicon Valley once, but leave before it makes you think that everyone wants to give you money just for existing.
Travel. Conferences are a good excuse to get your workplace to pay for it.
Accept certain inalienable truths: interpreted languages will be slow, smart people will sell out, you too will get old, and when you do you’ll fantasize that when you were young, virtual machines weren't memory hogs, everyone was devoted to free software, and young hackers respected their elders.
Respect your elders.
Don’t expect anyone else to support your work. Maybe you have a boss who's happy to let you spend time on your own projects; maybe you have a group of clueful users who kick in patches now and then. But bosses quit or get transferred, and users get busy, so don't rely on them.
Don’t mess too much with your hair, but do wash it a couple of times a week. Your co-workers will thank you for that, too.
Be careful whose technical books you buy, but be patient with those who provide their help for free. This is one of the only fields in which advice is expensive because once you understand something at a very deep level, it's hard to explain it without going into too much detail. Show your appreciation to those who can make their way down from the mountain to show you the path up, and for God's sake, RTFM.
But trust me on the smartpointers.
Ladies and gentlemen of the Computer Science department Class of 2006 ... use smartpointers.
If I could offer you only one tip for the future, smartpointers would be it.
The long-term benefits of smartpointers have been demonstrated by the Boost developers, whereas the rest of my advice has no basis more reliable than my own meagre hackery.
I will dispense this advice now.
Enjoy the power and beauty of functional programming. Never mind. You will not understand the power and beauty of the functional idiom until you have forgotten what anything else looks like. But trust me, in 20 years you'll look back at procedural and object-oriented code and recall in a way you can't grasp now how weird functional programming was at the time, and how much easier everything else would have been if you'd just broken down and learned it.
Your code is more bloated than you imagine. But it gets better with time and practice.
Don’t worry about optimization; or worry, but know that premature optimization is the root of all evil. The real troubles in your code are apt to be things that you never predicted would bottleneck; the kind that show up in gdb and make you say, "Why are there 10,000 calls to std::less?"
Learn one new technique every day. And actually use it.
Sing. But be prepared for people to look at you funny if you're wearing headphones and they can't hear the background music.
Don’t be reckless with other people’s code repositories, and don’t put up with people who are reckless with yours. A commit bit is a privilege, not a right.
Floss. Your co-workers will thank you for it. And don't forget the deodorant, either.
Don’t waste your time on flamewars; sometimes you’re right, sometimes you're not, sometimes there's no way to tell. Prove it with code -- or math -- if you can, and if not, forget about it; in the end, it's the software you write that matters, not the mailing list posts. (Except as warnings to later generations. The time you save may be that of the next poor bastard who googles the topic.)
Archive the compliments you receive, delete the insults; you will probably remember the insults anyway, but that way you won't re-read them and make yourself feel bad.
Keep your old patches, throw away your old programming assignments.
Stretch. That expensive chair is not as good for your back as you think it is.
Don’t feel guilty if you don’t know what you want to work on. There are a lot of great open-source projects in the world, and contributing to one is a terrific way to gain experience, pick up street cred, and come up with ideas for something else cool. Or think of a problem you have in your own life, come up with a solution for it, implement it, and release it. Release it even if you don't think anyone else in the world is going to use it; packaging software is a valuable skill in its own right, and you never know who else might desperately need the exact widget you just developed.
Get plenty of sunlight. You'll be amazed what it does for your mood.
Be kind to your wrists. You’ll miss them when they’re gone.
Maybe you’ll found a company, maybe you won’t, maybe you’ll do an IPO, maybe you won’t, maybe you’ll tank before you get VC, maybe Google will buy you out for $100 million. Whatever you do, don’t congratulate yourself too much or berate yourself, either. Your choices are half chance, so are everybody else’s. Enjoy your brain, use it every way you can. Don’t be afraid of it, or what other people think of it, it’s the greatest instrument you’ll ever own.
Dance. Even if it's just Stepmania.
Read the documentation, even if you don’t understand it. You'll learn something.
Read journals, as well. Yes, they will make you feel stupid, but remember that everyone with a published article has felt like all his or her colleagues are the competent ones, too.
Get to know your professors. You never know when they’ll take a job elsewhere and leave no forwarding address, which sucks if you need a recommendation letter.
Be nice to underclassmen; they're a good link to the department you're leaving, and you might end up hiring them in the future.
Understand that colleagues come and go, but some small few will be collaborators for a lifetime. Work hard to bridge the gaps in opinion and expertise, because the more of an expert in one area you become, the more you need the people who are experts in their fields and already know how to communicate with you.
Live in Seattle once, but leave before it makes you bitter; live in Silicon Valley once, but leave before it makes you think that everyone wants to give you money just for existing.
Travel. Conferences are a good excuse to get your workplace to pay for it.
Accept certain inalienable truths: interpreted languages will be slow, smart people will sell out, you too will get old, and when you do you’ll fantasize that when you were young, virtual machines weren't memory hogs, everyone was devoted to free software, and young hackers respected their elders.
Respect your elders.
Don’t expect anyone else to support your work. Maybe you have a boss who's happy to let you spend time on your own projects; maybe you have a group of clueful users who kick in patches now and then. But bosses quit or get transferred, and users get busy, so don't rely on them.
Don’t mess too much with your hair, but do wash it a couple of times a week. Your co-workers will thank you for that, too.
Be careful whose technical books you buy, but be patient with those who provide their help for free. This is one of the only fields in which advice is expensive because once you understand something at a very deep level, it's hard to explain it without going into too much detail. Show your appreciation to those who can make their way down from the mountain to show you the path up, and for God's sake, RTFM.
But trust me on the smartpointers.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-05-16 09:55 pm (UTC)(no subject)
Date: 2006-05-16 10:12 pm (UTC)(no subject)
Date: 2006-05-16 10:24 pm (UTC)The basic rule you want to remember for functional programming is data in, result out, no side effects. Input should not be consumed, transformed or invalidated as a result of what a function does. You know how so many C functions return void, take a pointer to something as an argument, and operate in-place on that argument? Icky bad. The idea here is that side-effects are hard to keep track of, so if you want your code to be clear, easy to read, easy to follow, and easy to debug, avoid them.
My advice is to install a LISP interpreter and pick up a copy of Paul Graham's ANSI Common LISP. You might also enjoy The Litttle Schemer and The Seasoned Schemer, which are basically Socratic texts aimed at fourth-graders.
(no subject)
Date: 2006-05-16 10:46 pm (UTC)I'd quibble, though, that Scheme and LISP aren't "proper functional languages" in the sense of purity: they both allow you to mutate data, which is a no-no in functional programming.
(no subject)
Date: 2006-05-16 11:10 pm (UTC)And, yeah, you're right about being able to mutate data in LISP and Scheme, but you have to try pretty hard to do it; it's certainly not the default way of going about things. They're more functional by comparison than, say, Python, which has in-place sorts in the core language, for example.
(no subject)
Date: 2006-05-17 04:18 am (UTC)Scheme and LISP both fail the "pure functional language" test not because they allow you to mutate data, which is fairly small change in the FP world, but because they both have procedural constructs. Think LISP's PROGN, for example.
But then again, SML/NJ has the funky (* *) notation for procedural constructs, and it's beloved by functional programmers everywhere.
Purely functional languages are conceptually clean, but almost never used anywhere. Practical functional languages have the occasional sharp edge, but I don't know I'd consider them to be less proper. Less pure, certainly.
(no subject)
Date: 2006-05-17 04:58 am (UTC)(no subject)
Date: 2006-05-16 11:14 pm (UTC)(no subject)
Date: 2006-05-17 04:12 am (UTC)Yes, all those languages are excellent. But you want to reduce your learning curve as much as possible. Learning functional languages is hard enough without having to master new syntax and keywords.
The good news is that you can do basic functional programming in almost any language. Some are clearly going to be better or worse than others, though, with C and C++ bringing up the rear of the group.
(Contrary to what
Once you've begun to understand the ideas behind FP, then go out and immerse yourself in Scheme. Once you grok Scheme in fullness, grasshopper, then you will know it is time for you to leave the monastery.
(no subject)
Date: 2006-05-17 12:54 am (UTC)(no subject)
Date: 2006-05-17 12:58 am (UTC)(no subject)
Date: 2006-05-17 03:01 am (UTC)(no subject)
Date: 2006-05-17 04:13 am (UTC)95% of the hate that I see towards C++ is misinformed. The remaining 5% of the hate that I see is stuff that's very hard for me to argue away.
(no subject)
Date: 2006-05-17 04:30 am (UTC)(no subject)
Date: 2006-05-17 06:07 am (UTC)(no subject)
Date: 2006-05-17 01:11 am (UTC)(no subject)
Date: 2006-05-17 02:02 am (UTC)(no subject)
Date: 2006-05-17 03:37 pm (UTC)(no subject)
Date: 2006-05-17 07:37 pm (UTC)(no subject)
Date: 2006-06-07 07:05 am (UTC)Very nice. I particularly like the wrist comment, but it's all good.
This reminds me of a variation on Molson's I Am Canadian commercial I recently helped a former classmate write for a school project (which will not be described here as it is as yet in progress).