sorted by: new top controversial old
[-] ylph@lemmy.world 11 points 9 months ago

What is your source for this ? Recent polls show reunification support is still <2%, with about 6% open to reunification eventually but not now.

In 2018, before the crackdown in HK, the reunification support was 3%, with 13% open to it eventually - the events in HK have definitely significantly eroded support for reunification in Taiwan.

I have family in Taiwan and literally don't know a single Taiwanese person that wants reunification with the PRC.

[-] ylph@lemmy.world 10 points 10 months ago

Early computers had very limited resources, RAM, storage, etc. (first computer I worked with only had 4k of RAM for example) It often made sense to only use the last 2 digits of the year as an optimization in many common tasks that computers were used for, as both the 1800s and the 2000s were far enough away that most basic date calculations worked fine. Also, the industry was changing rapidly, and few people expected their software to be used for more than a few years - certainly not for decades, so focus was usually on solving the immediate tasks as efficiently as possible, without much consideration for the distant future.

However, it turned out that a lot of the code written in this period (70s and 80s) became "legacy code" that companies started relying on for far longer than was expected, to the point that old retired COBOL programmers were being hired for big $$ in late 90s to come and fix Y2K issues in code written decades ago. Many large systems had some critical ancient mainframe code somewhere along the dependency chains. On top of that, even stuff that was meant to handle Y2K was not always tested well, and all kinds of unexpected dependencies crept up where a small bug here, or some forgotten non-compliant library there could wreak havoc once date rolled over into the 2000s.

A lot of the Y2K work was testing all the systems and finding all the places such bugs were hiding.

[-] ylph@lemmy.world 17 points 11 months ago

Chinese is also not right - 正确的 (zhèngquè de) means "proper"

Left and Right as the sides are 左 (zuǒ) and 右 (yòu) - you can also add 邊 (biān) to each which means "side" to be more explicit, but they are also used separately in many contexts where the left/right meaning is needed.

The Chinese characters for 左 and 右 actually originated as pictograms of the left and right hand in the early forms of Chinese writing, but later forms both contain general "hand" component (𠂇) with components 工 and 口 added for differentiation

[-] ylph@lemmy.world 6 points 11 months ago

What's wrong with using a text editor to remove lines ? In vim for example :g/pattern/d or :g!/pattern/d with regular expressions is a powerful tool for removing lines in bulk if needed.

[-] ylph@lemmy.world 16 points 1 year ago* (last edited 1 year ago)

The first computer I used was a PDP-8 clone, which was a very primitive machine by today's standards - it only had 4k words of RAM (hand-made magnetic core memory !) - you could actually do simple programming tasks (such as short sequences of code to load software from paper tape) by entering machine code directly into memory by flipping mechanical switches on the front panel of the machine for individual bits (for data and memory addresses)

You could also write assembly code on paper, and then convert it into machine code by hand, and manually punch the resulting code sequence onto paper tape to then load into the machine (we had a manual paper punching device for this purpose)

Even with only 4k words of RAM, there were actually multiple assemblers and even compilers and interpreters available for the PDP-8 (FOCAL, FORTRAN, PASCAL, BASIC) - we only had a teletype interface (that printed output on paper), no monitor/terminal, so editing code on the machine itself was challenging, although there was a line editor which you could use, generally to enter programs you wrote on paper beforehand.

Writing assembly code is not actually the same as writing straight machine code - assemblers actually do provide a very useful layer of abstraction, such as function calls, symbolic addressing, variables, etc. - instead of having to always specify memory locations, you could use names to refer to jump points/loops, variables, functions, etc. - the assembler would then convert those into specific addresses as needed, so a small change of code or data structures wouldn't require huge manual process of recalculating all the memory locations as a result, it's all done automatically by the assembler.

So yeah, writing assembly code is still a lot easier than writing direct machine code - even when assembling by hand, you would generally start with assembly code, and just do the extra work that an assembler would do, but by hand.

[-] ylph@lemmy.world 18 points 1 year ago

The kids always adapt though.

There is a strong survivorship bias in this though. Some kids do adapt, maybe even most, but many still are harmed, and have been by unhealthy exposure to radio, television, videogames, etc. in the past. Social media is even wreaking havoc in the older generations right now.

It's easy to point at the survivors and the success stories and say see, there is nothing to worry about - but that's also a bit like pointing at the lifelong smokers who do not get lung cancer as an argument against promoting non-smoking.

view more: ‹ prev next ›

ylph

joined 1 year ago