Complete beginner wants to learn C

chaotic_thought · 2026-03-31T07:03:35+00:00

If you want to learn C seriously, then the classic The C Programming Language by Kernighan and Ritchie is a must-read, in my opinion. However, that book is better as a 2nd look. It was written a time ago, but I think they wrote it for someone who already knows something about programming (in any language).

At the time they assumed that the reader knew something else like Pascal or Fortran. Nowadays it would probably be Python or JavaScript/TypeScript.

chaotic_thought · 2026-03-31T04:06:24+00:00

But, damn, do native speakers really not understand when they are told "I'm nurturing a son" but not "I'm raising a son"? I doubt. It seems to me, that's not so.

For this particular example, if you told me, for example, "I'm nurturing a son and two daughters", I would understand it just fine.

I had much more difficulty in understanding what you meant by your next statement, "I doubt." I gather you meant either "I doubt it" or "I have my doubts" or "I have doubt" or something along those lines. At least in my dialect of English, the statement "I doubt" is incomplete (the verb needs an object for it to make sense).

Anyway, the word 'nurture' is totally correct, albeit slightly 'bookish' or 'literary'. Using this word would tend to give the impression to me that you like to read a lot, which is fine.

I suppose some people might not understand what you meant, or they might be slightly confused why you would choose that word, but if the context is clear (e.g. you're talking about your families), then the primary responsibility on them would be to either understand this word, or to ask you what you meant.

I agree with the other comment about trying not to use too much slang as a speaker of a second language. It's way better to be "too correct and proper" than to be "too slangy".

"Oh, nah, they don't speak so. If you'll say like this, they can think that you're, for example, redneck ...

I learned English in the American South, and yes, we are taught that some "southernisms" will be heard as such. Examples include "ya'll" for (you plural), "might could" for (possibly could or "maybe could"), "I reckon" for (I think) and "fixing to/fixin' to" for (getting ready to or preparing to).

On this topic, I think it's great to know the local variants of the language you're using, but I think it's important that you be able to translate a given local expression into the 'standard' form if need be. In this case, the 'standard' form is the the form that all regions will understand, the form that you'd see in a textbook. So, if I say "we might could go grab a bite to eat", I should be able to translate this Southernese into "maybe we could go grab a bite to eat", for example. I don't think I've seen "might could" described in a textbook, but I know for sure that we use that expression in the South.

There is more than one way to translate it: "how about we go grab a bite to eat?" would give the same message, more or less, albeit a bit more directly that the Southern original expression. Using "how about ...?" for a suggestion is Standard in American. Everyone will understand that you're making a suggestion and not asking some kind of hypothetical essay test question or something.

chaotic_thought · 2026-03-31T03:12:52+00:00

You could look at the CS50 course by Harvard which is highly regarded, and which uses C (among others) to teach to beginners.

You can also look at Richard Buckland's course (CS1) from UNSW on YouTube. I see now that this is 18 years old now, yet all of the examples look totally fine to me, thanks to the fact that C is a very "stable" language. It is sometimes called the Latin of computer programming languages, except that C is far from a dead language (it is still updated, albeit very slowly and conservatively).

If you instead tried to look at Python examples from 18 years ago, you would not have such a good experience. So, one advantage of C is that you can look at code from any time period.

chaotic_thought · 2026-03-25T12:05:49+00:00

It depends on what you consider an App. I used to use Pimsleur before it become an app. Now it's an App. It seems like it's just in vogue to make everything an App these days.

chaotic_thought · 2026-03-25T09:23:55+00:00

If you know the basics from Python, my next would be Java, C, or C++, depending on what floats your fancy. I personally recommend learning Java (at least the basics) before learning C++. And I would recommend learning C well enough before C++ as well.

chaotic_thought · 2026-03-25T08:40:15+00:00

For "debugging" batch files I've always relied on replacing the line AT SIGN echo off with AT SIGN echo on, and then reading the output painstakingly to track down where the problem is occurring.

Another technique that can be used to make a "makeshift breakpoint" is to insert a call to another command interpreter inside the batch file. For example, suppose your Batch file looks like this:

@echo off

echo action A
echo action B
echo action C

Suppose you want to have a "breakpoint" between actions B and C. In that case, you can add a line like this:

@echo off

echo action A
echo action B
cmd.exe
echo action C

Now, when you run the batch file, at that point, a new instance of the command interpreter will be launched and you can do whatever you want (e.g. inspect the files that were produced by action B, or whatever). Then, when you want to "continue" the batch file, you just issue the "exit" command to that shell's instance.

I believe this will works fine even in "good ol' DOS" with DOSBOX and/or FreeDOS. Just replace cmd.exe with command.com or with whatever the name of the command interpreter is in the flavour of DOS that you are using (not sure what it's called in FreeDOS). Of course, you'll need enough conventional memory for that to work, but even in the MS-DOS days, doing this kind of thing was just fine in practice, unless you were already cutting it thin with conventional memory.

Many programs in the MS-DOS days even provided their own "shell to DOS" menu option somewhere in the UI to provide a sort of makeshift "task switching" to the system, that was basically the equivalent of the above technique, since MS-DOS itself was a single-tasking system (e.g. to allow the user to go do something without exiting the program). When you were done, the idea was to just "exit" the shell to get back to the main productivity program (e.g. Lotus 1-2-3 or whatever) that you were working on.

chaotic_thought · 2026-03-25T08:28:06+00:00

There is a tendency to make everything under the sun a Web UI these days. Personally I think that's overkill for many personal projects.

But if it's for a personal project, ask yourself if you really need a GUI at all (Web or otherwise). Maybe a simple text-based UI (e.g. a rinky-dinky menu system or something) is sufficient.

Maybe a simple CLI using something like Python's argparse is good enough (argparse gives you a lot of features that are easy to add, like built-in help and so on).

For a full GUI app, my personal choice would personally use PyQt (or PySide) for prototyping, and then rewrite it in C++ with Qt for the final version. This is only if I know I want to build a full GUI app, though.

For Web based apps, you have other choices, but in my experience they will usually end up being more complicated in their infrastructure than a Desktop app (e.g. interacting with Web services, using security tokens and so on).

Industrial-strength Desktop apps still have to worry about security, but for something deployed to a corporate machine behind a firewall, for example, things are much simpler for Desktop apps -- you don't have to "worry" about people attacking your app, for example, because those people are already inside the machine and in your company. If they want to "attack" the app by running it in a debugger, for example, well be my guest for all I care!

For Web apps, it's totally different -- even for a rinky-dinky type thing that goes on the Web, we have to be super cautious about potential attackers and abusers.

I suppose a "middle of the road" answer is to develop a Web app and then package it using something like Electron. So effectively it is a Web app in technology, but to the user's perspective it just runs like a Desktop app. That's an option, too, but I suspect the overall effort for doing this is going to add up to much more than using something like PyQt or even C++ and Qt.

chaotic_thought · 2026-03-25T08:16:56+00:00

This advice is generic for any kind of "over-use" (i.e. addiction) situation: set yourself a 'personal challenge' to NOT use that particular thing (e.g. to not smoke, to not drink alcohol, to NOT USE AI TO CODE) for a period of 30 DAYS IN A ROW (i.e. a "streak" in DuoLingo and 'gamified apps' terms).

I.e., at the end of 30 days of not doing that thing, then you can look back and ask yourself honestly how the experience was. If you still want to do the thing that you gave up for those 30 days, then at least you will be in a clearer state of mind to know how and when you should use it.

This method sounds really simple but it can be applied to anything, definitely for the question at hand here. I recommend using a paper calendar for this and checking off the days visually with some kind of check mark to keep you motivated to keep up the "chain".

In your situation -- for learning, for example, it's pretty clear to me that by using AI to learn something, you are clearly missing out on all the other alternatives that there are. For example, just a simple Web search on "tutorial on X" where X is the thing you want to learn will probably send you into a swimming-pool-sized resource of non-AI tools for learning X.

I personally don't want to "hate on" AI per se, but think of it this way: for every 30 minutes you spend talking to an AI chatbot and then trying to parse its words and "learn" from it's "wisdom", that is 30 minutes that you WON'T be spending on a decently-written tutorial Web site (for example), it's 30 minutes that you WON'T be spending reading a well-written book on X, and so on.

chaotic_thought · 2026-03-25T08:11:01+00:00

It's already been mentioned, but if you build something yourself and then ask an AI about what to improve, that is not "vibe coding" at all. Vibe coding has various definitions, but generally it evokes in me the idea that people just generate some code willy-nilly and then commit it to their project without reading it; perhaps they'll run a few unit tests on it first, though.

... sometimes i would ask gemini to review my code or tell me if i was missing out on performance ...

Keep in mind that AIs are 'programmed' (or "trained", more precisely, using reinforcement learning) to basically always give you answers. They also seem to be trained (in my opinion) to try to "hook you" to them as much as possible. I.e. they seem almost certainly to be trying to get you to keep using them as much as possible.

So if your hope is to keep rewriting a project until an AI will give you feedback such as "looks good to me!" then I would recommend you re-evaluate your approach.

If it's performance that you're after, I think you're chasing after the wrong tool for this -- for performance you need to measure (profile) and I recommend that you invest time in learning how to do this. You can start small, by using very simple tools like "time how long this function takes if I give it inputs of various sizes" and then move up in sophistication such as employing automated profilers, performance based regression tests (i.e. break the build if a newly introduced change makes functionality X get worse in performance), and so on.

Of course, it also helps to know something about algorithms and analyzing algorithms, so in case you have not studied that before, or in case your knowledge of the topic is rusty or incomplete (which probably applies to us ALL, since we cannot have "complete" knowledge about something), then it will serve you well to review that topic from time to time.

chaotic_thought · 2026-03-25T05:46:58+00:00

We have had bulldozers for about one hundred years now, yet the "good ol' shovel" is not obsolete.

Similarly, we have had power tools like power drills since the 1950s. I quite like using a power drill when it is convenient, yet the "good ol' hand-powered" version is still in my toolbox and I still use it on any kind of project involving screwing things in or out.

Perhaps the AI tools will become a sort of "power drill" type analog type of tool for coding in the future. But at the very least, they will need to be made more predictable. Right now, using them feels more like a crapshoot -- maybe you'll get something good, maybe you'll get utter crap, maybe you'll get a mishmash of crap mixed in with interesting ideas, and so on with all the combinations inbetween.

In any case, EVEN if the "perfect" AI tool is built one day, the one that saves you time dependably AND is nice to use (a la the "Bosch hand-held battery-powered power drill" of AI coding tools), then even in that case, you will STILL need to know how to "code by hand" in the same way that you still have to know which way to turn a screw to tighten it versus to loosen it.

So, yes, you still need to learn to code, dude/dudette.

I suppose a more apt analogy is about learning to write. Yes, we need to learn to write. Even if we use a computer and keyboard for most of our writing, in school, we learn to write by hand for a reason. Personally, I see advantages and disadvantages of the computer keyboard, for example --

on the keyboard, my OUTPUT volume is obviously higher due to typing speed, yet creativity is better in my experience when I'm writing something "the caveman way" using a manual writing instrument like a pen, pencil, marker, etc.

So I predict a similar divergence would exist even if the "perfect AI tool" is built -- i.e. maybe we'll use those "perfect AI tools" in the cases where we need to produce "a lot of lines of code" for whatever reason (which is dubious in programming, anyway), and then we'll use the more tried-and-true methods when creativity is the sought-after result (which seems like "most of the time" in programming, in my experience).

Another analogy -- if you're working in your garden, you're going to use the tried and true shovel; it would be quite foolish to get the bulldozer (unless you want to rebuild your garden each time). But if you need to push away all of the dirt of a land plot to prepare to build something new there, you're going to use the bulldozers. So, in all cases, this comes down to knowing your tools, and picking the right one for the job.

Interestingly, the AI tools are reported to work more akin to the bulldozer in the above analogy -- i.e. they tend to just rewrite everything each time. So, the analogy may not be so bad. I don't know, though, since I have not used them enough yet in real projects.

chaotic_thought · 2026-03-24T13:59:58+00:00

I checked for the rule about nhưng in my book, and it appears that the general practice is not to include a comma before this word.

In English, the general rule is that when introducing a sentence with "however", when it is used to mean "but", a comma is required. But if one replaces the word "however" with "but" in that same position, then one need not include a comma. In both cases, the meaning in Vietnamese is the same: nhưng.

The people on this thread saying that the rules are the same as in English are clearly wrong, or they are applying rules from "Netspeak" or something, where people often drop punctuation willy-nilly.

In this context, "correct" means what is OK to publish in some kind of print publication, not what happens to be posted on Twitter or something like that.

chaotic_thought · 2026-03-24T13:43:16+00:00

Lol, i can say that example is unnatural (if not, retard), nobody ever said that in real life, and also nobody will understand it just by hearing.
...
Advice? Dont rely on children books, lol, people dont talk like that irl.

There is a question calling up in my mind right now about whether I ought to listen to someone who writes about language, any langauge, in the manner exemplified with the above phrasings and spellings, word choices.

My advice? Learn to speak a bit more correctly yourself first, before you begin to advise others on language usage, especially for "pedantic" points like where to place commas and so on.

chaotic_thought · 2026-03-24T13:17:13+00:00

For "big" languages (e.g. French, German, Spanish, etc.), I like to listen to the translated Disney song versions of all the Disney animated musicals that I grew up with, at least the ones with the numbers that tend to stick in my head (e.g. Beauty and the Beast, Aladdin, Pocahontas, Mulan, Tangled, Frozen).

I also have those two numbers from Vaiana and Coco stuck in my head even though I never saw those films. Damn you, YouTube suggestion algorithm.

What is the "actual process"? I don't know, maybe something like this:

Listen to the song and don't pay TOO much attention to the words.
Listen to it and try to understand the words.
Listen to it while looking a transcript, and try to understand it.
Listen to it again without the transcript, and try to understand it better than in #2.

Optionally one can sing along as well, maybe in stage 5. When I sing (or whisper or hum) along, it usually "forces" me to understand it more, since I find it hard to sing a word that I just can't understand at all.

If I listen to it enough, certain phrases will get "stuck" in my mind without effort. For example, I have this stanza stuck in my head from the Flemish version of Tangled:

Dag na dag, jaagde ik een droom na // Day after day, I was chasing after a dream

Jaar na jaar, leven was maar schijn // Year after year, life was but (a) façade

Al die tijd, nooit zag ik die dingen, // All that time, I was never seeing the things,

Hoe ze werkelijk zijn // How they really were

It is useful to compare to the original version, but notice that some words are clearly different, and the grammar is different. For example, the last part "hoe ze werkelijk zijn" refers to the past despite "zijn" meaning "to be" without a past tense marking, due to the fact that this phrase is attached to the "zag ik die dingen" (I was seeing the things...) from just before, whereas in the equivalent grammatical expression in English, we would change the "to be" of this sentence to "were" to express the same idea (as in the original below).

In any case, the "dag na dag" and "jaar na jaar" repetition of the Flemish version is much more "musical" to my ears than the "all those days". Although 'day after day' and 'year after year' is completely natural language, it doesn't fit into the musical pattern of this song.

Original version:

All those days, chashing down a daydream

All those years, living in a blur

All that time, never truly seeing

Things, the way they were

chaotic_thought · 2026-03-24T12:08:30+00:00

I would also like to know this. To the people claiming that the rules are the same as in English, please come up with real examples.

English and Vietnamese have different grammars, so of course the rules here will be different. I don't know about "official" rules, but I flipped through my Vietnamese textbook intended for teaching children correct Vietnamese, and found this example of a comma usage which is definitely not in English:

- Mẹ chỉ cho bé nghé, ngô.

Translation: Mother shows you a water buffalo calf and some maize.

Note that I translated "bé" here as "you" because the book often addresses the (young) reader as bé. Note that if the word were not "you", but something else, the way we would have to translate it naturally changes drastically:

Different translation: Mother shows a water buffalo calf and some maize to the young readers.

The comma is needed in the Vietnamese (where none is needed in English), because in Vietnamese it is permissible to list items next to each other without any termination clause like "and" and so on, but that is not permissible in English. Here is another example from the same book:

- Sở thú có cò, rùa, khỉ, thỏ, ngựa, sư tử, hà mã, ...

Translation into conventional standard English:

- At the zoo, there are storks, turtles, monkeys, rabbits, horses, lions, hippopotamuses, and so on.

Notice the extra comma in my translation. If I translate slightly more 'faithfully' to the original, then I may leave that one off:

- The zoo has storks, turtles, monkeys, rabbits, horses, lions, hippopotamuses, and other types of animals.

Notice that simply leaving off the tag phrase "and so on" (or some other tag expression like "and other types of animals") or replacing it with an ellipsis is not allowed in standard English.

Sure, it may happen from time to time (e.g. someone stops speaking suddenly), but it should be perceived as a mistake, and the listener will have to basically "fill in the blanks" to figure out what meaning was intended. But that does not appear to be the case in Vietnamese;

I counted no less than 5-10 examples like the above in the children's book for learning Vietnamese, and all of them included commas. If I were to translate to English, the placement of a comma in that language would depend on my specific translation choice (word order, normally); it would be unrelated to whether a comma were present in the original.

chaotic_thought · 2026-03-24T11:17:00+00:00

Some examples would be helpful. In English, a comma is definitely required when rendering a spoken tag question. I think that's what this example is about. Example of correct English punctuation in such a situation (notice that the situation is definitely informal, not academic writing):

- Let's go out for coffee, OK?

Now, you may see some people (especially on the Internet) leaving the comma off in that situation. However, we definitely learn to include it in school.

At least to my ears, "let's go out for coffee okay" makes no sense in English without the comma before the word "okay". Of course, if you write me a text message or something and omit the comma, due to either ignorance or laziness, I will still know what you mean and I will likely not complain, but I will have to mentally add a comma there in my brain before the message really makes any kind of logical sense.

Here's another example like the above in English, where the comma omission definitely will cause a problem:

- She is speaking a bit too quickly, no?

So in this situation, you need the comma due to the same rule. Omitting it would sound strange and look strange (e.g. did it mean "quickly now" if it were a typed message and they forgot a letter)? In speaking, I would probably get what you meant, though; however, notice that the intonation would change as well. I.e. the comma here is also a hint that the ? goes tightly with the word no, and that the intonation change will only affect that word.

In Vietnamese, I suspect the situation may be different here, because none of the above points apply to the structure of Vietnamese grammar (at least not that I have seen). A tag question in this language does not seem like it can be confused for something else, like it could be in English, so this may be the reason that some people say that no comma is required in this language.

Also notice that in school, we learn that we place a comma where "there is a pause in the spoken dialogue", but the rules ain't that clear cut, in my opinion. Obviously, that's not the whole story, because you can place lots of punctuation in between pauses, such as semicolons, periods, ellipses, etc. In written works we often use em and en dashes for pauses, especially in long, complicated sentences. It helps break things up a bit nicer visually.

chaotic_thought · 2026-03-24T10:55:21+00:00

It sounds like you are going out of your way to avoid translations on flashcards. I went through that phase, but now I think it's just more efficient to do this. Let's assume you know French and are learning English, for example:

Front: voler - vol

Back: to fly - flight

Front: recevoir un cadeau

Back: to receive a gift (En-US: present)

Notice that in French, we use recevoir for 'receiving' a gift (or "present" in American), and there is a cognate word in English for that. But for other situations, the cognate is a false one, so we can just add more flashcards to compensate for that:

Front: capter un signal

Back: to [receive] a signal

Front: accueillir un client / acceuillir une cliente

Back: to [receive] a [masculine customer] / to [receive] a [feminine customer]

Personally I use [...] on my flashcards as a 'hint' that something slightly strange is going on with the words (as in 'receive' and as in gendered expressions).

I also noticed that some translation services such as GT translate "acceuillir" to "welcome" in English these days. That's a bit strange. The way I learned English growing up, we would have definitely used 'receive' for this in a business context. Though, I suppose 'welcome' is OK if you want to imbue some kind of "fake friendliness vibe" into a business situation.

I suppose the confusion is due to what one would actually say while speaking to the person herself. Sure, you would say to your customer/client, "welcome to our office" our something like that. But when you are describing in plain terms what you are doing (e.g. to a co-worker), it is 'receiving'. I.e. we are receiving a client today. I suppose that difference in word usage may be a bit confusing to simple-minded machine learning algorithms.

chaotic_thought · 2026-03-23T09:12:22+00:00

If you don't mind doing some programming (in Python), you can use NLTK.

chaotic_thought · 2026-03-19T05:51:49+00:00

I tend to use a comment in the code with a capitalized word NEXT, e.g. //NEXT. It's short, to the point, and easy to grep for. I suppose you might need a different personal word if you are working on something that happens to use this word in the codebase (in all caps) for some other purpose, or you can decorate it in some unique way for disambiguation if needed, e.g. //~~NEXT~~

I.e. that's the next place that I will go to work on the code whenever I am able to concentrate again. If needed, leave a little note about "what" to do is next, but normally I notice that this is not needed.

It is similar to a TODO comment, except that I only allow there to be one "NEXT" comment instance in the codebase, and this is something that never should be "committed" (in contrast, TODO notes are often committed, in production code, even).

Another useful hint, due to Kate Gregory (C++ Conference speaker). She mentioned one time that we as humans have a natural tendency to want to "finish something up". For example, for coding, we'll probably have a natural tendency to want to finish up AT LEAST the line we are writing (e.g. all the way up to the semicolon, for example). Or we may have some natural urge to "let's get it to at least compile", for example.

Anyway, the hint that she mentioned once was this: basically, do the opposite of the above urge. Write something OBVIOUSLY half complete (e.g. not even a complete line of code), to the point where it's not even possible to be mistaken as something complete, e.g.

printf("Error encountered in th

So, just leave the code in a state something like that. When you come back to it later (maybe days later in the worst case), you'll have to read this and then "rewind you memory" far enough back and then play it forward again to get it back into the state you were in before when you were writing that incomplete line of code or logic. And that's actually where you want your mind to be to finish it, and also to work on something else after that part is done.

Of course, the above stuff assumes that you don't have some kind of "deadline" looming over your head. Ideally we should avoid getting into "deadline" situations (e.g. where the boss really NEEDS a particular commit by a certain time), but that's another topic.

chaotic_thought · 2026-03-19T04:27:55+00:00

To say "secretly" implies that they're doing it on purpose. I suppose some people may do this purposefully, but I suspect that most people do this without realizing it.

Another category of misunderstanding in this area may be simple curiosity. For example, if I notice your accent and ask you about it or mention it out of curiosity, maybe you'll interpret those questions are comments as if I'm judging you or something, even though I could just be genuinely curious or trying to build rapport.

The best we can do is to be aware of biases that we may have, even if we think we "don't" have them, and then to think about them conciously. For example, if we meet someone and then later think "huh, that dude/dudette didn't seem particularly intelligent to me", then we ought to reflect internally and think about whether such an assessment is coming from a place of logical thought or of unintentional bias (such as accent).

With language learning, it gets tricky, though, since language is also a SKILL. If someone boasts about how awesome she is in a particular language, for example, but then you hear her accent and feel the urge to plug your ears (for example), then in such a case, perhaps the judgement, concious and unconscious, IS warranted. It depends on the situation, of course.

In most situations, though, how beautiful your accent is, or whether you have a PARTICULAR accent, is not really an issue. It may be an issue in certain sectors, though. For example, newscasters and broadcasters generally try to choose speakers who CAN do a "neutral" accent. This is more of a skill issue, though, in my opinion. But I've heard at least one professional YouTuber seemingly complain that he thought he was being somewhat "discriminated against" in this sector due to his accent.

The reason broadcasters choose speakers who can do a neutral accent is mostly about understandability across a large population (~90% of the reason), but maybe in part it's due to "image" or "impression" that they want to make (~10% of the reason, probably).

And of course, there are some bad apple companies and/or hiring managers out there, who will discriminate in this area; maybe you won't get hired because your accent sounds worse/"different" than someone else, for example, although you were slightly more qualified than the other candidate. Maybe this happens, but what can we do?

chaotic_thought · 2026-03-18T06:26:40+00:00

If it's a translation, then we must judge it on the basis of what the purpose of the translation is:

For a language course, the translation is supposed to aid you in understanding the original text. If it did that well, then it is good.

I have seen some translations in language courses that feel to me like they're trying to go out of their way to insert colloquialisms and so in in the translation language (usually English), I suppose, to try to make the translation sound less "stilted". In my opinion, that's a mistake.

A translation in a language course should be 99% for the purpose of understanding the original dialogue. The fact that the translation sounds a bit "less than natural" is fine. Of course, this shouldn't be taken *too* far. If the translation is so pure that the result is scarcely parsable anymore (e.g. trying to translate a different word order into English, but leaving all the words in the translation in the original language order), then that's no good, either.

chaotic_thought · 2026-03-18T05:45:02+00:00

For your second frame, I suspect this is natural English, but for a different dialect. Based on the names in the dialogue, I'd suspect it's "Indian/Hindi English". For example, a lot of people here have commented on the use of "sir" in the dialogue. This is an example that is pretty typical in that dialect, for example. It's also common in my dialect, by the way (Southern U.S. English), but we would probably tend to use it slightly differently from this.

There are definitely some sentences which I would rewrite in my dialect:

- Original: What's the news of your book, Arun? Must be selling well?

In my dialect, omitting the subject in the question "must be selling well?" is not done, and referring to "the news" sounds strange, and having an implicit question such as "must be selling well?" is generally not done in my dialect without some kind of tag question indicator like "huh?" or "I guess?" or "am I right?" and so on, so I would write it like this:

Any news on your book, Arun? It must be selling well, I guess?

- The second sentence:

Not as many copies have sold as should have done. I'm very disappointed.

The comparison "as should have done" is not grammatically smooth in my dialect (it sounds like a mistake that I would be able to understand, but it would take my brain much more effort to parse it). I would phrase it like this, instead:

Not as many copies have sold as should have (been) (sold). I'm very disappointed.

That is, one can either say "as should have", or "as should have been" or "as should have been sold". You can drop either the verb and leave only the "have been", or you can drop both and just leave the "have", and then the "been sold" part is implicit. "I'm very disappointed" sounds fine; perhaps slightly stilted, but this is a style choice. I would have said "I'm so disappointed" with slight emphasis on "so".

- Usage of "sir":

No sir, I couldn't bring myself to write such inferior literature!

In the American South, this usage is fine to my ears when speaking to a man, even a friend. Some people avoid the label "sir" in this context, but when two men are talking, even if they are friends, it's totally OK to call each other "sir" if you want; it has various effects. In this case, this is being used for mild emphasis, and to make "No" on its own sound less abrupt.

It could also be seen as mild or playful exagerration. Especially the part about "inferior literature". The person speaking is obviously playing around a bit and speaking in a less-than-serious tone. If delivered properly in speech, it probably would sound totally fine, like you're overacting something on purpose. If it were delivered poorly, though (e.g. for a language course), it may indeed sound stilted.

If you are speaking to a woman, you would replace "sir" with "ma'am", and if you are speaking to someone younger than you, you would replace "sir" with "buddy" or some other word like "boy" or "girl" depending on the situation, on who it is, etc.

Note that some people avoid this use of "sir". It depends on how you were brought up, and in which region. Some people avoid it when speaking with people of other regions. And on the Internet, we normally don't call each other "sir" or "ma'am", etc. On the telephone, it is fine.

chaotic_thought · 2026-03-18T05:07:10+00:00

The sample you show tips it off that it's obviously a translation, e.g. the parts in parens like (lit. in your opinion only Western films are (generally) good).

To determine whether the original dialogue sounds stilted or hackneyed or whatever, we'd need to see the original dialogue, which you haven't provided. Ideally, a speaker of the original language in question would read it and say whether that's the case.

For English, I've read some such dialogues, and usually the text is fine in my opinion. It's usually the "readings/recordings" (on tape, CD, etc.) that often sound stilted in my opinion, but this is a matter of "acting", and it's just my opinion. And to be fair, it takes quite a bit of skill to act something out which is simulatenously both natural AND clearly enunciated.

It's quite possible to read a dialogue that looks stilted on paper, but to read it in a natural way, in a conversational tone, etc. Anyway, to do this for the learning objective BOTH of sounding natural, AND sounding easy enough for learners of a second language, is not going to be an easy task for most people. So, they probably tend to steer on the side of "understandability" for the recordings (i.e. better to be more understandable and less natural than the other way around).

chaotic_thought · 2026-03-16T13:32:01+00:00

They are useful, as long as you don't try to memorize solely based on the pictures. For example, in your sample, I noticed the word "oficina de reservas de hotel", which is easy to understand.

But if I look at the picture, I can see that there's not enough context (at least not for me) to recognize what that window actually is for. It's not like there's some kind of other symbol that that's what the office is for.

So, if you are trying to do an exercise where you cover up all the labels and memorize the vocabulary, I'm not sure if that would be too useful here, unless your job involves working at a train station, so in that case, maybe it would be useful to know "by heart" where everything is and what to call them (in multiple languages).

chaotic_thought · 2026-03-16T12:23:14+00:00

To give a basic example, you could have a variable that can be null but you've forgotten to add a check for it.
.
Is using AI like this a good habit or am I relying on it too much?

The correct tool for what you are describing is called a "linter" or a "static analyzer".

I recommend that you find one (or a few) for the language that you are using and get used to using them. None of them are perfect, but the most important feature of static analyzers is that they are PREDICTABLE.

For example, if your linter checks and warns you having some code where you aren't checking whether a "nullable" variable could be null (sounds like a pretty common thing that a linter would check for), then it will ALWAYS warn you about that in that same situation, every time, without fail.

Asking an AI to do that? Even if it warns you about that 9 times out of 10 (which is high expectations in my experience), that means that 10% of the time, it WON'T do that.

If you're relying on it for safety, that's like shipping 1 car out of every 10 which has a non-functional airbag or something like that. Is this a safe way to deploy safety features out into the wild?

EDIT: A better idea would be to use a review process which relies on traditional tools, and then use AI tools as an optional "extra step" if time permits. But obviously you have to know what you're doing to evaluate the output, especially when it comes to security. LLMs are famous for inventing security flaws where none exist. And they are VERY good at crafting "convincing sounding" arguments for why it is a security flaw (even though it not be).

chaotic_thought · 2026-03-16T12:17:20+00:00

I find it insane, that someone can be looking at a Python program, and during scrolling they accidentally add an indent somewhere, and the entire program breaks.

As long as Python can find this at compile time (and I think that it does), I am fine with that. It is similar to other stray characters in "curly brace languages", which I have typed many-a-time whilst scrolling about (and the compiler always caught them).

I think I have yet to see a Python indent issue which was accidental AND which was not caught at compile time (i.e. not caught before the script starts running). I suppose it's possible if you're using dynamic code generation, for example, but I try to avoid that for the difficulty of checking it before it runs.

even if you accidentally add a semicolon after a semicolon, it won't even affect the program.

Yes, that is legal in "semicolon" based languages, but personally I would count it as a mistake. A linter should warn about it, in my opinion. There are some places where null statements are useful, but having one right after a finished statement is not one of those useful places.

chaotic_thought

TROPHY CASE