| last updated:06 Aug 2003 14:53 UK time |
 |
| JOS Statistics - Recent Comments (Comments added for week ending Sun 23 Mar 2003) | View Other Weeks |
| WinCE beats VxWorks in revenue | Sun 23 Mar | Nat Ersoz |
| http://www.embedded.com/story/OEG20030321S0033 With the handheld market growing, MSFTs revenue numbers exceed VxWorks. Nothing revolutionary, but certainly a data point on the history timeline. |
| Sun 23 Mar | Mitch & Murray (from downtown) | XP Embedded is the new Big Guy in town if you aren't after a small footprint. Near as I can tell from our own customer feedback is the adoption rate on this thing is amazing. Why? Because the masses already have the development tools and already know the Win32 API in their sleep. Over time, VxWorks, Wind River, and QNX are probably going to get hosed. |
| Sun 23 Mar | Myron Semack | Being an embedded programmer, I HIGHLY disagree with that statement. XP Embedded targets an entirely different market than VxWorks, WinCE, or QNX. XP Embedded is for lightweight PC's, like set-top boxes, thin clients, kiosks, etc. The biggest selling point for XP Embedded is its compatibility with desktop Windows. XP embedded does NOT provide any sort of enhanced reliability or deterministic real-time capabilities. It doesn't support any non-x86 architectures. You won't find XP Embedded in an avionics system, satellite, or submarine. VxWorks, WinCE, and QNX are hardened real-time OSes. They're made for truly embedded systems. Most RTOSes have no GUI (or it's optional). They usually don't have any separation between user mode and kernel mode. Real-Time operating systems are expected to be quick-booting and respond to interrupts instantly. CPU overhead is minimized. Also, most RTOSes support a wide range of architectures (PowerPC, XScale, ColdFire, etc). I will agree that WinCE is an up-and-comming player in the embedded market. I have more and more customers asking about it (Linux too). The embedded world is a huge growth market for Microsoft. 98% of all processors sold last year went into embedded systems. I read about this study about a week ago. WinCE, Symbian, and Palm are used in handhelds, cell phones, and industrial PCs. They all have practically zero usage in the military market. VxWorks and Green Hills are totally unused in the consumer market, but is a huge player in the military market. QNX is used in the medical and scientific systems. This study mistakenly lumps all consumer and military systems into one category. All this really shows me is that the consumer market uses almost as many embedded systems as the military market. Although, I must admit, I was very surprised to see LynuxWorks in the top 10. |
| MFC Future? | Sun 23 Mar | Hoang Do |
| Just a slight digression from this topic: http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=35297&ixReplies=17 For someone who have invested 4 to 5 years working with MFC to get to the nuances of the infrastructure, it is disappointing (to say the least) to find out that Microsoft will be obsoleting this. I am sure there are many many companies who have invested their products on MFC and ActiveX. What do people working in these areas think and what are your plans for the future? Move your applications to .NET? That is a major investment with a ZERO return business case. |
| Sun 23 Mar | Tony E | I see this as one of the issues with using a proprietary platform such as MFC, .Net, WTL etc. I expect in 5 years time I’ll see similar posts bemoaning the demise of .Net due to its replacement by some new essential technology from MS. |
| Sun 23 Mar | Duncan Smart | Is the source code to MFC not provided as part of Visual Studio/SDK? |
| Sun 23 Mar | dmooney | The source IS provided. |
| Sun 23 Mar | Nat.Ersoz | Tony E., So true, so true. There are some MSFT 'technologies' (ie, programming API's / techniques) that will have a longer life than 5 years: 1. The Win32 (kernel) API. 2. DirectX (specifically: DDraw, DSound). Outside of those, well, its pretty amusing... Party on. |
| Sun 23 Mar | Nick | Where did the story that MFC was being obsoleted come from? Looking at the MS web site, MFC is alive and well in VS.Net 2003: 'Visual C++ .NET 2003 continues to deliver a range of libraries, including: A fully ISO-compliant STL implementation (providing generic container classes and algorithms). ATL and MFC (now updated for Windows XP and Windows Server 2003). ATL Server (enabling unmanaged dynamic Web content and XML Web services). ' (from http://msdn.microsoft.com/visualc/productinfo/visualc03/overview/default.asp ) Is there something I'm missing? |
| Sun 23 Mar | Anonymous developer | Well, I think what worries the original poster is that the center-of-gravity of Microsoft platform application programming seems to be moving from Win32/MFC to .Net/CLR. It's not that MFC's going to stop working, it's more that it's become mature, and probably won't get many new features from now on. The 'ha ha, serves you right for trusting MS rather than going open source' argument doesn't really apply here, since you do get the source for MFC. It's just how things go -- you could port MFC to C#, and make it work with the CLR, but then it wouldn't really be MFC any more. I'm not sure why the original poster is worried, though. They can pretty much reuse all their MFC experince with C#/CLR. It's not like they have to start over from the beginning. |
| Sun 23 Mar | Brad (dotnetguy.techieswithcats.com) | I disagree with Nat. .NET represents a significant platform shift. The goal is to get away from unmanaged code, which includes directly accessing Win32 and DirectX. Those technologies are both exposed from within .NET (as of DirectX 9, which includes a managed wrapper). You can argue that the abstraction isn't good enough yet, but it will be. This IS Microsoft's future. MFC isn't going to just stop working one day, but I think we're all agreed that MFC had its last major update many years ago with VC++ 4.2. Since then, MFC has been on coast, because it's a matured technology. Unless and until Microsoft one day says 'we aren't going to support Win32 any more', MFC is still a viable (if annoying) way to write Windows apps. Now as to the original poster, I think your personal growth as a software developer means you need to make a choice what to do. Some day soon (let's guess a year or two), all new development jobs on Windows are going to be in .NET, and that MFC knowledge isn't going to count for as much as it does today. So you probably need to start learning .NET if you're going to stay with the Windows platform for the long term future. |
| Sun 23 Mar | Brad (dotnetguy.techieswithcats.com) | Oh, and by my guess, Microsoft has only had a shift like this twice in its history before: moving from real mode DOS programming to 16-bit Windows programming, and again moving from 16-bit to 32-bit Windows programming. Nothing else has really been as significant as the shift to .NET is. |
| Sun 23 Mar | Philo | Tony E - you forgot to mention Java. (Still owned by Sun, IIRC) I guess if you want to truly be 'vendor independent' then you're stuck with C++, PHP, HTML, Perl (can Larry call Perl home? [g] )... Philo |
| Sun 23 Mar | Albert D. Kallal | From a career point of view, one should always invest time in learning things that will have a long term value. For example, when people ask me what to learn, I always say learn SQL. I learned it more than 10 years ago in the dos based FoxPro. I use it for every application I work on today. Be it ms-SQL, ms-access/JET, and now MySql. Lean SQL, and I will take bets that you also will be using it in 10 years from now. I have no doubt this skill will last me more than 20+ years. So, one should pick and choose good long term technologies that don’t change. That means generally the platform should be based on as many proven standards as possible. I remember writing software in Pascal, and have not done that for more then 10+ years now. However, if I had learned C back then, it would certainly have been a skill that I still use today. So, C was also a major standard (it is obvious that system software was being starting to be written in C, and not Pascal at the time). The choice of language should have been obvious to me, but it was not. Don’t we all love hind sight!). The other key is to pick technologies that add value to the business community (so, standards + key technologies = good!). Many tools and platforms and environments we learn generally only have a shelf live of 5 years, or even less. If you don’t like the idea of learning a new development tool every 2 or 3 years, then you will quickly find out it is time to leave this industry. Remember, good developers will concentrate on those skills that make them good developers, and that is NOT knowing how to print hello in 20 different computer languages. A good sprinkling of software development books is really recommend here. Oh, gee, what is the new software flavor of the week? It should not matter. Don’t start learning Java because it is cool. Lean Java because it is key technology that IBM is using to deliver corporate solutions. Further, the value of what you learned is ONLY of use if those tools let you create solutions to people who WILL PAY for those solutions. Smalltalk was revolution in software development, but did not deliver solutions to the BUSINESS community. This is critical, since you want to learn tools that let you DELIVER solutions. Hence, Microsoft is not stopping me from writing software in FoxPro 2.6. In fact, I have often mentioned how incredible the MS track record is in this regards. Recall how apple in the early 90’s had everyone THROW OUT all software for the next platform. This was done again recently at apple. With MS, you should be able to use the MFC library for years to come anyway. Hey, how about learning a new word processor every year? Remember ZyWrite, then SuperScript, and then Wordstar, and then WordPerfect and then ami-pro, and then ms-word? Way back then, people learned a new word processor every year. In addition, people also were learning new systems all the time. Turbo-Pascal, then VB, then Delphi. Heck, the same goes for database software. Lets see, Advanced Revelation, then dbaseII, then Reflex, then FoxPro, then ms-access. This is the short list! Software cycles for development tools are actually increasing in time, not decreasing. I cringe to think of just the word automation code that I would have to throw out today if clients throw out ms-word. The only real problem I can say here is that developers can only absorb so much, and the HUMAN COST of learning a new system is rising DRAMATICALLY to day. The result of this increased hum cost now means that picking the right tools and platforms is VERY IMPORTANT. Before, it was easy, you just picked whatever you wanted, or seem to need at the time. Now, we have to use our brains, and pick real solid tools. So, while you might have to do some new platform learning..that should be viewed a welcome new challenge. Albert D. Kallal Edmonton, Alberta Canada Kallal@msn.com |
| Sun 23 Mar | complex matter | MFC isn't going to be supported? At what point in time? |
| Tips, Advices for writting EASY to port code | Sun 23 Mar | Codex |
| What kind of tips, advices you would give me to write *easy* to port code. Im planning to write a small video game that I would like to port to a few system (PC, Pocket PC, Palm OS,Mac) Is there any good articles, books regarding how to write reliable and portable code across a wide range of platform? |
| Sun 23 Mar | Myron Semack | It's not a very extensive article, but it provides some key tips. http://www.embedded.com/story/OEG20020924S0072 |
| Sun 23 Mar | Ori Berger | If you have games in mind, check out SDL, the Simple Direct-media Layer at [ http://libsdl.org ] - It's what you should target. If you want to target many platforms with a game, it better be a board game, or a relatively mild arcade game. Different systems differ to the extent that it's almost impossible to produce a fast paced arcade game that is addictive and compelling on more than one platform without optimizing for each platform individually. |
| Sun 23 Mar | Mike Swieton | Ori: I beg to differ. id Software has written games for multiple platform for quite a while. I don't know about early ones, but Quake ran on DOS and Windows initially, and also had OpenGL acceleration available. Every game out of them since has. And they've always been pushing the envelope. It's mostly done through the standard methods: wrap the important and system-dependant stuff. Rely on the OS's GL implementation. But then again, they have many many years of experiance writing code at all the levels, so competing with him is hard 8-} But it can be done, feasibly. Not to mention the after the fact Loki ports (not economically viable, but technically the succeeded.). |
| Sun 23 Mar | Arron Bates | Java?... Java can just about do anything. really. And it's on all the platforms that you require. I know someone's going to jump in and say it's not performant enough. Please dont, because it's simply not true. Take this truly hot flight-sim... http://www.il2sturmovik.com ...it's all Java. If pervasive computing across platform is what you're after, Java has no equal. |
| Sun 23 Mar | AEB | All java huh? IL-2 Sturmovik:MINIMUM SPECIFICATIONS Computer: Pentium III 800/AMD Athlon 700 or better Memory: 256 MB of RAM ( 512 MB is recommended) Operating System: Windows(r)98/ME/2000/XP DirectX: DirectX 8.1 or higher (included on disc) Video Card: 3D video card (DirectX 8.1 compatible) w/32MB RAM (64MB recommended) CD-ROM: 4X CD-ROM or better (Not recommended for use with CD-RWs) Audio: Direct 8.1 compatible sound card Internet/Network Play: Internet connection (56 kbps or better) or LAN for multiplayer Hard Drive Space: 1.1 GB So it's only Windows, uses DirectX, it uses dll's - so what part of it is java - the installer? |
| Sun 23 Mar | Fred the Elastic Pancake | In addition to the previous post, I can't help but note that there is nothing to download for this 'high-performance' java game. Screenshots, sure, but I can make pretty screenshots with Gimp; it won't make a fast game. Java CODE compiled to binaries for a single system has no reason to be slow. But then, it also has no reason to be Java. Multi-platform java DOES have performance issues, in spades. Check out jEdit, and tell me that you honestly believe a text editor should take so long just to start. |
| What One Recruiter Really Thinks of Techies... | Sat 22 Mar | Fly on the wall |
| This is a posting by a self described agency technical recruiter to a message board that is used by IT contractors. This post is in response to a thread that was begun about ways to disintermediate, that is, to find contract work or jobs directly with clients instead of using agencies. http://pub21.ezboard.com/fopenitforumfrm9.showMessage?topicID=392.topic&index=24 Im not advising joining in the flame war. But the next time you get a call from a headhunter, be advised that SOME of them really do feel this way. |
| Sat 22 Mar | anon | Sounds like a guy who's tired of the abuse. Wrote a little post to get it out of his system, no harm done. There's a few good recruiters and a whole lotta bad ones. Same with programmers -- a whole lot of bad ones, and allah forbid you work with them. Ever been on Slashdot and get tired of those bullshitters who repeat the same dogma? They don't represent opensource, and it's a catharsis to tell them off. |
| Sat 22 Mar | | That rant was directed at the open IT forum. I think he's right on the money about those guys. |
| Sat 22 Mar | Stephen Jones | So Bella's got a brother! The guy might be a troll, but he's got a fair point. Programmers should code and recruiters recruit; nobody ever worked out why all writers, film stars and sportsmen have agents? And as for people being embittered, well, when I'm depressed I go over and have a look at Netslaves; there's nothing guaranteed to cheer me up more than others' misery, particularly when the types who are miserable seem so thoroughly to deserve it. |
| Sat 22 Mar | Troy King | The poster sounds smart and observant to me. I think he nailed it. |
| Sat 22 Mar | Philo | I really, really hate people who stereotype and are successful nonetheless. 'You guys have no business sense.' Uh-huh. I'm assuming 'you guys' means techies? So was he referring to Michael Dell or Bill Gates? Maybe he meant Jeff Bezos? Each person is a shopping bag of skills and talents. Often times having one strong talent indicates a lack in other areas because of the effort required to maintain that talent (I'm sure the average Olympic gymnast isn't a 'business person' either). But you cannot categorically say the presence of one talent indicates the complete absence of another. After all, the term 'renaissance man' exists for a reason. Also be careful of the lawnmower handle effect... A boy was riding in his father's car when he asked 'Dad, how come they don't make lawnmowers with folding handles?' 'What makes you think they don't, son?' 'I keep seeing cars drive by with lawnmower handles sticking out' 'Ah. And how many cars have you seen drive by with lawnmowers folded in the trunk?' The moral: When one type of attribute is visible while the other isn't, we tend to overestimate the prevelance of the visible attribute. In the current case our beloved recruiter is laughing about techies being business morons based on the ones that come to him for jobs. But how does he know how many techies *with* business acumen are ignoring him because they're working? My final observation - he sounds like a snot-nosed college boy (even if he's in his 30's) that simply wants to believe himself superior and does so by putting down those he envies. He has not lost sight of the fact that he is brokering the talent people *really* want. And he doesn't like it. Philo |
| Sat 22 Mar | | The guy is as ignorant of some business basics as those he condemns. I'm not in a position to elaborate at the moment. While complaints about recruiters are often poorly presented, they do have a solid basis. Recruiters are just middle men; they don't create jobs; they just insert themselves into the job availability / job application process so as to extract a commission. They do add some value, but nowhere near as much as what they charge. To sustain their artificially high commission, they need to and insist on rigorous control of the process, particularly relating to information. On the comparison with agents for actors and sportsmen, there is a big difference. Those agents generate very large end payments for the actors and sportsmen - much larger than the actor or sportsman would obtain otherwise - so the actor or agent is happy to pay a significant commission. However for programmers, the pay is no greater than would be obtained by working directly for the employer, and in fact is less. For programmers, the game is a win-lose. Note also that sportsmen and actors know exactly how much they're paying the agent, and make that decision. |
| Sat 22 Mar | never needed to use a recruiter | Im an IT chappie, but frankly I think I preferred what mike had to say over the response of the childish bums who responded to him. |
| Sat 22 Mar | Fly on the wall | I think Philo explained this person better than anyone here, except that this guy is not really the picture of entrepreneurial success. On the response this guy garnered with his posting, I wish someone here would give give the Open IT participants some credit for having a constructive discussion on ways to market directly to companies ... that was diverted by a loudmouthed and egotistical a-hole 'setting everyone straight'. Really pretty damned dense of some of you to not support your own kind and to not take into account just who was intruding and who was having a 'meeting'... I think if someone elbowed their way into your house and invited themselves to your party and then started telling off color jokes, they would deserve a bad reaction too. I think it's an accurate generalization that recruiters are often untrustworthy, status grubbing materialists. A tech writer friend worked for one of these 'solution providers' a few years ago (in '99) and was getting a LOT of grief (pressure and snide comments from sales borks that worked in the place) over his declasse' mid 90s domestic sedan... |
| Sat 22 Mar | chunks | I'll take the conversation a step further in the wrong direction and say that any recruiter i've ever dealt with has been a guido from long island who went to nassau county community college and is now cold calling in an attempt to make it big without having to learn a useful skill. Think of the movie 'Boiler Room' but shift contexts a bit. In silicon valley, the recruiters were all dizzy girls with psych degrees from Cal State Hayward. In either case we are talking about people who make $50,000 a year and also drive $50,000 cars. These aren't people who care about your career, and don't really care about their own careers, either...they just care about making easy money and spending it as quickly as possible. |
| Sat 22 Mar | Daniel Shchyokin | Recruiters do have a usefull skill, they are willing to make those 300 cold calls a day to find somone a job, something most programmers are not willing to do themselves, if they did recruiters would not exist. Now as far as their commissions, I think the market dictates that also, I bet they have come down a lot (20% was normal) since the dotcom days. Also don't forget that the reason salaries got so high in the first place is recruiters would constanly move people around, driving up salaries |
| Sat 22 Mar | Mark B. | Mr. LasVegas' post is very interesting, but he never tells us why recruiters do the job they do. In this poor economy do recruiters really do that well? |
| Sun 23 Mar | | Daniel, you've got it wrong. Recruiters don't make 300 calls a day to 'find someone a job.' They do it to STOP programmers finding a job directly, and ensure THEY intercept the job and can then market it, collecting their commission on the way. If there were no recruiters, the jobs would still be there, and programmers would still get them. As to commissions, 20 percent is low. Recruiters were able to pocket much higher commissions, sometimes far exceeding the amounts paid to programmers. This was one reason H1-B's were so attractive, by the way, for certain classes of recruiter. This also is why recruiters earned salaries of $300,000 and above during the dot com days. |
| Sun 23 Mar | never needed to use a recruiter | 'Really pretty damned dense of some of you to not support your own kind'
my own kind? call me a fuckwit but I dont consider spoilt, childish IT people 'my own kind'. I like to pretend I belong to a group composed of at least vaguely well-behaved and polite individuals who behave politely right up until it becomes necessary to not behave politely.
'and to not take into account just who was intruding and who was having a 'meeting'... I think if someone elbowed their way into your house and invited themselves to your party and then started telling off color jokes, they would deserve a bad reaction too.'
|
| Sun 23 Mar | Stephen Jones | Philo, the 'you guys' are the people who are posting to that forum, in particular the main thread. I didn't see Bill Gates or Jeff Bezos there; perhaps they're using a handle. What is the difference between the attitude of the guys in the thread 'We'll start a recruitment agency. We don't have any customers but we've got a load of programmers so we'll get a web site going and then we'll hire some sales-monkeys to do the job.' and the attitude people on this forum are always complaining about 'We'll start a software company. We don't have any customers but we've got a load of salesmen so we'll get a web site going and then we'll hire some code-monkeys to do the job.' |
| Sun 23 Mar | ODN | I'm not convinced of the intelligence of that recruiter after he posted his own cell phone number in 'retaliation' a few posts down... |
| Sun 23 Mar | one programmer's opinion | The recruiter in that thread seems to be an independent broker (owns his own company). I tend to have more respect for these type of individuals than I do for the ones who work for someone else. My experience is that most companies that call themselves consulting firms are nothing more than body shops. They don't seem to offer much in terms of service to either their clients or the technical workers they employ. I noticed that EDS canned their CEO Dick Brown the other day. Supposedly he earned close to 50 million dollars last year and was given a 37 million dollar severance pay package. Anyone who believes that most staffing firms only take 20% of the billing rate, must be on crack. |
| Sun 23 Mar | | Stephen, I agree it is naive for programmers seeking to stop getting screwed to expect to do this by starting their own recruitment firm. That's not how it works. However the basis for their anger is valid. It's just they need to reconsider how to be independent, and also consider much deeper issues about the structure of this industry. Your point about their approach being the same as dumb business guys is valid. However their expression of the solution is not a valid one. If they expressed the solution properly, it would not fall foul of the problem you raise. In a way, the point you make actually supports their case and their anger. To a greater extent than, I think, any other professional occupation, programming is one where many other people profit by screwing the professional people. That is, by screwing the people who have the talent and have made the investment in training. |
| Sun 23 Mar | Bella | I have never consulted through an agency. Do they basically try to get the highest bill rate from the client, and. in turn, pay the lowest rate to the contractor, in essence maximinzing the 'spread'? I expect there to be some level of optimizing of the grey areas. ie: Agency needs pay as little as possible, while still maximizing the quality of staff they send the client, so as not to jeopardize other potential placements. ie: Collect $100/hr from client, but rather send over a $75/hr guru, as opposed to a $65 neophyte. Trying to save that extra $10/hr would be 'penny wise', as you may ruin the relationship with the client, if they sense the agency is trying to pocket as much as possible, at the expense of sending over decent talent. What kind of business/economic/MBA term/phenomena am I trying to describe in the above scenario? 'Maximizing'? 'Optimizing'? 'Trade off'? '2 variable optimizing'? |
| Sun 23 Mar | Bella | To anyone who is angry about recruiter 'gouging', I say don't use them. Problem solved. No one says you need to use them. They provide a service, perhaps overpriced in your eyes.. If you choose to do the work they find for you, you are agreeing to PAY them a cut. Like an agent. If you think their 'fee' is too high, then don't use their services, and find work on your own. You can pay $6 for a cup of Starbucks coffee, or you can brew your own cup for 25c. It's all up to you. In a free market, there is no 'right' fee or cut or 'too high' or gouging. They can charge whatever they feel like it. If 20% or 50% or whatever is unfair or too high, then market forces will force them to adjust. As long as there is someone who agrees to the terms, then that is what the market forces dictate as 'fair market value'.. If they are able to operate at the rates they have set, then it is YOU who is out of line with market forces and rates, b/c someone out there is willing to work under their terms. That really is the bottom line. |
| Sun 23 Mar | Tj | I once met with a very good recruiter (Thinknicity, nee Trilogy IT in SF) and their business model was clear. The fee was absurd for someone who didn't need them, but for the double-coincidence of clueless job seeker + clueless business, it seemed vaguely useful. The point that recuiters serve as gatekeepers, was not well made. Only an idiot company would sign an exclusive hiring deal with these guys. And if a company is completely unwilling to do the work of grepping through resumes when there's a job opening, then what's wrong when there's extra weight given to a recruiter's candidate? These companies aren't rational hirers anyway. Mike was flaming a bunch of guys who thought nothing of calling him bin Laden. Seemed evenhanded and fair, from where I stand. |
| Sun 23 Mar | Stephen Jones | Programmers are anything but the most exploited professionals around. Go to any maids agency in the States and they'll probably charge you about $25 an hour for the maid's time. The maid will be lucky to get $7 an hour. The States is not the worst place in the world for this. Go to Berlitz or Wall Street, or Inlingua to learn a foreign language and you'll find that the organization is probably paying 30% of income to your teacher. |
| Sun 23 Mar | Daniel Shchyokin | As one recruiter friend of mine said- 'you get paid what you negotiate not what you are worth'. I am not saying that is they way it should be, but that is the way it is. Incidently, someone mentioned 'dizzy psyche majors' in either this or the other board threads, there is good reason for this (think hall-kinion in SF). Attractive women are intimidating to a lot of techies to begin with, and if they can find a woman that is bad at math to begin with (or more commonly can pretend to be), it is that much harder to negotiate a fair price |
| Sun 23 Mar | | No, it is not just a matter of 'negotiating your worth.' Recruiters actively work to control the market, placing candidates at significant disadvantage in negotiating. If real estate agents tried to charge 30 or 70 percent for selling your house, they would be locked up. Even better, no-one would use them. Recruiters are able to charge these rates partly because they insist on hiding the rate of pay from the worker. The financial sums involved are equivalent over the course of a few years. |
| Sun 23 Mar | | Bella, yes, you're correct. Recruiting is a business where recruiters try to maximise the rate paid by the employer and actively minimise the amount they pay to the worker, including lying through their teeth. Standard business, really, but so many candidates don't understand how it works. A professional person might think the recruiter would be careful about putting forward the '$75' guy instead of the cheaper guy, but it actually works the other way around. The cheaper guy delivers higher profits. Most managements can't tell the difference anyway. One reason the H1-B program attracted a lot of angst is that there were firms who were essentially recruiters, but maintained they were 'consulting' firms, and hired Indian guys on $40,000 per year, yet farmed them out in the general contracting market. Needless to say, those recruiters made a killing. Also, there are many large companies now that do exclusuive deals with large recruiters with strict lock-down prices. The recruiting firm gets all the work, but to make any profit, they have to place really cheap people. |
| Sun 23 Mar | Fredrik Washington | the clients (usually big companies) choose recruiters because it's easier to bill to one place, and have the recruiter schedule interviews. For the most part techies are a commoditiy because companies are not doing anything new or involving thought. Once the economy turns around smart people will have the upper hand. |
| future of software engineering | Sat 22 Mar | anon |
| What do people see in the future? Any new pardigms or foundations coming up? |
| Sat 22 Mar | Enjoy | Just speculating: Executable (UML?) models. |
| Sat 22 Mar | Matthew Lock | It's funny how people speculate that in the future anybody will be able to write a program. What ever came of all the 4GL talk in the 80s? Having said that I think Scripting will play a very important role in the future, letting you develop programs much more quickly: Scripting: Higher Level Programming for the 21st Century http://home.pacbell.net/ouster/scripting.html |
| Sat 22 Mar | Daniel Shchyokin | 'Just speculating: Executable (UML?) models. ' good one |
| Sun 23 Mar | ODN | Executable UML does exist... http://www.taug2.com/tausolution/taudeveloper/ Although at $12,000 to $20,000 a pop plus 18% annual support and maintenance, it ain't cheap. It's targeted at real-time software development and uses UML 2.0-specific features. |
| Sun 23 Mar | Enjoy | Matthew, I don't think that in the future anybody will be able to write a program. Sure many will be (and already are) able to develop (well, now I'm very cautious) *'software'* with products like LEGO Mindstorms: Just put a few modules together and voila. But we agree, that's not an n-tier application? For those who want to develop complex systems, there will be something like xUML. I don't know if it'll have 'UML' in it's name, but we'll have it! Why? Because probably the best way to understand what's going on in a software system (i.e. to cope with complexity), no matter if it is a new system you're developing or you're maintaining an existing system, is to make some diagrams. There is an example (http://www.omg.org/mda/presentations.htm) from the world of real-time software development. It's a very mission-critical system but it's still not a method to develop each and every kind of software. That's why ODN, if Telelogic want's us to read 'real-time' we should do that. They admittedly don't write it's a silver bullet. xUML exists but we can only solve 15 percent of the problems we face in software development. Therefor 80 or 90 percent in the world of real-time doftware development. For me executable UML (?) still isn't there. It still isn't ready for the primetime. |
| Sun 23 Mar | Tj | Isn't the big hype building for aspect-oriented programming? |
| Sun 23 Mar | Ori Berger | The more things change, the more they stay the same. The future is going to be LISP, as it always has been. OOP, AOP, metaprogramming, scripting, whatever; All of these miraculous inventions are library-level in LISP, which means that you don't need a new compiler, new environment or new training when the next buzzword comes along. Unfortunately, it also means that it's never going to be fashionable. [And, if the IT industry had any sense, the future would be APL, as it had once been. This is even less likely to happen] |
| Bella's Pet Peeve #542 | Sat 22 Mar | Bella |
| I cant stand when techies celebrate free beer or free food in order to justify going to a conference, staff development meeting, xmas party, etc. Along the lines of, This sucks, but hey, at least theres free food! I recall wanting occassionally to go out to lunch on Fridays, but finding no takers b/c there was free pizza. Its a $1 slice of pizza, you can pass it up once in a while. Now, I know that in 95% of cases, its just a figure of speech. Trying to find the silver lining, or making a joke. But Im not sure this is always the case. Is anyone really so broke that you cant afford a beer or ham sandwhich for youself? Or do you value your time to little that you will waste 3 hours at an event that you would otherwise not go to, just to get a free 2 dollar sandwich? Is this just a human nature thing? Like some deeper hunter/gatherer type of mentaility. Can humans simply not pass up something free? Look at the lines at those (not defunct) trade shows, where people would line up around the corner for a lame teeshirt (80% of the time) or free pen. |
| Sat 22 Mar | Slacker | 1. stay at the office, work, pay for my own lunch. 2. goof off at a conference instead, eat free. tough choice. |
| Sat 22 Mar | Prakash S | read this soemwhere, FREE is the only word which gathers the most attention - among everyone. Ofcourse there is nothing like a free lunch, and pizza & beer - an excellent, healthy choice of food:-) Lots of kids I know go to Career fairs purely to get their hands on all the 'goodies' - ...... human nature after all.... |
| Sat 22 Mar | Jimmy Chonga | I couldn't stand going to COMDEX (back when it mattered) with several coworkers because they defined the experience by how many ten cent pens and plastic pieces of crap they could accumulate. I had much the same feeling as you: Why do people waste their time for cheap little trinkets? I think it becomes a game to see how much free junk people can get, rather than caring about what they're getting for free. Sorry, gotta run: I think I can score me a wrong-size ultra-cheap t-shirt with a cheesy iron on logo on it if I stand in line for 45 minutes! I'm SO there! |
| Sat 22 Mar | tapiwa | Sometimes it is making lemonade when life dishes you lemons. You are at the event already, and it sucks. The fact that you don't have to pay for your lunch is the only positive thing! I would not attend something just for the free pizza, but if I am already there, then I won't turn down the free booze just to prove that I can afford to by my own drinks. |
| Sat 22 Mar | Nat Ersoz | Sad but true... 1. Grab free pizza slice. 2. Covertly slink back to cube. 3. Read Joel on Software 4. Clean keyboard when finished. |
| Sat 22 Mar | Stephen Jones | Nothing to do with being broke. Ray Noorda, CEO of Novell at the time, and worth many tens of millions more than he could possibly count, was seen at an important meetins stuffing canapes into his suit pocket. His comment, 'ain't it wonderful to live for free!'. One of the leading police officials Felipe Gonzalez's Spanish government in the eighties was asked in a corruption probe how he had managed to build up such an impressive property portfolio on a relatively meagre public service salary. His comment, 'I'm a senior government officlal, everything's paid for by the state'. |
| Sat 22 Mar | Alex Chernavsky | What troubles me is the fact that doctors seem to be influenced by the glass beads given to them by pharmaceutical reps: http://www.yourlawyer.com/practice/news.htm?story_id=3626&topic=Medical%20Malpractice |
| Sat 22 Mar | Greg Kellerman | Bella, this bring up memories of crap that employers do. They want to to bust your ass and they dangle someting like pizza and beer as incentive. Gee let me think, you're going to bill extra thousands and buy 50 bucks worth of pizza and beer. Is it any wonder that I laughed at them when they'd make such a silly request? Sorry, I don't have a number for my Pet Peeve. |
| Sat 22 Mar | Dennis Atkins | Greg, I think that free beer and pizza is a nice gesture. The monetary value and whether one can afford to eat out are not relevant. It's the thought that counts. Obviously though, pizza offered as a substitute for a living, competitive wage is not a square deal. But a fair wage plus free lunch and tee shirts from time to time isn't oppresion by the man. |
| Sun 23 Mar | Patrik | Dennis, Free meals and beers is OK, but I started passing on them. When you hear things along the lines of this; 'Ah, yes. If you meet this very unrealistic deadline by working your asses off around the clock, you earned a night out.' you should watch out. This 'work-your-ass-off-for-$30' mentality used by some are nothing but insulting. |
| Sun 23 Mar | Dennis Atkins | Patrik, I agree with you completely. If presented with that offer, it would be reasonable and expected to slow down work output, take full hour lunches and leave for home at exactly five. But when it is presented as 'Since you've been doing such a great job lately, we're having a pizza party.' or 'I noticed you guys are working late so I ordered you pizza and beer.', then I tend to think it's a good place to work. But if someone is told 'If you work overtime we'll consider getting you guys $30 worth of pizza.' the appropriate response is, 'Boss, I've got a much better idea, you come to my house, dig a fish pond in the back, paint the spare bedroom, and remodel my bathroom and I'll buy you a nice sandwich and a bag of chips.' |
| Discussion Forum Software | Sat 22 Mar | Mark Sanders |
| After several weeks thought, Im so impressed by js arguments concerning the (lack of) features of the JoS discussion fora that I want to implement a clone on my site to replace a slightly-too-shapeless guestbook. Can anyone recommend any free/cheap packages that offer this type of cut-down functionality? Id prefer to avoid starting with bloat and stripping out IF I can, like, start slim and graceful. Thanks |
| Sat 22 Mar | Chuck | Mark, The functionality is so simple, is there some reason why you couldn't just throw it together in a couple hours like Joel did? |
| Sat 22 Mar | Mark Sanders | a) Several years out of programming practice b) Sloth |
| Sat 22 Mar | Matthew Lock | a) start programming again b) buy some coffee |
| Sat 22 Mar | Mark Sanders | c) Lose young children |
| Sat 22 Mar | Matthew Lock | c) Teach your kids to program, then sit back.... |
| Sat 22 Mar | Mark Sanders | i just feel that code re-use is so much more environmentally friendly... 8--}> |
| Sat 22 Mar | Justin | Given the number of occasions 'where can I get some discussion board s/w like this' comes up, I'm really surprised that Joel or FC haven't started selling it as a 'You get what you pay for, unsupported' $25 package. There must be some commercial reason for it that we're not seeing - presumably admin costs outweigh sales revenue or something. |
| Sat 22 Mar | Alex Chernavsky | PHP / mySQL version: http://www.johnsadventures.com/backend/DiscussionForum/APHPDiscussionForum.html |
| Sat 22 Mar | optimistic coder | Yes! Get the kids to do it - that is a fantastic idea! |
| Sat 22 Mar | Jimmy Chonga | I disagree with Joel's assertions regarding conference software in a couple of ways, and one relates to having a 'preview' of your post: Joel's assertion is that by removing the preview people will write better posts in the first place, however I disagree if 'preview' offers some tools to make it genuinely useful. Plastic.com offers a brilliant preview where they actually spell-check your posts (and yes most of us appreciate a spell check. My spelling has humorously gone to hell BECAUSE of the net: After reading gross misspellings on Slashdot time and time again, pretty soon it becomes the norm in your mind), as well as offering a reading index on the 'level' of your writing. Very cool little tools. |
| Sat 22 Mar | Chuck | Mark, You should really sharpen up those skills and you'll feel better doing so. Go ahead and make it a project where you teach the kids some Perl or whatever and you'll all have fun doing it too! It's really not a big project - I added a similar forum to a web site for a friend in a weekend, writing it in Perl in scratch. I am not a web guy and did not know any Perl but it was pretty easy to pick up. Go for it and have fun. Your question is kind of like 'where can I find a string reversal function'. The answer is always that its a simple thing and the fastest route is to write it yourself if it is taking you more than a few hours to find one you like. |
| Sat 22 Mar | Li-fan Chen | I have hear people beg for this discussion forum software enough times! Gonna go write one over the weekend and sell it. -- David |
| Sat 22 Mar | Dave B. | I have written an ASP page using VBScript that is similar to this forum, except it does'nt support e-mail. (I'm using WinXP and CDONTS does'nt work on XP.) The asp page and the MS-Access database can be downloaded at http://dbehnke.users5.50megs.com (Note: That link has banner ads. Sorry it's a free site.) (Note: I used Jet 4.0, Visual Interdev, MS-Access 2000, WinXP Pro, IIS 5.1) Anyway download the ssw.zip file, unzip it, ad the files to a Visual Interdev Project, update the connection string with the correct database path and away you go. Modify it to your hearts content. It would'nt be hard to add e-mail support and/or upgrade to SQL Server. |
| Sat 22 Mar | Jimmy Chonga | Dave B: Take a look at CDOSYS, also called CDO for Windows 2000, which is the email interface that works in XP, but is backwards compatible to 2000 as well. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cdosys/html/_cdosys_about_cdo_for_windows_2000.asp |
| Sat 22 Mar | BJ | Dave B.: Nice work. Now I know how the red highlighting was done. Thanks for sharing your knowledge (and code). |
| Sat 22 Mar | Dave B. | There is an extra space in the address above try: - http://dbehnke.users5.50megs.com - Hope that helps. Jimmy, Thanks for the link. I'll look into it. BJ, Thanks for the compliment. I'm glad the source helped you out. |
| Sat 22 Mar | Mark Sanders | my final post probably - at least re. this: alex - yes, that'll do the trick beautifully; thanks very much-like the forum + home pages' b/w-colour toggle - subtle; chuck - i was on the verge of (almost) agreeing 'til I saw alex's post; btw, kids are 8 and not quite 3. pedagogic suggestions? for now thanks bye peace |
| Sun 23 Mar | Andrew Burton | http://www.darkbeast.com/files/wccsbbs.zip http://www.darkbeast.com/files/wccsbbs.pl.txt Straight Perl implementation of a slightly cloned version of Joel's board. |
| Sun 23 Mar | | After several weeks thought, I'm so impressed by j's arguments concerning the (lack of) features of the JoS discussion Yeah, He could sell ice to the eskimos. |
| Sun 23 Mar | Dave B. | To those who have emailed me or are interested, I have 'cleaned up' the source. The site is also displayed in a cleaner format. You can download the ASP page, the database and the style sheet at the link above. It is VBScript - not Perl or PHP. As I said earlier, modify it to suit your needs, it should'nt be that difficult. |
| Hungarian Notation | Fri 21 Mar | Benji Smith |
| After reading some of the topics below about code commenting and documentation, I started to wonder if anybody uses hungarian notation anymore. I, personally, have always hated HN. I think it makes code extremely difficult to read. I much prefer to just camel-case my object names (i.e., thisIsTheNameOfAnObject). But I know there are some people who prefer to tack little type identifiers onto their object names. Ive especially seen alot of things that look like ptrMyPointer, which Im also not crazy about. This is akin, in my book, to calling something strTableName or intCounter. Object types, as far as Im concerned, dont belong in the identifiers of objects. |
| Fri 21 Mar | Chris Tavares | Hungarian is dying. Thankfully. The Microsoft .NET naming conventions explictly say NOT to use hungarian. It might have made sense originally, but it was never used correctly, and required too much of a maintenance burden. Good riddance. |
| Fri 21 Mar | Chris Tavares | That being said, I do have one situation where I use hungarian. In C++, particularly in COM code, I'll often times have the same logical data stored in different data types. Strings are the big offenders here. So I'll often have variables bstrName, lpszName, and csName, for 'Name as a BSTR', 'Name in zero terminated string' or 'Name in a CString'. |
| Fri 21 Mar | Joel Spolsky | I think people who think Hungarian makes code 'hard to read' have never learned to read Hungarian notation. Heck, I think Greek is hard to read. But if you actually take the time to learn it, it makes code that much MORE readable. You know so much more about what a variable is by looking at it. I still use hungarian -- in C code it's essential, in C++ code it's helpful, we even have a standardized hungarian notation for SQL here at Fog Creek and it's extremely helpful. |
| Fri 21 Mar | Prakash S | still stick with Hungarian, since it works. |
| Fri 21 Mar | Keith Weiner | The problem with HN is that the type of a variable can change as the system evolves. wParam is a case in point. It isn't a WORD any more, is it? False information is worse than no information... |
| Fri 21 Mar | Benji Smith | Joel and others, What is it about C code that makes HN especially helpful in making the code more readable? Would code in Java or VB or C# (or any other language, for that matter) benefit from an HN-style coding convention? Or is there something peculiar about C/C++ that makes it more essential for you to have type information in your identifiers? Also, why is it that HN is falling our of fashion so quickly if it helps so much? (I really am curious.) |
| Fri 21 Mar | Nick B. | I've grown to like hungarian notation, if only because associating variable type and scope information in a variable name makes code easier to read and understand. Furthermore, I've never found changing variable names along with variable types time consuming at all (just search and replace). I suppose it could be irritating if you have code where a global var whose name collides with that of class member or local vars, or some similar situation. But that never really happens if you're using hungarian properly in the first place. I've never really understood why everyone hates hungarian so much or why they think it actually makes code harder to read. Sounds like more of a cosmetic preference to me. I do concede it requires additional discipline on the part of programmers and there's nothing that enforces it besides programmer discipline ... perhaps that is good enough reason not to use it in some environments. However, my experience has been that programmers not familiar with first ask questions about it, and then adopt it. I suppose I'M SPREADING THE DISEASE. BWAHAHAHA!!! |
| Fri 21 Mar | Steven C. | I'd actually go one step farther than Nick B. did -- if you're changing your variable types, especially between similar types (different string implementations, for instance, or the like), I find it incredibly useful to also change the name of the variable. Thus, I have to go look at every instance where it is used and make sure that things are really doing what I want. Of course, using search and replace obviates this, so YMMV. |
| Fri 21 Mar | optimistic coder | Everything gets called oWhatever or objWhatever in the end. |
| Fri 21 Mar | Nick B. | Yeah, but at least you know its an object of type class CWhatever. Or do you ? ;) |
| Fri 21 Mar | Nat Ersoz | 99% of the Linux kernel is written in straight C (with a small amount of assembler for supporting the dozen or so CPU platforms it runs on). It is some of the most readable code I've ever come across, and there are no Hungarian notations floating around. I loathe HN, and am glad to see it end of life. Not that I even encounter it in my daily work, but just to know that it will be out of its misery soon - that's a good thing. Deconstructing HN: 'lpsz' LONG: yes, even as late as 1998, MSFT was still playing with LONG. Very quaint. POINT to STRING: Dammit, its pointer to char. ZERO terminated string. Aren't C 'strings' by default zero terminated? Why don't we add 'r' in there while we're at it - so we know it can be 'randomly accessed'. And 'x', EVERYTHING needs an X these days. Let's add x to lpszr to formally bring it into the new Millenium. Hmmm, what has 'X'? How about xenophobic? There ya go, the X for xenophobic (sort of gives you that 'closed source' warm fuzzy feeling). xlpszrMyString[] = 'Hello World'; Oh the gems... Forget HN, how 'bout these jewels: typedef void* LPVOID; // FIXME: WTF? What is so difficult about void*? Would it be so bad to not have to invoke the tagger just to know that you're dealing with a built in type? Kill it. Unplug the life support and say a prayer. |
| Fri 21 Mar | Nat Ersoz | Geeze, its as bad as 'comment maturbation'. (Likely the best term I've come across lately, thanks!) |
| Fri 21 Mar | optimistic coder | Quite Nick. Heaven forbid we need two instances of the same class, that'd just get confusing. |
| Fri 21 Mar | flamebait sr. | Well, there are some reasonable things like denoting member variables (like adding my or m_ or something like that to the front) and other 'special case' situations where namespace collisions are inconvenient and obnoxious. The LPVOID thing is somebody trying to turn C into their own language. Sheesh. |
| Fri 21 Mar | Matthew Lock | One of the great design points of perl is that all variables start with a symbol, a kind of hungarian notation I suppose. Scalars start with $mystring, arrays @myarray hashes: %myhash, which makes reading code really easy once you're used to it. |
| Fri 21 Mar | mb | I've grown to like 'simplified' hungarian. So in a manged envrironment, sFoo means string. With plain C (or C++) szFoo means a zero-terminated string; wzFoo means a Unicode string. But long or far, no. (Though I've seen win16 code where wz didn't mean unicode because it was #defined re-used code from people who really meant OLESTR). Once you've simplified something to its essence (i or c for an int or counter), you certainly will have to do more than just search/replace if you change the type of a variable. And if it's just something dumb like a size (short/long), the simplified name doesn't change. |
| Fri 21 Mar | Nat Ersoz | Basically, if you make good design choices, like scoping variables appropriately, there is no need for HN. Allofasudden, I'm doing some math... y = alpha * sin( omega * t ); becomes: dY = dAlpha * sin( dOmega *dT ); Well, of course, d means double - unless you're into math, then d connotes delta - and it reads a whole new way. And then there is the sin() function, it reutrns double - so make it dSin(). Well, what the hell, it takes double too. Make it dSind(). And back to strings, familiar old strcat() now comes out lpszStrcat() - yet why stop there, it takes 2 strings, the second one const: lpszStrcatlpszlpcsz(); Geeze, looks like the Bronx cheer. Whipe off the laptop screen when you're done with that, wouldja? And don't even try for those Windows GUI functions that take about 17 parameters... Too much fun. |
| Sat 22 Mar | Justin | Does anyone use both? By this, I mean do you differentiate between private variables etc(1) and public, e.g. parameter names? Some places I've worked use HN for *everything*; their declarations look something like: Dim lobjMyObject as company_objComponent.clsClassName The also like branding things, which makes things even more confusing, especially if its done to every single publicly accessible object/name. (This is not *my* idea, btw, and I also hate prefixing local scope variables - the first 'L' in lobjMy...). Is there a 'sensible usage guide' anywhere - preferably a heavy one that I can use for other purposes? (1) Etc means function names to indicate the return type, constants ( I have seen the hateful mstrCONSTANT_NAME used by people) |
| Sat 22 Mar | Stephen Jones | As a humble beginner VBA coder may I say I find it very useful to distinguish between control names: cboFirstName as opposed to lblFirstName Same goes for remembering whats a string, what's an integer and what's a boolean. |
| Sat 22 Mar | Sam Gray | Speaking as someone who's still stuck, for the most part, back in VB6, I like HN. I've started learning C# and there's a lot to like about it, but it seems utterly ridiculous to call a control okButton, cancelButton or calculateTheSubtotalForMyUnderpantsPurchaseButton (hey, if you guys can come up with ridiculous examples of HN abuse...). If you're going to tack 'Button' on the back of every button and 'Combo' on the back of every combo box, why not use a Hungarian 'cmd' wart on the beginning and take advantage of Intellisense to speed up your typing ever so slightly? That being said, I have started moving away from using HN in parameter declarations. The API calls don't include them, so putting them in my own functions gets a bit distracting. |
| Sat 22 Mar | Tom Payne | Good short article: http://ootips.org/hungarian-notation.html Key bad points: 1) Often wrong or misleading (e.g. wParam in Win32). 2) Ambiguous (is b a boolean or a byte, is f a flag or a float?). 3) No standard (lpsz vs. lpstr vs. lpcstr vs. lpc vs. psz etc., dw vs. ul, vs n). 4) Effort to maintain. 5) Does not take account of C's automatic promotion of types. 6) Prevents your code from being portable between 16/32/64 bit architectures. 7) Offers no automated type checking beyond what the compiler already does. 8) Lots of finger typing. 9) Enourages unnescessarily verbose variable names. 10) Conflicts with OOP principles. Longer discussion on kuro5hin.org: http://www.kuro5hin.org/story/2002/4/12/153445/601 |
| Sat 22 Mar | David Roper | Nat & Tom: I agree whol heartedly. All this goes to show that tracking object types is something that we should leave to the compiler. For my pennyworth, just name things clearly, concisely and consistently. |
| Sat 22 Mar | Justin | I would agree, Sam, however most VB etc programmers would *prefix* the control name with a mnemonic denoting the type, e.g. btnOK and btnCancel. Of course, even with HN, code can be hard to read. The following sample (apologies for text wrapping) illustrates, in my opinion, the need for coherent, readable variable names. Yes, I can read it...but the coder really isn't making it easy for me. The argument for mnemonics is that they require less effort to type and are less prone to spelling errors. The arguments were made before 'option explicit' and 'auto complete' were features that were commonly available. In fact, I'm not sure even if they are available. I primarily use VB, Interdev and lately .Net; I have no idea if these functions are available in other development environments 1 #include “sy.h” 2 extern int *rgwDic; 3 extern int bsyMac; 4 struct SY *PsySz(char sz[]) 6 { 7 char *pch; 8 int cch; 9 struct SY *psy, *PsyCreate(); 10 int *pbsy; 11 int cwSz; 12 unsigned wHash=0; 13 pch=sz; 14 while (*pch!=0 15 wHash=(wHash<>11+*pch++; 16 cch=pch-sz; 17 pbsy=&rgbsyHash[(wHash&077777)%cwHash]; 18 for (; *pbsy!=0; pbsy = &psy->bsyNext) 19 { 20 char *szSy; 21 szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz; 22 pch=sz; 23 while (*pch==*szSy++) 24 { 25 if (*pch++==0) 26 return (psy); 27 } 28 } 29 cwSz=0; 30 if (cch>=2) 31 cwSz=(cch-2/sizeof(int)+1; 32 *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic; 33 Zero((int *)psy,cwSY); 34 bltbyte(sz, psy->sz, cch+1); 35 return(psy); 36 } Sample extracted from MSDN copy of Charles Simonyi's 'explication of the Hungarian notation identifier naming convention'. |
| Sat 22 Mar | Justin | Sorry, that should have read 'the argument for short variable names' - mnemonics are supposed to be short. Doh. |
| Sat 22 Mar | Thomas Eyde | I started my programming career in VB3. The best practice back then was 3-letter-prefixed HN. Later in the VB5 or beginning VB6 era, bought a book using a single-letter-prefixed HN. I liked that better, but remember a rather heated discussion with my coworker on which HN was best. The discussion ended up with him using 3-HN, me using 1-HN. Then I became familiar with Agile Programming and read all the good opinions on why HN is bad, and why energy should be used on selecting better name in the first place. It's years since I used HN, and I have learned it's all about habit. I have also learned to apprechiate code which express intention. So I think HN is about implementation. Ditching HN freed my mind to concentrate more on solution, which I think is better. Many of my classes starts out as primitive datatypes, mostly strings. Sometimes they deserve to be strings, but other times they evolve with behaviour or more complex data representations. |
| Sat 22 Mar | rwh | 'One of the great design points of perl is that all variables start with a symbol, a kind of hungarian notation I suppose.' 'Scalars start with $mystring, arrays @myarray hashes: %myhash, which makes reading code really easy once you're used to it.' No, all variables start with a symbol that indicate HOW YOU WANT TO USE THE VARIABLE. They're typecasts. Every Perl statement is littered with typecasts. You have to typecast both sides of a simple assignment like '$foo = $bar'. And this casting is useless in distinguishing simple scalars like '3' from references to 'real' data structures (of arbitrary complexity). The '$' symbol LIES about what the variable holds. |
| Sat 22 Mar | runtime | I used to use hard-core HN, but now I mostly just use the following prefixes: p = pointer n = count/number of sz = null-terminated char string wsz = null-terminated WCHAR string is = boolean |
| Sat 22 Mar | Julian | For Hungarian notation to work, there must an explicit company standard. Then it only takes an hour to read the standards document, and it's always clear what everything means. Overall, Hungarian notiation added value when I started programming C in 1995 without an IDE, but it isn't worthwhile writing Java today with Eclipse. Here are some reasons for the change: 1) An IDE instantly tells you the type of any variable, so you don't need to search for the variable declaration to get that information. 2) Better programming practices, such as short functions and clear variable names, make Hungarian less necessary. Those practicies are more widespread now than they were before. 3) In C, not knowing a variable type can easily shoot you in the foot, such as when you call scanf. In Java, the compiler detects almost all type errors. 4) Other Java coders bitch endlessly when they encounter Hungarian notation. A few months ago, my employer implemented a no-Hungarian policy. It only took me a few days to adjust, once I wrote the logic to convert the existing code. |
| Sun 23 Mar | Chui Tey | Any explicit convention (such as Hungarian) is very helpful when coding in a team, and for new developers to get acquianted with a large code base. In OO, a notation which identifies the scope of a variable helps clear up what a piece of code is doing, instead of having to navigate back and forth through the source to look at where it was declared. In a dynamically typed language such as Python, variables begining with two underscores are automatically made private variables. For individual developers, the benefits are still there. I'm not the type who remember everything I have coded months after, and the improved readability helps. For competent programmers, learning a notation is not much compared to picking a language. Hungarian notation throws off people a bit if they are learning C at the same time. |
| Sun 23 Mar | Nick | From Nat: 'ZERO terminated string. Aren't C 'strings' by default zero terminated?' I'm with you I that one. I never could figure it out. Is there such a thing as a non-zero terminated string in C? |
| Headphones. | Fri 21 Mar | Prakash S |
| Which headphones do you guys use while working, if use them at all? I am planning to buy one, ideally if price was not as issue I would buy the BOSE QuietComfort http://www.bose.com/products/headphones/ Thanks, |
| Fri 21 Mar | Andy | At work Sennheiser HD-580s and at home Sennheiser HD-600s. You owe it to yourself to check out Sennheisers if you're looking for nice headphones. |
| Fri 21 Mar | anon | I can't listen to music while I'm working. For some reason, it seems to pull me out of the zone, so it's hard for me to focus. Weird, eh? |
| Fri 21 Mar | Brad (dotnetguy.techieswithcats.com) | +1 for Sennheiser. I have a pair of HD-570s, but the 600s are just outstanding (and out of the price range I wanted to spend). |
| Fri 21 Mar | Mitch & Murray (from downtown) | Sennheiser HD-600 driven by a modified Musical Fidelity X-CANS tube headphone amp. Source is a Sony CA70ES changer. The new Sennheiser PX-100 cans are outstanding for $40 and can be driven nicely with typical consumer devices (portable CD players, minidiscs, etc) as well as a decent PC sound card. Worth a look if you are on a budget. Hell, worth a look just to have a spare set laying around. www.headphone.com is the place to check out all known headphones, amps, cables, and associated gizmos. Not the cheapest, but a selection second to none. |
| Fri 21 Mar | Prakash S | Cool website, thanks. After the enlightenment, I am looking at the 'In Ear Canal' types, Etymotic: http://www.etymotic.com/product_list/product_list_product.asp?audience_category_id=1&product_type_id=2&product_number=ER-6 Shure: http://www.shure.com/earphones/eseries_e2c.asp what do you guys think? I used a Sennheiser (don't know the model - i think my frined paid something around 80-90 for it) - didn't like the fit (sine I wear spectacles sometimes), after using it for around an hour - ear started to hurt...., good sound quality though. |
| Fri 21 Mar | Prakash S | Spoke to one of the guys at HeadPhone.com - for starters it is an actual person who picks up the phone (no machine - wooHoo), he gave me excellent advice on both. According to him: The Shure is good if you listen to songs with a lot of bass (modren rock kind of stuff), while the Etymotic is good for high definition (classical). The Etymotic is slightly more comfortable, but expensive by $30. |
| Fri 21 Mar | Tj | I don't see why Sennheiser HD570-600s would lead to ear fatigue; the things push against your skull instead of the ear. It's possible for people to hear when you're using the Sennheisers, but only in silent rooms. It won't be audible in most computer rooms. I also use $12 Sony earbuds for portability; they're not bad. Probably bad for ear bacteria levels though. And you really don't want to let people use them. |
| Fri 21 Mar | Jonathan | I haven't tried any of the Sennheisers, but I do own a pair of Grado SR60s. For the price you pay (I got them for 60-70 at qaudio.com), they sound _excellent_. Note that if you're using them at work, they leak sound so these may not work for you if you like your music loud and everybody else in the office works in dead silence. |
| Fri 21 Mar | TK | Caution from a tinnitus sufferer: Over an extended headphone listening session folks tend to turn up the volume. The same is true if you are masking 'outside' noise. Headphones can be very damaging to your hearing over time. What is tinnitus like? Imagine how your ears ring after a loud rock concert. In my case, I woke up one day with that ringing in my ears and the ringing has never stoped, nor will it ever stop. It only gets worse. |
| Fri 21 Mar | Prakash S | I have heard about the tinnitus thing being mentioned from time to time. |
| Fri 21 Mar | anonymous | I use these, because music distracts me if I'm not concentrating, and I don't hear it if I am: http://www.walgreens.com/store/product.jhtml?PRODID=362489&CATID=100217 Oh wait, that doesn't answer your question. |
| Fri 21 Mar | choppy | the grado SR60s sound the best out of any headphone under $200. however like someone else said, they are not closed, so they leak sound. i have had the entymotics. they are great for isolation. however there is one really annoying thing, which makes me not recommend them (aside from the fact that they are super expensive): they are TOO sensitive and isolating. thus...if you ever move, and jostle the cord...you can hear the 'woosh' sound of the cord brushing against your shirt...amplified really loud. it becomes very distracting if you fidget around a lot, like i do. they are also VERY isolating...you can't really hear ANYTHING outside of the phones, which ends up being kind of weird. |
| Fri 21 Mar | optimistic coder | I know what you mean Choppy, but that's FUN when you get used to it. Feed the wire up inside your shirt and it won't make so much noise. Quiet enough for walking around, although I'll probably get run over soon... |
| Fri 21 Mar | Mitch & Murray (from downtown) | For those of you who are interested in, but do not yet own an 'in ear canal' phone like the Etymotic models I _highly_ recommend the Sony MDR-EX70LP for $50. I have used these extensively in both a (somewhat noisy) college library driven off my laptop's headphone OUT and on numerous (extremely noisy) trans-atlantic marathon flights driven off a Sony Minidisc player. Very good sounds and outstanding isolation for the price. Worth a look if you can find them, Sony sells them directly from their website. For those of you that haven't taken a look at the Minidisc format for portable tunes, these have always worked well for me. I am using the MZ-R90 which features digital and analog inputs which means it makes a perfect highly-portable live recording rig. |
| Fri 21 Mar | Mitch & Murray (from downtown) | Should have also mentioned that the Grados, most any Grados, are excellent as well. Very high on the 'bang for buck' scale, and much easier to drive than the HD-600 Sennheisers. |
| Fri 21 Mar | choppy | actually i forgot to mention the sony MDR ex70LPs. I bought a set when i was in japan and they were a godsend on the flight back. i prefer them to the etymotics because they don't have the 'cord woosh' problem I described above. the only thing i don't like about the sonys is that the cord seems to be about 30 feet long, which leaves a lot of extra slack to deal with when plugged into my ipod. i think there is a special 'short cord' version of the sonys, originally designed for use with MD player + remote. the grados also have a weird way-too-long cord, but if you want to get DIY, there are a number of sites that describe how to do cord mods. |
| Fri 21 Mar | Prakash S | I am not too crazy about the whoosh sounds, thanks for letting me know. - this rules out the Checking the sony out, the specs as the Shure.. for $50 lesser, ....unfortunately it says that it is currently unavailable. thanks again guys. |
| Sat 22 Mar | Brad (dotnetguy.techieswithcats.com) | Funny thing, I just pulled out a recent copy of Stereophile (April 2003) and looked through their list of recommended headphones. Of the 5 headphones on the list, 2 are Sennheister (model HD 600, Class A, $449; model HD 580, Class B, $260) and 2 are Grado (model SR125, Class B, $150; model SR60, Class C, $69). The Sennheiser HD 600 are considered by their staff to be the best dynamic headphones ever (although they did recommend driving them with a $3,333 tube headphone amp *snicker*). A perhaps more reasonable choice is their Class B rated Musical Fidelity X-Can V2 tube amplifier; I've heard the original X-Can, and it was a superb headphone amp, but definitely out of reach of the casual listener at $300. The only other pair of headphones on the list were the $4000 electrostatic Stax Omega SR-007, which requires a ~ $3000 amplifier to drive. Yeah, sure. :) |
| Sat 22 Mar | Brad (dotnetguy.techieswithcats.com) | Oh, a quick bit about the Stereophile ratings. Class A is the best in class, irregardless of issues like price. Class B is the next best thing, and generally still considered expensive. Class C is somewhat lower quality than A or B, but represents 'affordable high quality'. |
| Sun 23 Mar | Steven E. Harris | I use Sennheiser HD 600s with an Antique Sound Lab MG Head DT headphone amplifier. http://www.divertech.com/mgheaddt.html The Musical Fidelity X-CANS V2 amplifiers also come highly recommended, but were impossible to purchase about a year ago when I finally went for the MG Head DT. The sound is spectacular, with no fatigue, and they don't seem to disturb anyone around the listener. I also purchased a pair of the Etymotic ER-6 Isolator headphones for future use with a laptop or other portable listening device. http://www.etymotic.com/musicians/er6more.html As I have less experience using the Etymotics, I can't comment much on their faults, other than perhaps the strange prerequisite of wetting them before putting them in. 'Excuse me, did I just see you sucking on those headphones before you stuck them in your ears?' |
| Sun 23 Mar | Prakash S | I went ahead and purchased the Shure , the rest sound too expensive :-) |
| Sun 23 Mar | Brad (dotnetguy.techieswithcats.com) | The Sennheiser HD-570s I bought from Best Buy were less than $100 (I think around $80, but I'm not sure). |
| Why do Programmers Hate Documenting? | Fri 21 Mar | David Clayworth |
| Its a bit of a generalization but I think there is truth in it. Many programmers, even experienced ones, really dont like documentation. Most of us do it, because we know we have to, but if were under pressure its the first thing to go. Ive reviewed code from experienced programmers with hardly any comments at all, yet weve also all tried to maintain code and cursed the idiot author who didnt add enough comments. So why do we find comment writing such a pain? Its even worse when it comes to writing user documentation. Most of us would rather be thrown in the scorpion pit than be asked to write a manual, despite the fact that this would be the best way of showing off the brilliance of the program we wrote to a wider audience. I have a theory, and that is that its the Introvert in the Myers-Briggs type that most programmers seem to belong to (see the Orphans Wanted article in another thread). Programmers are interested in ideas, and once the ideas are fixed concretely we lose interest in their communication. But I could be wrong. |
| Fri 21 Mar | Steven C. | I'd tend to agree with you David. I think most programmers have an inherent dislike for staying on the same 'problem' after its been fixed (i.e., commenting the code they just wrote -- its usually incredibly obvious at that moment what the code does, so why comment?). I find that I usually comment at my best when I comment before or during coding, since at that stage I'm still figuring out the solution etc. If I wait until afterwards, my results tend to be slapdash and haphazard. Thoughts? |
| Fri 21 Mar | Tj | Usually people talk about their code when they're proud of it. Maybe these people aren't particularly interested in their work, and it doesn't strike them to defend or promote the code. I know that's an oddball theory, but maybe there's truth to it. |
| Fri 21 Mar | Jordan Lampe | When I am writing code, it all is blazingly obvious to me right now. In the future, someone is going to find some part of it confusing. The problem is that I can't predict /which/ bit is going to be confusing. So which bit do I comment? If I comment every last line, then the comments get tedious, as mentioned in other threads. |
| Fri 21 Mar | choppy | There is no profound reason...the answer is pretty simple: most programmers are very lazy. Writing comments is just more work. Writing a user manual is a LOT of extra work. I have to completely disagree with this statement: --- (re:manual)...despite the fact that this would be the best way of showing off the brilliance of the program we wrote to a wider audience. --- I don't know anyone who reads user manuals except as a last resort , or to figure out some obscure , non-obvious feature. The best way to show off the brilliance of the program you wrote, is to actually write a brilliant program... |
| Fri 21 Mar | Artist | Hi I tend to agree with David. We consider ourself (Programmers) as an intelligent being and want to create a good new and unique things which takes us from one steo to another better steps towards our goal. Now if documenting is driving your salary you would do that..,but it's not. If somehow they make documentation mandatory, it would take us forward towards the goal and hence will become and inherent part of what we do. Goal of the programmer in terms of intelligence is to increase the programming skills. Documentation if proven to increase the programming skill we would have done that already. |
| Fri 21 Mar | Reginald Braithwaite-Lee | 'Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits.' --Alan Perlis I believe that the problem with documentation is that the people who are supposed to write it derive no benefit from it, and the people who insist on it don't have to write it. Compare 'documentation' to strong and static typing. Many programmers these days don't have a problem declaring variable types, writing assertions, or even programming by contract: they perceive that there's a benefit inherent in getting the compiler to help them write better code. In my experience, programmers can and do become zealous about those portions of 'documentation' that have a demonstrable and immediate benefit to the project, such as documenting acceptance tests. -- http://www.braithwaite-lee.com/opinions/design-by-contract.html |
| Fri 21 Mar | One-Armed Bandit | 'Programmers are interested in ideas, and once the ideas are fixed concretely we lose interest in their communication' I think you really hit on something there. Sometimes, once I figure out how a piece of code should work I don't feel like even typing the code in. The challenge is gone. The same goes doubly for doc. There's a strong feeling of, 'I've solved this problem - I shouldn't have to still be working on it.' |
| Fri 21 Mar | Canuck | Documentation is *boring*. Writing help files is even more mind numbing. That's my major beef. I will say this though, inherting a system this well documented, especially if the domain knowledge is complex, is awesome! It makes life sooo much easier. |
| Fri 21 Mar | Brad (dotnetguy.techieswithcats.com) | How about considering the fact that people write code that REQUIRES a copious amount of comments to be, in itself, a broken process? Believe it or not, I write my 'comments' in the form of understandable code. Variable names are good, method names are good, confusion is refactored away. |
| Fri 21 Mar | Hardware Guy | I've repeatedly seen the claim that code can be written in such a way as to make comments unnecessary. But in almost 30 years, I've never seen such code. And that includes coding in hardware description languages, such as VHDL and Verilog. Does such a coding style actually work, or is it just a rationalization for bagging comments? Can anyone point to some examples of code that does something *non-trivial*, but which manages to explain itself to the uninitiated (say, someone who's taken responsibility for the code) without benefit of comments? |
| Fri 21 Mar | apw | how often (assuming you are a programmer), do you actually read the documentation of an application you just bought? not often, I would assume. you proabably just tear open the package, click through the lengthy EULA (anyone read that?), install, and play. programmers are lazy, who needs documentation if no on is going to read it? we reuse code cause the thrill is gone once the problem is solved, why? so we can get it over with and have a beer... those who do document either do it because thier boss is looking over thier shoulder or they are just bad coders and cover it up by looking busy and productive documenting thier crappy code. |
| Fri 21 Mar | Benji Smith | Asking why programmers don't write good documentation is like asking why technical writers don't write good code. Documentation and programming are two entirely different skillsets (although there are some people with skills in both areas). |
| Fri 21 Mar | Chris Blaise | I agree with choppy in that I'd rather work to make the application/function/etc easier for the user to use than to spend too much documenting it. The flip side is that if you start documenting it as a developer, you can wear a bit of both developer and user hats. In many cases, I found that when I do this for either myself or others, I 'find' better ways to code/display the feature. For me it happens when I'm trying to explain something complicated, I get frusted with the right way to explain it to 'my grandmother' (my lowest common denominator target audience) and a way to simplify the interface will reveal itself to me. Sometimes it's as trivial as showing/not showing data depending on a certain state (ie.,don't show these fields if this radio button is selected). Other times it can be much bigger, requiring a hefty bit of reworking but resulting in a much more intuitive interface. |
| Fri 21 Mar | | the code is the documentation |
| Fri 21 Mar | Thomas | Programming is a largely a creative, problem-solving effort. Documenting is largely a teaching and communication effort. We like programming because we like creating solutions to problems. (Some of us like finding the solution so much that once we've figured out the solution we're not interested in implementing it!) We don't like documenting because we feel like we're not really solving a problem, we're just describing something. Also, I think a lot of programmers view documentation as largely being a waste of time and effort. When you are writing the equivalent of, 'To create a new document click 'File', then 'New',' the thought going through your head is what a colossal waste of your time this is. After all, anyone can figure out how to do simple things, right? I don't believe the claim that programmers are lazy. I do believe that programmers dislike doing things that are not programming. Like writing documentation, working on schedules, defect tracking. And we'll procrastinate on those things, or do the minimal effort necessary. That's an ego thing. -Thomas |
| Fri 21 Mar | Philo | 'I've repeatedly seen the claim that code can be written in such a way as to make comments unnecessary. But in almost 30 years, I've never seen such code' I think this depends on what you're looking for. I think when people make this assertion, what they're saying is 'if you write good code, then it won't be too hard to figure out'. I suspect what you are looking for is something that tells you what the code is doing before you even get into it. There's also the issue that code is understandable *in context* or to someone with a system-wide view, but yeah it may take some more work for the 'hit and run' debugger. The description from Unmanageable Code is 'they are viewing your code through a cardboard tube; they don't have time to understand the application' I think if you're trying to debug an app without getting into it and understanding the application then you're asking for trouble. Finally, an example of how well-written code can obviate commenting - in the spaghetti code days comments were essential in a ten-page module to indicate what's happening where. In procedural programming the procedure names should replace the section-level comments. Instead of //Now we fill the bill of materials display for the order id requested you have public void FillBillOfMaterials(int OrderID) Philo |
| Fri 21 Mar | Reginald Braithwaite-Lee | I'm with Choppy and Chris: One book I read said that every user manual is a list of design mistakes. One benefit of code and design reviews is that anything too complicated to explain to smart people is quickly discarded. Perhaps reviews are a form of disposable documentation? Since the benefit is in the explaining but not the explanation, a review offers the 'lowest barrier to entry' form of documentation... -- http://www.braithwaite-lee.com/opinions/clothes.txt |
| Fri 21 Mar | Stephen Jones | Programmers probably hate documenting for the same reason that teachers hate keeping record books, and computer users hate having to fiddle with their computer; they're in that particular line of work because that is what they like and not the other task . In my experience peoiple who know how to do things the best are not always those who can explain it the best. There's no greater block to explaining something than thinking its obvious, and for the better the programmer the more obvious many things are. It's why large companies have technical writers. The question of commenting code is slightly different; the thread lower down seems to have dealt fairly well with that. That is to say that code might document itself, but you still need comnents on the why, and on what is not there. |
| Fri 21 Mar | Nuff Said | 1. The code is not documentation 2. Good coders document. 3. If you don't document you are AUTOMATICALLY a bad coder. |
| Fri 21 Mar | Philo | 'Nuff said' - you should look into this thing called 'supporting arguments.' They help. A lot. Think of them as comments for your debate.... Philo |
| Fri 21 Mar | Nuff Said | Read Code Complete |
| Fri 21 Mar | Steven C. | Going along with what Philo said -- the best description of what some programmers do is 'comprehension free coding'. That is...well pretty much what it sounds like: trying to fix a problem without understanding the code surrounding it. Now I don't want to discredit this entirely, since in large projects you have to do SOME amount of comprehension free coding -- i.e., assume that the rest of the system works in a good way, and fix the problem where you've found it. To be sure, too little comprehension will be a disaster -- but especially when you have people who are just joining a team working on a large software project, you have to expect that some of their work will of necessity lack the overall comprehension that someone working there much longer may have. Good comments, in general, allow less 'overall' understanding and thus faciliate this fixing style -- which is good, I think, especially if you want your software to be maintained by people far into the future. But mostly, I just like to make fun of people for doing 'comprehension free coding'. I just get a kick out of saying it. :P |
| Fri 21 Mar | Brad (dotnetguy.techieswithcats.com) | To add a different twist (and to reiterate something else someone said), comments come from the days of long, hefty code. Most methods do waaaaaay too much. Refactor. Methods should have no more than a handful of lines of code, and a single discrete tasks. Those 'big blocks of code' will then generally become calls to these smaller methods. We've all heard that any time you see duplicated code, you should pull the common code out into a method. I'll go farther to say that after you've done that, then go ahead and pull out small, discrete units of work (perhaps no more than 10 lines of code) and make those methods as well. At least in the environment in which I work, there is an effectively zero penalty for non-virtual method calls. All can be inlined in real-time by the JITter. And even if I pay a dozen nano-seconds for the method call, that's infinitely better as my servers get faster, compared to the minutes or hours I (or others) might have to spend understanding code. Our PCs continue to scale, but we developers do not. |
| Fri 21 Mar | Philo | Nuff Said - you're missing the point. Throwing out mantras and appealing to authority can be the equivalent of what some people are trying to suggest here - that doing a thing because 'this coding god said so' and 'that software bible insists' does not make one a good coder, and can in fact be a crutch that keeps one from being a good coder.
If the absolute truth is 'without comments one cannot write good code' then it's a subtle twist to 'comments can make one's code better' therein creating a reliance on comments to accomplish what can be done with editing, optimization, and refactoring.
A comparison of two 'does this appointment conflict with any existing appointments' routines:
[in pseudocode]
1)
CheckAppt(datetime start, datetime end)
//Check Appointment takes two datetime variables
//which are the start and end of the appointment
for i=start to end //let's step through the appt
//here we create a cursor of the days of each
// appointmetn that this person has
select cursor=days
from appointments
where personid=currentuser
//now we step through the cursor
//and compare each day to the current day
// in the appointment
for each day in days
if day=i then return 'Has Appointment'
//go to the next day
next i
End CheckAppt //end procedure
Or...
2)
CheckForConflictingAppointments(datetime startdate, datetime enddate)
Select 1 from appointment
where appointment.start |
| Fri 21 Mar | Master Ninja | I think the answer to why programmers hate documenting is obvious... writing documents is not nearly as much fun as writing code. I think more important questions are what documentation should programmers be writing and how do we motivate them to write it. I argue that code comments and functional specs are essential, and most of this content should be written before the code. If you can't describe what a function is supposed to do in English, then you don't have the knowledge to code it yet. I wish I knew how to motivate programmers to do this, as this is a problem I am facing in my group as a QE desperately in need of useful functional specs. |
| Fri 21 Mar | The Real PC | I hate writing comments even though I love to write. I have previously been a teacher and I really like explaining things to people. And I was a researcher and I loved writing research papers. Therefore, I should like writing documentation or comments, but I don't, I hate it. It might be, as someone said, because it's so hard to guess what parts of the code will be obvious to others and which will not. The managers where I work are programmers also and they hate writing comments, so they forget to make us do it, so it hardly ever gets done. |
| Fri 21 Mar | Dennis Atkins | I don't thing being introverted is related to it. My understanding is that most authors are introverts. Sitting down and writing documentation or a book is low on the list of interests for most extroverts. Introversion is a concept misunderstood by extroverts. It doesn't necessarily mean shy or unable to deal with people. It means one is comfortable with the company of one's thoughts. Introverts can do great at parties if they want to, contrary to popular prejudice. Many hollywood actors and actresses are introverts as well - INTP in particular is very well represented in Hollywood. |
| Fri 21 Mar | jb | I never understood the business about coders having such a hard time with comments. For me, commenting is part of my thought process. I write the comments to document the purpose of the next block of code before I actually hammer out the code. It helps me figure out what I want it to look like. Maybe I'm just the odd one out. |
| Fri 21 Mar | __Felix Somnia__ | As a user I have an emotional reaction whenever I read a manual/helpfile (online, or printed) and I find chunks of text such as: To set the color of page text and background: 1.Open the Edit menu and choose Preferences. 2.Open the Appearance group and click the Colors category. 3.Click a color button to change colors of text, background, unvisited links, or visited links. 4.(Optional) Click other checkboxes as desired: 'Use Windows colors' ('Use default colors' on OS/2, Mac OS, and UNIX) to restore the original colors. 'Underline links' to make links easier to find. The emotional reaction I feel comes with a thought attached to it: 'Why doesn't the moron who wrote this doesn't merely say 'On the menu bar, click on Edit| Preferences| Appearance| Color, and customize to your heart's content'--instead of making me read grating lonnng sentences to say something stupidly simple.' To be safe with complete L-users (L = learning), a hyperlink on 'click on' would suffice to explain there the notation 'click on xxxx| yyyy| zzzz|.' I can only imagine the emotions and thoughts that would invade me if I had to perfunctorily pipe 'good idea' to a manager that would arrogantly require me to write a manual as quoted above. Quite likely my private thoughts would be 'what an unbelievable cretin!' And writing such manual would be a bitter transaction for my livelihood. As a further observation, I find it extremely annoying and stupid to find entries in a manual that merely restate in other words what the evident meaning of a label of a widget in a GUI is, such as 'to restore the original colors' in explaining the pushbutton labeled 'Use Windows colors.' Isn't it easier to 'write what you mean' for a label, thus obviating an explanation in the manual? *sigh* |
| Fri 21 Mar | bryan | The problem with this kind of argument is that there's always enough strawmen to feed a large herd of cattle. If all you do is write code which is simple enough to be self documenting, then you should be fired and replaced with a college intern. In particular, comments should be used to inform the reader of things like pre- and post-conditions for methods, the intended use of variables, and anything else which might be non-obvious to someone other than the author (including the author a year from now). For example, Philo, in your conflicting appointments method, you appear to be making the assumption that the dates you have are in the same timezone as the dates stored in the database. For a more complex method, there are often questions like 'is null a legal argument here? what meaning would it convey? Am I allowed to modify this data structure?' etc. Of course you shouldn't comment every line of code. In fact, for most methods you only need a single comment describing the intended use and parameters. But any real-world system will have plenty of cases where explanatory comments are helpful and greatly reduce the time spent maintaining the code, especially by reducing bugs introduced by the maintainers through misunderstanding. |
| Fri 21 Mar | Mike McNertney | Philo, your example is a poor example for saying that good code doesn't need comments, because those are extremely bad comments. I think everyone can agree that commenting on things that are obvious from language constructs or variable/method names is extraneous and should be left out (ie, the 'X function takes two parameters' or 'Start looping over X'). However that is just one class of comments. As for the idea that good code documents itself, to some extent I agree. Appropriate factoring and good method/variable naming goes a long way toward making the code readable without comments. But there is one thing that the code itself can not answer, and that is *why* it does something, or why it works the way it does. This sort of commentary on design decisions made by the previous coder can be invaluable. Other things that should be well documented are invariants, and why they should hold/why they make sense. When possible, of course, these can be documented using code such as asserts The other problem with the 'good code documents itself' stance is that, if the code doesn't do what was intended (ie, there is a bug), there may be no way for a future developer to know what the code was *meant* to do. Sure your code is very clear about what it actually does, but I don't care about that when what it actually does is not the correct behavior. What something is *supposed* to do, and does incorrectly, can be very difficult to gleam unless there are comments discussing the intent of the programmer. |
| Fri 21 Mar | Bored Bystander | More generally, I think a lot of programmers hate to write prose. Why? I don't know. I think there's a certain culture of 'functional illiteracy' in some programming circles. It's almost a blue collar attitude of being a 'specialist' who is held exempt from communicating concepts or ideas. I've known programmers who were quite proud that they didn't understand basic text formatting in a word processor and that any memos they did always looked sh*tty. Sometimes I think that certain stereotypical pet phobias like this held by programmers cause the rest of the business world to roll their eyes at us as 'oh, THOSE losers'. My belief is that real professionals, by definition, WRITE. Professionals write: overviews, documentation, communication to peers, clients or management. And code comments. And I'm not talking about some featherbedded crap where you write a 15 lb treatise to document an action plan to have a meeting to plan a new internal application... That's *always* the feeble strawman excuse of those who have developed a phobic reaction to writing - a blather that they're not working in DOD or for the space shuttle or whatever, so they 'can't' be expected to write (poor babies). I just mean that someone being paid at the kind of salaries or rates prevailing in this industy really should be able, ONCE in a while, to write decent and understandable prose that informs others as needed. The idea of a person earning $80,000+ / year exempting themselves from communication with others is ridiculous. If someone in this field does not want to write and is even proud of not writing... then accept the consequences. One of which is that nobody in management will believe that you know what you're talking about. |
| Sat 22 Mar | choppy | per godwin's law, this thread has devolved from 'huh?' to 'what the fuck?' I'll do my part to make it even more pointless. my dad is a 'professional' obstetrician and makes about five times as much money as I do. i'm pretty certain he has not written any sort of prose since he was a college undergrad. he can't type and can barely write, so far as i can tell. i don' think anyone else in his field cares. marginally related, the last time I had to spend a significant amount of time writing documents was when i was working in an academic lab after graduating from undergrad. in fact, we never really accomplished anything in that lab,other than accumulating millions of taxpayer dollars through approved grant applications. since i've been a programmer in the 'real world' i've never had to write any sort of prose again, so i'm wondering where you pro-prose people actually work, and what you are talking about? I'm all for communication and yes, comments in the code are usually good, but writing a user manual or random word documents has usually been the job of a technical writer, not a programmer... |
| Sat 22 Mar | JC | I agree that the code itself is the best documentation. It's hard for beginners to wrap their heads around a large body of code, but if you want to know how a program works, reading the code is the best way. |
| Sat 22 Mar | 3 | There's a useful distinction that can be added to this discussion - the distinction between documenting the code, and writing user manuals. They're quite different things. Programmers generally don't want to write user manuals because they find them boring. Also, some can't write well, although by no means all. Generally, though, preparation of user manuals is best done by people who take a pride in that job. Regarding documentation for code, I personally favor the concept of literate programming - self-explaining code. There are occasions when this should be supplemented by notes. As someone above pointed out, 'comments' along the lines of: 'Takes two parameters ugh and oh and returns an int' have no place in quality work. |
| Sat 22 Mar | Thomas Eyde | So Philo provided a bad comments sample. Can someone provide a code sample with good comments, please? With good comments which can not be removed by writing the code a little different? |
| Sat 22 Mar | Thomas Eyde | My biggest problem with documentation are requirements like '...and it has to be documented!'. No indication on indended users or usage, nothing on what it should describe. Nothing. Too many customers require documentation, but have no clue on what should go into it. We are programmers, not magicians or mind-readers. And I don't like to waste my creative energy on guessing what the customer needs. I need the energy more elsewhere. |
| Sat 22 Mar | Jimmy Chonga | The conclusive reason why programmers hate documentation: It's wasteful, and most programmers hate anything that doesn't have a purpose. When I say wasteful I don't mean that it doesn't serve a purpose, but rather that without a strenuous committed, time sucking process the documentation can be more of a hindrance than a help as it diverges from the actual purpose and function of the code to being completely separate reality. Many help files and programs share very little in common. How do you solve this quandary? Through the use of tools and technologies that eliminate duplications of effort and divergence. For instance if you have a UML tool that comments your class diagrams, inserting them as comments in the code, and then another tool pulls the code comments and creates a nice WinHelp or HTMLHelp or PDF, then THAT is a process that coders can work with (and it'll yield much better results). Manually synchronizing things NEVER works over the long run. |
| Sat 22 Mar | Dennis Atkins | As far as commenting your code, the answer is yes you should do it. It will help when you come back to it later. And it will help others when they have to fix your bugs. I guess though the super geniuses whose code not only is bug free but prefectly meets current and future requirements are exempt from writing comments. I even put comments in one-off utility code that I know for a fact no one will ever look at again. The comments help me design and structure the code. Perhaps if you have separate design documents that specify everything in advance before you start coding you can skip the comments. Perhaps. But what I really want to talk about is the issue of user manuals. I write user manuals for all my applications. It's the very first thing that I write in fact. The user manual IS the requirements document in my style of writing. It works for me and I think it's a very good way of doing things. I suppose it takes all kinds but honestly you need to have somebody on your team that can generate plain talking easy to understand documentation that explains what the program does. maybe its a fancy pants pdf file with embedded this and that or maybe its a plain text man page. Whatever it is, it's real helpful to have a high level view of what you are doing to help stay on course. It's also great reading for customers and investors. Just last week, one new client said one of my manual's was one of the most intriguing and compelling things he had ever read. yeah, OK, I work some sales talk and rah rah in there as well. Why the hell not? It's all part of taking over our segment of the industry and leaving our slow and dimwitted competitors far in the dust behind. |
| Sat 22 Mar | Brad (dotnetguy.techieswithcats.com) | This thread and the comment thread have something in common: most of you are where I used to be. I used to be a stickler for commented code. Then I started learning and using refactoring. This was a real eye-opener, that you could make the code speak for itself instead of needing comments. I read 'any time you find yourself writing a comment, refactor instead'. It sounded like crap when I first heard it, but I started doing it anyway, and it's absolutely true. Someone posted that they wanted to see code that had perfect comments, that couldn't be divorced from the comments. Other than explaining the 'how' of an algorithm (like, say, describing how an encryption system works), I've yet to see this. I can't promise I have the time to do it, but if someone posts something they think qualifies, I'll give a shot at refactoring out the coments. |
| Sat 22 Mar | Hardware Guy | One more time: can anyone point to a *non-trivial* example of self-documenting code? If self-documenting code can be written, I'd like to try it myself. But I need something more than assurances that it's possible. |
| Sat 22 Mar | Dennis Atkins | Well, I don't know how old you are but likely I was refactoring since you were in diapers. And writing comments. Good ones. 'In our olfactory analogy, comments aren't a bad smell; indeed they are a sweet smell. the reason we mention comments here is that comments are often used as a deoderant. It's surprising how often you look at thickly commented code and notice that the comments are there because the code is bad.' -- Martin Fowler, Refactoring, page 87 See, it's not that comments are bad. Your argument suggests you believe that not writing comments is a mark of brilliance because some bad code has comments. This is like saying that because some meat is spoiled, everyone should be a vegetarian. |
| Sat 22 Mar | Dennis Atkins | Brad, I accept your challenge. Please refactor the following FFT code to make it easy to understand without comments: import java.awt.*; double[][] fft_1d( double[][] array ) { double u_r,u_i, w_r,w_i, t_r,t_i; int ln, nv2, k, l, le, le1, j, ip, i, n; n = array.length; ln = (int)( Math.log( (double)n )/Math.log(2) + 0.5 ); nv2 = n / 2; j = 1; for (i = 1; i < n; i++ ) { if (i < j) { t_r = array[i - 1][0]; t_i = array[i - 1][1]; array[i - 1][0] = array[j - 1][0]; array[i - 1][1] = array[j - 1][1]; array[j - 1][0] = t_r; array[j - 1][1] = t_i; } k = nv2; while (k < j) { j = j - k; k = k / 2; } j = j + k; } for (l = 1; l <= ln; l++) /* loops thru stages */ { le = (int)(Math.exp( (double)l * Math.log(2) ) + 0.5 ); le1 = le / 2; u_r = 1.0; u_i = 0.0; w_r = Math.cos( Math.PI / (double)le1 ); w_i = -Math.sin( Math.PI / (double)le1 ); for (j = 1; j <= le1; j++) /* loops thru 1/2 twiddle values per stage */ { for (i = j; i <= n; i += le) /* loops thru points per 1/2 twiddle */ { ip = i + le1; t_r = array[ip - 1][0] * u_r - u_i * array[ip - 1][1]; t_i = array[ip - 1][1] * u_r + u_i * array[ip - 1][0]; array[ip - 1][0] = array[i - 1][0] - t_r; array[ip - 1][1] = array[i - 1][1] - t_i; array[i - 1][0] = array[i - 1][0] + t_r; array[i - 1][1] = array[i - 1][1] + t_i; } t_r = u_r * w_r - w_i * u_i; u_i = w_r * u_i + w_i * u_r; u_r = t_r; } } return array; } /* end of FFT_1d */ |
| Sat 22 Mar | Bored Bystander | OK, I'll tone it down. Usually - management imperatives to document code are nonsensical and Dilbertish. I'll agree with that wholeheartedly. In fact, the directives to document are do thoughtless they're just plain stupid. 'Document it so we can get a trainee or clerk to understand it.' 'But it's really complex, how do you suggest I document it?' 'Make it clear, you techies are always making things too hard.' Etc. But telling someone 'the code will tell you everything you need to know' is often unfair, arbitary, and is a mask for laziness and unprofessionalism. I've found that only trivially small applications can be reliably understood by examining uncommented code. And when I rant about the need for written communication I'm also ranting (by implication) about tendencies among most geeks to not want to explain anything or break anything down into simpler concepts. Case in point: last year I did a turnkey contract that consisted of porting a 100,000+ line piece of avionics code into a training simulator. I could find *NOBODY* in that organization that would bother to give me the time of day to review the basic operational concepts of the existing software. Even SW people that knew couldn't begin to even describe lucidly what the general operation of the thing was. The point is, the inability of my 'peers' to support the work with even a token level of overview of major subsections of the thing did several negative things. It probably added 2-3 months to the task. It made me less sure of the architecture, to the extent that I had to guess why things worked. It reduced my productivity greatly because I had no idea how interconnected different parts of the whole were. My work was less effective overall because my self described world class peers were functionally illiterate about conveying ideas. In fact, most tech workplaces with legacy code tend to resemble frat house hazings. It's considered a badge of honor and necessary dues paying to be unproductive while you re-invent the wheel. You're swimming in mud trying to get some traction while a bunch of oafs that *know* willfully withhold information, your lifeblood. This unwillingness and lack of ability to communicate concepts to peers or management is woefully rife in this industry. |
| Sat 22 Mar | slacker II | I pretty much agree with the code being the best documentation. That said, there's good code and bad code. Bad code, like the example Dennis Atkins provided, is usually accompanied by bad comments, again, like the example Dennis Atkins provided. Good code usually doesn't need the comment. Caveat: I'm a fan of a 1-liner 'why' comment every now and then. |
| Sat 22 Mar | Brad (dotnetguy.techieswithcats.com) | Everybody can be upset with me if they read vitriol into what I wrote. I was just pointing out that the people who are militant commenters may be better served by learning to refactor than learning to write longer, more prosaic comments. I didn't claim to be brilliant or superior to anybody here (I don't know you, you don't know me; how could anybody make such a claim?). I was merely trying to point out to people that there's life after 'novellas of comments'. As for the FFT sample, we have two problems. First, I don't know what an FFT does (sorry, no math degree), and second, that code is not really commented in any significant way to help me figure it out. Besides which, I think I pointed out that I find there to be a general exception of comments to descibe the 'how' of algorithms. A purely mathematical algorithm -- which occurs pretty rarely in most code -- is probably going to require comments. *shrug* I'm not anti-comment. I'm pro-refactoring as a way of getting readable code. Comments are often covering up bad code (as a previous posted pointed out), but just as often, they're out of date and inappropriate. As for non-trivial code that has little commenting, I can't post the code I'm working on right now for obvious reasons. As of today, it's approximately 4550 files broken into 4 projects, covering about 3.5 megabytes of code (we haven't released v1 yet). Well over 98% (at a guess) of the comments there are XML comments for auto-generating help files. Look, everybody can be pissed off all they want. I'm not really interested in a pissing contest with anybody. My offer stands to attempt to refactor out the 'perfectly commented' bunch of code that somebody brings. I'm afraid the FFT example doesn't really work for me. |
| Sat 22 Mar | Hardware Guy | Brad - We're not pissed off with you (at least I'm not). We're just not convinced. It's not your job to prove that someone can write good, self-documenting code. Nor is it our job to believe you, at least not without a little proof. |
| Sat 22 Mar | Dennis Atkins | Ahem. Well that Java FFT routine I cut and pasted from the web is not all that optimized, but it's a pretty decent one pedagogically. It's laid out pretty clearly and concisely. The variable names seem clear to me since I have a general idea how the FFT works. I don't see any point in documenting it further, it looks good as it is. I think you are sort of getting my point and sort of not getting it. i'm really with you on the refactoring and agree with what I posted by Fowler -- a lot of comments might be a bad smell indicating the code could be refactored. but fowler never says you shouldn't comment - he says commenting is a sweet smell, meaning he fawors it and sees commenting as good. On the FFT, comments added would tremendously help someone who was not intimately familiar with the FFT understand it a lot better, and maybe even enable them to do some optimization or tweaking. Most code is this way. Most code is obvious to the person who just wrote it today, and much is obvious to someone who is intimately familiar with the problem domain. Even so you should still comment since not everyone dealing with the code is going to be that familiar with it. And for many other reasons too. |
| Sat 22 Mar | Brad (dotnetguy.techieswithcats.com) | Perhaps you didn't understand my point about self documenting code. Variable names like a_b are hardly self documenting. And a mathematical formula is a little bit outside the scope of self-documenting anyway, as I pointed out earlier. Done posting. Good luck. Write novels of comments! |
| Sun 23 Mar | Stephen Jones | The other thread on commenting code seems to state it pretty clearly. You don't comment primarily on what is in the code. You comment on what isn't in the code (the why, the business case it's trying to address, the reason for doing it this way and not another, any pitfalls to watch out for when refactoring, and so on). I really fail to see how refactoring is going to make those comments redundant. Also one or two line comments at the top of each short block of code saying what it does, so you don't have to read it all can be useful. You could use meaningful names instead but do you really want controls called PrintReportToShowHowManyApplicantsFromCountrySpecifiedinCountryOfCurrentResidenceDialogBoxArrangedInReverseChronoligicalOrderofApplicationDateButton |
| Sun 23 Mar | ODN | Maybe it's the mathematical mind at work. As One-Armed Bandit said, 'Sometimes, once I figure out how a piece of code should work I don't feel like even typing the code in.' This reminds me of a joke I once heard: An engineer, a physicist and a mathematician are staying in a hotel. The engineer wakes up and smells smoke. He goes out into the hallway and sees a fire, so he fills a trash can from his room with water and douses the fire. He goes back to bed. Later, the physicist wakes up and smells smoke. He opens his door and sees a fire in the hallway. He walks down the hall to a fire hose and after calculating the flame velocity, distance, water pressure, trajectory, etc. extinguishes the fire with the minimum amount of water and energy needed. Later, the mathematician wakes up and smells smoke. He goes to the hall, sees the fire and then the fire hose. He thinks for a moment and then exclaims, 'Ah, a solution exists!' and then goes back to bed. Another way of stating it: 'The proof is left as an exercise for the reader.' |
| Sun 23 Mar | Patrik | I dont mind writing some small document to go with my code if its needed. Usually if you do document an api half a page of text per function is plenty. However most places I have seen use totally bloated templates for documentation purposes. These templates usually are one-size-fits-all, used for all program documentation needs regardless of platform, which renders 70% of the template not applicable because it deals with say mainframe related stuff, and Im documenting UNIX stuff. Short and sweet goes for code. Short and sweet should go for documentation as well. Templates are so stupid it is laughable. This is why I hate writing docs. And needless to say, why people hate reading it. |
| Sun 23 Mar | simple mind | Where's the proof that someone can't write good, self-documenting code? |
| Sun 23 Mar | simple mind | this is self documenting code: http://www.cis.ysu.edu/~kramer/DataStructures/Intro/SelfDoc.html |
| Sun 23 Mar | simple mind | McConnell shows you how to do it: http://www.construx.com/survivalguide/doc/chk17.htm |
| Advantages to MFC | Fri 21 Mar | Alai |
| Im new to Windows programming (mainly use Perl and some Java, have edited existing VB code) and was wondering what the advantages and disadvantages to the MFC are vs. the Win32 API. |
| Fri 21 Mar | GML | MFC is a C++ wrapper, among other things, around the Win32 API. It builds a framework for developing Windows applications. |
| Fri 21 Mar | dmooney | The primary advantage would be you can develop windows applications more rapidly using MFC vs. Win32, while still using C++. |
| Fri 21 Mar | William C | Since the |