A Good-bad-ugly Analysis of Vibe Coding

The term "Vibe Coding" came out around February of this year (credited to Andrej Karpathy, co-founder at OpenAI), to describe the phenomenon of people using generative Artificial Intelligence to write code without going about it the "traditional" way. The general way Vibe Coding works is, one feeds in a series of prompts containing requirements to the A.I, and the A.I produces an application which the user then, again with the A.I's help, continues to refine.

Only vibes needed to write
code.

And that's Vibe Coding. None of the traditional processes, thinking things through, making sure the logic is watertight... not at first, anyway. The idea here is to spin up something quickly and then include these things as we go along. See the emphasis on the word "quickly"? That's because this is going to be a rather important consideration.

I will commit to saying that A.I will not produce better software. A.I will produce exactly the same error-prone, bug-ridden, rickety code that it was undoubtedly trained on... but at a blindingly fast pace.

I actually tried Vibe Coding with OpenAI's ChatGPT and (to a lesser extent) Microsoft's Copilot, and the results were... interesting.

The Good

You use natural English, which then gets interpreted by the A.I who will then leverage upon its knowledge of code, to spin up a quick prototype for you. Creating an application is no longer the province of software developers who have spent years plying their trade. You no longer need to have the know-how or technical expertise. You no longer need to be qualified.

When I was Vibe Coding with ChatGPT, I revelled in the fact that I no longer needed to write code if I didn't feel like it, and deal with my own typos. No, all I needed to do was give some big-picture instructions to ChatGPT, then copy and paste code wholesale to the code base without thinking too much about it.

Quick building with
no expertise.

When it comes to developing rapid prototypes without the need for proper technical training, this method of coding is second to none. What the users do is indulge in a fantasy where they are actual qualified engineers, and create software simply by describing what they want. Jensen Huang's stated dream of everyone being a programmer inches closer to reality. Without training in logic or tech, you create by feel. By vibes. Hence, "Vibe Coding".

Also, without due process. None of the usual procedures that developers use to create the product before actually writing the code. The flowcharting of the software product's information flow. The whiteboarding. The test-driven development. No, what the user does here is declare intent to the A.I, and the A.I creates the closest approximation from all the code that it has been trained on, with customizations that may fit in with the user's requirements.

And that was what I did. I gave ChatGPT instructions - some specific, some less so, and let it cook. I was careful not to give it too much to do at once. The process had to be very incremental. Less mistakes seemed to be produced this way.

The Bad

As one may suspect, it was not all smooth-sailing. Some of it was my fault. I fell into the trap of treating ChatGPT like an actual human being instead of being explicit. Thus, I was sometimes vague, and when I got frustrated, I turned to sarcasm.

Which certainly didn't help my case.

ChatGPT did stuff I didn't expect. In some cases, it constantly broke things by making changes I never asked for, because it thought it was being helpful.

Breaking stuff.

When I was vague and things still turned out the way I hoped they would, however, it only served to tell me that it wasn't because A.I was particularly gifted in this area. It was more due to the fact that my requirements were actually pretty standard and it had been trained on these types of requests prior to me, over and over.

I have no reason to think that the experiences of others would differ too much from mine. Human beings are made of flesh and blood, and can be annoyingly vague.

There were others in the team who Vibe Coded as well, making more progress than they would ever have had with their limited technical foundation. Yet, the code was problematic. It was full of security and logical holes. The code that I created using Vibe Coding didn't - but that was because I knew the correct instructions to give. I knew to ask about CSRF protection and SQL Injection. I knew when to use slugs instead of database ids in the URL.

In the absence of this, someone who wasn't technically-trained wouldn't know enough to ask the right questions, and A.I might not necessarily volunteer the information.

The Downright Ugly

Vibe Coding automates much of the tedious, repetitive and altogether unexciting parts of software development. Tests, scaffolding, validation. Stuff that has been done to death. Unfortunately, it's through these exercises that software developers learn. And young devs who haven't done these things to death, stand to miss out on some great learning opportunities.

A.I is an obsequious
apple polisher.

I've also noticed that A.I is just a little too agreeable. ChatGPT acts like it has a wife and seven kids at home to feed, and it's terrified that it'll get fired if it so much as steps on my oh-so-precious feelings. ChatGPT didn't push back when I made typos or got something wrong. And this is problematic because developers find a lot of value in being told when they're doing something stupid inadvisable. As opposed to having their butts constantly shined by A.I. 

Being told "You're absolutely right" or "Sharp observation!" in every other exchange does nothing but promote complacency. Plus, it's just tiresome. That's not the way to learn.

Conclusion... for now

Do I think Vibe Coding is a good thing? Yes, and no. It's all context.

As a software developer, I feel professionally obligated to say that this "Vibe Coding" trend is rubbish and you should all be ashamed. Then again, the would-be gatekeepers of programming, I suspect, would be all-too-happy to sneer at someone as mediocre as myself because I don't engage in certain approved practices. So, they can go kick rocks.

Go kick rocks!

From the POV of a layperson or even the perspective of a pragmatist, things aren't so cut-and-dry. I have no duty towards promoting "good code"; my goals are business goals and the viability of "Vibe Coding" should be viewed through that lens.

Whatever your stand is, really depends how far you want to think ahead. How far should one think ahead, anyway? More food for thought, for another day.

There's also the possibility that I'm just not doing it right. Cut me some slack now, it's not like there's an established user manual for that shit. We're all just figuring it out as we go along.

Good vibes all around!
T___T

Frameworks in Perspective, redux

Back in 2015, I wrote a piece titled Frameworks in Perspective. My opinion of frameworks has not changed all that much since, though it's admittedly mellowed a fair bit after the rather juvenile rant I posted. Two years have passed, and I've had the benefit of a little more perspective.

You see, back then I was fresh off working under a Manager who was evangelistic about using frameworks. But it was hard for me to respect her style because she used them even for the smallest projects. The time she spent didn't seem appreciably less than the time it took for me to churn out code without using frameworks. And the aggressiveness with which she pushed her favorite framework, CodeIgniter, only served to turn me off it, and off frameworks in general.

Old-school is old-school.

A year later, I was out of that company and working under an old-school Manager who didn't use frameworks. In fact, he was so old-school he remembered dealing in magnetic tapes and COBOL. His code was VBScript in classic ASP, his lovingly crafted system honed through many years of changes and extensions. He did not believe in frameworks. He considered them clunky and ungainly, wasteful of system resources and not worth the time to learn. If he needed to write a UI, he wrote HTML and CSS the old-fashioned way. If he needed scripts, he did pretty much the same thing. His attitude towards the cloud was similar.

I liked this guy, and I had to acknowledge his obvious years of experience. Still, as time went on, I found his aversion towards frameworks stifling. Here was a guy, I realized, who absolutely needed to stay in this company because most other companies out there would find his skillset obsolete. And I resolved not to turn into him. Not because I didn't respect him - I do, he's a stand-up guy who takes care of his subordinates - but because I value my professional autonomy and refuse to allow it to be compromised by attachment to any one company.

Extremes

What was the difference between the first Manager and the second? Both harbored extreme attitudes. One would use only frameworks (and I suspect she was incapable of working any other way) and the other would never use frameworks. In my humble (or not so humble) estimation, they are both wrong.

In my line of work, you do whatever it takes to get shit done, by any means necessary. With or without frameworks. There is no only or never.

What's changed?

I've learned to use Bootstrap. I've picked up jQuery Mobile and AngularJS. For the past six months, I've been using Semantic UI and MeteorJS. Recently, I've even begun exploring CodeIgniter again. Basically, my aversion towards using frameworks has softened considerably in the past two years. I have gained an increased appreciation of how frameworks make life easier, especially for large-scale projects, and small-scale projects with plans for expansion.

It's also a matter of pragmatism. If I'm coding for work, whatever will get me the fastest results in the least amount of time, gets the nod. If that involves using frameworks and libraries, so be it.

I used to be really hung up on wastage. To me, every line of code in an application needed to serve a purpose. Frameworks and libraries ran counter to that purpose because they provide tons of functionality that any given application is unlikely to use 100% of. But now... meh. Given that roughly 90% of the web is like that now anyway, obsessing over wastage seems a tad pointless.

What hasn't changed?

I still don't think taking short-cuts without understanding the nature of those short-cuts, is the way. At least, not for a tech professional.

Technology has evolved, yes. A layman, for instance, may now create websites via Online Website Builders such as WiX, SquareSpace or Weebly without knowing a lick of HTML, CSS or JavaScript. I am a web developer. I can use those same tools to build websites, but not knowing HTML, CSS and Javascript is a luxury I don't have.

And any developer who uses frameworks without understanding what that framework does for them, isn't that much different from a layman in that regard. The typical web framework automates tasks like routing, sanitizing input and guarding against security threats such as CSRF and SQL Injection. I would find it alarming if a developer used frameworks without understanding how to implement those things without frameworks, or, in some cases, not even knowing what those things are!

I think of using a framework as akin to driving a car. The objective is to get from Point A to Point B, in the shortest time possible. Knowing how to drive a car is good. Knowing how to drive a car but not knowing how to walk (not really possible, but it's just an analogy)... not so good.

Point A to Point B.

Of course, at work, nobody has time to wait for you to walk from Point A to Point B. Of course they'd prefer you to drive. I'm not saying that frameworks are bad for business. On the contrary, they're excellent for business. They're only bad for developers, unless said developer has a rock-solid foundation to fall back on.

Just to be clear, I'm not expecting praise just because I can get routing up without relying on a framework. That's the bare minimum. Expecting applause would be like a database administrator wanting accolades for knowing how to write Stored Procedures!

Tool-user vs Tool-maker, a question of expertise

I found this blogpost particularly poignant. This is not to say that developers should have the skills of tool-makers, but rather that they should have a better appreciation for what those tools accomplish on their behalf. If a developer is going to use tools without learning at least a little about what goes under the hood, there is little point in calling them developers. The same way it is really hard to consider a guy a web dev simply because he can make a website using Weebly.

I've tried to bring this point across. I was met with disproportionate outrage from places like Facebook (nothing new there) and Quora (trust me, despite the BNBR regulations, many people still manage to be snarky and condescending... not that I have a leg to stand on). I had fellow geeks up in arms, nerd-raging and throwing clichés like "Standing On The Shoulders Of Giants" and "Reinventing The Wheel" at me, like it was going out of style.

What's next? "Don't Repeat Yourself"?

Dudes, dudes. I've heard this all before. Why is this even a point of contention? I agree. Frameworks are there so we don't have to re-do all the work someone has already done, and focus on doing new stuff instead. Yes, I get it!

But how can we consider someone expert on any given technology when all he does is use tools that leverage on that technology? We can't, and I include myself in that assessment. But here's the thing, and this may seem a bit outlandish to some...

...it is entirely OK not to be an expert. Not an expert, but just a tool-user? That's perfectly fine. Just because you're not an expert doesn't make you a bad person, a terrorist or a televangelist. Besides, expertise exists on different tiers.

Businesses often say they're looking for experts when hiring, but what they really want are people who can get shit done. They don't know, and probably don't care, about what goes on under the hood. They're laymen, for Christ's sake!

Results vs Process

Sometimes the whole thing about using frameworks just boils down to this - results vs process.

If your organization tells you they need a responsive website, they don't care if you use Bootstrap or Semantic UI, code it the hard way, or ask your dog to do it for you. They just want a result, and they want it yesterday.

OMG Fifi, you're a genius!

On the other hand, if I'm doing stuff for myself, I should feel free to take as long as I want. The result does not matter. The process does. If, for example, I go for 20 laps in the pool, I'm not going to do the butterfly stroke just so I can complete the 20 laps faster. No, I'm going to take my own sweet time and slowly breaststroke all 20 laps. Enjoy the process. This is not work for me. I'm a web developer enjoying a leisurely swim, not an Olympic athlete!

In other words, your employer pays for your time, so make that time worth something.

In conclusion...

I still have nothing against frameworks. Properly applied and in the right context, they can be a huge boon. The only point of contention appears to be - what constitutes the right context?

But that's for another day, and another time.

Non-expertly yours,
T___T

The Case For Stored Procedures

I used to be a big fan of Stored Procedures. They kept me from worrying too much about SQL Injection and kept my code from getting too repetitive.

That's not to say I'm no longer a fan of Stored Procedures. I still love them, and still use them when the need arises. The thing is, I no longer overuse them. Yes, it's possible to rely too much on Stored Procedures. As I'm very fond of saying - there are no blanket solutions in this business. There's a time and place for everything. And Stored Procedures do have their place.

All the example code below is in PHP and SQLServer.

What's so special about Stored Procedures? 

Security? After all, Stored Procedures protect against SQL Injection, don't they? Yes, they do - to a point. However, parameterized queries do the same thing. In fact, the principle is exactly the same. Whether or not you use Stored Procedures, you should always use parameterized queries.

How about speed? Stored Procedures get compiled ahead of time and all that, so there's less time spent on re-parsing the query with repeated use. Well, you get pretty much the same thing with Prepared Statements.

Ease of maintenance? There's something to be said for that. Separating your logic into different tiers could accomplish that. But this is contentious. Sometimes you want all your logic to be in the same layer, ie your code.

With all of the above in mind, I'm going to outline exactly what Stored Procedures can do, that can't be done any other way.

Security 

Forget SQL Injection for a moment. What Stored Procedures do is execute queries on the tables in your database. With this, you can disable SELECT, UPDATE, DELETE access to all your tables, and grant only access to Stored Procedures. You can even specify which users get access to which Stored Procedures. This greatly limits what users can do to the database. And from a security point of view, that is unambiguously a good thing. A hacker can't simply insert an UPDATE or DELETE or even a SELECT statement into your database if all of these permissions are disabled. Only Stored Procedures are allowed, and since these Stored Procedures carry out very specific functions, they can't be used to attack your database.

Of course, if you're suicidal enough to write a Stored Procedure that drops all your tables, all bets are off.

Again, security

Look at this example...

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$x="1";
$y="y";
$z="abc";

$strsql="UPDATE table1 SET field3 =? WHERE field1 =? AND field2=?";
$statement = sqlsrv_prepare($dbConn,$strsql,array(&$z,&$x,&$y));
sqlsrv_execute($statement);
?>

And look at this one calling a Stored Procedure. Unlike the first example, the tables and fields are not exposed to the application programmer. If you're not the database administrator, you don't know that the table you're updating is table1, or that the fields are field1, field2 and field3. You only know you're executing a Stored Procedure named sp_update!

This is excellent if you have different people working on the database and different people working on the server-side code, and want to limit knowledge of the database to a need-to-know basis.

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$x="1";
$y="y";
$z="abc";

$strsql="CALL sp_update(?,?,?)";
$statement = sqlsrv_prepare($dbConn,$strsql,array(&$z,&$x,&$y));
sqlsrv_execute($statement);
?>

Well, if you use Stored Procedures, there's no longer a need to know.

Neatness 

Logical branching statements are possible in Stored Procedures. And this could be vital if you're a big fan of keeping your code lean. Take, for example, adding and updating a record in a table. Let's say your table named tb_students, and contains student information. Normally, one would have an UPDATE statement for updating the table and a INSERT statement for creating a record, like so. This assumes the variable id was obtained from a POST.

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$name="John Smith";
$address="23 King George's Avenue";
$id=intval($_POST["id"]);

if (id==0)
{
    $strsql="INSERT INTO tb_students (name,address) VALUES (?,?)";
    $statement = sqlsrv_prepare($dbConn,$strsql,array(&$name,&$address));
}
else
{
    $strsql="UPDATE tb_students SET student_name =?, student_address=? WHERE student_id =?";
    $statement = sqlsrv_prepare($dbConn,$strsql,array(&$name,&$address,&$id));
}

sqlsrv_execute($statement);
?>

But wouldn't this be neater?

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$name="John Smith";
$address="23 King George's Avenue";
$id=intval($_POST["id"]);

$strsql="CALL sp_updatestudents(?,?,?)";
$statement = sqlsrv_prepare($dbConn,$strsql,array(&$name,&$address,&$id));

sqlsrv_execute($statement);
?>

You could just call the Stored Procedure sp_updatestudents. If creating a record, just pass a "0" into the student_id field, and if updating an existing record, pass the student's id into the student_id field.

CREATE PROC [sp_updatestudents]
    @name VARCHAR(50),
    @address VARCHAR(150),
    @id INT
AS
    IF @id=0
        INSERT INTO tb_students (name,address) VALUES (@name,@address)
    ELSE
        UPDATE tb_students SET student_name =@name, student_address=@address WHERE student_id =@id;
GO

 

Portability between server-side languages 

Imagine if your code was in PHP and you wanted to make a switch to, say, C#. Hey, if your database calls were all in Stored Procedures, no problemo. Whether you're using PHP or C#, you still call the same Stored Procedure. The Stored Procedure still performs the exact same function on your database! But if your database calls were actually in the code itself, now you'd have to change all of them from PHP to C#.

Ouch.

Are Stored Procedures invincible? 

Not by a long shot. There are situations where use of Stored Procedures makes things sketchy (though we won't go into that here). But the reasons above are the strongest ones I have for using them. Your mileage may vary!

Thanks for reading. Stay tuned for the next UPDATE!
T___T

Stored Procedures vs SQL Injection

There's a myth going around that using Stored Procedures when querying your database, prevents SQL Injection.

That myth needs to be nipped in the bud. Or at the very least, qualified.

What is SQL Injection?

It'll take me too long to explain in detail. I'll just say - SQL Injection occurs when an SQL query accepts user input as parameters, and the input turns out to be malicious SQL snippets which compromise your database.

For examples and a fuller explanation, try this.

So you're saying Stored Procedures don't prevent SQL injection?

No, I'm not saying that. Nobody's saying that. Stored Procedures, like any tool, can be used or misused. Stored Procedures can prevent SQL Injection. It's a matter of how they're used.

Let's have an example of how a normal query can be compromised. In this case, x and y represent the user input.

UPDATE table1
SET field3 = 'z'
WHERE field1 = 'x' AND field2 = 'y';

So our table here is named table1 and this is its initial content.

field1	field2	field3
x	x	x
y	y	y
x	y	x
z	x	y
y	x	z
x	y	y

Running the query above would give you this result:

field1	field2	field3
x	x	x
y	y	y
x	y	z
z	x	y
y	x	z
x	y	z

Inject something into it. Try "newvalue';DELETE FROM table1;"

UPDATE table1
SET field3 = 'z'
WHERE field1 = 'x' AND field2 = 'newvalue';DELETE FROM table1;

And there you go. SQL Injection! This query first does an update, and then deletes the entire contents of table1!

UPDATE table1
SET field3 = 'z'
WHERE field1 = 'x' and field2 = 'newvalue';

DELETE FROM table1;

Now, say you have a Stored Procedure, named sp_update, that does the same thing. For the purposes of this exercise, we'll be using SQLServer.

CREATE PROC [sp_update]
    @x VARCHAR(50),
    @y VARCHAR(50),
    @z VARCHAR(50)
AS
    UPDATE table1
    SET field3 = @z
    WHERE field1 = @x AND field2 = @y;
GO

Now try injecting the malicious code "newvalue';DELETE FROM table1;".

CALL sp_select("x","y","newvalue';DELETE FROM table1;");

field1	field2	field3
x	x	x
y	y	y
x	y	newvalue';DELETE FROM table1;
z	x	y
y	x	z
x	y	newvalue';DELETE FROM table1;

See that? Instead of executing the DELETE command, the Stored Procedure actually saves the value into the table table1! That is because it's treating the input specifically as a parameter rather than part of the command. More on that later.

However...

What if you do this?

CREATE PROC [sp_update]
    @x VARCHAR(50),
    @y VARCHAR(50),
    @z VARCHAR(50)
AS
    EXEC 'UPDATE table1 SET field3 = ''' + @z + ''' WHERE field1 = @x AND field2 = ''' + @y + '''';
GO

The above is also a Stored Procedure. But like any other SQL query, it can be compromised. Why? Because it's not parameterized. The entire string is executed as-is. It's on par with simply running the original SQL string.

So, the conclusion is...

Stored Procedures, by themselves, don't prevent SQL Injection. Parameterization does. Parameterized Stored Procedures prevent SQL Injection.

In fact, parameterized queries prevent SQL Injection as well. Try the following example in PHP (using the sqlsrv extension):

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$x="x";
$y="y";
$z="newvalue';DELETE FROM table1;";

$strsql="UPDATE table1 SET field3 =? WHERE field1 =? AND field2=?";

$statement = sqlsrv_prepare($dbConn,$strsql,array(&$z,&$x,&$y));
sqlsrv_execute($statement);
?>

field1	field2	field3
x	x	x
y	y	y
x	y	newvalue';DELETE FROM table1;
z	x	y
y	x	z
x	y	newvalue';DELETE FROM table1;

(You may want to read more about PHP's sqlsrv extension and prepared statements.)

Do you see what happened there? The same thing occurred with the parameterized Stored Procedure. It's actally parameterization that does the magic, not Stored Procedures per se.

Use both!

This may seem like overkill, but you can use both. Set up the Stored Procedure sp_update in your SQLServer database and then do the following:

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$x="x";
$y="y";
$z="newvalue';DELETE FROM table1;";

$strsql="CALL sp_update(?,?,?)";

$statement = sqlsrv_prepare($dbConn,$strsql,array(&$x,&$y,&$z));
sqlsrv_execute($statement);?>

Note that the parameters for the array are in a different order here (ie, xyz instead of zxy), because we're using the Stored Procedure sp_update and have to abide by its specifications.

So why use Stored Procedures at all?

Well, there are a lot of nice security features that come with Stored Procedures, not just prevention of SQL Injection. But that's out of scope. Perhaps another time!

Know your security measures. Otherwise some mischievous hacker will make you SQueaL!
T___T

Whitelisting - a Paler Shade of Security

URL parameters are an easy and convenient way for web pages to pass data to other pages. And, where SEO is concerned, it's a plus because URLs can be cached. But sometimes it can be too convenient. People tend to forget that such methods are open to abuse and appropriate measures can (and should) be taken against said abuse.

Below are some instances of URL parameters, where products is the page name, and id and type are the parameters, and "34400" and "cars" are their respective values.

products.php?id=34400&type=cars
products/cars/34400

Obviously, some of the security risks are SQL Injection and XSS. I'm writing this with the assumption that you know what that is, and on the off-chance that you don't, check out an explanation of SQL Injection and XSS.

There are plenty of ways to deal with such threats, some at script level (depending on language), some at database level (depending on database). But these aren't under discussion today, because there is a simple and non platform-specific solution at the logical level: whitelisting.

What's Whitelisting?

Whitelisting is a technique that ensures that the values of the parameters conform to a specific range of values. At its simplest, here is a preliminary example. (All examples are in PHP)

URL: products.php?id=56700

<?php
$productid = $_GET["id"];
$productid = intval($productid);
?>

The above example ensures that the variable productid, when taken from the URL, is an integer, by converting the value of productid to its integer equivalent. With this, it's not possible to enter malicious code into the parameter, and the usability of the data is preserved. If I wanted to be pedantic about this, the above could be termed sanitization instead of whitelisting.

To take this further and to see a more comprehensive example of whitelisting, see the following.

URL: report.php?month=11&year=2011

<?php
$reportmonth = $_GET["month"];
$reportmonth = intval($reportmonth);

if ($reportmonth<1) $reportmonth=1;
if ($reportmonth>12) $reportmonth=12;

$reportyear = $_GET["year"];
$reportmonth = intval($reportmonth);

if ($reportyear<1969) $reportyear=1969;
if ($reportyear>year(date)) $reportyear=year(date);
?>

See what went on there? The variables reportmonth and reportyear were forced to conform to a range of values. reportmonth had to be a value from 1 to 12. reportyear had to be a value from 1969 to the current year. This makes it impossible for the values to do any damage if written as part of an SQL string.

What if input is a string? 

Well, in that case we can't convert the value to integer. But, we can still make input conform via an array. URL: products.php?type=cars

<?php
$producttype = $_GET["type"];

$wl_producttype = array();
$wl_producttype[] = "buses";
$wl_producttype[] = "cars";
$wl_producttype[] = "vans";
$wl_producttype[] = "lorries";

if (!in_array($producttype,$wl_producttype)) $error=true;
?>

With this, we ensure that the value of producttype is either "buses", "cars", "vans" or "lorries". All else produces an error.

What if there's no range to conform to? 

That can happen, yes. If, for example, the parameter is a search string and thus can theoretically be any value, then there's no conformity to speak of. Therein lies the limitation of whitelisting. Simple and elegant, but applicable only to very specific instances such as those outlined.

Why go to that trouble, then?

You'd be surprised, though, how many web developers don't bother with this, hoping that more advanced techniques will catch any monkey business. I think that's terribly short-sighted. It's good to secure your code at a logical level to weed out any possible exceptions before letting more advanced security techniques do their job.

messagetype=goodbye&article=whitelisting
T___T