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

101–110 of 173 posts

Re: Discipline Doesn’t Scale

#101

Post by solresol »

lioeters wrote: post #95
foerbert wrote: post #42

Earlier quoted context omitted.

This is one of the few times I've seen anybody mention threading in Ada in this sort of discussion. I've become quite fond of the language, and my first brush over the tasking stuff left me fairly impressed/interested. However actually getting into it is something I've been meaning to do, so I don't really have much experience with it in practice. So I'm quite curious, what problems with it you were referring to?

Not OP, and not familiar with Ada - but this might go into the limitations of Ada's concurrency model: Rendezvous Facilities: Concurrent C and the Ada Language - https://www.computer.org/csdl/journal/ts/1988/11/e1546/13rRU... > The concurrent programming facilities in both Concurrent C and the Ada language are based on the rendezvous concept. Although these facilities are similar, there are substantial differences. >…

A lot changes in Ada-95; the Ada-83 concurrency model was indeed very limited (which is what that article talked about).

Re: Discipline Doesn’t Scale

#102

Post by ozim »

emotional_fool wrote: post #79

TLDR: Humans make mistakes, use better tools/languages that prevent this, since discipline can't enforced. Wasted few minutes reading this blog post.

Not wasted.

That is important point for arguing with people who say things like 'ORMs are bad I can write my SQL queries', 'Angular is bad I have my perfect approach for vanilla js'. When such person will have to explain their 'perfect' approach to 10 developers and then such person will have to keep doing code reviews so that approach is still used by those 10 developers it will be an eye opener

Re: Discipline Doesn’t Scale

#103

Post by dkersten »

overgard wrote: post #33
qppo wrote: post #29

Earlier quoted context omitted.

Lock free algorithms and data structures are even harder to get right! And most of the canonical descriptions of them assume that you have a garbage collector and that memory allocation is a bounded operation. Neither of which is really true when you're working in constrained situations. On top of that, locking is faster than most lock-free strategies unless you deal with high contention or deterimistic guarantees (9…

When I say lock free, im suggesting concurrency that doesn't assume shared memory. I think the notion of multiple cores working on nearby memory blocks just is a bad way to do this, and so threaded models are not great. More along the lines of an actor model or how gpus subdivide work.

So a task/job system with explicit dataflow, where data is handed off to the task that uses it, rather than being shared? A lot of game engines do this nowadays and it works quite well. It doesn't eliminate synchronisation completely, but it does simplify things a good bit.

Ideally, any shared data is immutable (and modifying it would then need to be done in a coordinated synchronised fashion) while most mutable state is only ever owned by one task/thread, with ownership explicitly passed between them as others need access, unique_ptr style. Reality doesn't always match with the ideal though.

Re: Discipline Doesn’t Scale

#104

Post by ozim »

Yes of course, that is why 'special forces' in military are special, most of people are just cannon fodder.

Military orgs around the world are turning into smaller head counts of disciplined people. That is known since the Battle of Thermopylae but maybe getting lost from time to time. There is also a lot of military tech that is trying to prevent soldiers from shooting themselves in the foot, which fails from time to time.

We also know that just adding more developers to project is not increasing velocity and that small focused teams outperform large teams by orders of magnitude.

Problem we have to tackle are big orgs that need a lot of code and have high dev turnover. That is why frameworks like angular and tools first are so important, they help to scale code better than plain code or plain js.

Re: Discipline Doesn’t Scale

#105

Post by ChrisMarshallNY »

bluetomcat wrote: post #98
ChrisMarshallNY wrote: post #93

Earlier quoted context omitted.

Sadly, you are correct, but that’s not new. This has been the case throughout history. I was just thinking about the difference between “good,” and “excellent.” If we look at the difference between a Henkels kitchen knife, and a Japanese Takayuki knife, we are talking exponentially divergent costs. The Takayuki is definitely a lot better than the Henkels, but is it twenty times as good, as the price difference might…

Germany seems to be doing quite well in producing exactly those products from the upper-middle tier – mixing a reasonable blend of longevity, ingenuity and ergonomics, at an earthly cost. In the rest of the world and especially in "emerging markets" however, such products are often unaffordable, uncompetitive and even sometimes seen as old-fashioned. A household in India that goes from not having a kitchen cutlery se…

Tell me about it. I grew up in Africa.

I will say that poor folks act a lot like pros. They take care of their tools.

I know people that use Takayukis as bottle-openers. They have so much money that they don't care.

Re: Discipline Doesn’t Scale

#106

Post by Chris_Newton »

olau wrote: post #96
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…

IMHO, types for function parameters depends on the use case. If you have a function in a standard library, types are obviously helpful, albeit it can be convoluted if they are templated. On the other end of the scale, if you have a little helper function used to reduce duplication/increase readability in another function, explicit typing easily becomes busywork. This is where duck typing/templates shines. I once sent…

I quite like the Haskell culture for this one: you specify the type signatures explicitly for your top-level functions, but you don’t usually specify them for nested functions. Put another way, anything with an interface you might need to understand somewhere else should be explicit, but anything only used very locally doesn’t need to be.

Re: Discipline Doesn’t Scale

#107

Post by ChrisMarshallNY »

underwater wrote: post #90
ChrisMarshallNY wrote: post #84

Personally, I think Discipline is one of the things that separate “coders” from “engineers.” This sounds like it’s really a treatise on “learning to build a house by making your own nails.” Of course that won’t scale. Especially if most houses, these days, are prefab, and don’t use too many nails. But learning how to stay out of flood plains, and selecting good prefab sources, is vital to being a builder. The first o…

I don't think your worldview is inconsistent with the authors. Software is one of the few areas where we can easily and rapidly change our tools and the medium we work with. To be professional in this field you must use that ability to systematically remove issues where possible. To fall back on the mindset that being a good engineer means eschewing those safeguards and relying on discipline is more about image that…

Completely agree. Discipline is only one of many tools at my disposal.

One of the most important things about being a software engineer, in my mind, is the ability to be flexible (I won't say "agile," as that word seems to be pretty much worthless, these days).

One of the disciplines that I've developed, over the years, is writing flexible code; Code that has a future.

One of my favorite text editors is BBEdit[0]. I've been using it since the 1990s. During that time, I've tried others that have been raved about, like Sublime, TextMate and VSCode. I've liked them, but always ended up going back to BBEdit, which has been doing a great job of adapting to the new operating systems and workstyles.

The fact that the app is nearly thirty years old, and started off with a bus factor of 1, says that the original author applied discipline and a "future-facing" design ethos, back in 1992. I can respect that.

I also use Adobe Photoshop, which I first met before Adobe brought it, in the late 1980s. That seems to have grown well.

[0] https://www.barebones.com/products/bbedit/

Re: Discipline Doesn’t Scale

#108

Post by trumpeta »

einpoklum wrote: post #77
jchw wrote: post #10

Earlier quoted context omitted.

I think this is a little oversimplified, because I’m pretty sure C++0x had move semantics and usable smart pointers prior to Rust really entering the public conscience/probably before it existed . AFAICT Rust takes a lot of inspiration from how you would “fix” C++, in ways that you could never actually do in C++ because it would break backwards compatibility.

Everybody and their uncle have an idea about how they would "fix C++" - but these ideas mostly contradict each other and would make for rather different languages :-)

I’d argue it doesn’t make sense to fix c++. A language is not about what you can do with it, its about what it doesn't let you do. C++ will continue letting you do everything in the name of backward compatibility.

Re: Discipline Doesn’t Scale

#109

Post by Chris_Newton »

dkersten wrote: post #103
overgard wrote: post #33

Earlier quoted context omitted.

When I say lock free, im suggesting concurrency that doesn't assume shared memory. I think the notion of multiple cores working on nearby memory blocks just is a bad way to do this, and so threaded models are not great. More along the lines of an actor model or how gpus subdivide work.

So a task/job system with explicit dataflow, where data is handed off to the task that uses it, rather than being shared? A lot of game engines do this nowadays and it works quite well. It doesn't eliminate synchronisation completely, but it does simplify things a good bit. Ideally, any shared data is immutable (and modifying it would then need to be done in a coordinated synchronised fashion) while most mutable stat…

most mutable state is only ever owned by one task/thread

For many applications, this is the way I prefer to structure code these days. If you know that the only part of your program that will touch certain state directly is always running in a single thread, a lot of problems just go away, because whatever you do in response to any given message or other signal is effectively an atomic transaction, regardless of any concurrency or asynchronous behaviour you have going on elsewhere in your system. You still need to figure out how your message passing or other signalling infrastructure is going to work and in particular what will block and what won’t, so it doesn’t answer all of the usual questions with concurrency, but it’s a widely useful strategy and it goes a long way toward keeping things manageable.

Re: Discipline Doesn’t Scale

#110

Post by oblio »

trumpeta wrote: post #108
einpoklum wrote: post #77

Earlier quoted context omitted.

Everybody and their uncle have an idea about how they would "fix C++" - but these ideas mostly contradict each other and would make for rather different languages :-)

I’d argue it doesn’t make sense to fix c++. A language is not about what you can do with it, its about what it doesn't let you do. C++ will continue letting you do everything in the name of backward compatibility.

At some point, that's going to stop being sustainable.

I think C++ could really use what Rust calls generations. Figure out the obviously bad ideas and deprecated them over 10 year cycles.

That would allow the language to shrink again, I don't think it ever did.

Post reply on HN