Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discipline Doesn’t Scale

sicpers.info

Post reply on HN
Print view View original

61–70 of 173 posts

Re: Discipline Doesn’t Scale

#61

Post by Slikey »

dusted wrote: post #57

While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software. While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of th…

The key is that hardware has marketpreassure to become faster and faster. Software gets faster if there is market preassure (see gaming & financial). When the feature backlog is more important than performance that is obviously what is prioritized. You obviously can't work on everything.

Re: Discipline Doesn’t Scale

#62

Post by justmyname »

dusted wrote: post #57

While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software. While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of th…

That's a quite unobvious consequence of the software progress. Making software be "a bunch of bricks for creating applications" do come with costs. And the main cost is performance.

Re: Discipline Doesn’t Scale

#63

Post by spyckie2 »

hrktb wrote: post #51
spyckie2 wrote: post #43

Earlier quoted context omitted.

The point of the article isn't to belittle someone for having a good, deep knowledge of machines. The foundation of most code written is built by those people. The point of the article is to point out that languages, frameworks, or apis that expect a level of discipline to write well are inferior to ones that don't expect discipline out of its coders. The takeaway shouldn't be - I as a programmer shouldn't learn how…

I like the focus on scale in the title, and think it’s very apt. Requiring discipline is not superior or inferior, but doesn’t scale. It’s then your to decide how much it matters: do you have/need to only focus on a small group or are you tools targeted at a wide audience or you want it to widely succeed ? The answers to that question won’t be the same for everyone.

My usage of inferior/superior is contextualized mainly to scaling but the article mentioned many more things other than scale in the anecdotes (like producing better code overall). Maybe the vagueness of the word choice is a bit controversial in this definition-sensitive environment.

Re: Discipline Doesn’t Scale

#64

Post by dfabulich »

There are two kinds of discipline; one scales, and the other doesn't.

Consider this line from the article:

> you don’t need TypeScript to write good React Native code, just Javascript and some discipline

The author provides this as an example of the "disciplinarian" approach, which the author says "doesn't scale."

It's an interesting example, because learning a new way to code requires discipline. IME, the main obstacle to TypeScript is that you have to have the discipline to learn TypeScript and endure the compile errors it generates.

I think you could rewrite the author's example the opposite way:

"You don't need to write careful JavaScript, you just need enough discipline to learn and use TypeScript"

But this is a different kind of discipline; it's the discipline to seek out a "better" (or at least more scalable) way of doing things. You typically hear static-typing fanatics calling dynamically typed languages "undisciplined."

TypeScript is an order of magnitude less popular than pure JavaScript, even considering just new code on Github. TypeScript may be better, but it isn't taking over the world--not yet, at least--because it requires (enforces!) more discipline to get started.

Re: Discipline Doesn’t Scale

#65

Post by sergeykish »

> does that mean our tools should not let us write code for which there’s no test?

I've heard not so good stories about 100% code coverage. Metrics do not scale.

Software development is a balancing act of visible results, technical debt, available workforce etc etc. Life (cells and above) is not perfect but it matches environment.

> no strong motivation to become more disciplined

Bug on production bug is much better motivation to write tests than some discipline. Write code so other people want to work with or search another place.

> either torpedo your whole idea or turn it into not doing the thing (see OOP, Agile, Functional Programming)

A lot of languages are not OOP by Alan Kay, Agile and SCRUM subverted. That is marketing, when benefits is in the badge not in the substance. Those who chased idea do well.

Re: Discipline Doesn’t Scale

#66

Post by rusk »

Slikey wrote: post #61
dusted wrote: post #57

While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software. While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of th…

The key is that hardware has marketpreassure to become faster and faster. Software gets faster if there is market preassure (see gaming & financial). When the feature backlog is more important than performance that is obviously what is prioritized. You obviously can't work on everything.

The feature backlog is rarely more important than performance but you often see it being pushed ahead of nonfunctional concerns for presentational reasons.

Re: Discipline Doesn’t Scale

#67

Post by imoverclocked »

pm90 wrote: post #60
dusted wrote: post #57

While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software. While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of th…

Do you think the market is not pricing it correctly? In the dawn of computing, machines were far less common, much more expensive, and society was willing to pay programmers boatloads of money to write optimized code because that was cheaper. The hardware engineers did an excellent job, they reduced costs of computing by a lot. Society is not willing to pay programmers boatloads of money to write optimized code; beca…

... or reduce software engineering salaries. Arguably, people want faster software if they also want faster hardware.

Re: Discipline Doesn’t Scale

#68

Post by scatters »

dusted wrote: post #57

While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software. While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of th…

Where do you get 1% from? We're several orders of magnitude further than that from the Landauer limit, if that's what you're referring to.

However, there is considerable economic incentive to keep Koomey's law going - mostly from mobile these days, since increased computations per joule means longer battery life.

Re: Discipline Doesn’t Scale

#69

Post by [deleted] »

dwaltrip wrote: post #54

There's an interesting comment below the blog from someone named Alex (not me): > As a proponent of discipline, I see things a bit differently. You’re coming at it from the perspective of “In software, we automated X, and now X is no longer a problem, therefore, we should just keep automating as far as we can”. That’s one pattern. > I’m seeing from the perspective of: “There’s no way to automate everything, and profe…

[deleted]

Re: Discipline Doesn’t Scale

#70

Post by jayd16 »

Animats wrote: post #7

Over a decade ago I used to argue this with the C++ committee people. Back then, they were not concerned about memory safety; they were off trying to do too much with templates. The C++ people didn't get serious about safety until Rust came along and started looking like a threat. Now they're trying to kludge Rust features into C++ by papering over the unsafe stuff with templates, with some success. But the rot under…

I thought Java's locking worked fine as long as you didn't make your locks public or lock on `this`. What is Rust doing that's an improvement?
Post reply on HN