Hacker News Reader

Comment by arilotter | Hacker News Reader

> The entry barrier to programming needs to [be] high!

I strongly disagree with this sentiment. I think the author's view that frameworks like Electron offer "no value over a native desktop application what so ever - well, perhaps with the only exception that now a 2 year old baby can make something shiny that you can click on with your mouse." is missing the point that a "2-year-old baby" making something shiny you can click on is an amazing feat, and an example of the power of the democratization of computing technology.

I do agree that tech stacks are increasingly obtuse, and not something any one person can carry in their head. I do agree that this is problematic. However, I really believe that the more individuals get access to a technology and have their barriers to using it removed, the better odds we have of letting someone with great ideas execute those ideas.

View on HN

I’m not sure I want an app designed by a baby though. Chances are they missed something important.

I’m not saying I agree entirely, but I’ll say this… every day I’m writing embedded microcontroller code, I’m getting my ass kicked. I’ve been doing it for sometime, it doesn’t really get easier, I just am able to write code that does more with the same hardware. It’s tough work imo. … then I hop on a YouTube channel and see some messaging queue system, and the guy writes four lines in two files, does some npm magic and that’s it, he has a server running and multiple clients connecting and queuing and etc. Very cool… but…

This guy is talking about how he has no idea how it works, it just does…

The high bar might be welcome for when it “just doesn’t anymore”. Because I don’t care if a website sucks, but do care if my furnace stops or a plane falls out of the sky or a bad queuing system causes a global shipping deadlock, etc.

Maybe the bar should be low for bringing people in, and high for people that actually make things.

I agree. And the thing is, you could take out that final paragraph and I'd agree with every other word in the piece.

It should be perfectly possible to write libraries and frameworks which are easier to use without writing additional layers of abstraction. Instead of writing a new template language in PHP on top of PHP, we could write it in C (or Rust) and it shouldn't be substantially slower or more resource intensive.

This would of course require an experienced programmer who knows a lower level language, but then the barrier to entry would be lower for everyone else!

While I can get behind the idea that lowering barriers to entry is a good idea, I don't think that's the same thing as tolerating ludicrously slow garbage tools just because everyone insist on either developing like a baby or only hiring babies. As an industry, we should be deeply ashamed at how much of the world's time and resources are wasted running poor software so a company can save a few bucks.

> As an industry, we should be deeply ashamed at how much of the world's time and resources are wasted running poor software so a company can save a few bucks.

This seems like you are saying everyone should write in assembly or c language for ever task possible, since that's the only way to avoid "wasting the worlds resources running poor software". At some point the trade offs are not solely "so that a company can save a few bucks", the trade offs also are things like "why spend 1 year writing a simple server which I can write a far superior server in say python/go/etc. in a few minutes". Yes, I understand you may be more specifically talking about Electron here, but at what point are you allowed to stop focusing on saving a few KB of ram or CPU cycles and focus on actually getting things done? Feeling productive? More platforms?

> This seems like you are saying everyone should write in assembly or c language for ever task possible, since that's the only way to avoid "wasting the worlds resources running poor software".

No. Look, computers today are many orders of magnitude faster and more powerful than they once were but our software still takes measurable seconds to do simple tasks. That's not 'oh, my software could be a bit more optimal' level of slow, that's 'I built my software like a Rube Goldberg machine made of garbage' slow.

> but at what point are you allowed to stop focusing on saving a few KB of ram or CPU cycles and focus on actually getting things done?

If it were only a few KB of RAM and a few dozen CPU cycles we wouldn't even be having this conversation! We live in a world where people seem to think a chat program using a GB of memory is acceptable. That's just insane.

Barrier is perhaps the wrong metaphor here; it's more of a slope. So then the question becomes: do you make the slope less steep but longer, so that climbing it easier, but you end up at the same elevation in the end, just having spent more time? Or do you dial down the overall elevation, so that the climb is less steep and takes the same amount of time?

Both are valid approaches to democratizing technology, but the last one results in reduction of quality. And also higher profits, which is likely why it won in the end. Given the existence of the other approach, though, I think there are valid grounds for complaint here.

I agree with the sentiment. I've been in a Magento and WordPress shop where I had to implement badly written plugins that my boss payed money for. I've seen people come out of code bootcamps calling themselves developers and all they can do is implement a design spec with HTML, SCSS, and jQuery. Yes, I taught myself a few programming languages,but I put in the work and effort to make my skills worth the time to an employer. We shouldn't lower the barrier only to call whomever can get past it with the low-level skills an expert in the field.

I also strongly disagree with the entry barrier thing.

But it's a false dicotomy. Simple solutions aren't inherently more difficult to master than complex ones. Actually, it's often the opposite.

Reply on news.ycombinator.com