Frequent versus infrequent developers, in languages and so on - <AUTHOR> https://utcc.utoronto.ca/~cks/space/blog/programming/FrequentVsInfrequentDevs <comment><USER2> The thing that always get me when doing infrequent development is the differences in how languages handle common tasks.

For instance, if I have a string and need to get its length. Do I call a length() function passing the string? Or is a string an object and there is a .length() member function? Or maybe its an object but the length is a property?

Not a super big deal...but it is an annoying interruption when I realize I don't remember which this particular language uses, and have to either go Googling or start looking around the code to try to find an example. There are a whole bunch of these.

Is it "elseif", "elif", "elsif", "else if", or sometime else?

Is the "for" loop like C, or does it take some kind of iterator object? Is it "for" or "foreach"?

Null, nil, undef?

How to break an outer loop from within an inner loop? How to continue an outer loop from within an inner loop?

Variable scope is a whole can of worms. In some to access a global from inside a function you have to explicitly say you want the global. In others variables in functions are global unless explicitly marked otherwise. Is the scope of a variable declared in a nested block just its block, or the whole function? Is it lexically scoped?

(The scope ones are particularly treacherous, because getting those wrong often won't cause a compile or run-time error. You might just end up creating a global when you thought you were creating a local, or changing a local when you thought you were changing a global).

How do I do multi-line string literals? How do I concatenate strings? Parse strings as numbers? Apply regular expressions to strings? Find substrings?

<comment><USER3> Classic polyglot problems :)

I really, really resent how every language seems to use the same concept but slightly different wording. The elif/elsif/'else if' distinction is a particularly annoying one. Same for null/None/nil

<comment> 52-6F-62 And camelCase or not to camelcase:

        foreach(...)
        /* OR */
        forEach(...)

</comment></comment></comment><comment><USER4> I'm also an infrequent developer in many languages. I find this is a really important article especially for new languages (Go, Rust, F#).

If your language has less adoption _most_ of your developers will be infrequent developers. There won't be many companies purely building on this one technology. You will have a lot of people dabbling in small side projects to see whether the language fits their needs.

So it's important to have an easy way to update your whole toolchain or install the toolchain easily whenever needed. E.g. updating my Rust toolchain means runnning rustup update and updating VSCode (the RLS extension updates automatically) cargo does everything automatically for builds with a very simple project structure.

It's also best if you can avoid the need for specific tooling (I use VSCode as my main editor anyway).

Another thing that should be thought of is that commands should do similar things like in other languages in order to not surprise people unnecessarily. If you want to go against the flow, you should have a good reason for it.

<comment><USER5> I sometimes wonder if the tooling should be different for infrequent tasks. I might update the build scripts for my desktop software just once or twice a year, given the infrequent use it would make sense to use a GUI for this rather than a text editor.

<comment><USER6> Indeed - infrequent tasks should be low-friction, or infrequent turns into "never".

<comment><USER4> I'd say low friction tooling even helps a famous language. It's essential for convincing the dabbler though.

</comment></comment></comment></comment><comment><USER7> If you infrequently use a language and you are not planning on writing write- once/throw-away code. Then don't use any library/framework. The overhead of development today as I see it is not just the languages, but the cognitive overhead of having to learn gigantic libraries and frameworks. I'm seeing libraries/frameworks that are 20x-100x times as complex as the language. Shed those bloat and free your mind. If the language is also fairly large, constraint yourself and restrict yourself to a subset of the language. It's not a must that one must use every feature of a language. The suffering of developers that use an infrequent language is self inflicted. Hell, don't use a language that you don't plan to use often unless it truly offers something that other languages don't, which is rarely so.

<comment><USER8> I also recommend avoiding unnecessary libs/frameworks for any code that you expect to run for a long time without change.

I do this at work when writing small services in Go and it works out well. Some have been running for three years now without being touched yet there is no code rot and anyone can easily pick it up.

<comment><USER9> Absolutely this. Even the base dev environment is often an exercise in madness. I loathe every new iOS version because Xcode will break my code in new and interesting ways, requiring me to recheck every single library I've developed to make sure they still compile (often they don't) and run (almost always they don't).

And then, once I've got that headache handled, I update the version number, type 'pod lib lint', and watch all the new and interesting ways that cocoapods has broken things since I last used it.

Every 3rd party component you rely on is something that WILL break as soon as you need to rebuild your project.

<comment><USER10> Not necessarily. People make fun of Java, but any half decent Java place, especially the ones using Maven, won't have this problem.

Maven is quite verbose and it forces you to pin a lot of things down. Where it doesn't outright force you, the general practices are to pin them regardless.

All the dependencies are in the same immutable Maven repo (or your own proxy/cache), all the build tool extensions/plugins/etc. are there as well. Java is generally very good at backwards compatibility, as is Maven itself.

So you can come back a few years later and do a :

mvn clean install

and things will work.

Of course, humans are fallible and things could still break due to various factors, but in this sense the ecosystem helps you and either offers stability already bundled it or guides you towards achieving it.

The downside: Maven is boring. Developers don't like boring :)

<comment><USER11> In JS world we got a package lockfile fairly recently. Locking your own package.json version wasn't enough because packages have deps too.

Beforehand running npm install on newly checked out repos was a gamble, especially given that we have packages for every minute "feature" like leftpad (which is a horror story of its own).

</comment></comment></comment></comment></comment><comment><USER12> As an "infrequent developer", I usually piggyback on others to find best practices, in case I have a bigger project. For the tiny ones it simply doesn't matter.

The advantages of being an "infrequent developer" is that you grow an intuition on how to get started with something completely new (cfr. Taleb's anti-fragile), and that you learn a lot from cross-contamination.

Also, others might refer to frequent/infrequent developers as specialists and generalists.

(Edit: reformulation of some Dunglish sentences)

<comment> GuB-42 I don't think that the "infrequent developers" they are talking about are necessarily generalists.

For example, you may be an expert in Python and need to write a bit of C code for now and then. It makes you a frequent Python dev and an infrequent C dev.

In fact, good generalists should be able to fit the "frequent developer" pattern more closely for any language, at a reduced efficiency of course. "infrequent developers" are more likely to be specialists that are out of their specialty.

<comment><USER13> I find this issue with Node.js stuff. I can't count the times where I found some software that looks great, would really help development, but then it's based off of Node (which we don't use at all), and it requires 3 build tools (none of which we use) and a pile of dependencies... :(

<comment><USER14> I think node of all things have no excuses. They're javascript all the way down, why don't they have one command to download, build and deploy everything, including any build tools that come to need? Instead they seem to have a baroque setup

<comment><USER11> Well maintained packages do have that:

        npm install
        npm run (dev|build|deploy)

Poorly maintained ones don't have these run command set and instead rely on pages upon pages of crap in README.md or do have a subset hacked together from whatever the dev needed for their FUD-driven development workflow.

Edit: as an afterthought: maybe the infrequent developers are to blame for not reading about what npm provides?

Edit2: another, I guess inexperienced, developer type I've seen in the wild is "I did some jQuery 5y ago, React probably is as easy to pick up and spaghetti out". For these: stick to what you know and don't play the hype game.

</comment></comment></comment></comment></comment><comment><USER15> Web Development in recent years has made being an infrequent Web developer unnecessarily complex, to the point that only frequent developers can perform tasks

<comment><USER16> Absolutely, I tend to stay away from web development, but when I have to do it it's just seems so unecessarily complex and painful.

<comment><USER17> Only if you are using the latest hipster JS framework. I write only vanilla JS (infrequently) and things have been getting easier and easier as browsers (and JS) advance.

<comment><USER14> jQuery seems to be an underrated gem. It's just as good as 10 years ago.

<comment><USER18> It's not that it is underrated, the paradigm has moved past manually grabbing bits of the DOM and updating them. Today, it is all about two way databinding. You have a variable that lives in your controller and when he is updated so is the DOM, automatically. I'm glad jQuery has been put to pasture because you end up writing way less code which is way more maintainable.

</comment></comment></comment></comment></comment><comment><USER19> I'd like to make explicit what the author made only implicit, that languages are just one example of many. For me, setting up an apache server used to be a task that took 2 hours, even when I was an engineer with half a decade of experience (mostly windows).

I view this as a major failure. In fact, if your open source software takes many hours to set up, it's costing hundreds of dollars of effort to learn the unnecessary quirks every time.

(Example issues: permissions, conf file failing silently, server installing in multiple distinct places leading to multiple installations, .htaccess ignored due to config setting, config settings including directories of other config settings, logs going to different places, OS security setting screwing up server. )

<comment><USER20> I like to defend apache a little bit here since you can actually do a lot with no config file or even a very small one. :)

It's your crazy (I mean really crazy on debian/ubuntu) distro who made it so scary.

[https://wiki.apache.org/httpd/Minimal_Config](https://wiki.apache.org/httpd/Minimal_Config)

</comment></comment><comment><USER21> Some cool insights in there that I have not had the ability to articulate myself but I have been feeling for maybe 5 or so years.

The biggest hurtle is that a "frequent dev" isn't always the best at remembering the sum of everything needed and so it takes an "infrequent dev" to write the docs and outline the helper tools and environment setup and common gotchas.

Which if done for a certain amount of time the "infrequent dev" will gain enough insight and mastery until they move into the "frequent dev" category. As a result they will become blind to the pitfalls. They become the blind "expert".

This is why I'm completely fascinated with teaching and knowledge transfer and I feel like there is huge advances that can be done in this field.

Here is the catcher, this isn't just limited to computers or programming! In fact it isn't even limited to spoken language.

This "blindness" to detail applies to all of reality!

If you want to read more checkout: [http://johnsalvatier.org/blog/2017/reality-has-a- surprising-...](http://johnsalvatier.org/blog/2017/reality-has-a-surprising- amount-of-detail)

<comment><USER22> > As a result [the now frequent developer] will become blind to the pitfalls. > They become the blind "expert".

This is known as "The Curse of Knowledge":

[https://en.m.wikipedia.org/wiki/Curse_of_knowledge](https://en.m.wikipedia.org/wiki/Curse_of_knowledge)

</comment></comment><comment><USER9> Another major source of frustration for infrequent developers is tools & commands that cater to the 10% first and the 90% second (commands that require a bunch of flags/configuration to be set for the 90% use case).

If your tools/frameworks don't do the 90% use case by default, you're doing it wrong.

</comment><comment><USER14> I was trying to be an infrequent user of OpenGL. People were totally not understanding why amn't I "just writing a shader".

Modern 3D environment is hostile to infrequent developers now that drawing a simple sphere suddently needs a page length blob of code. Or a "model". Exported from "3D editor".

<comment><USER23> I frequently imagine the terror that junior computer graphics devs encounter when they realize you can't just "draw lines" in OpenGL.

<comment><USER14> ...and there's no good reason why you can't, other than that in some iteration of API, frequent developers could not imagine why would anybody need that.

<comment><USER18> Isn't it because everything is represented as triangles? That is fundamental to how openGL works I believe.

<comment><USER14> Everything can be represented in terms of everything else. It's a matter of caring, or not caring, about convenience.

</comment></comment></comment></comment></comment><comment><USER24> Go is actually a pretty good language for infrequent developers. There isn't much to is so it's easy to pick it up again. The language is largely backward- compatible so it's easy to pick the latest version and get up and compiling. It also encourages low levels of abstractions which in my mind is the biggest scourge against infrequent programmers. Now if only dependency management was solved...

<comment><USER25> I agree that Go makes infrequent use easy. That was part of why I went for python over perl; I just didn't use perl often enough for it to stick in my head. There are similar issues with Haskell, just because of all the many libraries of abstractions and operators to memorize.

I still don't see why dependency management has everyone so up in arms for Go, though. Especially for infrequent use, it's hard to beat just copying the lib into your source tree and re-fetching from git every now and then.

<comment><USER10> > I still don't see why dependency management has everyone so up in arms for > Go, though. Especially for infrequent use, it's hard to beat just copying > the lib into your source tree and re-fetching from git every now and then.

That's not "dependency management", that's step 1 of any development environment setup ever made. It's basically giving up on dependency management and doing everything manually.

The correct way to do dependency management:

Have a config file with all the dependencies, clearly specified, including versions.

Have a tool that has a standard command (mvn install, gradle build, npm install, etc.) without parameters that brings the dependencies locally and makes them available for your local environment.

For the standard command, depending on your environment and philosophy, either fetch sources or fetch sources and compile them or fetch binaries.

To upgrade a library, change the version in the config file and re-run the tool. To add a library, add the library info in the config file and re-run the tool. To remote the library, remove the library info from the config file.

The cognitive overhead is much, much smaller with a well designed dependency management setup. I just run the standard command and it does what I need, no rummaging through Github repos to find what I need.

<comment><USER25> Me, I long for the days when I could just download a tarball and be done. :-)

Seriously, as a mostly C++/python/R developer, maven was a PITA to set up for experimenting with Java, and I still don't feel like I entirely understand the npm/bower/yarn ecosystem. (Will they install globally or locally? What permissions do I need? etc. etc.)

It's certainly not something that I can't learn, or something that's really all that complex, but it's another barrier to just messing around with a new project. It's better for the frequent-users than the infrequent.

As an infrequent user of Java/Javascript, I'm fine with just downloading a tarball or cloning a single all-inclusive repo, and dealing with it being harder to update or to push a change back to the source project.

Even in python, I just maintain a local global install and occasionally update numpy/scipy manually. I'm not saying it's the best setup, but it's pretty easy to download verson X.Y.Z, config/make/make install, and done.

<comment><USER10> I imagine the pain is setting the environment variables? This thing: [https://maven.apache.org/install.html](https://maven.apache.org/install.html)

After that you run mvn install and things should just work. If not, the project maintainers have bigger issues :)

</comment></comment></comment></comment></comment><comment><USER26> I don't find that this hits home.

Instead, I find that nobody on planet Earth is as disrespectful of your time as programmers.

Imagine the slowest waiting room for some government office. You might be stuck sitting there for 5 hours.

To a programmer, that's nothing! You'll be up and running the same afternoon.

They routinely send you off to RTFM, and if it will only take you two or three days that's nothing. It's like programmers live in a magical land where time is free, and they just don't understand why it's an issue for anyone.

It's about time as a resource.

<comment><USER27> That's a very black and white point of view. There's lots of grey areas and varying urgencies for problems. I'm sure most respectable programmers would take care of matters as fast as they could, even if it isn't that urgent.

If it takes me an hour to take systems back up after things go bad during the after-hours, it's not because I was purposely not doing my work. It's because that's literally what took me to fix the problem.

Programmers aren't magicians and we certainly aren't out there to get you and waste your time on purpose.

<comment><USER26> Tangent

\</comment></comment></comment><comment>--

>Programmers aren't magicians

All right, so this part is tangential but after I posted my (GP) comment I realized that in one sense programmers _are_ magicians. I had left the following aspect out of my black-and-white comment:

(I hadn't considered that) some of the best programmers I know don't REALLY read every word, the way you read my comment or I read yours. There's just no way there's enough time, given the speed of use of totally new information in totally new documentation that I've seen. It would be inhuman if they really read every word.

I think they must skim and scroll and use magical ways of picking out just what they need.

So when someone links a 500-page specification and tells you to "read it" (which might take, say, two weeks of an hour a day to read, starting at the first word and ending on the last -- perhaps they legitimately expect you to "read" it in 1 minute 48 seconds, since that's how long it takes to "read" it.

Back on topic

\</comment><comment></comment><comment>---

You've directed most of your response to how long it takes to do something. But I had actually directed my comment at how long, when designing (documentation/installation/whatever) you _expect_ people to spend doing something.

With the tangent I just added, I realize that perhaps some of it is misleading. If you direct someone to do something that takes 15 hours, that doesn't mean you don't expect them to be done within 3-10 minutes. Because programmers have magical abilities at times.

So it is far from as certain as I had said.

</comment><comment><USER28> Elixir got a lot right with regards to the infrequent developers -- the tooling and the package management is very nice and low-friction.

</comment><comment><USER29> Even for non-infrequent developers, an automated dev environment set up is welcome.

</comment><comment><USER30> As an infrequent developer, dabbler, and amateur in a vast number of programming languages, I think a great deal of the difficulties that arise when plodding around between different languages stem from a great number of design decisions that prioritize elegance, abstraction, terseness, and library economy over user experience. What results are a number of extremely powerful language features that are useful to _everyone_ but remain inaccessible to anyone uninitiated into the cabal of that language's practitioners.

While we're on the subject of cabals, I think Haskell is a paragon case of this type of situation. Haskell is a phenomenal language and has the potential to be incredibly expressive and useful when it comes to accomplishing tasks that require one and done programmatic solutions. However, the language ecosystem refuses to abandon a great number of practices that, while they are historically and conceptually justified given its relation to category theory and mathematics, will ensure haskell never sees the same degree of general purpose adoption other languages do. For example, the following function is one I came up with on the spot for illustrative purposes:

folds :: (b->b->b)->[b]->[b]

folds f x = map (\n -> foldl f n x) x

It's not immediately obvious what this does unless you have basic knowledge of functional programming. Part of the difficultly stems from my choice of names, but I'm sticking with the convention to use single letters in the majority of cases that capture abstractions.

If I have obtained the prerequisite knowledge of haskell necessary to quickly read the above simple function and tell what it does it's incredibly powerful and easy reading, however, if I'm just picking things up for a small project there is waaaaaay to much learning overhead for me to even consider using haskell. Compare the haskell function with the same function expressed in javascript:

function folds(f, items){ return items.map(x => items.reduce(f, item)); }

If you are familiar with haskell, the haskell version is probably faster to read and comprehend. However, if you don't know haskell the js is probably easier to come to grips with based on its lingual contents.

The there's common lisp, which _almost_ reads like English if it were't drowning in parens and quote weirdness:

(defun folds (f items) (map 'list (lambda (item) (reduce f items :initial- value item)) items))

The keyword arg goes a long way in helping the code read like a sentence, which is a good thing. In fact, that's the sort of syntactic support of semantics swift promotes using parameter labels:

func move(from start: Point, to end: Point)

x.move(from: x, to: y)

It's immediately clear to a caller what purpose each of the arguments of that function serve.

Obviously this is a huge, complex issue, and I'm never going to do it justice in a hackernews comment, but in general I think if library designers and developers focused more on user experience and usability we'd have more pleasant code to interact with. User experience isn't a concept reserved strictly for graphical applications--any tool, no matter what it is, has a user experience, and it's important to consider the user up front when we go about designing technology.

In this respect I think Knuth's concept of literate programming has a lot of worth, as it can cut down on research time tremendously and increase ease of use--if the code itself can provide _all_ of the contextual information I need, there's no reason for me to go scouring the documentation, which-- another issue--is frequently spotty, unclear or confusing, and on some occasions incomplete.

<comment><USER10> I wish this had more upvotes. I agree. That's one of the reasons Python is so popular, despite its many flaws. It's just easier to grok for newcomers. And overall it is quite consistent and usable.</comment></comment>


Photography is dead, long live photos - <AUTHOR> http://www.engadget.com/2010/07/10/switched-on-photography-is-dead-long-live-photos/? <comment><USER2> There are a number of serious problems with this vision:

1) Of course the digital components of cameras (storage size, sensor resolution, processing power) will continue to improve at Moore's law pace, but optics is quickly becoming the limiting factor. In particular, diffraction limits sharpness as you increase depth-of-field (a result of the small aperture size) and the limited number of photons in dark scenes limits our high-ISO potential and resolution on small sensors.

2) "...the ability to keep everything viewable in focus at the same time".

Even if you could do this you wouldn't want to. Depth-of-field and focus point are some of the most important creative decisions a photographer makes per photo, and since they are "3D" phenomenon the effects cannot be accurately simulated during post-processing. (maybe stereoscopic cameras would be able to but then you need two lenses, which would add cost & weight in comparison to a "single" lens model)

3) "But perhaps the most radical thing about this camera is that it's really a camcorder. Rather than take individual stills, Wonder Camera owners would simply have their pick of perfectly crisp photos as frames grabbed from video."

Maybe, but there would have to be a way to have it integrate over several frames to get long-shutter-speed effects, and there would have to be a way to "tag" points in time so you're not sifting through hours of footage later to get the stills you wanted. Much of what this article proposes sounds like it just defers work (choosing aperture, choosing shutter speed, choosing point in time) to a later point, something I would NOT think photographers would want to do, since they already complain about how long post takes!

4) Finally, even this concept turns out to be 100% correct, I don't see it changing the art of photography all that much. As other people here mention, good photography is about good subject matter, framing the shot, clever use of lighting (whether artificial or available), post-processing to get the desired artistic effect, and being in the right place at the right time. Technology can certainly assist us with these things, but fundamentally it is these human element, not the technology, that makes photography what it is, and that won't change. As technology improves the photographer's decision process focuses less on making technical trade-offs (like shutter-speed vs aperture, high-ISO vs noise), but the creative aspects remain as important as ever.

</comment><comment><USER3> It's a boring concept. Get on with it, Canon, don't waste our time with concepts. Don't tell, just do. You are the biggest maker of cameras in the world. Leave publishing concepts to those who can't actually make the future happen.

Aside: I don't think photography will ever die. Video is not just improved photography, it's something different. Stopping the action and making it possible to look at details are unique to photography. Photography is not just a wax cylinder [+] that will be cast aside as progress marches on. (Shooting halfway decent videos is also much harder than shooting halfway decent photos. But, arguably, people might not care about that and shoot their pathetic videos anyway.)

[+] <http://en.wikipedia.org/wiki/Phonograph_cylinder>

<comment><USER4> Exactly. And personally I think digital photography is a completely different animal from film and becoming more so everyday.

</comment></comment><comment><USER5> When I've seen professional photographers at work, they seem to operate by taking a LOT of photos, often manipulating the shutter as fast as it can go, in the hopes that one of the pictures will be just right.

Isn't this the logical extension of that practice?

<comment><USER6> That's the new way of doing it. The art of photography is about framing, subject, lighting, and a range of other factors. When film cost money it was about squeezing good shots out of a roll of 24 or 36. The cost of film, development, and blackrooms had a real $ value attached to it. You hired a photographer because he/she knew what they were doing and knew what you wanted.

Now, digital cameras are cheap and everyone has one. You can basically post a project online, and get 1000 photographers to respond. Instead of hiring 1 photographer to hopefully get "the" shoot. You can browse through flickr and other photo sites chances are they will have what you need.

</comment></comment><comment><USER7> Just like motion pictures killed photography, right? After all it was just the same as still photography, only 24 times per second?

</comment><comment><USER8> I think you guys are being a bit too short sighted. This shows some pretty neat "out-of-the-box" thinking about photography. In the past you were restricted to taking lots and lots of photos to possibly get one that worked. With video streams you can capture all you want and then go back and find the gems; probably stuff that you didn't even see the first time through.

Think about a play at your child's school; while your concentrating on your kid some other kid on the other end of the stage does something funny. Now you can go back "in time" and grab both shots and even a short section of video for context.

The whole thing makes me think of Blade Runner and the ability to shoot such high definition "streams" that you can "zoom - enhance" them all day long. Pretty cool if you ask me.

<comment><USER9>
      *Think about a play at your child's school; while your concentrating on your kid some other kid on the other end of the stage does something funny. Now you can go back "in time" and grab both shots and even a short section of video for context.*

I'm not sure that is the case. The weakest link in photography and videography is the human holding the camera. No amount of technology can fix that.

What does that mean? People with camcorders tend to zoom and pan like there's no tomorrow (classic case of "just because you can doesn't mean you should"). So assuming that a normal person is shooting their kid's play, they probably don't know to shoot it wide, meaning that the funny moment will be still offscreen, since the camera's zoomed in on their kid. And I haven't even mentioned any depth-of-field settings yet.

Some of the ideas in the concept are neat and make sense in theory, but in practice, you're just going to end up with way more video that none of your friends and family want to watch and are too polite to tell you so.

</comment></comment><comment><USER10> To me, photography is all about thinking about the shot you are going to take. Things that people have mentioned before me, framing, lighting etc, this just takes the heart out of it in my opinion.

Also, I wonder if this is going to take users a lot longer to pick out photos. Even now with digital camera's and people shooting at will there is a whole lot of material to browse through to pick a few photos that are good.

</comment><comment><USER11> photography won't be dead. I heard same opinion when digital camera emerged. One day you see that beautiful liquid "photo"stream, but at same time you can still feel the beauty of gelatin silver print as great "photography".

</comment><comment><USER12> I know this article's focus is more on the technology but this specific camera is going to look incredibly old in a year or two.

</comment><comment><USER13> I'll stick to my 7D for now.</comment>


Highest-Paid YouTube Stars 2018: Markiplier, Jake Paul, PewDiePie and More - <AUTHOR> https://www.forbes.com/sites/natalierobehmed/2018/12/03/highest-paid-youtube-stars-2018-markiplier-jake-paul-pewdiepie-and-more/#3eb178f909ac <comment><USER2> Honestly I think the most fucked thing on this list is the top earner is a child whose parents obviously use him as a cash cow. There's no protection for children on YouTube, unlike a child actor.

You want to dive into a creepy side of YouTube, just look into toy channels and family channels. Toy advertising runs YouTube. My 7 year old cousins barely watch TV, they all mindlessly watch YouTube channels that have very little regulation on advertising. The kids don't understand they're just watching a ton of ads.

</comment><comment><USER3> It seems like a majority of this article is devoted to mark a pair of pliers. Even though he is number 6 on this list. With little no no mention of the actual top 3 people.</comment>


Silicon Valley Doesn't Like Trump. It Can Still Work with the Government - <AUTHOR> https://www.nytimes.com/2018/09/03/business/silicon-valley-trump-government.html <comment><USER2> I find it unsettling that Silicon Valley employees would rather see a foreign nation win the race to build autonomous killing machines. It's not just the open contempt they have for their own countrymen, but it seems borderline suicidal.</comment>


The Best Name Ever for a Computer Language - <AUTHOR> http://blog.pokercopilot.com/2010/02/best-name-ever-for-computer-language.html <comment><USER2> Tech has a misogyny problem? No way.

> It took some years for me to realise that Linda was named after the porn > star Linda Lovelace. It was a subtle joke and allusion to Ada by the > language's designers

Try and read this and then explain how this is an appropriate "subtle joke", "allusion to Ada [Lovelace]" and "best name ever for a computer language":

[https://en.wikipedia.org/wiki/Linda_Lovelace#Charges_against...](https://en.wikipedia.org/wiki/Linda_Lovelace#Charges_against_Chuck_Traynor)

<comment><USER3> _sigh_ I know I shouldn't touch this with a ten foot pole, but I really don't think overreactions like these help anyone.

First of all, sexist jokes are a bad thing, but we need to keep in mind the meaning of the word "misogyny": _hatred_ of women. While sexist jokes desensitize men to sexism in general, which can _lead_ to misogyny, the knee- jerk reaction you're having is beginning to resemble crying wolf.

As for the name Linda, it is a clever reference to a person who shares the same surname as the person for which another programming language is named. No doubt the choice of the person was motivated by that person's fame and no doubt that choice was immature, unprofessional and sexist. Likewise, calling it a "best name ever for a computer language" is probably equally immature and unprofessional.

But the fact is that the reference really is clever and a subtle joke. I agree with you that it's not appropriate, but it's not really the reason to cry "misogyny". Criticizing the OP for being childish, unprofessional and sexist would have been enough without trying to demonize him.

<comment><USER2> > First of all, sexist jokes are a bad thing, but we need to keep in mind the > meaning of the word "misogyny": hatred of women.

You are correct in that the definition of misogyny is the hatred or dislike of women or girls. Misogyny can be manifested in the denigration or sexual objectification of women and in entrenched prejudice against women. From Wikipedia (first item in the definition) "Misogyny .... is a central part of sexist prejudice and ideology and, as such, is an important basis for the oppression of females in male-dominated societies. Misogyny is manifested in many different ways, from jokes to pornography..." (Allan G. Johnson).

The attitude expressed in the linked article is that pornography is an appropriate (and amusing) subject to link to something to be used in academic and professional contexts. Further, that it's amusing that pornography is linked to a prominent woman simply by virtue of her surname. In doing so, those who named the programming language and those who find it amusing are denigrating both Linda Boreman and Ada Lovelace and expressing and normalising the attitude that this is amusing and appropriate. I find this a clear case of misogyny.

> I really don't think overreactions like these help anyone.

I don't think it's an overreaction, and I would think that the appropriate reaction is to condemn these instances of misogyny. In doing so, hopefully we can create an environment and industry less hostile to women and girls. I'd say that would help quite a few people.

</comment></comment></comment><comment><USER4> The page says, about C#,

> C#, which is also a musical note one semitone higher than C.

Which is true enough, but am I the only person to think that the original idea must surely have been to signify "(C++)++", with the two "++"es one on top of the other? (See: [http://imgur.com/8On6Stn](http://imgur.com/8On6Stn))

[EDIT: Thanks, _wtetzner_ : apparently Anders Hejlsberg had the good taste to agree with me :-).]

<comment><USER5> [http://www.donnfelker.com/how-did-c-get-its- name/](http://www.donnfelker.com/how-did-c-get-its-name/)

</comment></comment><comment><USER6> Agree with the article; Linda is great, both the name and the project. It was one of the more interesting topics of a Distributed Systems course that I followed, but I never ended up using it (or its concepts) in practice due to the performance overhead.

As a nitpick: Perl is originally not an acronym, the language used to be called "Pearl". [https://en.wikipedia.org/wiki/Perl#Name](https://en.wikipedia.org/wiki/Perl#Name)

</comment><comment><USER7> I'm currently designing a Hardware Description Language. I'm probably going to call it Vee, because it's main competitors are VHDL and Verilog HDL, which have the same acronym. So mine will be VeeHDL. I'll HN it when it get nearer to completion.

PS I am aware no one says Verilog HDL...

<comment><USER8> When you release it, if it is good, I will curse your name (hah) when I try to google for information and get back 10,000,000 near misses.

</comment></comment><comment><USER9> No mention of TCL, pronounced "tickle"? This was the scripting language used in the ArsDigita Community System, one of the first commercially available platforms for database-backed websites.

<comment><USER10> This is a good point, that some languages cross barriers. Tool Control Language is just another acronym, but "tickle" is a funny one.

<comment><USER8> There are a number of TCLs (usually job control shells similar to JCL/DCL/etc.) but for some reason they never get called "tickle" the way Tcl does.

</comment></comment></comment><comment><USER11> What exactly is so brilliant about naming a programming language after a porn star, especially one famous subjected to sexual abuse? How on earth is it a "subtle reference" to Ada Lovelace? What do they have in common, apart from both being women? I don't understand the premise for this article.

<comment><USER12> They have a surname in common, it seems.

The article calls Linda a porn star, but she became an anti-porn activist. I call sexism on the article for childishly thinking that loose association with sex makes something "best ever", and double sexism for failing to acknowledge her choice to _stop_.

<comment><USER11> Oh, good point on the surname. Don't know how I managed to miss that.

Totally agree on the rest of your comment.

<comment><USER8> "Oh, good point on the surname. Don't know how I managed to miss that."

Don't feel bad. You were not the only one.

</comment></comment></comment></comment><comment><USER13> I personally like that PHP originally stood for _Personal Home Page_. Love it or hate, it's pretty cool that a language with such humble roots rose to such widespread use.

</comment><comment><USER14> Clojure is probably one of my favorite language name ever; it's an homonym of an extremely important concept in the language, the 'j' in the name refers to the Java/JVM ecosystem and it's very easy to google for.

</comment><comment><USER15> > A reworking of C++ became D

Hey, this is pretty offensive! D is a clean and nice language, compared to the comparatively train-wrecky C++.

<comment><USER16> > There are only two kinds of languages: the ones people complain about and > the ones nobody uses.

</comment></comment><comment><USER17> I've always been partial to "Lua". It's as fun say as it is to work with.

</comment><comment><USER18> I heard that the perl name also is an allusion to it being found primarily within the shell.

</comment><comment><USER19> > So a successor language to C was C++ (Like C, but a bit better)

C++ is not a bit better than C. It's a whole lot better (for most situations, that is).

<comment><USER4> Of course, in C, "C++" actually means "add 1 to C, _and then use the old value_ ". (After executing C=3; D=C++; the value of D is 3, not 4.)

<comment><USER20> Yep, and I bet you've maintained that project as well: "//" comments, and that's about it.

</comment></comment></comment><comment><USER21> Maybe it's because I've been watching too much _Justified_ , but I really liked hearing the "Harlan" announcement.

</comment><comment><USER22> "BODOL" is pretty funny.</comment>


All Twitter Mobile Traffic Is Now Powered by Node.js - <AUTHOR> https://twitter.com/necolas/status/829128165314306048 <comment><USER2> Wish they'd do a full write-up. I'd be interested in how they run their node processes.

      - Using containers, VMs, bare metal?
      - Using a process manager like Forever[1], PM2[2] or just native systemd?

[1] [https://github.com/foreverjs/forever](https://github.com/foreverjs/forever)

[2] [https://github.com/Unitech/pm2](https://github.com/Unitech/pm2)

<comment><USER3> They probably will a bit later. Highly doubt that they use forever or pm2 tho.

<comment><USER4> Out of curiosity ( because we use pm2 here, and it works well ) why would you doubt them using those solutions?

<comment><USER5> Judging from their other infrastructure talks its far more likely they are shipping the application in a container to Apache Aurora, and having the process managed by Mesos.

I can't remember if all their services are now running on Mesos, but I'd bet their newer ones are.

</comment></comment></comment></comment><comment><USER6> I'm still confused.

Did they add a layer between their backend and mobile to pre-render the page server side, or did they get rid of their whole scala/jvm stack to replace it with Node?

<comment><USER7> My guess is they have a front with Nodejs for mobile.twitter.com and behind that you have all their scala/jvm microservices. Recoding all their microservices would be way too expensive. I don't think they use Nodejs for their RESTful API but I am curious to see more about that. Uber uses Nodejs for their GPS API so who knows...

<comment><USER6> ha, that would make sense!

</comment></comment></comment><comment><USER8> They seem to have done this only for Webpack (splitting JS libs + prefetching).

Why use Node at all? It's all static content...

Crazy that a top engineering post is about some company discovering "compile- time".

Next post will be about how they discovered this thing they call Testing?

<comment><USER9> Most likely they include a bit of Server Side Rendering using the same templates they have in their compiled asset. Actually getting to share code here would be a pretty big win.

</comment></comment><comment><USER10> I remember seeing Twitter switching from ruby/rails to the JVM for a lot of their backend a few years ago. I wonder why they're using node now (unless the mobile traffic was never moved to the JVM)?

[https://www.infoq.com/articles/twitter-java- use](https://www.infoq.com/articles/twitter-java-use)

</comment><comment><USER11> I'm impressed, it's very snappy.

</comment><comment><USER12> anyone knows why it was done?

</comment><comment><USER13> why did not go for go</comment>


Meet Bill Gates, the Man Who Changed Open Source Software - <AUTHOR> http://www.wired.com/wiredenterprise/2012/01/meet-bill-gates/all/1

<comment><USER2> Wired used to be a good magazine full of interesting and insightful articles.

Sigh...</comment>


Study suggests lithium in drinking water to lower suicide rate - <AUTHOR> https://www.cambridge.org/core/journals/the-british-journal-of-psychiatry/article/association-between-naturally-occurring-lithium-in-drinking-water-and-suicide-rates-systematic-review-and-metaanalysis-of-ecological-studies/B7DDAF6E2A818C45EA64F3424E12D67A <comment><USER2> [https://www.nytimes.com/2014/09/14/opinion/sunday/should- we-...](https://www.nytimes.com/2014/09/14/opinion/sunday/should-we-all-take- a-bit-of-lithium.html)</comment>


Ask HN: Code review tools - <AUTHOR> We've been using Gitlab's merge request resolution/code review tool for as long as I've worked here (9 months). However, it seems like Gitlab has gone and broken a good workflow: previously, a line in the diff marked with a comment would be marked resolved whenever the next commit would touch that same line on the diff. Now the line has to manually be marked--I can see validity to this, but maybe I just don't like change.
Anyway, I'm just curious of any other code review tools (which don't send our code anywhere questionable) which allow for similar functionality. Please note, we're pretty sold on the Gitlab kool-aid for now, so switching off doesn't seem viable. <comment><USER2> GitLab backend lead here, and the guy who developed that feature :)

What you're describing is indeed a departure from previous behavior, but I think it is a change for the better, even if it may take a little bit of getting used to. You're not the only one who was surprised by it though, and it's being discussed in [https://gitlab.com/gitlab-org/gitlab- ce/issues/21406](https://gitlab.com/gitlab-org/gitlab-ce/issues/21406) I've laid out my thoughts in a comment there.

Feel free to chime in; as always, we'd love to hear your input!

<comment><AUTHOR> I'll go add my grievances, then... You asked for it!</comment></comment>


Why Don't We Just Call Agile What It Is: Feminist - <AUTHOR> https://firstname.lastname@example.com/why-dont-we-just-call-agile-what-it-is-feminist-8bdd9193edba <comment><USER2> >One way of making Lean-Agile methodologies more palatable to progressive and non-profit spaces could be to define them in a different way.

I'm really not seeing why these two paradigms need to relate to each other at all. Lean-Agile is not a moral framework it's a business strategy. If the private political beliefs of your employees/coworkers are interfering with your operations you already have a much more serious problem than making a particular strategic approach more palatable to one group of people. Bringing politics into the workplace is a mistake.</comment>


Seven Weeks to Venice: History Through Isochronic Maps - <AUTHOR> https://resobscura.blogspot.com/2018/10/seven-weeks-to-venice-history-through.html <comment><USER2> What might have happened to degrade postal service between Paris/Savoy and Venice between 1500 and 1765, from 2 weeks to about 3.5? Could it have been possibly been Switzerland leaving the HRE (and maybe imposing border duties) in 1648?</comment>


Rebecca Black Means The (Internet) Fame Game Has Changed - <AUTHOR> http://techcrunch.com/2011/03/20/fun-fun-fun-fun-fun/

<comment><USER2> The AOL-ization of TechCrunch headlines continues apace.

More technically, SEO-ified titles like this are a great example of Goodhart's law:

<http://en.wikipedia.org/wiki/Goodhart%27s_law>

<http://wiki.lesswrong.com/wiki/Goodhart%27s_law>

Techcrunch is going to lose its audience with posts like this over time because they are improperly using a global trend ("Rebecca Black") to attract a local audience (fairly technical/entrepreneurial crowd, or used to be).

One possible technical solution would be for Facebook to launch Facebook Trends, such that you could start cross-sectioning Google Trends by _demographic_. This would mean blogs could stop going for lowest common denominator stuff and start at least putting together linkbait titles optimized for their intended audience.

[Of course, this only works if the global strategy actually is suboptimal relative to the local audience strategy. Empirical question.]

<comment><USER3> TechCrunch is dead to me, and was long before AOL bought them. The AOL purchase was simply public acknowledgment that the fix was in.

</comment></comment><comment><USER4> The article seems unnecessarily harsh, frankly. It's easy to forget in all of this that Black is still 13 years old.

<comment><USER5> Being young doesn't (and shouldn't) give you a pass in life, in any industry. For a HN crowd example: just because you started your first company in high school doesn't mean it's any more or less legitimate than one started by college students. Results and talent should be the measure of success. The article simply points out the 'results' and 'talent' of the Ms. Black...

<comment><USER4> I'm not saying she should get a pass in life. I'm saying that mercilessly mocking a teenager for failing at something like this is just out of line.

</comment></comment></comment><comment><USER6> Rebecca Black is the gift that keeps on giving. Here's another business idea...get kids parents to spend $2000 and then produce their kid's music videos.</comment>


SEO advice for a small (non-IT) business? - <AUTHOR>

<comment><AUTHOR> hi, i've started working for a small tech company (catalysis, engineering, R&D; services) and to my horror, i've discovered it's almost impossible to find us on a search engine unless you know our company name. I suspect that a consultant got the website up and running a few years ago and nobody has really fed and watered it since. Compared to the crowd that hangs out here i'm an IT newb but i'm suspicious of hiring a SEO company (especially one that cold calls us!) since i'm not qualified to distinguish quality from snake oil. Can anyone recommend a quality service provider or should we just focus on making the best quality site we can, try and get our customers to link to our homepage and make sure we're indexed? Any help appreciated.

<comment><USER2> Do the research and do it yourself. It's not rocket science, and most SEO services seem to be snake oil salesmen to me. Even the honest ones don't have that many tricks to teach you. If they were to sit down with you for an afternoon, that would probably be enough to tell you most of what you need to know.

<comment><AUTHOR> thanks david. ideally this would be the end result, i was just wondering if there was a way to purchase the experience quickly while on the learning curve without getting ripped off.

<comment><USER2> You could pay for a day/afternoon. The people out to rip you off will be looking for long term contracts, to milk you, whereas someone on the level ought to be happy to try and impart as much knowledge as possible in a short time frame.</comment></comment></comment></comment>


Most common one-line bugs in C?  - <AUTHOR> http://stackoverflow.com/questions/5438347/most-common-one-line-bugs-in-c <comment><USER2> There's lots of C gotcha lists out there; the "Undefined behavior" series is good (and I think Koenig's Pitfalls book from 1989 is still worth reading (pre-ANSI C)

<http://www.literateprogramming.com/ctraps.pdf>

<http://blog.regehr.org/archives/232>

<http://blog.regehr.org/archives/226>

<http://www.andromeda.com/people/ddyer/topten.html>

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

</comment><comment><USER3> I have to admit that after reading that over, I find myself wondering why we teach students C as their first language...

<comment><USER4> I agree; we should start with assembly language. Students will never understand why these are dumb things to do until they can visualize the assembly code they get translated into.

<comment><USER5> C, being the glorified assembly language that it is, would be an excellent intro to programming if we didn't insist on teaching it as a high-level language.

A beginner's course in C will tell you "uninitialized variables are bad", and "don't use pointers after free", but it won't explain the stack frames or heaps that underpin so much of our computing.

I happen to think that having C blow up in your face (and fixing it) is one of the best ways to learn the subtleties of programming.

<comment><USER6> A lot of students would not respond well to that kind of approach. It's too much at once; you're trying to teach them to think like an idiot savant computer, _and_ teach them common patterns for translating their thoughts into code, _and_ hit them with a bunch of low-level details about pointers and stacks and instructions? Some exceptional students would thrive. Others would dig in and do sort of okay, passing the test and then maybe learning it properly later on. Many -- maybe most -- would just get discouraged and switch majors to something where they'll never have to deal with null pointers or case fall-through or (god help us) malloc alignment along dword boundaries.

If you want to do it that way, you've got to take one thing at a time. Colin's idea of starting with assembly language isn't nearly as crazy as it sounds; I know several people who learned that way. Personally, I would start with very simple, linear programs in a high-level language like Python. Let them get a feel for it, and fiddle around. Then gradually start introducing more and more difficult concepts, like if statements, or looping, and how to use these strange new wonders. Later -- much later -- you'll be able to talk about the low-level details exposed by a language like C. If you try it too early, you'll either get head-explosions or blank stares.

(Incidentally, head explosions are preferable. One of the greatest horrors of teaching is that there will always be students who stare at you with looks of blank incomprehension, and it always might be your fault.)

<comment><USER7> I mostly agree with this answer. However, in my experience, starting with a high-level language (like python) is a double-edged sword.

a) It fails to get people interested in low-level things like call stacks and frames. Someone once told me, "My language frees me up to think about the really important things: like solving the problem at hand. I don't have to worry about things like the stack and where my memory is going or coming from." Perfectly valid point maybe, but I didn't learn about these things because I needed to, I did it because I was interested and curious. I think C and it's pointers played a big role in helping me "get interested".

b) People take the _awesome_ things in high-level languages for granted. When I first moved into python from C, functions as first class entities blew me away! Lisp macros were like learning to do magic. People who have only used a high-level language don't give these features the credit they deserve. (Alright, this might just be a pet peeve of mine...)

I think that C _should_ be taught to students, at a slower pace and in more detail than it was taught to us. And if it occasionally blows up in their face, I think they'll be better off for it.

</comment></comment></comment></comment></comment><comment><USER8> Anyone else remember the magazine ads for PC-Lint, each of which featured a subtle C bug? Those were fun!

edit: <http://drdobbs.com/199900339>

</comment><comment><USER9> Makes me wonder how hard the programming languages that C defeated must have sucked.

<comment><USER10> BCPL barely had types. Everything was an "int" and you stored pointers, addresses, floats and so on in that same type (no concept of sizeof(int) != sizeof(void*) in those days!)

Edit: nice intro to BCPL. It's much worse than I thought: <http://www.davros.org/c/bcpl.html>

</comment></comment><comment><USER11> Most common in my world? Not checking return codes. Or check return codes and logging "there was an error" rather than using errno.

A couple uncommon ones: for (float x = 0.0; x < 3,5; x += 0.1) {...}

if (flag == TRUE) {...} (TRUE was #defined as 1 somewhere, but someone else set flag to a different non-zero value like -1, !0 or ~0.)

<comment><USER12> With the float for-loop, is the bug initializing the variable inside the loop declaration or is it the comma in "x < 3,5"?

<comment><USER13> I think you mean "declaring the variable inside the loop initialization", which is not a bug in C99 and not subtle anywhere else.

The intended bug is that 0.1, in floating-point, is not exactly 0.1. On x86 (and probably anything with IEEE-754 floating-point) the loop counter reaches 0.5 successfully, is a little bit high when it should have reached 1.0, remains high up to when it reaches slightly more than 2.2, and then suddenly becomes low when it should have reached 2.3, and continues to be slightly low and get progressively lower thereafter, all according to whether the sum is being rounded to a value that's slightly too high or slightly too low. The consequence is that the loop runs for an extra iteration with x ≈ 3.5, or 3,5 if you're from, say, Argentina.

</comment></comment></comment><comment><USER14> If someone has enough SO reputation (I don't), you might mention on pmg's post that casting malloc is a good idea, even though it's not necessary in C. Otherwise, should your code ever move to a C++ environment it'll be an error -- not even a warning.

<comment><USER4> That sounds like a good reason to omit the cast. Compiling C code as C++ is a bug: You can take valid C code, run it through a C++ compiler without any errors or even warnings being printed, and have it behave differently.

If you want to use C code from a C++ program, you MUST compile it with a C compiler and link it in.

</comment></comment><comment><USER15> One of the commentators mentions some... frustration... with _void main()_

Out of curiosity, is there any reason to have a return value from main() in something like a microcontroller, where there's nobody and nothing (that I know of) to care what main() returns?

<comment><USER4> _Out of curiosity, is there any reason to have a return value from main() in something like a microcontroller, where there's nobody and nothing (that I know of) to care what main() returns?_

It's very unlikely... but yes, just possibly. There are some very wacky calling conventions out there; among them, "caller reserves space for result on the stack after the function arguments".

If you run into this particular variety of crazy, declaring _main_ as returning _void_ will result in the compiler looking in the wrong place for _main_ 's parameters, with obvious and very rapid breakage resulting.

I'd say that you don't need to worry about this, except that microcontrollers are exactly the sort of niche environment where you're likely to encounter craziness -- so it's better to play it safe and declare main correctly.

<comment><USER16> Starting the program is almost entirely implementation-defined in freestanding environments (i.e. those without a host OS), so I don't think your example works.

Of course, there are reasons not to use "void main" - for one, a strict C99 compiler will not compile it.

</comment></comment></comment><comment><USER17> Does it count as irony that when I loaded this link I hit a SO maintenance page with this image at top: <http://sstatic.net/stackoverflow/img/offline- ide-1.png> ?</comment>


Ask HN: Where can I host a file for free in 2020? - <AUTHOR> I'd like to host a file somewhere in the cloud and publicly share a link to download it.
1. For free 2. Reliable 3. I want the file to start downloading right after a link is clicked. So that no "download page" shows up in between. All major cloud vendors offering free file sharing (Google Drive, WeTransfer, etc.) show this download page.
It is EXE file, 29MB large. <comment><USER2> You can copy the direct download link from Google Drive's download page. For instance:

[https://drive.google.com/uc?id=1cwRBCm3TbjpYMTVqJBsjfFGtrQ5Z...](https://drive.google.com/uc?id=1cwRBCm3TbjpYMTVqJBsjfFGtrQ5ZdkGq&export=download)

I'm sure other providers are similar.

</comment><comment><USER3> Use a ngrok tunnel. I also had some luck with transfer.sh I believe. Your operating word here is "free".

For a exe, just use github . i know a few projects that host downloads on there.</comment>


Robot Navigation Using Neuro-Electronic Hybrid Systems [pdf] - <AUTHOR> http://chips.ece.iisc.ernet.in/images/a/ab/Jude_robot_Navigation_VLSI_2015.pdf

<comment><AUTHOR> From the abstract:

"... we have set up a system which demonstrates the use of a live neuronal culture to solve a real world problem of controlling a robot doing the task of obstacle avoidance. We show that a neuronal culture can look at the sensor inputs to the robot and generate motor commands to allow it to explore an arena while avoiding obstacles."</comment>


Bill Gates says robots that take your job should pay taxes - <AUTHOR> http://www.businessinsider.de/bill-gates-robots-pay-taxes-2017-2?r=US&IR=T <comment><USER2> duplicate, please check before submitting: [https://news.ycombinator.com/item?id=13666124](https://news.ycombinator.com/item?id=13666124)

</comment><comment><USER3> Makes sense. It'll be political infeasible to increases taxes enough on the entities that will directly derive the most value from automation--robot manufacturers, businesses switching to automation, etc.

And because most of those profits will accumulate within a small segment of the population, it's not possible to tax the profits indirectly. Not enough will trickle down.[1] And it's politically difficult to increase taxes on the super rich much more than we already do. Taxing financial instruments--which is where the rich move and grow their wealth--is problematic. Taxing income and assets at a point where they're readily identifiable and easily enforceable is the most efficient and most equitable.

Plus, there's ample precedent in terms of personal property tax. Most basic example: some states tax cars. That's probably how a thing like this would be implemented--not as a type of income tax, but as a property tax.

[1] Lower prices of goods and services notwithstanding.

</comment><comment><USER4> This is a great topic. We can think in this solution or in the Elon Musk solution, about that every person must to be a salary, working or not. I don't know what solution should be, but this is one of the main topic for the next decade.

</comment><comment><USER5> You mean like taxing the hell out of Microsoft because they automated tons of jobs due to computers? Pay up Bill.</comment>


Dean Edwards on Callbacks vs Events - <AUTHOR> http://deanedwards.me.uk/weblog/2009/03/callbacks-vs-events/

<comment><AUTHOR> _In a real [event] system, events are dispatched sequentially._

This seems off to me - if an explosion goes off, people's reactions will be simultaneous, not sequential. Similarly, in an actor/event model (which is what I'm thinking of) - when an event occurs, I would expect all objects affected by said event to respond simultaneously.

<comment><USER2> I wonder if he was talking about:

Let's say some code executes which fires event EA. Then we go execute handlers HA and HB for that event, in turn. But handler HA somehow triggers event EB which has a handler HC that _depends on the state changed by HB_. But HB hasn't fired yet because we're still in the HA handler. The illusion of simultaneousness is violated and we're fucked.

The solution is to delay handling of events until all handlers for one "generation" of events have been called.

edit: So maybe he meant "sequential" as in "not out-of-order".

<comment><AUTHOR> I'm not sure if I'm following... we've got:

        EA -> HA + HB
        HA -> EB -> HC

With HC expecting HB to have run. My reaction would be "don't do that". If HC relies on HB completing, either put in a check in HC and keep trying until the environment is right (write a higher-order function if you're doing it often), or (better!) make your event system handle the logic you are trying to describe: HC is triggered when both HA and HB complete, like so:

        EA -> HA + HB
        HA -> EB
        HB -> EC
        EB + EC -> HC

This is all trivial in JS, since handlers are just functions assigned to variables!

</comment></comment></comment><comment><USER3> Using try/catch does not imply that you must silently eat errors; in fact you get arbitrary control over what to do with them, which I have often put to good use. I would still prefer the try/catch solution, if it is browser- compatible, on the grounds that it makes more sense if you just read it.

<comment><USER4> The problem is that the try/catch part is implemented in the library.

It is impossible for library developers to know how it should handle your exceptions, and you don't get to catch your exceptions, so there's no advantage whatsoever in using the try/catch.

<comment><USER3> Sure you do. If you care about exceptions, your callback routines or event handlers should use try/catch themselves. This is true regardless of the other machinery; browser event handling or higher-level library, the upper layers do not know what to do with a failing callback. Your objection is meaningless because it's true independent of what is being discussed.

Furthermore...

          for (var idx in callback_array) {
             var callback_data = callback_array[idx];
             var callback = callback_data.callback;
             var error_handler = callback_data.error_handler;

             try {
               callback();
             } catch (err) {
               try {
                 error_handler(err);
               } catch (ignore) {}
             }
           }

there is nothing intrinsic about "not being able to handle your own errors", either. (This is obviously simplified.) I don't think I'd implement, this, though; I'd say if you want to handle exceptions, handle exceptions within the callback.

Most implementations of callback loops suck, but this is the fault of the implementors, not the idea.</comment></comment></comment>


Photo Shows How Ridiculously SpaceX's Falcon 9 Rockets Are - <AUTHOR> https://www.inverse.com/article/26522-spacex-falcon-nine-rocket-huge-size-people-how-big <comment><USER2> "ridiculously ..." what? ridiculously large? ridiculously ridiculous?

</comment><comment><USER3> Spam site with aggressive, timed full-page overlays.

</comment><comment><USER4> This is some incredibly title gore.</comment>