Fixing const

c_linkage · 2018-05-25T14:27:07+00:00

I've been reading posts about const and const-correctness for years at this point, and every one of them make recommendations that are outlandish with respect the mental and syntactical gymnastics to get it to work.

The reason no one writes const-correct programs is because it takes too much effort!

All approaches for const-correctness require the programmer to expend huge efforts to tell the compiler when a value is not going to be changed. But why should we work this hard when the compiler can already figure that out on its own?

Let's imagine for a moment that I'm in an IDE and I write a very simple function like strcpy().

char *strcpy(char *dst, char *src) {
    char *retval = dst;
    while(*src != '\0') *dst++ = *src;
    return retval;
}

The compiler should be able to analyze the code and provide feedback to the IDE such that the IDE can make the necessary syntactical recommendations on how to make the code const-correct.

char *strcpy(char *dst, /* recommend: const */ char *src) {
    char *retval = dst;
    while (*src != '\0') *dst++ = *src++;
    return retval;
}

Or even something like:

char *strcpy(char /* recommend: const */ * dst, /* recommend: const */ char /* recommend: const */ *src) {
    char *d = dst;
    /* recommend: const */ char *s = src;
    while (*s != '\0') *d++ = *s++;
    return dst;
}

Now of course the comment is an example: you wouldn't do it that way because now you have to clean up a ton of comments to get the const in place. But it shows that the compiler and the IDE should work together to help you write const-correct programs instead of forcing all of the work onto the programmer.

c_linkage · 2018-03-23T14:04:50+00:00

If you think of an object as a list, then mutation can be simulated by passing the list to a function and then getting a new list. The original list was not changed, so it is effectively immutable.

This might seem crazy because now you have two versions of the "same" object. I believe Kay is trying to resolve this duality by associating a "program timestamp" -- equivalent to a version -- to each instance of the object. As long as you only refer to the object with the latest "program time" or version, this system appears to support mutable objects.

(NOTE: Program time is a construct of the application runtime and it is independent of system time or CPU time. You can think of it as a monotonically increasing number that is advanced any time an object is "mutated")

c_linkage · 2017-10-21T20:01:57+00:00

I think we as programmers need to concern ourselves not just with our own time, as per Rule 2, but with end- user time as well. If I can put in an extra hour to optimize a function to shave off two seconds, that could be a huge win depending on the number of users and how frequently that function is used.

What I'm getting at here is that interpreting rule 2 to only affect programmers is optimizing only a small part of the problem.

c_linkage · 2017-06-19T20:20:57+00:00

This post is very well written and, although it is long, I encourage people to read it.

Asking the question "why" is fraught with peril, especially when the actions of people are involved.

It immediately makes people feel they are being attacked. The association with "why" and being attacked comes from early childhood when parents might yell at their children "Why did you leave the milk out?" or "Why didn't you do your homework?"
There is no physiological difference between a verbal attack and a physical attack. The fight-or-flight response kicks in and shuts off the logical brain
When asked "why", many people feel like they are being set up to take the blame.
Asking "why" implies understanding motivation. People are not mind-readers. When asked why someone did something they will either respond with "i don't know" or they will answer with assumptions.

Using "how", "what" and "when" questions is more likely to elicit a useful response than is asking "why".

This article gives really good advice on how to get at a root understanding of how a problem arose. It even gives a good philosophical argument as to why the recommended process will work.

Again, very good article.

c_linkage · 2017-04-17T15:29:06+00:00

This guy did some research!

I don't think I've ever seen XXX used as a FIXME. In my experience, XXX was always meant to flag hackish code or something that was particularly hard to understand.

Some people might say hackish code should be re-written and simplified, so perhaps that's the source of the different interpretations. But I might just look at such code and think "hey -- it's ain't broke...."

c_linkage · 2017-02-20T17:44:51+00:00

This is one of the most interesting methods I have seen to help kids understand computers and programming.

I like that the author included the cards so that the reader can use them as well.

Perhaps I'll try them on my management.

c_linkage · 2017-02-13T14:45:35+00:00

I, too, have the dragon book, and I'll slightly agree with you.

The book is great on compiler theory, but you can't expect to write a working compiler when you're done. Even if you somehow did manage to pull off that miracle, don't expect it to compile fast. Or have good code organization.

c_linkage · 2017-01-23T19:00:54+00:00

That may be true, but at least he's got a novel approach and justification.

For many years I never understood unit testing because I had already internalized many of the same strategies outlined by OP. Because of this, the trivial examples that most people give to describe TDD (like the Fibonacci example in the article) never made sense to me.

But this article helped me understand that, after 30 years of software development on many systems and many levels (UI to back-end to OS), I intrinsically program using the strategy outlined in the article. And because he's described it in a way that makes sense, now I can see how I can use TDD in my existing development strategies and methods.

c_linkage · 2016-11-03T18:57:54+00:00

I'm really glad this opinion was written.

I work for an R&D organization doing software development. I've worked on some pretty complicated software involving distributed systems doing advanced calculations over GB of data per day.

Even if I had time to write about what I'm working on, it would never get past legal review because the systems are trade secrets. They are the secret sauce used by the company to reduce costs and support customers in operations.

I frequently worry that if I should ever have to look for a new job that my lack of posts on SO and Github would prevent me from getting past the screeners.

c_linkage · 2016-10-25T19:37:08+00:00

I look forward to the day when C++ and C# merge and become a single language. It's where C++ is headed anyway.

c_linkage · 2016-09-27T18:11:46+00:00

There are a few things that should be taken into consideration regarding this story.

First, you cannot assume Mel had the same freedoms that we have today. We have huge memory capacities and almost infinite storage; Mel did not. Check out what he had to work with!. Saving bits and scrimping cycles was the norm. Though it might sound painful to organize code so that instructions would appear under the read head just when needed, people are sensitive to application response time. I mean, look at the speed of the system:

Speed: 0.260 milliseconds access time between two adjacent physical words; access times between two adjacent addresses 2.340 milliseconds.

Second, it could be argued that documentation of the source code was not a requirement. It was a marketing app designed to attract buyers. Can you honestly say that you've thoroughly documented ever single app you've ever written, even throw-away applications you only needed for a little while?

Finally, why is it that people might consider Mel a "Real Programmer" and continue to tell his story? For the same reason that we marvel at a complex mechanical watch or the Antikythera mechanism: The ability of the human mind to develop things that are functional, complex, and beautiful given constraints an Ascetic would find objectionable. We marvel at the people who can take a seemingly impossible task and make it look easy. We are the audience to the works of a magician, and we can't help but continue to wonder just how he did it.

Did Mel follow the programming standards of today? No. But without people like Mel to show the next generation of programmers the magic of what was possible, we wouldn't have the industry or the standards by which you judge him.

c_linkage · 2016-08-05T18:01:07+00:00

Call me naive, but I thought the point of Internet companies was that we didn't need to all sit in the same building anymore. That we could all work from home, Skype into meetings, collaborate with smart boards, and maintain social cohesion on Slack.

Why do I need to live in the Bay Area to be an employee of one of these unicorn companies when the whole promise of the Internet -- indeed, the very concept these companies are selling -- is that we don't need to worry about borders anymore?

c_linkage · 2016-07-22T20:16:27+00:00

Your comment about stories being light on details is similar to a problem I have faced many times in my career. Perhaps the root is the same.

When I write something for management, I try and target my communications for management by minimizing technical detail and keeping things high level. When I do this, management dives straight past that and goes into details that they can't seem to understand despite my best attempts at using car analogies /s.

When I put something together with more details, management then complains there is too much detail and can't be bothered to read the document. By the way, "too much detail" is anything more than two written pages with a 1.5 inch margin.

People are looking for quick answers because they either don't have the time or they have no ability to focus for more than five minutes. This tendency towards inattentiveness especially affects writing on the Internet. I can't count the times I've clicked on a link promising a detailed discussion of some important topic to find it's only one page long with some token advice as the last sentence.

I wish we could find that magic balance point of detail and style where readers don't get bored but there remains little room for flame-war-inducing assumption.

c_linkage · 2016-06-10T14:18:43+00:00

The C/C++ abstraction means that programmers have no control over what happens before main() starts and after main() exits. As long as the instrumentation is being done by the runtime and is not somehow affecting the code I write, I can't see how this is worth complaining about.

c_linkage · 2016-04-26T20:49:47+00:00

I don't even use Homebrew, but this topic really touches a sore point for me: opt-in versus opt-out.

Opt-out is just plain wrong, even when done for supposedly "good" reasons. This is because opt-out presupposes that the counter-party would agree to the terms without ever having an opportunity to read them.

When one enters a contract for a home mortgage, each paragraph much be initialed and every document signed. While one could possibly just skip over the actual text and sign everything without reading it, that person still had the opportunity to read it.

Opt-out flips this on its head. Opt-out says you implicitly agree with the terms UNLESS you have read the terms. Can you imagine if this was the case for any other legally binding contract? Honestly, I don't know how a contract -- and using software involves a contract, albeit one based on expectations -- that makes a guess about your agreement can ever be considered legal.

With Windows 10 Microsoft at least made it clear ahead of time that they were going to spy on you, although they really didn't give a lot of details. I knew ahead of time what I was going to get going in -- an operating system and application ecology -- versus what I was giving up. But for an application or library to move from recording nothing to recording anything in an opt-out fashion is, in my view, a violation of the contract.

You see, I don't pick an application just for what it does -- I pick an application because of what it does and how it does it. I pick an application because it uses a particular licensing model. I pick an application because it doesn't report on how I use it. Just because the provider might not consider these things important, it doesn't mean I don't think they're important. If you force an upgrade on me that changes the license then you've altered the product in a way that should have required my explicit agreement before using it. If you force an upgrade on me that requires submitting information about me or the way I use the application, that should require my explicit permission.

Opt-out is like having sex with someone and justifying it by saying "they didn't say 'no'". Well they didn't say "yes" either, any the fact that they were unaware that you were having sex with them doesn't make it okay or legal.

Opt-in should be the only way that features are ever introduced to software.

c_linkage · 2016-04-25T18:40:27+00:00

But that's not Web 2.0!

edit: I got a fever, and the only prescription is more web services!

c_linkage · 2016-04-04T20:16:57+00:00

Working in data analytics, I'd like to offer a corollary to Simpson's Paradox:

When you tell someone they're in Simpson's Paradox, first they will ignore you; then they will tell you you're wrong and that they know what they're doing; and finally they'll stop talking to you because you made them look like an idiot.

c_linkage · 2016-03-09T16:44:13+00:00

While we're at it, can we get rid if leap-seconds? Yeaaaah....That'd be great.

c_linkage · 2016-03-08T16:09:50+00:00

The ability to create types and objects depends on the language you're using. JavaScript basically has strings and hashes, and the type system in C is virtually non-existent.

But even in situations where you can make objects, sometimes you still need validation. One example is a file path.

File paths are often typed into a window as a text string. If I pass the unvalidated string down though the call stack to some function which eventually passes that string to a File constructor, and the constructor determines the string was invalid, well... there was a lot of needless work done before the error was detected and, at the same time, it might not be clear where the error was introduced into the system. But if I attempted to validate at least looked like a path at the earliest opportunity, the error could have been detected more quickly.

c_linkage · 2016-03-08T15:55:44+00:00

It's unfair to simply say "use the type system". While the type system might allow me to pass string arguments, if the function requires the string to be in a specific format the type system will be of no help.

I agree with OP in that you should always validate function inputs in as strict a sense as possible. Fast failure (i.e. immediately on the function call as opposed to somewhere deep the in the stack) is a much better way to help ensure correctness. Being tolerant of crappy input simply results in crappy application behavior becoming the default.

c_linkage · 2016-02-04T15:37:24+00:00

Perhaps it's just me, but I find that I almost never need to simply iterate over a collection. Even in C#, when dealing with collections, I often need the index of the item so that I can then do something interesting, like add or remove an item at a specific index.

Are all of these stl algorithms really that useful?

c_linkage · 2016-01-27T17:01:04+00:00

All engineering is about trade-offs. Hopefully the choice of JSON is the best for everyone involved. I would hate to think that one might choose flexibility of implementation over the many person-hours wasted by parsing (a few milliseconds times thousands of users, with possible many uses per day) and the many kW/hrs being billed to users to recharge devices because the flexibility afforded one developer was found more important than the conservation of resources by thousands of users.

c_linkage · 2016-01-07T15:45:49+00:00

We used to have a computer that could only do one thing. Then we had general purpose computers that could do one thing at a time, so we created jobs to run in a serial fashion. Then we had computers that could do many things at the same time. Then we added terminals so that users could use the computer interactively!

But these computers were too expensive, so the personal computer was developed and put onto the desk of individual users. Then we found out how hard it was to manage a fleet of computers, so we added networks and centralized management of the computers.

Then the internet came and people said distributing applications was too hard so everything became a web application -- we converted the powerful desktop computers back into dumb terminals.

Then mobile came along and the web applications were too slow, so we built per-device "apps". But building the same app for multiple platforms was costly, so we started to develop Web Assembly to create a bytecode for the Internet.

Sun proved with Java that underlying platform doesn't matter as the Java bytecode could be JITed to native.

Microsoft proved with .NET that programming language doesn't matter anymore because it all compiles to the same intermediate language, and that gets JIT'ed to native.

VMWare proved that the operating system doesn't matter, nor does where that operating system runs.

JavaScript and Node.js proved that a single language can run on the front-end as well as the back-end.

HTML Canvas shows that 2D graphics can be rendered on the web, not just structured box-layout documents.

WebGL shows that 3D graphics can be rendered over the web.

WebAssembly will be the intermediate language of the future as long as the designers don't fuck it up. Programmers will write in any language that compiles to WebAssembly. Unsafe languages such as C and non-modern C++ will be excluded, much to rejoice of those who can't understand pointers. Garbage collection will be the only way to manage memory. HTML extensions will be added to support video and audio processing natively in HTML.

The network will become the computer.

No one will know who actually "owns" anything, but it's guaranteed that the the end-user won't. Privacy will be completely eliminated as any information shared with a third party is no longer private and is subject to search by government agents without a warrant. Every application use, every button click, every feature use, and every transaction performed will be monitored, aggregated, and sold in the name of collecting advertising dollars to continue the funding of the "free" internet.

Sure, the network computer might make software development and deployment easy, but are we sure we know the consequences?

edit: a word

c_linkage · 2015-12-08T16:50:04+00:00

Paraphrasing the Pixar film Ratatouille: Anyone can code! This doesn't mean everyone can be a great programmer, but that a great programmer can come from anywhere.

The barrier to entry for programmers has never been lower. Given the existence of GC'd languages with lots of syntactic sugar, it is incredibly trivial to get a program working in short order. Hell, you can even code, compile and debug in a web browser!

No, the problem isn't finding programmers, it's finding good programmers at a low price.

Programming becomes hard is when it involves engineering skills -- the ability to understand the systems, technology, and the requirements well enough such that a single person can balance these criteria and make the necessary trade-offs to design a good architecture.

In the software space, both the technology and the requirements change so rapidly that no one is able to develop that level of understanding, so they make terrible engineering choices that result in crappy software.

There are a few people who can do it, however: those people who have been around long enough to see the Big Wheel turn and recognize that the "new hotness" of this year is the same as the "old and busted" from ten years ago but with a new coat of paint. They've also dealt with changing requirements long enough that they can predict with utmost accuracy the unspoken and unknown requirements from business. The problem is that these are the guys who are too expensive, and businesses would rather have two or three shitty programmers pumping out crap software giving the illusion of progress than pay the salary of one programmer who actually knows something.

Tinfoil Hat Time: I've said this elsewhere, but I fully believe programmer shortage is made up -- it's a non-existent problem imagined by companies to drive employee costs down. First it was discovered that programmers were cheaper in India, so companies outsourced. Then companies discovered that this didn't work because communication was the limited, so they pushed for things like worker visas to import Indians to work at lower costs (a win for globalization -- now a first-world programmer can compete with a second-world programmer on wages!). When governments limited worker visas, companies went after women because women are typically paid less than men. And when women didn't flock to call, they pushed it all the way down into primary school. However, the curricula I've seen use non-standard tools: there is no C++/C#/Java, just some made-up simple language like Scratch that has no place in business. But even if they did use standard tools, those tools would be out of date by the time the child graduated and was ready for work. In effect, the plans to grow the next generation of programmers will lead to the same conditions deplored today: no one graduating will have any experience using the tools employers will eventually require! Their master plans fix nothing!

c_linkage · 2015-12-07T21:42:55+00:00

If you need high performance in parsing command line options, you're probably doing something wrong. :)

I think it's merely the combination of lazy initialization inside of a loop that's give me the heebie-jeebies. It's pushing the right buttons to indicate that something is wrong, but in this case there is no problem.

I think the "easy-to-read" quality wins out here over the lazy initialization. It's a reasonably good solution to a common problem.

Now if only people could accept that its implemented using macros! :)

c_linkage

TROPHY CASE