I remember seeing two main camps in the old debate on whether a hot-dog is a sandwich: those that argued "it's meat between two pieces of bread, therefore it's a sandwich" and those that counterargued "if I asked whether you wanted a sandwich and then gave you a hot-dog, you would be surprised". And both sides are right! That said, one of them is more right from a language-theoretical point of view, and that's the point of today's post.

(Spoiler: the "not a sandwich" camp is right. Sorry, pro-sandwichers!)

According to Herbert Clark a dialogue is a cooperative activity. It is a joint activity in which both speakers try to accomplish a common objective, ranging from something as formal as "make me understand where the train station is" to as vague an objective as "let's kill some time". And because it is cooperative, we do not expect the other person to be deliberately obtuse. If I ask "Can I get you something to drink?" and someone replies "I don't know, can you?", nobody would assume that this person has a genuine interest in my capacity for carrying drinks. Instead, we would immediately see this for what it is: that this person is not cooperating, that any reasonable person would have understood what I meant, and that this person stopped cooperating on purpose. Whether he did it to make a joke or because he's a jerk, that's a topic for a future discussion.

There is also a principle called the "maxim of quantity" (one of Grice's four maxims) according to which a person will always give as much information as possible, but not so much that it breaks the dialogue. If someone asks me where I come from, my answer can be as precise as a specific neighborhood or as vague as "somewhere near the border with Brazil". My answer will depend on how familiar I believe the other person to be with South-American geography, because I don't want to give them excessive information that they cannot handle. Again, I'm cooperating.

Which brings us to the hot-dog debate. From a taxonomic point of view, a hot-dog is a sandwich: it is composed of two pieces of processed meat between two pieces of bread, which is as clear as it gets. But this is only half the story.

The definition of sandwich came long after the sandwich itself. It is an artificial construct designed to model and understand a set of real-life language usages. Spoken language, on the other hand, is the real deal. Language rules and word definitions model how we speak, and not the other way around. All definitions are artificial and, therefore, may not always reflect the way we actually use those words.

Bringing this all together, I would only use the word "sandwich" to describe a hot-dog if I had a reason to believe the other person doesn't know what a hot-dog is. If you know what a hot-dog is and I know you know what a hot-dog is, using the word "sandwich" to speak about a hot-dog is neither maximally informative (I am giving you less information than I could) nor cooperative (I know which word would help us the most, but I'm not using it). "Sandwich" is a catch-all word that can only be used when no better word exists.

Even worse: you know we both know what a hot-dog is. By choosing "sandwich", I am actively leading you to believe that I want to offer something that can be described as a "sandwich" but not as a "hot-dog". Fans of malicious compliance will argue that this is not technically untrue, but you and I both know that there's little practical difference between "I told you a lie" and "I told you something that any sane person in the world would understand in a certain way while secretly using a different, opposite interpretation that I kept to myself".

So there you have it. A hot-dog is a sandwich if you stick to rigid categories created by researchers with a tenuous grasp of the real world at best (you know, people like me), but you are only allowed to use it if you talk to people who never heard about hot-dogs before. Using the word "sandwich" for a hot-dog in any other context is uncooperative, mildly dishonest, and kind of a jerk move. People do not use the word "sandwich" like that and, since spoken language is where "true" language usage lies, they are the ones who are using it right.

As so many immigrants expats around the world, I like to follow the news regarding what's happening back in my home country. But getting complete, reliable information has been getting more and more difficult every year, and 2020 is the year in which I finally ran out of news sources.

Unlike my parent's generation, I don't consider newspapers a reasonable source of reliable information. The problem is that, following the example set by Fox News, the largest newspapers at home have substituted fact for opinions, extremely biased articles, and outrage has replaced objectivity as the main selling point. All of this seasoned with local celebrity gossip, of course.

If despite my best judgment I decide to check what's going on based on newspapers, I currently start with the biggest newspaper (which is very right-leaning) and then compensate with their main opposition (which is, as expected, very left-leaning). I then figure out which news are common to both, and decide which version is more likely to be true - one newspaper's fair trial is the other newspaper's witch hunt, and one newspaper's smart move is the other newspaper's national betrayal. Finally, I check which news have been mentioned in only one of them, and decide on a reasonable narrative for why only one of them is talking about it. Suffice to say, doing this in the morning on my phone takes a lot of effort.

In my case, this was one problem (probably the only one) solved by the news aggregator Reddit. The sub-reddit for my country used to be relatively good at highlighting the main issues in the public conscience, and reading the main posts used to be enough to get a good, updated picture. But not anymore: extremely lax moderation and general apathy have turned the forum into a meme-laden wasteland where all information has been replaced by bad jokes, political outrage, and the occasional "kill all poors" post. So I quit it for good, and haven't looked back.

Which leads me to today. I have not yet found any source of news that I can trust to inform me. Sure, I can easily get distracted, entertained, outraged, tricked, and lied to, but informed? Good luck with that. I have remained uninformed for a couple months now, and I don't see that changing anytime soon.

Being a programmer who has spent a bit of time toying around with NLP, I have been working on a solution - a small news aggregator where I can get a proper sense of what's going on. But it hasn't been easy: news agencies no longer offer RSS feeds, important data is locked behind proprietary formats made intentionally hard to read, and there is barely any corpora around in Spanish that I could use to train models.

I don't have a deeper point. I can't promise that my solution will work, because it's entirely possible that it never makes it out of vaporware. I don't have a website to recommend, because websites are getting bad faster than good ones are propping up. And I'm not going to talk about the cesspool that are unmoderated forums because we all know about that already.

I just wanted to say: I am very unhappy with this situation.

I am okay at drawing. That means: I am probably better at drawing than a random person walking down the street but I'm far, far behind the type of artists that regularly post in Instagram. I am also mostly self-taught: I took some initial lessons via mail from the well-known (at the time) Modern Schools, gave up for a couple years, and picked it back up in my late teens when I needed something to do besides programming and not having friends. Some of my drawings have been published, and one in particular has been stolen countless time by people who thinks copying things from the internet without attribution is fine.

I was recently asked what I would recommend to someone who wants to learn how to draw. This question took me by surprise for two reasons: one, because I was never asked this before, and two, because my answer was surprisingly useless even to me:

Any tutorial you find online will give you the right steps. But you'll only understand them after you already know how to draw.

This is a pointless answer, which also happens to be 100% correct. This post is my attempt at giving a slightly clearer answer, explaining why anyone would think that my advice makes sense and hopefully give beginners some good points on where to start.

Note 1: this post contains links to drawings of naked people. If you are not comfortable with drawn nudity, you should probably not follow the links and definitely reconsider whether figure drawing is good for you.

The boring advice

All drawing is, at its core, more or less the same. Whether you are interested into realistic drawing, comic drawing, manga drawing (a term I hate), webcomics or editorial cartoons, the art of representing human figures in 2D is based on 90% the same rules. Sure, US comics have more muscles and japanese manga characters have no nose, but the fundamentals are the same. A typical drawing curriculum should include:

• How to sketch a human figure. This guide is relatively good, while this one sucks for reasons I'll explain later on. If you've seen those wooden figures, they are useful for getting the hang of this step.
• The proportions of the human body. More specifically, this guide on how many heads you need to draw a full body.
• The proportions of the face. This is annoying enough that it often warants a section on its own.
• How perspective works. One, two, and three points perspective are the typical ones.
• How shadows work. Getting it perfect will take a long time, but "dark part is dark" will get you far with little effort.

Once you reach this point, you can either start learning about muscles and improve your anatomy (have you ever stopped to think about how weird knees look?), or become a caricaturist and call it a day.

The number of books and tutorials out there convering all these points is virtually infinite, and therefore any book you choose it's going to be probably fine. If you want some more specific advice, multiple generations of artists have learned with Andrew Loomis' books, which are freely available on the Internet Archive. You should start with Figure drawing for all it's worth, follow up with Drawing the head and hands, and fresh up your perspective with the first half of Successful drawing.

Practical advice I: Keep drawing

There are two extra pieces of advice worth discussing.

The standard advice says "keep drawing until you become good at it", which is technically true but only barely. The full, honest version should say:

Start with one drawing. It will suck, and that's fine. Once you're finished, look at it objectively and enumerate its defects. For your next drawing, focus on solving those defects. Repeat until you consider yourself good enough¹.

In other terms: you can draw circles all day and all night for years, but that won't make you any better at drawing squares. If you want to get better at drawing, you first need to be aware of what's there to improve.

That doesn't mean that you can't be happy about something you just drew. Few things are as rewarding as putting your art supplies to the side, looking at your drawing, and admiring something knowing that you made it. All I'm saying is: you need to know what your blind spots are. If you are like me and your eyes are always sliiiiightly out of alignment, it is perfectly fine to still be happy about that portrait you just made. But if you are not honest and accept that yes, that one eye looks weird, then you will never learn how to fix it².

Practical advice II: Copy other people

As the quote goes, "Good artists copy, great artists steal". Therefore, it is your duty as aspiring artist to copy as much as you can. Most self-taught artists I know started the same way, copying drawings over and over until they felt comfortable enough to start doing their own.

My suggestion: find an artist you like. Pick one of their drawings and copy it. Add the final work to your sketch folder. Repeat. This exercise serves several purposes:

• It will improve your pencil grip, make your lines stronger, and improve your technique overall.
• It allows you to focus on a sub-part of the problem (drawing a figure) without having to worry about the complicated stuff - you don't need to think about perspective, shadows or posture because the artist already did it for you.
• It helps you to build your personal portfolio. It will help you visualize your progress, and gives you something to brag about whenever someone learns you are drawing and asks you to see something you've done. Plus, it's not like you wanted to throw those drawings away, right?
• It will help you answer questions you didn't know you had. Do you want to know how to draw a feminine-looking nose? Copy one of Phil Noto's illustrations. Would you like to know how does a professional go from zero to done? You can watch professionals like Jim Lee do a couple pieces in real time online and even explain their process as they go. Are you wondering how much attention to pay to clothes and background? Once you notice that classical painters couldn't care less about whatever is below your shoulders, maybe you won't lose your sleep about it either.

Eventually, you'll start noticing that different artists have different skills to offer. Maybe that guy draws cool hands, that other artist draws clothes very well, and that third other one has very expressive faces. Copying their work helps you understand the tricks they are using, and adding them to your repertoire helps you develop your own style.

Rest of the owl

The final point is both super important and really difficult to explain to beginners.

Are you familiar with the how to draw an owl meme? This picture is very popular in amateur art circles because it goes straight to the core issue: that most tutorials will take your hand and guide you step-by-step, but then they will let go at a critical step and you'll fall down a metaphorical cliff.

The root of the problem, I think, is that one step where the book tells you to "do what feels natural" or to "just keep going". What these people forget, however, is that learning what feels natural takes a lot of practice!

This tutorial I mentioned above is as bad as it gets: the instructions tell you to "Draw some vertical and horizontal lines to plan your drawing", which is completely useless advice that only makes sense once you know which lines to draw and where. Whoever wrote that guide has forgotten what it was to be a beginner, and their advice is really not helping.

When that happens, you have two choices. You can look for a better tutorial, or you can keep going, and see how far you make it. There is no shame in trying and failing, and who knows? maybe you'll still make it. Truth be told, there is a point at which no tutorial can help you and all that's left for you to do is to just draw. But that only applies for specific, advanced tutorials. It is the sad truth that, as a beginner, you will often recognize bad tutorials only once you are stuck in them.

Nobody said the life of an artist was easy.

Closing remarks

This guide ended up being longer than I intended, and half as long as it should be. That's always going to be a problem: the average artist does not let structure get in the way of their vision, and any attempt at a "formal" answer will stop halfway (as I have complained before). That said, if you would still appreciate a more structured approach, I have heard good things about Betty Edward's book Drawing on the right side of the brain.

And finally: have fun. All of this advice is useful for when you want to get objectively better, but there's a lot to be said in favor of simply drawing because you enjoy it.

Happy drawing!

Footnotes

1. Fair warning: in my experience, most artists never feel that they are "good enough". This is a well-known bug of art.

2. I believe the process of "find defect, correct defect, repeat" is why most artists I know are never happy about their work. Seriously, go to an artist and tell them you like a particular drawing of them - there's a good chance that they'll give some excuse for why the drawing sucks.

I have been giving programming languages a lot of thought recently. And it has ocurred to me that the reason why (reportedly) lots of people fail at learning how to program is because they are introduced to it at entirely the wrong level.

If you as a beginner search "Python tutorial" right now, you will get lots of very detailed, completely correct, very polished tutorials that will teach you how to program in Python, but that will not teach you how to program. Conversely, if you search for "how to program", the first results will be either completely useless advice such as "decide what you would like to do with your programming knowledge" or they ask you to choose a programming language. You might choose Python, in which case you are now back to square one.

One of the founding principles of my field is that "Computer Science is no more about computers than astronomy is about telescopes". In other words, programming is a skill that it's expressed typicall using programming languages, but it's not exclusively about them. And programming, the skill underlying all of these programming languages, is hard.

To be a good programmer, you need to master three related skills:

1. Understand how to convert messy real-life problems into a clearer version with less ambiguities.
2. Understand what the best practical approach to this problem is, and choose one as a possible solution.
3. Understand how to use programming languages and data structures to implement that solution.

Mastering the first skill requires an analytical mind, and in particular forces you to see the world in a different way. If someone asks you for a program to keep track of how many people are inside a room, you need to stop thinking in terms of people and rooms and think in terms of numbers and averages. You also need to account for badly-defined situations: if a woman gives birth inside the room, is your solution good enough to increase the room count by one?

This part alone is quite hard. Some people make a living out of it as software requirements engineers, meeting with clients and discussing some approaches that would make sense. It also requires at least a surface level understanding of the type of solutions that one could realistically employ. If you ever wondered why your high-school math teacher always asked you to turn apples and trains into equations and solving for x, well, this is why: they were teaching you how to solve real-world problems with simpler methods.

In order to master the second skill "choose a viable solution", you need to read a lot about which problems are easy and which ones are hard. There are some problems that a programmer solves daily, and some problems for which the best known solution would still take thousands of years. If you think that finding new solutions to problems is interesting, I encourage you to go knock at the Math department of your nearest university. They do this for a living, and will be very excited to have you around.

Finally, the third and last skill "implement a solution" requires you to write it down in a way that computers can understand. Half the job requires understanding common concepts for structuring programs (variables, databases, data structures, networks, and so on), and the other half requires learning the syntax of your preferred programming language.

And here we reach the core of this post's answer. If you type "Python tutorial" right now, what you'll get are very detailed guides on how to acquire the second half of the third skill, also known as "the unimportant one". Sure, programmers love discussing which programming language is better and how not to write code, but here's a little secret: in the larger scale of things, it rarely matters. Some programming languages are better suited for specific tasks, true, but the best programming language is not going to be of any help if you don't know what you are trying to build.

At its core, programming is learning how to solve problems with a specific set of tools. And while you do need to understand how to use those tools, they are completely useless if no one explains to you how to solve problems with them. If knowing how to use a pen doesn't make you a writer, and knowing how to use a wrench doesn't make you a mechanic, teaching you a programming language and expecting you to become a programmer overnight is just going to leave you confused and frustrated. But remember: it's not you, it's them.

Appendix I: what does problem solving looks like?

Let's say someone asks me to "write a program to know who I have been in contact with in any given day", a problem known as contact tracing that has been in the news in the past weeks. How would the skills above come into play?

(Note: for the sake of simplicity, I am going to solve this problem badly. It's a toy example, so don't @ me!)

The first step is to model this situation in a formal, more structured way. Real people are difficult to work with, but luckily we don't care about most things that make them human - all we care about is where they have been at any point in time. Therefore, we replace those real people with "points", keep track of their GPS coordinates at all times, and throw all of their remaining attributes away.

We have now turned our problem into "tell me which GPS coordinates (i.e., points) have been close to my GPS coordinates at any given time". We can simplify the problem further by defining what "close to me" means, and we turn the problem into "give me a list of points that have been 1 meter or closer to me at any given time".

Next, we need to find a way to efficiently identify which points have been close enough to our coordinates. Since there is a lot of people in the world, we start by crudely removing all points that are more than 10km. away from me - this can be done very quickly, and it probably won't affect our results too badly.

We now need to refine our search, and therefore we take a dive into the geometry literature. After a quick look, I decided that building a Quadtree is the best solution for what I want to build. Note that I only have a passing knowledge of what Quadtrees are, but that's fine: once I have a hint of where the solution might be, I can search further and learn the details as I go.

And finally we get down to writing code. If our programming language doesn't already include an implementation of a Quadtree data structure, we might have to do it ourselves. If we choose Python, for instance, we need to understand how to create a class, how to use lists of objects, and all those other implementation details that our Python tutorial has taught us. Similarly, storing the list of points will probably require a database. Each database has a different strong point but, as I said earlier, knowing which database to use is not as important as knowing that some database is the right tool.

Let's now picture the same exercise in revers: imagine I come to you and say "Write me a program to know who I have been in contact with in any given day. Here's a guide on how to use Quadtrees in Python". You wouldn't find that last bit of any use, would you?

As many other people around my age, I learned programming from a book. In particular, I started programming with a 3-books series called Computación para niños (Computers for kids). Volume 3 was dedicated to programming in BASIC, and it opened the door to what is now both my profession and hobby.

That said, that book was also the source of a 25-ish-years-long frustration, and that story is the point of today's article.

In the ancient times known as "the 90s", it was still common to get printed code for games that you had to to type yourself. This book, in particular, included a game called "Lunar rocket" in which you were supposed to (surprise!) land a rocket on the moon. For context, this is how the game was sold to me:

And this is what the code looks like:

Suffice to say, the program never worked and I couldn't understand why. I spent weeks trying to tweak it to no avail, getting different errors but never making a full run. And no matter how hard I tried, I could never get a single picture to show on screen. Eventually I gave up, but the weeks I spent trying to understand what I did wrong have been on my mind ever since.

That is, until last Sunday, when I realized that I should go back to this program and establish, once and for all, whose fault all of this was.

Problem number one was that the book shows pretty pictures, but the program is text-only. That one is on me, but only partially. Sure, it was too optimistic of me to expect any kind of graphics from such a short code. But I distinctly remember giving it the benefit of the doubt, and thinking "the pictures are probably included with BASIC, and one or two of these lines are loading them". That was dead wrong, but I'll argue that young me at least had half of a good idea. A few years later I would learn that the artwork and the game rarely had anything to do with each other, a problem that has not entirely gone away.

Now, problem number two... That code I showed above would never, ever work. My current best guess is that someone wrote it in a rush leaving some bugs in, and someone else typed it and introduced a lot more. In no particular order,

• Syntax errors: Line 130 has a typo, the variable name "NÚMERO" is invalid because of the accent, and line 150 is plain wrong. The code also uses ";" to write multiple instructions in a single line, but as far as I know that's not valid BASIC syntax.
• The typist sometimes confuses "0" with "O" and ":" with ";" and " ". This introduced bugs on its own. Line 150 (again) shows all mistakes at once.
• Error handling is a mess: if you enter the wrong input, you are simply asked to enter it again. No notification of any kind that you did something wrong.
• The logic itself is very convoluted. GOTOs everywhere. Line 440 is particularly bad, and could be easily improved.
• Some of the syntax may be valid, but it was definitely not valid in my version of Basic. And seeing how my interpreter came included with the book, I feel justified in not taking the blame for that one.

And so I set out to get this to run once and for all. The following listing shows what a short rewrite looks like:

LET DISTANCE=365000
LET BARRELS=100
LET MASS=1000
LET TIME=60
LET A0=0
LET VO0=0
LET V0=0
LET EO0=0
LET E=0
LET F=0
LET THROWS=0
DO WHILE BARRELS>0 AND E<=364900 AND THROWS <= 30 
    LET REMAINING=DISTANCE-E
    PRINT "DISTANCE SO FAR="; E
    PRINT "DISTANCE TO GO="; REMAINING
    PRINT "SPEED"; V
    PRINT "BARRELS LEFT="; BARRELS
    PRINT "THROWS LEFT(MAX 30)="; THROWS
    PRINT "-----"
    INPUT "NUMBER OF BARRELS?"; NUMBER
    INPUT "DO YOU WANT TO BRAKE (Y/N)"; RESP$
    IF NUMBER>BARRELS THEN
        PRINT "NOT ENOUGH BARRELS!"
    ELSEIF RESP$ <> "Y" AND RESP$ <> "N" THEN
        PRINT "INVALID INPUT!"
    ELSE        
        LET THROWS=THROWS+1
        LET BARRELS=BARRELS-NUMBER
        IF RESP$="N" THEN
            LET F=(F+NUMBER*1000)*0.5
        ELSE
            LET F=(F-NUMBER*1000)*0.5
        END IF
        LET A=F/MASS
        LET V=VO+A*TIME
        LET E=EO+VO*TIME+0.5*A*TIME*TIME
        LET EO=E
        LET VO=V
    END IF
LOOP
IF BARRELS <= 0 THEN PRINT "MISSION FAILED - NOT ENOUGH FUEL"
IF THROWS > 30 THEN PRINT "MISSION FAILED - NOT ENOUGH OXYGEN"
IF E>364900 THEN
    IF V<5 THEN
        PRINT "MISSION ACCOMPLISHED. ROCKET LANDED ON THE MOON."
    ELSE
        PRINT "MISSION FAILED. ROCKET CRASHED AGAINST THE MOON SURFACE."
    END IF
END IF

I think this version is much better for beginners. The code now runs in a loop with three clearly-defined stages (showing information, input validation, and game status update), making it easier to reason about it. And now that the GOTOs are gone, so are the line numbers. However, and in order to keep that old-time charm, I kept all strings in uppercase and added no comments whatsoever.

I also added some input validation: the BASIC interpreter I'm using (Bywater Basic) will still crash if you enter a letter when a number is expected, but that's outside what I can fix. At least you now get a message when you use too many barrels and/or you choose other than "Y" or "N".

It is only fair to point out something that I do like about the original code: that the variable names are descriptive, and in particular that the physics equations use the proper terms. If you are familiar with the physics involved here, those equations will jump at you immediately.

If I had time, I would still tie a couple loose ends in my version. A proper rewrite would ensure that the new code behaves exactly like the old one, bugs and all. And there's a good chance that I have introduced some new bugs too, given that I barely tested it. I also feel like making a graphical version, using the original artwork and adding some simple animations on top.

But even then, I finally feel vindicated knowing that younger me had no chance of making this work. Even better: the next exercise, a car race game, just gave you a couple pointers on how to draw something on the screen, and then left you on your own. That one would take me some time today.

Next on my list: finally read the source code of Gorilla.bas. I know I tried really hard to understand it when I was 10, so maybe I should get closure for that one too.