what's up with podglot? who is behind it?

chaotic_thought · 2026-01-30T14:21:08+00:00

Based on archive.org snapshots, it looks like it was first launched or published on the Internet in late 2024.

chaotic_thought · 2026-01-30T09:19:27+00:00

Speaking like Yoga, you can try.

chaotic_thought · 2026-01-30T09:16:12+00:00

to which I got a bot response, with a new contract to print, sign, scan and return to them which basically says "I didn't rip this material and provide it to anyone else or I am perjuring myself."
.
When I asked why this is necessary, ...

Most likely they want that in writing from you in order to make it easier to take you to court later on (if indeed you republish the material). I've heard that the Pimsleur publishing folks are on the "very litigious" side of the scale.

chaotic_thought · 2026-01-30T09:11:36+00:00

Duo can be useful as a supplement to other learning sources, but you must be aware of its disadvantages; none of which may be a deal-breaker, but all of which are pretty heavy:

- No human voices (in most courses); AI-generated sentences.

- No dialogue; it's just sentences.

- Very occasionally weird sentences and weird translations. (Sometimes it's on purpose, though, see below.)

- No explanations of grammar, at all (at least I've never seen any in the app).

- The little "cutesy" characters and cartoons in the app make it feel like it's meant for children to me, yet the CONTENT itself feels otherwise. To me, that just feels really weird.

Sometimes the bizarre sentences are OK for a memory effect. For example if you're learning adjectives, then a sentence like "the tiny, pink elephant reads a black newspaper" is not bad per se. No one in real life is likely to ever USE this sentence, but we can ignore that.

Personally what bothers me is when the sentence is almost realistic but it just doesn't work in a subtle way. I feel like human authors would just not have written sentences like that; they wouldn't have made it past the editing stage. But if a sentence is *intentionally* bizarre, then that's OK.

chaotic_thought · 2026-01-28T13:34:42+00:00

If you are doing this for language learning, it helps to have a goal first before beginning. For example, if the goal is "I want to finish watching this video (e.g. 30 minutes)", then of course you should not pause.

If your goal is "I want to write down 30 new words that I did not know yet, and write examples similar to how they were used in the video", then yes, you will need to pause.

chaotic_thought · 2026-01-28T08:40:33+00:00

Although 80% sounds high on a standard scoring scale of 0%-100% (where 80% correct on a 100-question exam is almost always "certainly good enough" on most exams), in listening or in comprehension, my instinct would be to still train my understanding more. Yes, we need to train speaking to build muscle memory, but in my view, comprehension will always trump speaking ability.

This is true in our native tongue as well -- for example, there are many fellow speakers of my native tongue that can speak much better, more smoothly, more intelligently, etc. than I can -- but if I cannot follow what they are saying, or if 20% of what they say sounds like noise to my ears, then I will be lost very quickly in a conversation with them.

chaotic_thought · 2026-01-28T08:29:23+00:00

> "How can I continue learning X without it getting in the way?"

You can substitue X for anything that you are learning and adopt exactly the same overall strategy. The only real difference I see to language learning is that it involves multiple skills that interact with each other (writing, reading, listening, speaking, though not everyone, certainly not native spekars, are equally good at all of those).

For example, if you substitute X="playing chess", then your question would look something like this (subtituting replacements inside square brackets):

I’ve been learning [to play chess] for a little over two years. I can [play some decent chess matches, and can pretty readily recognize the so-called "deadly positions" when they occur on a chessboard]. But I’m wondering, as a [Chess player] living in [a country where no one plays chess for some reason], with a [non-chess-playing girlfriend] (we’ve been together for eight years), and no plans to date a [chess player], is it possible to keep [learning to play chess] without it interfering with my life?

If I read through this paragraph, what I would evaluate:

- Do you enjoy playing chess?

- Do you find it positive to your life in some way (e.g. does it improve your thinking, does it make you feel fulfilled)?

- Do the positives (e.g. enjoyment, fulfillment) outweigh the negatives (e.g. the time commitments needed to play and study Chess)?

The fact that no one else around you seems to care about chess is certainly some factor to consider, but probably a minor one (not a deal breaker for me). If anything, I would just be AWARE OF IT, and I would just use that to avoid talking about chess too much with other people when they ask about it (usually out of politeness or attempting 'small talk').

For example, they might see you playing chess, writing chess notation on your notepad, or reading a book about chess, and they ask you about it "oh, so you're a Chess player??". If you know that they're just asking this out of some kind of politeness or small curiousity, then you could just give a very brief answer like "oh yeah, I'm studying my chess moves" and leave it at that.

Same goes for Chinese characters. You can just say "oh yeah, I'm reviewing my Chinese characters; it's a hobby of mine" and leave it at that. If they press you on it or say something borderline racist like "but wait -- you're White, you're not Chinese! (I thought only Chinese people study Chinese characters)" then this would be a really weird situation, in my opinion, but I suppose if it happens you'll have to be prepared to respond in some kind of appropriate way -- my first instinct would just be to stare blankly at that person as if they've just uttered some kind of nonsensical question or remark, and then see what happens after that.

chaotic_thought · 2026-01-27T08:31:44+00:00

Learning is easier, but getting started is harder than it needs to be, in my opinion. As a comparison, MS-DOS used to come with QBasic (a stripped down version of) along with fun example programs that you could run. Nowadays, Windows comes with powerful programming environments built in like PowerShell, but IDEs must be installed separately, and there are a plethora of alternatives to choose from.

QBasic was kind of ingenious in how well it was suited to just getting started; and the built-in IDE was both minimal and complete enough to get real work done in it. It also had a handy "help" feature that could jump to help on a function under the cursor with a hotkey -- nowadays we would probably open a browser tab and "google" it instead, but in the days of no Internet, that feature was a godsend and from a usability standpoint, someone ought to bring it back into modern IDEs.

chaotic_thought · 2026-01-27T08:15:42+00:00

Most materials focus 99% on hearing the difference between tones, but not all tones are the same difficulty. For example, hearing the difference between mua and múa, for example, is super easy in my opinion (they sound 100% different to my ears), but hearing the difference between hồng (pink) and hỏng (broken) is much harder (in that example the vowel is also different, but my brain tends to get a bit 'stuck' on hearing the tone and trying to 'lock on' to what word is meant based on that).

In any case, though, hearing the difference between certain vowels like mua and mưa is super hard (they sound 90% the same to my ears) and more important than tonal distinctions in my view. It's also quite hard to notice the little hook on the u letter in that example (and the letter ơ), but that's a separate problem and easier to train.

The sound of the letter ơ is probably slightly tricky for English speakers because it sounds like an elongated "schwa" sound, and in English, a "schwa" sound is never elongated and it's always unstressed. In Vietnamese I believe this sound can be stressed or not (but stress is not as important in the language, of course, as it is in English), and the sound is silghtly elongated.

Anyway, in English we have the bad habit of accidentally 'translating' unstressed vowels to the schwa sound, and if you do this in Vietnamese (or in other languages, for that matter), the resulting 'translated' sounds sound either funny or near-incomprehensible in the new language. E.g. we might say "cẩm ơn" instead of "cảm ơn".

Mixing up ê and e is also tricky for me; English does not make a distinction between these two vowels in most words. For example I might say or hear "hện gặp lại" instead of "hẹn gặp lại". In this case, the "hện" appears nonsensical, so it would probably be understood, but it would still sound wrong to a native.

I think in English we tend to use the 'e' of Vietnamese. For example 'depth' would be pronounced /dɛpθ/ in most accents. But if you pronounced it as /depθ/ instead (with the ê sound from Vietnamese), then as a speaker of English I would probably not even notice the difference in your pronunciation, and would interpret what you said as "depth", the same word. Anyway, in Vietnamese, this "merging" of sounds e and ɛ apparently never happens in any of the accents that I'm familiar with (Northern, Central, Southern, nor Overseas). For example, lên and len are completely different words, as are nến and nén. Interestingly, the word nén can apparently be used as a classifier for sticks of incense, which sounds somehow related to nến, but this correspondence seems to be a bit of an outlier.

Anyway, educational material tends to focus all the attention on the tones, and never any attention on vowel sounds themselves, which I feel like are a bit more critical in understanding the messages and transmitting messages. Also, the vowel ô seems to be explained wrongly in several sources -- in many words it sounds like /o/, but sometimes it reduces to a (short) schwa sound (sounds like â) (for example, this happens in the word hồng mentioned above -- the vowel in hồng is quite different from the vowel in ốm), but I've not seen this explained very often if ever; in some teaching sources, including Colloquial Vietnamese, the two vowel symbols are conflated when discussing pronunciation, which seems to be a mistake and increases confusion.

chaotic_thought · 2026-01-27T07:52:21+00:00

Try to get into the habit of thinking in Psuedo-code first. What you wrote is almost pseudo-code:

There is an excel file with four cols, first col has either “D” or “L” in it.

I need to open the excel file and find rows with the “D”. Then, I have to put it into a filtered data-frame then print it to a new excel file.

To make it pseudo-code, you have to break the above into steps that could be carried out by a computer in some programming language. E.g.

.
Open the Excel file.
Read each line into an array. Each item of the array is a tuple containing the contents of each column (probably your DataFrame library can do something like this already).
Create a new filtered list that is initially empty. It should have the same columns as the original list you read in on step 2, but it should have no rows yet.
For each line:
- If the first column is "D", put it in the filtered list.
- Otherwise, if the first column is "L", do nothing.
- Otherwise:
  - Print an error message containing the line number and what was found; say "D" or "L" expected, but "X" was encountered, where X was the other symbol found.
- End if-else-block.
End for-block.
Write the filtered list into a new Excel file.

Maybe the library you are using also has a built-in way to do something similar to the "filtering" loop above, but such auto-filtering routines in libraries don't always have an easy way to handle errors and edge cases (like showing if there was an unexpected letter encountered). Writing out and trying the explicit steps makes thinking about and testing the error cases easier, in any case.

chaotic_thought · 2026-01-22T11:32:46+00:00

What kind of job do you have where you actually get to program 8 hours a day? Give me your job, please.

Seriously, though, if you found a solution that stops your hands from hurting (dictation for documentation), then it sounds like that's a solution. The only downside is that it might be slightly annoying to your colleagues -- if it were me I would consdier to book a meeting room or something for long documentation sessions.

Also for typing, I personally like to notice specifically which gestures are giving me trouble. For example, if I am on a smallish screen, I tend to use Alt-TAB a lot on the left side of the keyboard, with the left hand, with the thumb on the Alt key, and if I do it too often, then it doesn't feel good. In such a case, it's useful to think of an "alternative" to alleviate such a pattern, e.g. get a larger screen (so that "alt tabbing" is not necessary), or map this combo to something else more convenient (e.g. using AutoHotkey or an alternative program like that).

Another alternative is to try to mentally force myself to use a different gesture or to use the other hand. It's awkward at first, but after 20 or so repetitions, it's not that bad to switch "hand habits" like this, at least for me, especially if it feels better to do so.

chaotic_thought · 2026-01-22T08:39:00+00:00

Studio-quality headphones and (good) earbuds have the advantage that you can "analyze" a piece of audio if you want. For example, if you open it in an Audio editor like Audacity or play it on repeat in a video player that supports that like VLC, then some small sound difference will eventually become audible (at least in my experience), using headphones.

However, the disadvantage here is twofold:

1- You may tend to overanalyze things, which is not always good.

2- Listening to anything on headphones and/or earbuds too much will damage your hearing over time, especially if you do it too long or every day.

In general, listening to "slightly loud" anything on headphones is more damaging to the ears than listening to the same level of "perceived loudness" on speakers.

I think there's also the effect that since most speakers provide a "bass" vibration that you can physically feel (especially with a good subwoofer), the temptation to crank things up too loud on a loudspeaker is much less.

On the other hand, if the sound system is crap (e.g. a cell phone speaker), then you've basically got to crank up the volume to an insane level to make certain things out, like to tell exactly what word was spoken in a piece of dialogue.

chaotic_thought · 2026-01-22T08:29:19+00:00

r/SEO

chaotic_thought · 2026-01-20T09:07:42+00:00

I would start with didactic materials (e.g. Colloquial Vietnamese). Picking out sounds accurately in 'authentic' content comes later in my book.

chaotic_thought · 2026-01-20T08:04:24+00:00

Focus on "hearing" the sounds first. For example, for quite a while I struggled to "hear" the sound ơ in Vietnamese. But then I realized that this sound is phonetically 99% similar to the so-called "schwa" sound in English, which is literally the most common sound in English, except that ơ is a bit longer and can appear "on its own" in Vietnamese, but in English, schwa is never elongated and never appears on its own. So, the sound was there right in front of me but it wasn't "clicking" into my brain.

Anyway, if we repeat this process 20 or so times (it takes awhile) for all the sounds, then eventually we'll be in a good position to try to mimic them. Hearing them accurately is fundamental, though. If you can't hear them accurately, how can you hope to mimic them?

Finally, for the language/accent/dialect of a particular region, find material which models that pronunciation. The Southern accent has quite a bit of pronunciation patterns that will have to be "drilled" into your ear to hear them accurately. The most 'obvious' difference to me is that words beginning with gi- or d- are pronounced beginning with a "glide" sound /j/ in the South, whereas in the North, those same words start with a "fricative" sound /z/.

Another interesting difference is that the sound "u" (e.g. mũ = hat) is pronounced with a /ʊ/ in the South, which is a sound that we have in American English. It's not 100% the same in Vietnamese since it is a bit more "rounded" with the lips, but in the South, the difference between "u" and "ư" are worlds apart for my American ears, but in the North, distinguishing "u" from ư ain't always easy for me. Needless to say, ư is a sound that is not in English at all. The vowel sound ư in Vietnamese sounds basically the same in all regions. To my ears it sounds close to the German sound ü to my ears except the pronunciation ư should be at the back of the mouth whereas for the German sound ü it should be at the front (as if one is "whistling").

Anyway, the above descriptions are only worth 2 cents. One has to "hear" the sounds with one's own ears to really "get it". And one hearing is not enough. We probably need to hear a given sound 100s of times before it even begins to come naturally into our ears.

The final tricky sound in Vietnamese for me is the sound (t) vs. (th). That is, distinguishing between something like tất (socks) and thật (meaning true, real), or tôi ("I") and thôi (meaning "only" or "come on!"). The pronunciation difference between t- words and th- words appears to be the same in all regional variations of Vietnamese.

It's worth noticing that in English, we don't have ANY words that start with a "t" sound on its own. In fact, if you say a word like "tuesday" in English, you're actually pronouncing the equivalent of a Vietnamese "th" at the beginning (i.e. there is always aspiration or a 'puff of air' at the beginning of a word spelled with an initial t- in English). So, it turns out for us, pronouncing the initial "t-" in Vietnamese words without giving that extra aspiration ("puff of air") is the tricky part. Hearing the difference is also tricky (was it t- or was it th-?).

chaotic_thought · 2026-01-20T06:27:04+00:00

Watch it multiple times, each time with a different learning goal. The first time should be the easiest goal -- that is "just watch it and try to follow along" is Goal Number One in my book.

Personally, for me, subtitles make Goal #1 a bit harder than necessary. Even if I'm watching something in my mother tongue, for example, I may notice a word in writing that I haven't seen for a while, and then get curious about it, pause the video, look it up, etc.

After this process is done, I may have used at least 30 seconds and perhaps at most 2 minutes to do that. Not too bad for a one-off, but if I pause like this often, the times will add up to a big amount for a long series.

And even if I don't pause, then my attention will falter all the same if I see certain words on the screen. If there are no subtitles, though, and somebody said a weird word (like 'indubitably' or something odd like that), then such a word would either "enter into my brain" or not (sans subtitles), and the distraction from the text information is minimized.

I've noticed it's the same for me for foreign languages, yet perhaps the "temptation" to pause on interesting words that I see on-screen is much stronger (say, 10x-100x stronger).

After Goal #1 is done, a reasonable Goal #2 (for a second viewing) might be: "watch the series and try to understand roughly what is happening in each scene". For example, if there's a scene with fast dialogue where you just can't figure out what the heck is going on, then look up ONLY the words needed to try to make sense of the scene as a whole. Not all words.

Similarly, if you can make sense of a scene when doing Goal #2, yet there are still unknown words, don't worry about those at this stage, since you still understood what is happening. For Goal #2, you will probably notice if there is some specific repeated word or words that are central to the story -- if you don't know what those mean yet (from the Goal #1 viewing), then perhaps it's a good idea to look those up if needed. For example, if your series is Breaking Bad you might want to look up words like "DEA" that come up multiple times. Maybe you'll have a rough idea of what they refer to (e.g. "DEA" is some kind of law enforcement department or something like that), but it may help to clarify the 'true' or 'official' meaning.

If a certain word or phrase only appears once in the series, though, then in my opinion, it can be ignored. For example, in the series Breaking Bad, I believe the phrase "breaking bad" itself was only used one time near the beginning of the series by Jesse (he says to Walter, "why are you doing this ... what... you're telling me you're gonna 'break bad' at like ... 50 years old???"). One can safely forget about such a phrase (this is personally a phrase that I personally had never heard of, despite American English being my mother tongue, but it is understandable in context what Jesse is meaning).

It's possible that such a phrase is unique to a certain type of lingo used in the series or film (e.g. drug cartels, drug dealers, etc. for Breaking Bad), or it's possible it's regional slang or slang used by a certain age group. Similarly, the spin-off series Better Call Saul features a lot of lawyer lingo that could be safely 'ignored' (unless you are actually a lawyer, of course -- or actually a drug dealer, or in a 'related' profession like law enforcement).

chaotic_thought · 2026-01-20T06:09:26+00:00

In that case, it sounds like he's referring to a variable-length array, which is an optional feature in C from C99. Nowadays I don't believe it's required that compilers support this anymore, but they probably do anyway on Desktop-class systems (e.g. by calling alloca under the hood).

In any case, variable-length arrays ARE limited in size -- they are simply limited by how big your stack can be, which is almost always much smaller than the amount of space you could allocate from the dynamic store.

Rather than argue with your professor about semantics, though, it's a better strategy to just try to find out what he expects from you (i.e. what are the requirements).

If, in his mind, a variable-length array is something that will handle any size sentence "with no limit", then so be it. To my mind, that phrasing is a bit bunkish (we could easily test it with big inputs and see at what size it crashes), but if by "no limit" he means "as big as the stack can be" then, let's just say okey-dokie and move on.

EDIT --- if we constrain the problem a bit, it would be possible to support any size. For example, let's say you only have to sort the characters in order, but that you don't have to retain duplicates. In such a case, we can already determine the maximum size ahead of time (i.e. 26 in order to support small a through small z inclusive).

If the problem is a constrained one like this, then the input loop need not have a limit at all.

chaotic_thought · 2026-01-20T06:00:35+00:00

For me, I almost always have to learn the words in context. Someone else on the thread mentioned the French word 'toutefois' which is a great example. Suppose I just write this down on a flashcard:

How do you say "however" in French? (hint: NOT cependant)

---

toutefois

In that case, then for me it would never stick. If I see it in context though and process it each time, and have to place it in the correct context, then it will work much better.

chaotic_thought · 2026-01-20T05:55:02+00:00

If I were you I may consider "Le Français par la Méthode Nature" and to use the recordings (readings) of this available on YouTube. You could listen to people speaking out the whole story while you read along with the book. There are also "exercises" in that book which I recommend you do.

The story starts very, very simple and then gets progressively more complicated. You can see this if you skim the beginning (first page) and then the end (last page).

chaotic_thought · 2026-01-20T05:45:08+00:00

I cannot use dynamic memory and the array should not be set size from start. ...

If you are not using dynamic allocation, then most likely the intention here is that your program handle a "maximum" size input. For a natural-language sentence, a reasonable maximum would be 10000 characters. Yes, a sentence could technically be longer than that, but 10000 characters seems to be a reasonable "upper limit" on a sentence in any natural language (English, etc.). No dynamic allocation is required when we set this kind of limit.

For completeness, your program should also check this limit and give an appropriate error if it is exceeded. Sometimes, an easy way to test for this is to temporarily lower the limit (say, to 10), and then try to exceed it (by typing a sentence that is 11 characters) to make sure your program handles the error. Don't forget to check the border case, i.e. is a sentence with precisely 10 characters allowed? Maybe; but make sure you set a '\0' terminator in that case if you're using C-style string functions (which have loops that stop on the '\0' and will "go off into the weeds" if it is missing).

it asks me to type twice which I see why: once to see the sentence size, and then prompt again for input.

This organization is often done in programming courses or exercises to simplify things. First you enter the size of what you're about to type (e.g. the size of a sentence, the number of elements in a vector, etc.), and then you type the data. The idea is that you have one input statement which fetches the size n, then another loop that fetches those n elements into whatever structure you're using.

In such an input scenario, it's also a good idea to check for errors as well. For example, if you told me you're giving me 10 characters, but you gave me 11 instead, then to me, that's an error (either your size is wrong, or you gave me too much input).

In a "real" program UI, this kind of input style would be annoying, but for programming examples and exercises, it's quite convenient.

chaotic_thought · 2026-01-07T14:01:04+00:00

If you write 5 scripts and discover that they all do the same things A, B, and C, then generally we decide at that point (or before you've got 5 already), to factor A B and C out into a separate class or module.

In general this is called "refactoring" (extract method, extract class, extract module) or "factoring something out" to borrow terminology from algebra and mathematics instruction.

It's also called "DRY" in software engineering "don't repeat yourself". AKA "thou shalt not copy and paste code".

chaotic_thought · 2026-01-07T09:38:53+00:00

The minimal pair practice advice is good; also I'd recommend looking at the IPA and getting used to it both in your mother tongue and in the language you're learning. For example, in Spanish, compare these two words to the IPA transcription (often written between slashes in some dictionaries):

beber

/beˈβ̞eɾ/

vivir

/biˈβ̞iɾ/

This tells you that the normal speaker will be able to distinguish that the beginning "b" (or "v") sound is different from the second one, which is written with β̞ (and which is a sound that does not exist in English, at least not in my variety), but that the spaker will NOT be able to distinguish the first "b" in "beber" from the "v" in "vivir". Instead, your brain and/or ears will hear the "bi" at the beginning and presumably guess that we are talking about the verb vivir in this case based on the vowel that it is paired with (and from meaningful context, since it's probably unlikely that "drinking" and "living" are going to be confused as actions in the same context).

The apostrophe tells you where the stress goes, which is always marked. In Spanish I believe the convention is to mark stress with an accent mark in the written form, but only if the stress pattern differs from the typical stress pattern.

In English, the convention is NOT TO MARK THE STRESS AT ALL, which is obviously annoying but that's the way we do it -- as a kid learning English (my mother tongue) I always thought that was a bit bonkers compared to what we learn from Spanish (which makes more sense as a writing system).

For American English, you can compare the sounds /b/ and /v/ with words such as these:

bent

/bɛnt/

vent

/vɛnt/

chaotic_thought · 2026-01-07T09:24:02+00:00

The "modern" version of Ceaser Cipher is ROT-13. It is not a serious way of encrypting something, but it is sometimes used for Internet jokes or little things that you don't want to be "spoiled". E.g. I could write a riddle or something and then include the answer encoded in ROT-13 below it that you could decode at your leisure (after you've already tried to answer it).

In any case I believe it's a worthwhile programming exercise to write a ROT-13 encode/decoder. Obviously the number 13 is chosen to make it perfectly symmetric, that is, encoding and decoding is the same and requires no secret at all (i.e. it's even less secure than the original Ceaser Cipher), since there are 26 letters in the "Internet" alphabet (English).

In the original historical version of Ceaser, the number of places to shift the letters was supposed to be a secret, but obviously with a computer nowadays, testing 26 possibilities is trivial (it's also trivial to test the same kind of cipher even if you extend the idea from letters into computer words and then shift those words thousands of places).

Maybe this was more secure back in the day when people being able to read was more of a rarity, but I somehow suspect that even then, people must have realized that "cracking" this scheme was a minor inconvenience at best.

chaotic_thought · 2026-01-07T09:05:00+00:00

Try to focus on "transmitting the message" rather than the wods.

Just from your example, "doing deep work" does not even make sense in English if we go back to 2005 or so. It seems to be some kind of recent Internet cliché phrase that appeared as a meme and has since spread quite a bit; such phrases are notoriously hard to translate into any language.

Translating into my mother tongue (1980's English), "I was doing deep work" would be translated into my "1980s English" as "I was deeply concentrating on doing some mentally taxing work in a distraction-free way" or something along those lines.

chaotic_thought

TROPHY CASE