2,750 karma · joined July 18, 2018
Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.
People like this are the input side of the "oops we built the Torment Nexus" pipeline.
https://www.muppetlabs.com/~breadbox/software/tiny/somewhat....
Unleaded solder and a decent fume extractor make the process cleaner. A decent soldering iron and solder wire with good-quality flux (e.g. Kester) makes it faster.
If you'd rather not deal with the iron, you can manually apply solder paste and use a hot air rework tool or even a heat gun (careful!) to melt it. (A proper reflow oven is better, of course, but that's pricey.) This makes working with surface-mount components much easier.
If you'd rather not deal with it at all, have a PCB assembled somewhere else. JLC is pretty cheap, especially on simpler boards.
> The people who brought us this operating system would have to provide templates and wizards, giving us a few default lives that we could use as starting places for designing our own. Chances are that these default lives would actually look pretty damn good to most people, good enough, anyway, that they'd be reluctant to tear them open and mess around with them for fear of making them worse. So after a few releases the software would begin to look even simpler: you would boot it up and it would present you with a dialog box with a single large button in the middle labeled: LIVE. Once you had clicked that button, your life would begin. If anything got out of whack, or failed to meet your expectations, you could complain about it to Microsoft's Customer Support Department. If you got a flack on the line, he or she would tell you that your life was actually fine, that there was not a thing wrong with it, and in any event it would be a lot better after the next upgrade was rolled out. But if you persisted, and identified yourself as Advanced, you might get through to an actual engineer.
> What would the engineer say, after you had explained your problem, and enumerated all of the dissatisfactions in your life? He would probably tell you that life is a very hard and complicated thing; that no interface can change that; that anyone who believes otherwise is a sucker; and that if you don't like having choices made for you, you should start making your own.
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.
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.