It's theoretically possible for a local government to levy an income tax, but a lot would need to change -- much more than just changing tax rates. Employers and banks report income to the federal government (and states, I suppose, but I live and work in Texas so I don't know much about that). They would have to report that information to towns and cities too. There's also the problem of granularity -- how does an employer or bank know where someone actually lives? If you have a P.O. box in a town, do you have to pay taxes in that town? If you work in a different municipality (not uncommon!), do you have to pay taxes there too? If you have a home in one town, work in another, but spend most of your free time hanging out in a third, are you completely off the hook for supporting the third town?

You could have the federal government collect all the money and then allocate it to state and local governments, but that's a massive change in how American society works, and I'm not sure it's any less complex in the end. Some of the complexity in the tax code (e.g. different levels of capital gains tax) is a policy choice, but some of it reflects the complexity of the real world.

I agree with your overall point of simplifying taxes by merging more things into income tax, but some of the taxes you mentioned are levied by local governments to fund themselves. The United States has a federal system; it would be a much bigger change to centralize all of the funding.

1. When working with small rectangles, I had trouble getting the rectangle to move instead of enlarge. It looks like holding down the mouse button for a second makes moving more reliable. The UI should make it clearer what I'm actually doing.

2. If I open MonoSketch in another tab, I can't make a second diagram at the same time as the first -- there seems to be one shared context between tabs. I would like to be able to make a new diagram separate from my current one.

The kana are usually written in a table where each row is a vowel and each column is a consonant, like on Wikipedia[1]. Most columns of the table have five characters, each representing the same consonant combined with one of the vowels. For example: か/き/く/け/こ ka/ki/ku/ke/ko, ま/み/む/め/も ma/mi/mu/me/mo. Some columns have "missing" sounds (や/ゆ/よ ya/yu/yo); but what's important for our purposes is that some columns have irregular sounds: さ/し/す/せ/そ sa/shi/su/se/so and た/ち/つ/て/と ta/chi/tsu/te/to. There are no si, ti, or tu sounds in standard Japanese; they have shi, chi, and tsu instead.

Using diacritic markings gets you more consonants. Most of these are made by adding a couple tick marks to the corner of the character, which makes the consonant voiced instead of unvoiced. For example: か ka -> が ga, と to -> ど do, ひ hi -> び bi. But the irregular sounds stay irregular: し shi -> じ ji instead of zi, ち chi -> ぢ ji (again) instead of di, and つ tsu -> づ zu instead of du. (す su -> ず zu gives the same sound but in a regular way.)

You can also combine i-vowel characters with y-consonant characters to get sounds with consonant clusters: き ki + や ya = きゃ kya, み mi + よ yo = みょ myo, etc. The irregular sounds remain irregular: し shi + ゆ yu = しゅ shu (instead of syu), ち chi + や ya = ちゃ cha (instead of tya), じ ji + よ yo = じょ jo (instead of zyo). There's a Reddit post with a nice table showing all the available sounds[2].

Now the problem for romanization is this: Should the romanization reflect the irregular sounds in the spoken language? Or should it reflect the regular groupings of the kana characters? づ and ず might both be pronounced "zu", but they come from different linguistic origins, just as "bear" and "bare" do in English. The Hepburn system uses spellings that match the sounds, while the current standard (Kunrei-shiki) uses spellings that match the kana grouping: し si (instead of shi), ち ti (instead of chi), じ zi (instead of ji), つ tu (instead of tsu), じょ syo (instead of sho), etc.

The Hepburn system tells you how to pronounce the word[3] at the cost of being a lossy encoding. For anyone familiar with the Latin alphabet, that's almost always the better choice, and it's nearly universal in the Western world. Kunrei-shiki does better reflect the underlying structure of the Japanese language and its native writing system, which is probably why the Japanese government preferred it. But anyone who wants to learn the language is going to learn the kana almost immediately (it's just a few hours with flash cards), so IMHO that's pretty small advantage.

I deliberately didn't talk about long vowels, glottal stops, the differences between hiragana and katakana, different pronunciations of ん (n), or how to handle ん (n) followed by a vowel, but if you're curious about Japanese romanization those topics may also be of interest to you. I can try to explain more if anyone's curious.

[1] https://en.wikipedia.org/wiki/File:Kana_chart_1.png [2] https://www.reddit.com/r/LearnJapanese/comments/awzw04/kana_... [3] Most of the consonants are the same as English or close enough and are trivial to write in the Latin alphabet. The big exception is ら/り/る/れ/ろ, normally written ra/ri/ru/re/ro but it's not really the English r sound. See: https://en.wikipedia.org/wiki/Voiced_dental_and_alveolar_tap...

I'm not sure a full ban is possible, but LLM-written comments should at least be strongly discouraged.

Comments URL: https://news.ycombinator.com/item?id=45649490

Points: 2

# Comments: 0

Theoretically, it still doesn't hold up, at least not for the foreseeable future. PCBs and integrated circuits are basically two-dimensional. Access times are limited by things like trace lengths (at the board level) and parasitics (at the IC level), none of which are defined by volume.

A key purpose of the repeated exercises in circuit analysis is to build up the student's intuition for how electricity works. Mathematically, it's "simple" -- just systems of (possibly complex) equations and basic diff eq. But for sophomores, all that is still new, and most students don't enjoy going deep into derivations.

Building kits and plugging pre-made modules into microcontroller development boards is fun, but it's not really engineering. You don't hire an EE to plug off-the-shelf components together, you hire an EE to do design work, to make sure everything is going to work under all operating conditions, and to diagnose problems when something goes wrong.

Finally, software is just easier[1] than hardware. Modern software is a mathematical idealization that runs of top of decades of high-level tools and abstractions. That's why it's so cheap and popular!

[1] This does not mean that everything in software development is easy, just that you don't need to deal with physics or chemistry or manufacturing or the procurement of physical goods in order to create new software.

No. Career development includes paid training sessions, title promotions (junior -> senior, etc.) opportunities to work on larger projects in more significant roles (resume building), and opportunities to transfer into management, as well as (in some cases) opportunities to publish conference papers and the like. As you get older, this kind of career development becomes more important because it is recognized by people who will hire you.

The same goes for many other pieces of software. People (especially home users) would buy software once and then keep using it until something justified an upgrade. Software subscriptions were historically a B2B thing and IIRC usually came with support packages to help justify the ongoing cost -- especially important in the pre-internet and early internet eras.