Kung Fu Typing - Keyboard Finger Movement Diagrams - <AUTHOR> http://www.datapointed.net/2010/01/typing-styles-compared/ <comment><USER2> As an aging coder, I have to inject a PSA: be very careful here. Learn to type properly and use a good ergonomic keyboard like a Kinesis. Many of the most productive programmers I know have had to work through RSI issues from typing too much and/or improperly. Certain programs with hand-stretching key bindings like Emacs are especially dangerous without a keyboard like a Kinesis that eliminates the use of single-handed Ctrl-<Key> combinations. (The Kinesis puts Ctrl/Alt/Meta on the thumbs so you never stretch your hand to type <Modifier>-<Key> combinations.)

One reason I migrated away from C++ and towards Python over the last 5 years was the verbosity of C++ -- it was killing my hands (#). It really does add up. The absolute worst was when I was writing the rendering pipeline for Crash Bandicoot in MIPS R3000 assembly: the sheer verbosity difference between assembly and C was enough to destroy my hands, to the point where, in the home stretch towards shipping Crash 2, I was typing with my fists clenched, holding two pens and pecking a key at a time. I didn't really "get over" the RSI for another five years. Even now, I have to _stop typing_ when I notice I'm getting fatigued, or I will get right back into serious problems. And this is far from unique; as I said, lots of coders my age have these issues.

 _Do not_ ignore hand/wrist pain. _Do_ learn to type properly. _Do_ invest in an ergo keyboard. If you are a coder, your ability to type is utterly critical to your livelihood and well-being. Don't mess around with it.

(#) C++11 makes this a lot better.

<comment><USER3> As a complete aside,

You worked on Crash?! That is truly awesome. It's not very often that I get to read a story from someone that works for a company I respect very much, on a series that has many happy moments in my childhood.

</comment></comment><comment><USER4> > The result is a compact, muscle-memorizable repertoire of just over 50 > unique motions in total.

Typing for me isn't much about speed(that's an added advantage). The muscle memory and ability to type without looking at the keyboard alone is worth learning it even if you experience a slowdown in the beginning compared to your one tap, two tap or what have you.

I am a bit surprised typing isn't emphasized enough. Techie or not, if you use computers a lot, learning to touch type is worth it, specially considering that if you aren't a techie(i.e you don't need all the special characters), it doesn't take much time to learn. For anyone trying to learn touch typing, I would suggest stick with the rule 1 - concentrate on accuracy, speed will come with time. And if you are a programmer, don't worry too much about speed. You generally don't type code at full speed anyway.

<comment><USER5> THIS. I got a Das Keyboard with no markings just to finish learning touch- typing (I had done half a course at one point, so I sort of knew what to do..)

Speed is secondary to not breaking your focus/train of thought mid-sentence.

<comment><USER6> _I got a Das Keyboard with no markings just to finish learning touch-typing_

Me too.

I recently also noticed that if I close my eyes while typing, my accuracy is very very close to 100% (ie in every typing test I've taken to try it, I got 100%, but in real-life typing, I do make the occasional mistake) while with my eyes open, its anywhere between 80% and 99%, depending on how tired I am.

</comment></comment></comment><comment><USER7> I can only imagine how much hairier these diagrams become if generated from code instead of English/html. Even for the best case scenario of "The Robot" combined with an "ergonomic" layout like dvorak or colemak, the right pinky area would be a tangle of deep purple. If the diagrams were updated to include backspace key usage, the mess only gets worse.

I couldn't find a typing tutor that addressed the difficulty of typing the symbols in code, so I created a webapp called <http://typing.io>. It allows programmers to practice typing open source code instead of English or drills.

</comment><comment><USER8> I taught himself how to type and was lucky enough to use a split keyboard for a while - really awesome for improving technique. My technique is probably somewhere between touch typing and "The Robot".

But the 110wpm rate is worth it. And people look funny when I blast away at the keyboard without a screen in sight (I often type on a bluetooth keyboard attached to either ipad or iphone)

edit: The funniest result of being a quick typist is that I use copy+paste less than I did a few years ago. Often the context switch between typing and selecting is too much work and it's quicker to just type things twice.

<comment><USER4> > My technique is probably somewhere between touch typing and "The Robot".

How do you learn "The Robot"?

<comment><USER8> You touch type without moving your fingers back to home row every time.

I especially do this with my index fingers who will often jump from, say, Y to U directly without hitting J in between. It looks very funny because they often hover above the keyboard because of this.

But I do tend to move my wrists too much when typing.

<comment><USER9> I learned to touch type with the home row thing, but I never find my fingers really going back to the home row, they just go to the next letter that needs to be typed. I guess with experience comes automatism, which in my case doesn't always involve going back to the home row after typing a letter. Or something.

<comment><USER4> I think it's quite common. I have seen friends type. And everyone who is commenting on this thread and touch types goes to home row only to take a break. There is no home row between two consecutive letters unless they involve letters on the home row.

</comment></comment></comment></comment></comment><comment><USER10> I never formally learned how to type. I had no clue what "home row" meant or where you're supposed to keep your fingers at any point in time.

However, I do touch type -- I never look at the keyboard while typing, even for symbols used when programming and I use almost all my fingers, except perhaps my left thumb, it stays on the space bar but I always use my right one for that. And I just tried an online typing test. When I strive for 100% accuracy, ie, I go back to fix mistakes when I notice I made a typo I got 75WPM. Also, I usually type faster than I do when taking these tests because the slowdown for me is in reading not typing because many of them have nonsensical texts(not as bad as "Green ideas sleep furiously" but nonetheless, probably something I wouldn't write naturally).

I also don't even remember going through a "hunt and peck" phase when typing. I thought this was natural and all people who use the keyboard a lot evolve into something like this naturally.

Edit: I just looked at the definitions for some of these things and which keys you're supposed to hit with which fingers and I noticed that I usually keep the keyboard slightly to the left side so that my right hand is at an angle, not straight. So instead of splitting things vertically between my fingers on the right side it's a bit different. For example I hit the "Y" key with my middle finger and I move my entire hand down to hit the "," with my index. So it's definitely suboptimal but it's good enough for me.

</comment><comment> loup-vaillant I'd like to see equivalent diagrams on a Dvorak (or colemak) layout. The "touch typing" diagram would be much closer to the "robot" one, demonstrating you don't have to be a robot to type efficiently.

Oh, and It'd be cool to have non-slanted keyboards. My hands don't both lean on the left. <http://loup-vaillant.fr/articles/better-keyboards>

<comment><USER11> You should check out TypeMatrix[1]. I've been thinking of getting one for a couple of years now. I guess I'm just being lazy...

[1]<http://typematrix.com/>

<comment><USER12> I wanted to buy it until I read this: <http://a3nm.net/blog/typematrix_review.html>

Dvorak is cool, but you don't need typematrix to feel its benefits. I use normal keyboards to type dvorak, all you have to do is to change the keyboard layout.

<comment><USER11> Thanks for the link. When I first discovered TypeMatrix, there weren't many reviews of it. By the sound of it, maybe I should save my money for something else.

</comment></comment></comment></comment><comment><USER13> > As for Yours Truly, teenage peer pressure kept me from riding the touch > typing train. Per the sexist suppositions of way-back-when, before computers > went mainstream, keyboards were for secretaries, and secretaries were > female. Dudes just didn't do that kind of thing.

I took the hard way out. I took "Secretarial Office Procedures" in high school just to learn typing.

<comment><USER14> When I was a kid, about 9 or 10, my mother taught me to type. As a teenager, she had gone to secretarial college and had become a legal secretary typing up documents for lawyers before getting married.

I learned on a manual typewriter. I was the weird kid who typed up school reports on a manual typewriter before computers were widespread.

Along with basic sewing, it's one of the most useful things my mother taught me. We should teach every schoolchild to touch type.

<comment><USER13> It was incredibly embarrassing at the time, but I'm very grateful to have learned touch typing.

</comment></comment></comment><comment><USER15> I'm a bit scared of changing my typing style now...

I started programming at 8 years old, doing the two-finger method, which eventually evolved into a modified 3-finger left, 2-finger right, with pinkies for modifier keys. I took a typing course in high school and did well, but I went right back to my old style afterwards. I've now been doing this for 30 years. My typing isn't super fast (maybe 70wpm), but I've also never had any wrist pain, regardless of the keyboard or sitting style I've used. My primitive typing style never allows for contortion moves, and I'm worried that if I do move to a more proper style, I'll end up with the wrist pain that everyone talks about...

</comment><comment><USER16> Do I miss the explanation how they created the diagrams? Would be cool do it for one self.

</comment><comment><USER17> After 18 years in front of a keyboard I'd hoped my typing would be better than it is. But I'm stuck between a "Pointers with Thumbs" and a "Von Style"

Does anybody have recommendations for a good online touch type training program? Specifically for developers.

<comment><USER3> Put your hands on home row and keep your eyes on the screen and just go, with discipline... it's how I learned, sorta. A friend and I competed to learn how to type without looking.

<comment><USER4> I won't recommend it. You sure can just go to a shallow swimming pool, flail around and learn swimming, but re-discovering first principles is distracting and might de-moralize you.

I don't remember which one I used when I learnt(it was about 6 years ago and I was using windows at that time), but I would say use one which teaches basic letters, n-grams, symbols and integration. Muscle memory is built over time and it's hard to override. Unless you believe using wrong fingers give you some sort of advantage, why would you want to learn the wrong fingers when you can very well learn the right ones with the same level of effort(your comment about y and b)?

<comment><USER3> I'm just giving anecdotal evidence for what worked for me; and TypeRacer puts me at 90-110 wpm, which is far more than I'll ever need for my programming work.

Then again, if he's actually asking for a program to help him because he actually wants a program's help (as opposed to thinks it's the only way he can learn), it'd be better to go with a program. What I was encouraging was that you didn't have to have a program to help you learn how to type. Also, just using all 10 fingers on the keyboard all the time, and having them rest on or near home row, even when you have to look down occassionally to see which finger should go after which key, and where that key is, is a good step toward improving as touch-typist.

</comment></comment></comment></comment><comment><USER18> And here I am, still desperately waiting for _the perfect_ speech to text converter that just removes need of having to type text entirely. I can see a future where programs are narrated.

<comment><USER4>
        #include <stdio.h>

        int main(void)
        {
            printf("Hello, World!\n");
            return 0;
        }

Why would I want to dictate that? "Hash include less than sign(do I mean "less than sign" or "<") stdio.h greater than sign newline(do I mean actual newline or to print newline?) int main open parenthesis(actual or sign)...."

And you are assuming if there is a perfect speech to text converter, it's automatically better than typing. I don't see myself using one for most of the tasks. Speaking is too distracting.

<comment><USER19> Well, C is made for keyboards. In fact, every programming language I can think of is, so the ones who write with tts must create new languages.

</comment></comment></comment><comment><USER20> "Everybody was kung-fu typing | Those cats were fast as lightning | In fact it was a little bit frightning | But they did it with expert timing..."

</comment><comment><USER21> If you're going to touch type, you should use a layout designed for it, not a layout designed to prevent typewriter from breaking.

Dvorak, Bépo, etc. Much easier on the fingers. Then you can do the "robot" diagram because it's sort of built in your layout. Even for programming it's much better.

<comment><USER22> Placebo, at best.</comment></comment>


A clear explanation of JWT - <AUTHOR> https://michelenasti.com/2017/09/21/a-clear-explanation-of-jwt.html <comment><USER2> These examples do not appear to have been run.

      const jwt = require('jonwebtoken')

<comment><AUTHOR> When writing these examples I use to test in one simple file. Then, for the sake of clarity, I copy and paste pieces of code in the blog post. Some typos come from there.</comment></comment>


Guy Kawasaki goes against the crowd. Who was wrong? - <AUTHOR> http://createabeta.com/guy-kawasaki-goes-against-the-crowd-who-was-w

<comment><USER2> Its not about the number of people liking the design, but more about the quality of people rating them. In his book, guy was targeting certain type of audience. Personally, I didn't like the design "Daisy".

and moreover, I feel you are using Guy's name here for publicity purposes.

<comment><AUTHOR> When doing market research its about both the number and quality. I agree that our polling audience may not match Guy's key demographic but we do get the numbers for a very cheap price. More to the point of the article, if you didn't like the Daisy design that's fine, I just think its a bit foolish to not poll an audience of more than 1.

Obviously using Guy's name and polls as an example will draw more readers, so yes it helps with publicity. I don't see the issue. It happened, I wrote about it.

</comment></comment><comment><USER3> I think he should have gone with the crowd.

<comment><AUTHOR> lol, thanks gav :)</comment></comment>


Amazon sued for wrecking teen's Kindle work - <AUTHOR> http://www.cbc.ca/technology/story/2009/07/31/tech-amazon-lawsuit-student-1984-kindle-gawronski.html

<comment><USER2> See <http://news.ycombinator.com/item?id=733312> and <http://news.ycombinator.com/item?id=733774>

</comment><comment><AUTHOR> The title of the article is misleading. Amazon has not been sued; A class- action lawsuit has been launched.

<comment><USER3> I don't know the difference. What is the difference?

<comment><AUTHOR> IANAL, but my understanding is that a class action involves a group of people suing at once.

What I meant though is that "sued" usually refers to a completed case in past tense. This lawsuit just started.

<comment><USER4> They've been sued, they haven't yet lost the lawsuit.

<comment><AUTHOR> You can say they are _being sued_ but they haven't yet _been sued_.</comment></comment></comment></comment></comment>


Ice Cream Sandwich will not save Android tablets - <AUTHOR> http://www.extremetech.com/computing/100667-ice-cream-sandwich-will-not-save-android-tablets

<comment><USER2> Not a lot here, Apple fan screams defiantly at new Android release claiming its not a threat to tablets.

<comment><USER3> FWIW, the author, Ray Walters is one of the most Androidy people out there. He used to write for an all-Android site.

<comment><USER2> "Fascinating" as Mr. Spock would say. Perhaps he's screaming because he _wants_ an Android release that will challenge the iPad but isn't getting it.

<comment><USER3> That sounds likely :)

</comment></comment></comment></comment><comment><USER4> If I looked at all the tablets that were $399 or higher, I would get the iPad hands down each time. You know what you're getting, and you know you're getting 100,000 apps to do just about anything. Why would I pay the same (more or less) amount as an iPad for a non-iOS device? Look at the TouchPad and Playbook. Same price, but almost NO apps.

The Kindle Fire will do well because it's $199. The fact that it'll have the Amazon AppStore and (presumably) run most Android apps will help is sustain itself, but people will buy because of the price and the Amazon name.

Android is going to have to go a long way with a lot of great apps to make an Android tablet worth paying the same as an iPad.

<comment><USER5> > Why would I pay the same (more or less) amount as an iPad for a non-iOS > device?

Because you don't want to support Apple, don't like the iPad, like Android, have a killer app on Android, or any of a myriad of other reasons. Until iOS5, "because I don't have another computer" was even a good reason.</comment></comment>


Creating vs. Disrupting - <AUTHOR> http://www.iamcharliegraham.com/2015/04/28/creating-vs-disrupting/

<comment><AUTHOR> Nice blog post about how entrepreneurs should aim to create a new industry vs trying to disrupt an existing one.</comment>


The Triton malware is murderous and spreading - <AUTHOR> https://www.technologyreview.com/s/613054/cybersecurity-critical-infrastructure-triton-malware/ <comment><USER2> From [https://www.fireeye.com/blog/threat- research/2017/12/attacke...](https://www.fireeye.com/blog/threat- research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html)

>The targeting of critical infrastructure to disrupt, degrade, or destroy systems is consistent with numerous attack and reconnaissance activities carried out globally by Russian, Iranian, North Korean, U.S., and Israeli nation state actors. Intrusions of this nature do not necessarily indicate an immediate intent to disrupt targeted systems, and may be preparation for a contingency.

This reeks of Stuxnet 2.0

<comment><USER3> " We have your critical infrastructure by the balls, you have ours. We would both be MAD to trigger anything"

Is that the planned situation here?

</comment></comment><comment><USER4> At some point, we're going to start seeing an internet connection not just in terms of the benefits, but in terms of the liabilities too. I really would have thought that by 2019 we'd be there with industrial control systems, but apparently not.

One wonders if the governments of the world wouldn't be well advised to go ahead and hack their a couple bits of their own critical infrastructure a couple of times and horribly break it, just to make the point, before a bad actor hacks all the infrastructure. That visibly has huge costs, but it's not clear that the hidden costs of just blithely letting people keep hooking up critical stuff to the Internet isn't orders of magnitude higher.

And by no means could such a result be called a "Black Swan", because that it's going to occur is perfectly predictable. It's only a question of when.

<comment><USER5> An air gap won't even save you. See also: Stuxnet.

<comment><USER6> It decrease the attack surface. Delay the attacker getting feedback from the system. Attacks take longer and more likely to be uncovered.

<comment><USER7> Are attacks on air gapped systems more likely to be uncovered though? Having it isolated makes auditing/alerting harder too, and could instill an overconfidence in the security of said system.

<comment><USER8> On the other hand it's easier to spot irregularities, the auditing is simpler because there isn't any variance.

</comment></comment></comment></comment></comment><comment><USER9> Redundant Safety PLCs run the same program in parallel in lockstep and if they get different results then this triggers an error. I think Triconex in particular requires 2 out of 3 controllers to agree.

It is odd that the attacker tried to modify the program in the PLC configured this way. They should have known it would cause a noticeable disturbance.

The Schneider Quantum PLC literally runs a pentium 166 or 200 and there is a steady string of firmware and operating system (VxWorks) updates. We had one from 2006 that would simply stop communicating if it was plugged in to a cisco switch from 2016.

A zero day in VxWorks which is the operating system for a large swath of controllers would be pretty bad.

<comment><USER10> I don't want to call anything without dedicated gates and hard traces a 'PLC'.

You have a computer there; something that isn't continuously integrating results via hardware but is rather emulating that in software.

The future probably has more of those systems than what I think of when I hear PLC, and maybe that industry has loosened the terms since I was in college, but it's important to call tools what they are so that their shortcomings are obvious.

<comment><USER11> As you know PLC is just s programmable logic controller. All computers are, by definition, that. Perhaps you're referring to the 'gated logic' programs that exist? To me they're just like the old punch cards, but with the purpose of controlling a contactor -- they're very simple systems indeed.

However, it's also not hard to incorporate hardware watchdogs into industrial systems that check for proper running software (& vice versa). I've done them.

It might be time (if it doesn't already exist) for the industrial networks to upgrade to newer security practices though... (eg code signing, encrypted networks, changes to fs, ...)

<comment><USER9> I haven't worked with it yet but Schneider's M580 PLC I believe even supports authentication!

It is crazy that a Quantum or M340 PLC on an ethernet network basically has unauthenticated DMA. any device on the network can read or write to any addressed memory using the dead simple modbus protocol, and there is some more complicated protocol for reading and writing unaddressed memory.

I don't think Allen Bradley is any better as I don't recall ever having to specify any credentials or any other means of restricting which clients could connect and write to the PLC.

<comment><USER12> All de facto modbus implementations that I am familiar with use virtualized register banks that map to higher level parameter accesses including input validation. So the shenanigans you should be able to do with then are somewhat limited. But there is no authentication at all. This was designed at a time when notion of having a bad actor mess with an control system was not even invented yet.

</comment></comment></comment></comment></comment><comment><USER13> [https://twitter.com/SarahTaber_bww/status/110525655715412787...](https://twitter.com/SarahTaber_bww/status/1105256557154127872)

>I don't I've quite articulated why I'm so critical of the tech industry. Tech isn't just software anymore. They're coming for ag, food, & manufacturing- & they're bringing a negligent attitudes towards risk & safety that they learned in the cushy world of apps.

And this malware is affecting industries with a strong incentive for safety, think about what that might imply about every other industry.

<comment><USER14> > I don't I've quite articulated why I'm so critical of the tech industry. > Tech isn't just software anymore.

She is picking the wrong target. Tech would do security if directed to do security. _Business management_ doesn't care about security.

Until someone has to _pay big money_ or _do jail time_ for lack of security, this will not change.

<comment><USER15> Hierarchical management structures are part of the problem. Managers generally treat technicians as flunkies and don't value their opinions, and most technicians aren't willing to get yelled at or fired, so corporate systems select for the lowest common denominator instead of the highest common factor. It's not going to change under our existing system because capitalists don't give a shit about consumers or employees, and 99% of managers just want to get into the winners' circle.

</comment></comment></comment><comment><USER16> > [The malware contained] an IP address that had been used to launch > operations linked to the malware.

> That address was registered to the Central Scientific Research Institute of > Chemistry and Mechanics in Moscow, a government-owned organization with > divisions that focus on critical infrastructure and industrial safety.

Ironic, sounds like they also have the job of _subverting_ critical infrastructure and industrial safety.

<comment><USER17> I suppose the best way to improve critical infrastructure is to create an emergency that makes improvement a priority lol

</comment></comment><comment><USER18> This is definitely not the first time malicious software was implanted in industrial control safety systems. Here is an example from the Cold War (it caused the largest non-nuclear man-made explosion in history):

[https://www.zdnet.com/article/us-software-blew-up-russian- ga...](https://www.zdnet.com/article/us-software-blew-up-russian-gas- pipeline/)

The actual sabotage involved adding an integer overflow to valve control software, and making sure it took months to hit (so testing would miss it).

</comment><comment><USER19> I think people need to keep in mind, that "disconnect it from the Internet, it shouldn't have been on the internet" doesn't fix this. If the injection works from USB devices, then the typical field engineer is not going to scrub their USB before downloading the field upgrade. Almost everything worldwide now uses USB as a field-upgrade path. Maybe as a cost cutting and simplification method this was ok, but the risk side? way way above the benefit (in my opinion)

What mitigates this (if anything does) is signed code on media you have to work harder to program. Rather than a USB device, this should be some form of media which doesn't present as a bootable device to a BIOS/UEFI. The field unit should have signature checks over images based on PKI. This is what a lot of things do, but somehow it seems not the ones which matter here?

Field upgrade by kermit or xymodem would be better than this, in that narrow regard. -The risk of an unexpected packet hitting the code path is lower if the code upgrade is reading a byte stream for a hash/sig check, compared to mounting a USB device, loading drivers, enabling HID mode ...

I deliberately avoided working in engineering contexts where the risk was above my comfort factor. It ruled out industrial process control, health, civil engineering and a host of fascinating fields, but I was just too worried about the liability side and my own competency to work in these areas.

I did not foresee (inter)net technology becoming so critical it exposed all of these risks, in my core competency. I still feel inadequate to these risks, 37 years later.

</comment><comment><USER20> Industrial operations are going to have to start giving a damn. A lot of them just don't right now. Most of the ones I've been in are an amalgamation of devices and software spanning the last thirty years. The number of xp boxes still controlling vital systems while being connected to the internet is insane.

</comment><comment><USER21> > "...likely through a hole in a poorly configured digital > firewall that was > supposed to stop unauthorized access. .."

'Every' penetration tester I talk to says that this is what they find all the time: actual 'reality' within networks does not align with assumed network policies or topology.

But, I don't talk to that many. Is this really the case? We put great care to have network architectures and policies that define network segmentation, isolation, and other strategies to harden and protect the network. But those policies are not implemented properly, or over time their technical enforcement isn't guaranteed?

<comment><USER22> Yeah, I don't think I've ever seen an 'airgapped' network that was actually airgapped.

About half the time no discernable effort was ever put into airgapping and it was only ever a paper goal. Most of the rest of the time it started out configured reasonably but either drifted out as business needs changed ("Chloe get me a port!" is a pretty common joke) or someone just didn't realize it was special and configured it badly.

The rest of the time you just stack up edge cases: bad management credentials, forgotten management interfaces, canned router or switch exploits, broken q-in-q implementations, etc. The list is endless. And all that's without getting someone authorized to carry you onto the airgapped network, which happens facepalmingly often.

</comment></comment><comment><USER23> Instead of having Internet connectivity 24/7 for IoT devices or critical infrastructure, why not have a small window for things like updates and so on, but be physically air-gapped the rest of the time? The window doesn't have to be at the exact same time either: if you need 20 minutes to download and apply updates once a week, then you can start that 20 minute interval at anytime on whichever day. The air-gapping could also be done using analog means or another network that isn't connected to the Internet.

The best solution would be to be air-gapped 24/7, but in cases where that is not possible, there are other viable and more secure approaches than being online 24/7.

</comment><comment><USER24> Made in Russia?

[https://www.fireeye.com/blog/threat- research/2018/10/triton-...](https://www.fireeye.com/blog/threat- research/2018/10/triton-attribution-russian-government-owned-lab-most-likely- built-tools.html)

</comment><comment><USER25> What causes some of the finest hackers to come from Russia? Is it attributable to their education system? Comparatively, I don't see as many hackers coming from any other country? I don't mean it in a bad way. Just curious.

<comment><USER26> Excellent mathematics in secondary schooling and lots of folks with degrees but not high paying jobs is my guess.

</comment></comment><comment><USER27> I know that this is tinfoil-hat territory, but isn't the problem of Boeing 737 MAX recent crashes related to software issues? It would be scary. I'm referring to this article: [https://www.businessinsider.com/boeing-737-max- receive-updat...](https://www.businessinsider.com/boeing-737-max-receive- updated-control-software-2019-3?IR=T)

<comment><USER28> You're right to be scared of course - a software bug in a safety-critical system is a bug in a safety-critical system, no matter if it happens in a plane or in some piece of critical infrastructure. And yes, they have now patched _this_ flaw, but most likely it's still a pile of old F0RTRAN code or something like that, that they're now stuck dealing with in some way. The notion that these sorts of systems are somehow less prone to having serious bugs in them is being revealed as a dangerous delusion.

<comment><USER29> No software is perfect, but the aerospace industry has standards as far as software validation/verification that mean airplane software is in general less bug-ridden than comparably complex low-level software written for less risk-averse industries. Hard to say if that applies to any particular chemical or energy plant as well.

</comment></comment></comment><comment><USER30> Mobile platform apps run in considerably stricter environments than do desktop apps.

I'm wondering why MS has not come out with a similar kind of Windows, wherein every app is effectively sandboxed.

<comment><USER31> > Mobile platform apps run in considerably stricter environments than do > desktop apps.

Mobile phones (android) are full of malware, most only get patched for a couple of years at best and these are often late and infrequent. Stricter != safer.

> I'm wondering why MS has not come out with a similar kind of Windows, > wherein every app is effectively sandboxed.

That would be windows 10 and the app store included, but it looks like it's limitations led to failure.

<comment><USER30> Stricture definitely means safer. Android apps written in Java cannot wipe the device or run amok and do whatever. The opportunity for malware is considerably reduced if the API attack surface is limited.

Security measures on Win10 are superficial in the sense that any app compiled to the platform can essentially do whatever.

It would I think something quite more fundamental than the app store or signatures, effectively a totally new OS architecture.

</comment></comment></comment><comment><USER32> > In attacking the plant, the hackers crossed a terrifying Rubicon. This was > the first time the cybersecurity world had seen code deliberately designed > to put lives at risk.

This is no regular malware. This is war.

<comment><USER33> I don't know enough about the production of nuclear centrifuges to say for sure, but it seems probable that the damage intentionally inflicted by Stuxnet[1] may very well have put some lives at risk. Triton looks more like another step down this path than like a watershed moment.

Mike Hayden, 2012 [2]:

> We have entered into a new phase of conflict in which we use a cyberweapon > to create physical destruction, and in this case, physical destruction in > someone else's critical infrastructure.

Still, an alarming development.

[1] [https://en.wikipedia.org/wiki/Stuxnet](https://en.wikipedia.org/wiki/Stuxnet)

[2] [https://www.cbsnews.com/news/stuxnet-computer-worm-opens- new...](https://www.cbsnews.com/news/stuxnet-computer-worm-opens-new-era-of- warfare-04-06-2012/)

<comment><USER34> Don't forget about Crimean power outages before the Russian annexation. And the cyber breadcrumbs we've found in our dams and power stations. Oh, and I hear Venezuela is coming out of a 4-day blackout right as we're ramping up all our aid/regime-change talk...

About a year ago there was a major transformer that blew in downtown SF, knocking most of the fidi offline. I didn't think much of it -- stuff breaks, and this was pre-PG&E fiasco -- but then I heard the same thing happened in NYC and another major city (maybe Seattle?) that same morning. Things break regularly, and there's always some 3-city combined probability function, but it still made me glance over my metaphorical shoulder.

Ideally we'll still be too scared to use nukes in the next hot war. Everything else that makes modern life bearable is fair game, though.

[edit]: LA was the third city, and all failures were traced to physical faults/aging infrastructure: [https://www.snopes.com/fact-check/power-outages- la-sf-nyc](https://www.snopes.com/fact-check/power-outages-la-sf-nyc) Like I said, there always is a combined probability function, but point is we're gonna be doing a lot more glancing over our metaphorical shoulders the more we see stories like this.

<comment><USER35> If I wanted to blow a transformer over the internet, I'd pick one that would be regarded as aging, too.</comment></comment></comment></comment>


A Response to Hello World in Go - <AUTHOR> http://www.doxsey.net/blog/a-response-to-hello-world <comment><USER2> > _But regardless of what our computer is doing, if it takes less than 100ms > to execute our program, we simply won 't be able to tell the difference > between executing 1 instruction or all 10 billion._

> _All of the example programs except for "Python 3 (PyPy)" are basically > within this threshold. No user will notice the difference._

This is a contentious point. 100ms is very noticeable for a human being. I'd say most humans probably hit the "simultaneous" range at 33ms (30fps). I know, personally, I can very much tell when there's an input latency of 100ms.

Regardless, for Drew's somewhat contrived benchmark, I can't imagine a situation where starting a program in 33ms or 100ms would matter, but if that program was running in a loop in a bash script? Then those milliseconds very much do matter. Spending 90ms more in a loop is an extra 9 seconds for every 100 items.

<comment><USER3> I would argue if you're doing performance sensitive work in that fashion, you're doing it wrong.

I'd also probably argue that if you're doing it that way, you're probably already _not_ that concerned with performance to the degree where losing a few tens of seconds is a big deal.

I certainly wouldn't include any tight bash loops that execute external code in any service code, for example. Performance there shouldn't be impacting either the sync or async path.

Much like the article's point, it's a question for optimising for the right things.

I do agree that people can perceive values faster than 100ms.

Several years back I was interviewing for a sysadmin job at a futures trading company. Part way through the interview, one of the traders complained to the interviewer that the latency was increasing on the connection to the exchange, and sure enough it was up 20ms from normal (I forget the normal, but it was very low, on the order of only maybe 10-20ms) and monitoring was just about to page the interviewer.

</comment></comment><comment><USER4> The author makes a benchmark that compares a go program that explicitly buffers many "hello world" strings, and compares this to an assembly program that does not do this, then goes on to argue that this shows that high level languages can be faster. This can certainly be true, but this particular example is not a great way to show it, because the same optimization can be done in an obvious way in assembly, (just allocate enough space with brk or mmap2, write your strings and send the right memory address to ). This would of course be harder to do in assembly than in Go, but it is still quite straightforward to see what is the optimal way to do it. Furthermore, this would probably still outperform the optimized Go version by a wide margin.

A better example could be where a compiler picks an obscure but faster parallelization operation, or unrolled a loop appropriately in a way that is both faster and unlikely to be written by a competent human, or a complex memory management scenario etc etc.

I think this is not the point of the original article though. I think we all understand that abstractions can in theory bring great benefits, but we do need to scrutinize the cost they add. The hello world examples shows that even with the simplest program we can imagine, the result is extremely far from optimal in popular programming environments. If this is the case, why should we assume that these same compilers are doing an excellent job in situations that are actually hard?

<comment><USER5> He called this out, saying that the added complexity overhead of Go allowed the abstraction to be done much simpler than it would be in assembly. This is just tradeoff that is worthwhile in most cases.

The gripes about boilerplate overhead in Hello World miss the point that the runtimes involved are themselves making tradeoff about what to optimize for. Go explicitly trades off ultra-efficient binary size for ultra-fast compilation and mostly-static artifacts. Go is not designed to make the most efficient possible Hello World binary, nor should we want it to be. The fact that you can optimize Hello World better by hand than the Go compiler does tells us nothing interesting. How well can you optimize Docker, Consul, or Kubernetes by hand?

</comment></comment><comment><USER6> _> By some estimates human beings perceive two events as instantaneous at around 100ms._

This is not _at all_ what the linked article says. The article says human _reaction time_ — the time it takes to receive a stimulus, process it, and perform a physical act in response — is about 100ms.

Human time _perception_ is _much_ faster than that. A software button that takes 100ms to switch to its pressed appearance feels dramatically different than one that does so in 10ms. As the linked article notes, game player performance degrades as latency increases from 13ms.

</comment><comment><USER7> Original observation: programs do a lot of things you didn't ask for.

This response: well, actually™ you really want all these things you didn't ask for. And don't worry about that bloat, the memory is cheap and the CPUs are fast.

So, the points of the original article still stand (this "response" does not address them in any way).

The claim about 100ms latency being imperceptible is the cherry on the top. Try delaying a drum track by 100ms and listening to it without pain (or try singing karaoke into a mic with that much latency).

But that's beside the point, which is that _all these programs are doing a lot of things you didn 't ask for and take megabytes to do that_.

<comment><USER8> do you agree that there are tradeoffs is system design?

A plane could weigh a lot less if we removed all the computers and sensors that it carries. However, as logical beings we make the trade off because speed isn't as important as safety.

<comment><USER7> Great example! An airplane only carries the stuff that it actually needs.

Aerobus A380 carries 300 miles of wires in its body.

You can be absolutely sure that a Cessna 152 _does not_.

Putting all of A380's wires in a Cessna 152 is not a trade-off, it's insanity.

</comment></comment></comment><comment><USER9> > Computers are fast - a lot faster than we can possibly perceive. By some > estimates human beings perceive two events as instantaneous at around 100ms. > To Drew's point, this is an eternity for a computer. In that time a modern > CPU could execute 10 billion instructions.

This type of thinking is why we can't have nice things, and why technology and software seem stuck on an eternal treadmill. A system with lower latency feels amazing - compare a high and low latency terminal or text editor sometime and feel the difference. A touchscreen with 1ms latency (input to output, which requires a 1000Hz display) feels like a real physical object - way different from a touchscreen at 16ms or (god forbid) 100ms. We are _never_ going to get there if people keep assuming that latencies lower than 100ms (or 30ms) are imperceptible.

100ms is the minimum viable performance. If an operation takes longer than that, you've failed for interactive purposes. But just because that's the minimum requirement doesn't mean we shouldn't try our dang hardest to improve on that!

</comment><comment><USER10> I strace'd Rust's hello world and the vast majority of the syscalls are just ld.so setting up dynamically loaded libraries. Presumably if you really cared you could statically link against musl to eliminate those. The remaining syscalls are needed for stack guards to work, which you actually want for security, even with hello world.

I would go so far as to say that publishing benchmarks that encourages languages to skimp on important security features like guard pages is irresponsible.

<comment><USER11> It's still weird that it has significantly more syscalls than the C program dynamically linked to glibc, which presumably has the same overhead wrt ld.so and guard pages. (BTW, the guard page for the main thread, IIRC, is setup by the kernel)

<comment><USER10> Here are the list of syscalls: [https://gist.github.com/pcwalton/60ff97c2353feda11638be10118...](https://gist.github.com/pcwalton/60ff97c2353feda11638be10118851f2)

I think the extra syscalls you're referring to are the result of linking with pthread. Obviously Rust code always wants thread support.

Here's the setup code: [https://github.com/rust- lang/rust/blob/master/src/libstd/sys...](https://github.com/rust- lang/rust/blob/master/src/libstd/sys/unix/thread.rs)

A fair number of the syscalls are to ensure that stack overflow is reported like a Rust panic (with a stack trace), not like a segv in unsafe code. I think this is worth it.

</comment></comment></comment><comment><USER12> > A full-program, aggressive optimization step might lead to smaller binaries, > but it would do so at a great cost to projects with many dependencies. > Incremental compilation is a boon to developer productivity which is also > important.

Isn't the traditional way to solve this problem to have two different modes for the compiler? You can have a "development" mode that compiles quickly and supports incremental compilation, and that doesn't stop you from also having a "release" mode that produces a Hello World executable that fits on a floppy disk.

And then if you're Google and you have infinite disk space and memory but limited time to spend waiting for builds, you can just run all your builds in "development" mode. (But if you also ship smartphone apps, maybe you compile _those_ in release mode.)

<comment><USER13> The Go Way ain't the traditional way. I'd argue you should want the same binary everywhere, though there's always C or you could come up with your own scheme to break production.

<comment><USER12> I don't especially care about the binary (beyond wanting it to be as small and fast as possible on end-users' machines), but I do want the _behavior_ to be the same everywhere.

In C, this is difficult because code often accidentally relies on "undefined behavior" that changes depending on the compiler and optimizations you use. But is that still an issue in newer languages that don't have as much undefined behavior? (Is this something Rust programmers struggle with, for example?)

<comment><USER13> Safe language implementations such as Go and Rust are specifically designed to avoid such inconsistencies. If your builds differ, you never know 100% though.

</comment></comment></comment></comment><comment><USER14> From the original-original post: _Most languages do a whole lot of other crap other than printing out "hello world", even if that's all you asked for._

This should be of great concern to all the people who write "hello, world" programs for a living, and no concern to anyone else.

</comment><comment><USER15> On c64 you just load the "hello world" ~~program~~ text into the screen buffer.

<comment><USER16> On an "etch a sketch" you go up one dial then down a half then right half a dial then down half a dial then right half a dial and then right half a dial and then left half a dial and up one dial and then right half a dial and then down half a dial and then...bugger stuck

<comment><USER17> That's when you yell out to your female sibling for help, aka a sis-call.

</comment></comment></comment><comment><USER18> > Kinda neat that it handles the binary getting deleted

…and then it goes and reads /proc/self/exe. This looks really racy.

<comment><USER19> Reading the symlink isn't racy.

But why is the os package doing a syscall to determine the executable's path in a hello world program?

<comment><USER18> I believe the function of this feature was to get the executable before it could be deleted off the disk, which it presumably could in the time between the binary was executed and the call to readlink was made.

<comment><USER19> I've looked into it some more; I had assumed /proc/*/exe acted like a symlink whose value never changed, but actually it's more complicated[1]. As a result (only considering Linux here), there actually is a race condition in what they're doing: /proc/self/exe will have " (deleted)" appended if the executable is deleted. In an apparent attempt to make the problem more subtle, they're doing the readlink on every program startup so that if the value is needed, it will be correct--unless the file was deleted between when it was exec'd and when it got to the readlink call.

1: [https://unix.stackexchange.com/questions/197854/how-does- the...](https://unix.stackexchange.com/questions/197854/how-does-the-proc-pid- exe-symlink-differ-from-ordinary-symlinks)

<comment><USER18> Yup, that's exactly it.

</comment></comment></comment></comment></comment><comment><USER20> > By some estimates human beings perceive two events as instantaneous at > around 100ms.

Would be fun to design a realtime audio app using that supposition.

Also, a question to troll fans of the phrase "Gell-Mann amnesia effect": how flippantly should I now reject the other paragraphs that are outside of my expertise?

</comment><comment><USER21> // shortest "hello world" in go

package main

func main(){

           println("Hello World")

    }</comment>


Ask HN: Anyone Interested in AMAs on HN? - <AUTHOR> So many great people on HN. Has this been attempted before? Is this something that would be appropriate for this community? <comment><USER2> There are some that were done here: [https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=ama&sort=byPopularity&type=story)

And then quite a bit of linking to ones on Reddit.</comment>


OpenAudible – desktop application for downloading&managing Audible audiobooks - <AUTHOR> https://github.com/openaudible/openaudible <comment><USER2> Not working as expected for Ubuntu 19.04!

<comment><AUTHOR> Grab the logs and create issue on Github.</comment></comment>


One-Day School - $188 per student to build - <AUTHOR> http://tinyhouseblog.com/announcement/one-day-school/#more-14371 <comment><AUTHOR> As opposed to spending $137K per student:

      http://news.ycombinator.com/item?id=1625976</comment>


Survival Guide : IRC - <AUTHOR> http://www.mahdiyusuf.com/post/6176918750/survival-guide-irc <comment><USER2>
      A little note for you Experts out there. Don't take
      yourself too seriously; We are all here to learn and
      grow. Coddle the dumb ones and challenge the smart ones.

If you consider the ratio of expertise to ignorant questions you'll see that this is really bad advice. Experts, even when they dabble in Q&A, are not by definition tutors. It's unfair to expect that whole category of people to waste their own time and the time of people with smart questions by 'coddling' those who fail to grasp this fact. When dealing with people who are clearly overreaching their current capabilities, or who ask 'how' questions without any interest in the 'why', giving them the cold shoulder and an invitation to gather more background knowledge from published resources is often the best service that can be done.

Another factor in support fatigue among open source software experts is the (often inept) commercial application of the software, which is commonly associated with a lack of respect for the software itself and for those who have deep knowledge of it. Then* you get questions paired with criticism like 'I know exactly how to do this in Y, why can't stupid X behave the way I want?' or insistent pleading like 'I need to get this working ASAP! Please halp!'. When the intent behind the question is not to learn but to make money faster, volunteers support 'staff' are not obliged to step up.

Anyway, advising experts in general to change the way they volunteer time and information is pointless. They know what works for them and there are no levers on IRC to make them change their habits.

PS, config help on #apache? What network is that? :)

* I know, not only then.

</comment><comment><USER3> "Protip: Learn to laugh it off. Another thing when you decide to be a bitchass; add a smiley. Trust me it makes all the difference. "

I grew skeptical of the advice at this point. Putting a 'smiley' after an unpleasant statement is the equivalent of saying it with a snide smirk on your face.

<comment><AUTHOR> it just goes to show that your not trying to be malicious in your somewhat harsh statement. Sometimes there is no way to put something delicately to a complete stranger. adding the smiley is more of a way to get the reader to look at it as constructive as supposed to judgement on the person asking the question.

<comment><USER3> Unfortunately, some people use it to be snide, so its unclear and should be avoided. Some think that adding a 'smiley' is a license to be tactless, blunt or insulting, but it's better to learn how to express ones thoughts properly. 'just sayin' serves the same faulty purpose. If you feel the need to add one of those to avoid being misinterpreted, rewrite your statement. 'not trying to be harsh' or 'please take this as constructive criticism' are more expressive.

<comment><AUTHOR> (+1) I totally agree, but people tend to be lazy, especially when their goal is to help the person rather than dealing with them as a human being.

</comment></comment></comment></comment><comment><USER4> Keep in mind that IRC is no exception to the Fuckwad Theory:

        Normal person + Anonymity + Audience = Total Fuckwad

<comment><USER5> I'd go so far as to say it was one of the earliest examples.

</comment></comment><comment><USER6> This is a great, IRC-specific extension to esr's "How To Ask Questions the Smart Way" ( <http://catb.org/~esr/faqs/smart-questions.html> ). Reading (and understanding) both of these documents as an IRC newbie will most likely make your experience much more pleasant.

<comment><AUTHOR> That was my goal. glad you enjoyed it.

</comment></comment><comment><USER7> I personally loath meta answers like "why are you doing X and asking Y" instead of wasting the equivalent typing of explaining why X and Y is a bad idea.

With that said, I usually find the most serious experts just quietly ignoring silly questions or trying to pry out the root of the problem through a constructive dialog. Why superior douchebags get satisfaction of showing of their superiority by bashing beginners has always been beyond me.

That said you really need a tough skin on IRC on some channels, and always take the topic to the letter. That usually indicates what type of people hang there and what type of messages are accepted.

<comment><USER2> > I personally loath meta answers like "why are you doing X and asking Y" > instead of wasting the equivalent typing of explaining why X and Y is a bad > idea.

That's funny; I'm more often annoyed by the second response because often X and Y are only generally bad, not universally bad. Even though the supportee should probably have an up-front justification, it's reasonable to check for one and avoid handing out an unfair critique.

<comment><USER7> The point is being up front and to the point, in spirit with "don't ask to ask, just ask". Most of these meta-answers are founded in the belief that the asker doesn't know what they are asking. And by supplying another set of questions instead of just bluntly stating what you think, you are feebly trying to guard yourself from being wrong - which is something people hate to admit on IRC.

The better being that you explain that "X and Y is a bad idea" and getting a quick "No" in response (assuming the asker knows what he/shes asking), instead of having the asker having to going in to more (often unnecessary) detail.

</comment></comment></comment><comment><USER8> More people should be referred to this when introduced to IRC. Or really you should just be told this by anyone introducing you.

There is one thing wrong about the article though: irssi is clearly the best client... X-Chat? Are you mad!? :p

<comment><USER9> Agreed. I've tried many clients over the years and loved bitchX from the old days and now use irssi exclusively. It's great and really easy to learn. Very scriptable as well.

<comment><USER10> But ... but Mirc is such an amazing tool!!

(please don't hate me, I use xchat and irssi much of the time)

</comment></comment></comment><comment><USER11> I'm tempted to write a pilot for a show where the only purpose is to have silly explanations for technical things.

<comment><USER12> It's already been done, kind of, <http://www.youtube.com/watch?v=bCWA7uevo_Q>

</comment></comment><comment><USER13> These are fairly obvious to anyone over the age of 13... (except the first one perhaps)

Be patient, be polite, help out, and don't ask ambiguous questions without enough detail.

An inclusion of where / what servers to go to for help would be more useful. I think most people get lost with that rather than etiquette.

<comment><USER14> You'd be surprised how many people in there aren't over the age of 13!

<comment><USER15> I first encountered IRC at the age of 9 or so, when I installed Linux for the first time and randomly opened X-Chat, which took me to Freenode. By the time I was 13, I had engaged in screaming competitions with GNU fundamentalists in #gnu, asked hundreds of stupid questions in ##linux, and provided support to countless others in #pearpc and #distrowatch, and obviously grown a much thicker skin.

</comment></comment></comment><comment><USER16> I'll add a few points:

* Read the topic. That includes also any relevant URLs in it.

* Follow the channel for little time before asking anything.

* If you had a problem which was solved, tell how it was solved. This adds to the communal knowledge.

<comment><USER2> > Follow the channel for little time before asking anything.

Related: an IRC stream is always conversation of sorts and, for humans, there is only enough bandwidth for a few voices at a time to be heard. If three people have just asked questions or there are multiple ongoing discussions, it might be wise to wait until things quiet down a bit.

</comment></comment><comment><USER17> Guide to #startups on Freenode: don't ask questions, post cat pictures.

</comment><comment><USER18> Fortunately, not all irc rooms are filled with douches.

Of course, you should do your homework and be precise but "the Experts" should take it easy on newcomers.

</comment><comment><USER19> There's one thing that annoys me that you missed. People who ask for advice, then disregard any advice that is given.

</comment><comment><USER20> I wish I read this when I first started using irc. I always used to ask to ask...

</comment><comment><USER21> They should have simply let NUMB3RS explain IRC.

</comment><comment><USER22> >If you want to piss off the most knowledgeable person in the room; simply ask if you can ask a question.

Don't forget the corollary: Never ask if you can ask a question on channels where they don't like answering questions. You should know that its not a channel for asking questions. If you are brazen enough to ask a question expect the following answer:

        <a> How do I XY my Z?
        <@b> !google XY a Z
        <bot> http://lmgtfy.com/?q=XY+a+Z

<comment><USER23> Well, the point is you need to try to figure it out for yourself before you ask someone else directly for their attention. If someone simply points you to google, you should be able to tell them why that isn't an acceptable response to your question.

<comment><USER22>
        <a> That won't help my XY is W and V. What can I do?
        *b has changed the channel topic to: Don't ask questions.

<comment><USER10> In my experience, whenever someone has proven to have sufficiently searched out for an answer themselves, this doesn't come up.

That said, my primary experience in help rooms is in ##java on freenode.

</comment></comment></comment></comment><comment><USER24> I thought this was going to be about using IRC to control bot networks or programs in general.</comment>


Apple Reportedly Developing 5K Retina Thunderbolt Display with Integrated GPU - <AUTHOR> http://hothardware.com/news/apple-5k-retina-thunderbolt-display-integrated-gpu <comment><AUTHOR> If true, I think this is awesome. I ended up recently getting a top-of-the- line Macbook Pro because of its better GPU, but I would have greatly preferred a Macbook Air + this kind of external display.</comment>


When Not to Serialize - <AUTHOR> https://hacksoflife.blogspot.com/2018/08/when-not-to-serialize.html <comment><USER2> This quote from [http://erights.org/e/StateSerialization.html](http://erights.org/e/StateSerialization.html) has always stuck in my mind:

 _Do you, Programmer, take this Object to be part of the persistent state of your application, to have and to hold, through maintenance and iterations, for past and future versions, as long as the application shall live?_

 _\- Erm, can I get back to you on that?_

<comment><USER3> See also: configuration file formats. Outside of systems where configuring the installation is basically part of the sales process, you will probably have at least a handful of customers raising hell if version 10.0 doesn't seamlessly run with a config file from version 1.0. And maybe even vice-versa.

<comment><USER4> An upside to SAAS, I guess -- if the user data lives on your servers in a reasonably structured format you can try to migrate it, and your migrations don't have to work across too many versions if that's difficult (unlike file format compatibility, which is a long term commitment.)

Of course, that only works to a certain extent. Removed features can't be "migrated" cleanly, and often config files (or worse -- code written by users in most DSLs) aren't well-structured enough to make migration straightforward.

</comment></comment></comment><comment><USER5> I agree with the overall message of the article, but I don't think "serialize" is the right term here. Serialize means going from in-memory data representation to a flat bytearray, which is eventually persisted. There are numerous way to perform serialization, from just memcopying the datastructures up to defining a good and extensible persistent format and converting into that.

The compatibility and extensibility issues are mostly coming up from the first approach. And can often be avoided by utilizing a more flexible persistent format, which can be anything from a total domain-specific format up to json, xml, protobuf, etc.

</comment><comment><USER6> I think Serialization and associated changes in APIs is my #1 headache for software development. The problem is with all the new auto magic frameworks now it seems to be getting worse not better. Anyone got any solutions?

<comment><USER7> Do protocol buffers count as a 'new auto magic framework'?

[https://developers.google.com/protocol- buffers/](https://developers.google.com/protocol-buffers/)

<comment><USER8> The problem is, protobuf isn't just a serialization protocol, it's also a bunch of generated model code you have to start using in your application. You don't just serialize your domain model to protobuf, you tell protoc to build you some classes that _become_ your model.

Which means if you aren't careful, you can't easily move to anything else for serialization, ever again. Your code now uses protobuf-specific objects everywhere, because that's what protobuf encourages. I'm currently in a codebase where countless method signatures (which _should_ be serialization- agnostic) take or return `Message`-derived objects because, that's what we get when we read in a request or emit a response, and using those types everywhere was just so tempting.

And now, we have new requirements that introduce some dynamism to our data model, in a way protobuf doesn't provide, so we're trying to move away from protobuf, and it's turning out to require a rewrite of practically everything because these protobuf classes _are_ our data model, so everything depends on them.

What I've come to prefer is for serialization to be implemented a the boundaries of your service, with your models at least somewhat isolated from any given serialization technique. Protobuf is a foot-gun here because it blends these roles in a way that's hard to get away from.

<comment><USER9> > _What I 've come to prefer is for serialization to be implemented a the > boundaries of your service, with your models at least somewhat isolated from > any given serialization technique._

I think this is the right way to do it. Just like how UTF-8 to a string type is kept at the borders. Inevitably, someone comes along with a requirement that implies the first iteration of the data modeling was not only wrong, but backwards-incompatibly wrong.

It's hard to convince coworkers that it isn't code duplication though.

> _Protobuf is a foot-gun here because it blends these roles in a way that 's > hard to get away from._

I'm not sure; in many ways it is just trying to give you a way to supply it the data to serialize with those models. I'd be nice to not have the "foot gun", but I'm not sure what such a serialization framework would look like.

<comment><USER8> IMO the serializers should be their own standalone classes/modules which live separately from your application's core types. You can invoke them when you need to do the serialization and keep parallel versions of them for legacy clients, etc.

ActiveModel::Serializers work like this in Rails, although I haven't tried any similar approaches in statically-typed languages where protobuf is so commonly used.

<comment><USER10> For Python there's Marshmallow ([https://github.com/marshmallow- code/marshmallow](https://github.com/marshmallow-code/marshmallow)) and Django REST Framework if you're using Django ([http://www.django-rest- framework.org/api-guide/serializers/](http://www.django-rest- framework.org/api-guide/serializers/)). Both of these work as you described.

</comment></comment></comment></comment></comment></comment><comment><USER11> Coming up with a format which is independent of your in memory structure can be limiting in some situations. A successful strategy is to isolate key persistable types in a manner that allows you to carry the old types into later versions of your application at minimal cost. This allows you to deserialize the data in its exact original form. From this point a series of transforms are used to map the data to the current version of the application. The nice thing about this strategy is it is entirely additive - transforms are added as required and chained together and old transforms are never mutated. Having said this, if you can get away with defining your data structure up front, by all means do it as there are many advantages to doing so. If you cannot (unknown requirements, large team, etc) then a more rigorous transform chain approach can be a reasonable option.

</comment><comment><USER12> Example for C (for structures not using enums nor bitfields, because are compiler-dependant, and avoiding architecture-dependant types like e.g. size_t/ssize_t) :

if (islittleendian() && sizeof(mystruct) == REFSIZE_mystruct)

       memcpy(buffer, mystruct, sizeof(mystruct));

else

       conversion_mystruct(buffer, mystruct);

(so you can avoid slow serialization in most platforms)</comment>


Ask HN: How different was the software industry when you first started out? - <AUTHOR> <comment><USER2> When I started, TCP/IP was in the process of vanquishing other network stacks.

C or possibly Fortran or Pascal were the main languages. Although, skill with assembly was often necessary to work around buggy or non-performant compilers.

Information was shared on dialup BBSs - access to the internet was rare or expensive.

If you wanted to know something, you bought a book or got a job at a place that did that thing and learned from others.

x86 was just one of many possible hardware choices.

Companies were so desperate for people who could write software, I knew people who were hired right out of high school because they could program. They instantly made more money than their teachers.

Upon discovering UNIX and X11, a whole new world opened up. Learning that ecosystem has really paid off as I've been able to more or less ride that wave for decades.

</comment><comment><USER3> In the early 90's, everything was client/server where I worked. If you couldn't fix your problem from the command line, there was something really wrong with the software itself. If the database broke, it was perfectly normal to fire up a command line client and manually enter SQL queries to find the bug.

Before the decade was up, the overall belief was if you had to use the command line to fix a problem, there was something really wrong with the software itself. But you wouldn't use the command line to debug it. There is a reason penetration testers still use the command line so extensively to this day. I pity developers who don't get to learn what you can do from "underneath" since it is often so much more efficient.

The funny thing was, it was all client/server, but both the server and the client were powerful. Then things got monolithic and power was taken away from the client. And now that we're still reaping the benefits of Moore's Law, our clients are super powerful again, but we moved the server portion to "the cloud" which may or may not have simplified things. It's starting to look like the mainframe days again - just more efficient.

The takeaway is that no matter how you see things right now, it'll be deconstructed and reconstructed forever -- even if it doesn't really need to be. There is a lot of money being made on change for change's sake.

ADDITIONAL: A big thing back then was how information got shared so freely in the 80's and early 90's. It was easy to get into conversations about Artificial Life (for example) directly with folks at the various national laboratories. Once the Internet started to become commercialized, it was all about keeping secrets and profits - even on things that were mundane or reasonably well known to technical folk. Patent trolling really messed things up. There is still some openness, but it isn't as casually free as it was then.

Having said that, I really love how technology is evolving. Look at Raspberry Pi. In the 90's, you couldn't afford to build your own super computer to learn parallel coding, and cpu's were single core, so you couldn't really even fake it all that well. Now you can build some really amazing things on the cheap, with all the available sensors, etc, and of course, Arduino.

Perhaps sharing didn't really die. It just became more focused.

</comment><comment><USER4> When I started (1985) there was no web/internet to speak of. Development was for desktop apps and embedded.</comment>