Forgot your password?
typodupeerror

Comment: Overwhelming call volume (Score 1) 133

by Marginal Coward (#47766341) Attached to: Time Warner Cable Experiences Nationwide Internet Outage

TWC's customer service reps are reportedly a bit overwhelmed by call volume at the moment

Hopefully, their remaining customers, who evidently are willing to wait on hold for at least two hours under normal circumstances, will understand and will patiently wait on hold for ten hours for the privilege of being told "We're looking into it but there's nothing we can do right now."

Luckily, TWC has competition in my area. Every time I see an ad from them that seems cheaper than what I'm paying to their competitor, I remember the horrifying customer service, and the urge to save money goes away.

Comment: Just a few little things (Score 1) 548

1) You'll spend as much or more time fixing code than you do writing it. Therefore, anything you can do early in the process to reduce those is time well spent, even though it may seem like a waste of time:
- Single-step through every line of newly written code
- Do a little personal code review of all code you write
- Develop module tests as you write code
- Test every line of code in some way, either informally or formally.
- Write comments and documentation, even if just for your own benefit. Your future self may not understand what you've done as well as your present self does.
- Make changes to working code sparingly, and take steps to make sure that every change is for the better. (See above.)
2) Write code in small pieces, get the pieces working well, and stitch them together. Don't write something giant all at once that may never work.
3) Approach debugging on a data-driven basis. Most problems can be solved best by instrumenting what's happening in some way, e.g., via a debugger or a simulation. Though the trial-and-error method often is appealing for instant gratification, it's usually inefficient.
4) Read a few very good books: "Writing Solid Code", "Code Complete", "The Mythical Man Month", "The C Programming Language".
5) Learn several languages, including Python. Every language you learn makes you better at the other languages you already know.

Comment: Re:Templates all over again (Score 1) 427

by Marginal Coward (#47678975) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

Thanks for your comment. FWIW, here's what really happened. The function took a std:string as a parameter. The nominal use of it was to put in a char * literal which would get automatically converted to a string, so the parameter couldn't be passed by reference. While trying to step into the function, I stepped through the string constructor, which made several small function calls. When I replaced the parameter declaration with "char *", all that went away, and I was able to step directly into the function.

To be fair, the actual runtime overhead of the std:string constructor might be minimal, and could potentially be avoided by using a reference in many cases - though not this one. So, my concern about bloat when using template classes was anecdotal and might be overblown. As with any tool, you should use the right one for the job, and the string class does have some advantages, notably the ability to magically grow as needed. In this case, though, a char * would have worked just fine, so I contend that the original programmer didn't choose the right tool for this job.

I've used STL classes over the years, primarily vector and string, but I've had many experiences like this where something that C provided was a better fit for what I was trying to do. For example, a file name parameter probably doesn't need to magically grow, so a char * works just fine for that. That sort of experience, combined with having to repeatedly consult the documentation about STL functions because they aren't very intuitively named, has led me to prefer C constructs when I could potentially use either. That's what I meant in my original post when I said "many programmers minimize their use of templates".

Then again, I'm from the "less is more" school of programming. Some folks like to impress themselves and/or their friends by using as many fancy constructs as possible, in order to be judged a "*good* programmer" - as another commenter in this thread evidently does.

Though my original post was perhaps a bit overstated (for your entertainment), I actually do use the STL, but only at a very basic level, and only where it explicitly solves a problem. I think I would be a lot warmer to it if C++ templates and the STL itself were better designed. For example, I much prefer Python's string functions and MFC's "CString" class to std:string.

But even if templates and the STL were better, good-old-fashioned C still can meet most such needs very nicely. And as Tim Peters said, "Beautiful is better than ugly." (BTW, I wonder if Dr. Stroustroup thinks his template baby is beautiful? - maybe he'll tell us. ;-)

Comment: Re:Templates all over again (Score 1) 427

by Marginal Coward (#47676603) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

...but I do at least make an effort to understand the language that I'm using.

Unlike us "bad" programmers...

My basic point in the original point was that C++ templates are so complex as to be nearly impossible for most of us to *fully* understand. Don't you think that implies at least some sort of effort to understand them? In retrospect, though, my failure to fully understand them can only be attributed to my own abilities, not to the design of templates themselves. My bad...

Comment: Re:Templates all over again (Score 1) 427

by Marginal Coward (#47674147) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

Thanks. Please forgive my idocy. I think I got fooled the other day when I stepped through several std:string functions that were involved in passing a std:string parameter into a function. Then I replaced the parameter with a char *, and there was nothing to step through anymore. Apparently, though, all that std::string stuff would magically disappear in the release version. I forget whether the string parameter was passed by reference or not - somebody else wrote that part.

Comment: Re:Templates all over again (Score 0) 427

by Marginal Coward (#47673011) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

So what if you used a set of powerful templates to create a complex layered system rather than writing a simple one by hand? For an example, compare the STL string class to C's string library. It's not about the use of templates, per se, it's about the design of the systemthat the use of templates may lead you to. In effect, the major benefit of templates - their ability to create large, reusable systems - is a major drawback if you're looking for something fast and small.

Comment: Re:Given that (Score 1) 427

by Marginal Coward (#47672945) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

Likely true, but the benefit of C that I'm highlighting is that it gives you very little rope to hang yourself with in terms of creating a system composed of layer-upon-layer of classes. In contrast, I once worked with someone who loved to create class-upon-inherited-class for the simplest things in C++. Everyone who looked at his code wondered "where's the beef?", that is, the part that did something useful. The code worked, so the useful part must have been in there somewhere. But it sure wasn't easy to locate. I think he had tiny bits of useful stuff cleverly hidden in most of his classes. As best I could tell, though, some did nothing at all.

Basically, I regard C's inability to create a large complex hierarchy of objects, together with its ability to support objects in a basic way via pointers to structures, as a primary selling point that explains its persistence in a world where a "better" superset has long been available. That's not to say that the C++ approach of layering inherited classes is bad or wrong, just that its lack in C can prevent a certain category of problems.

Comment: Re:Given that (Score 1) 427

by Marginal Coward (#47671947) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

Having used both extensively, I can tell you that it is much more difficult to write slow, bloated, overly complex code in C than in C++. It keeps you honest in that way. Also, most of the good things of C++ such as object-oriented programming and templating can be done at a basic level in C. For example, in C++, a class function is just an ordinary function with a hidden pointer to a (class) structure. Why not just pass in a pointer to a class structure in C? And class member privacy can easily be a matter of naming convention rather than something the compiler enforces.

C++ has its value, and may be better suited for building large, complex, systems such as GUI frameworks, but C is a great choice for cases where speed and minimal size are paramount, such as most embedded code as well as the Linux kernel. In principle, it's possible to write fast, small code in C++ by using its features selectively. However, if you do that, you're left with mostly just the features you could have emulated in C anyway.

Oh, and did I mention that in its current form C is the "perfect" programming language? Other languages have their own goals, but judged in terms of its own goals, C does what it's trying to do better than just about any other language - far better than C++ meets its goals. There's a reason that changes to C over its many years have been very minimal, and virtually always for the better.

Comment: Templates all over again (Score 3, Interesting) 427

by Marginal Coward (#47671765) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

I'm a fan of C++ overall, but it seems to me that C++ templates are a bit of a disaster. They're so complex that I doubt that anybody but you and P. J. Plauger *fully* understands them. Also, when they're actually used, they often result in bloated, slow code - as I recently experienced when stepping through some STL string functions. Further, they bring on a lot of portability issues, evidently due to the difficulty that even the compiler folks have had in understanding and implementing them. Therefore, many programmers minimize their use of templates, both in their own code and in their use of templated library code.

Compared to the complexity of C++ templates, the C macro preprocessor provides a rudimentary form of templating via its very simple and powerful paradigm of text substitution. I've had some success implementing a limited form of generic (type independent) programming in C using just the C preprocessor. I've had much less success doing generic programming via C++ templates.

If you had templates to do all over again, what would you do differently? Was all the complexity of C++ templates (e.g. "partial specialization") really necessary to achieve its goals? Were the goals maybe too ambitious?

Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition.

Working...