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

Algorithms we develop software by

grantslatton.com

Post reply on HN
Print view View original

41–50 of 108 posts

Re: Algorithms we develop software by

#41

Post by AlotOfReading »

mgaunard wrote: post #30
a1o wrote: post #22

> Write everything twice There's an enhancement in a software I use/maintain that I wrote once and lost (the PC I wrote kaput and I was writing offline so I also didn't backup). It was an entire weekend of coding that I got very in the zone and happily coded. After I lost that piece of code I never could get the will to write that code again. Whenever I try to start that specific enhancement I get distracted and can'…

That's a good point. Particularly good pieces of work are hard to rewrite. I remember rewriting some piece of infrastructure once when I moved to another job, but I failed to summon the energy to rewrite it a second time at another job.

Every time I've pushed through that feeling and rewritten it anyway, the end result was better than the original. The memories eventually come back once I get into the problem and hindsight makes clear how much stuff past-me missed.

Re: Algorithms we develop software by

#43

Post by _0ffh »

dataflow wrote: post #34
_0ffh wrote: post #31

Earlier quoted context omitted.

Of course they don't, how could they? How could anything, for that matter? (Apart from guarantees you could ensure statically, natch.)

> Of course they don't, how could they? How could anything, for that matter? Uh, that's literally what unit tests do? They tell you if you broke any of the cases they test for, before you release your implementation to other people...

Well, that's a mutual misunderstanding then. I meant quite literally neither assertions nor unit tests prevent you from breaking things. Of course they'll help you to catch those mistakes before release. I didn't think that counts as prevention, my bad. Assertions should trigger during system testing if any contracts are broken, so under your interpretation they do prevent breakage as much as units test (meaning before shipping).

Re: Algorithms we develop software by

#44

Post by stanac »

andsoitis wrote: post #13
nkozyra wrote: post #7

Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness. But if you plow through a feature and get it "working," you'll do much of that work cleaning up the logic and refactoring through your first pass. What rewriting allows you to do is crystalize the logic flow you de…

A project manager or bizdev person writes, rewrites, and rewrites again the document they produce do they not? Or do they write the perfect document at first go?

Worst kind of jira ticket is just a link to a document that can be edited anytime. In that case I just replace the link with a new link pointing to the fixed version of the document and inform the author of the ticket/document about it.

Re: Algorithms we develop software by

#45

Post by rmnclmnt »

> Write everything twice

I’d say « Write everything three times » because it usually take 3 versions to get it right: first is under-engineered, second is over-engineered and third is hopefully just-right-engineering

Re: Algorithms we develop software by

#46

Post by dataflow »

_0ffh wrote: post #43
dataflow wrote: post #34

Earlier quoted context omitted.

> Of course they don't, how could they? How could anything, for that matter? Uh, that's literally what unit tests do? They tell you if you broke any of the cases they test for, before you release your implementation to other people...

Well, that's a mutual misunderstanding then. I meant quite literally neither assertions nor unit tests prevent you from breaking things. Of course they'll help you to catch those mistakes before release. I didn't think that counts as prevention, my bad. Assertions should trigger during system testing if any contracts are broken, so under your interpretation they do prevent breakage as much as units test (meaning befo…

System tests prevent breakage as much as unit tests? Really?

How do you "system test", say, string.indexOf(string)? Could you write a system test for this example to show us what you mean and help us see how they're superior to unit tests?

And how long and complicated are your system tests to catch breakages "as much as" a unit test would, for this example?

Re: Algorithms we develop software by

#48

Post by hintymad »

I remember seeing somewhere a popular list of top 10 algorithms used in systems, and it's kinda depressing to realize that the most recent algorithm on the list, Skip List, was invented roughly 30 years ago, and every single one of them was taught in an introductory data structure course. That is, we most likely do not need to study the internals of algorithms nor need to implement them in production. For such a long time in history, smart and selfless engineers already encapsulated the algorithms into well abstracted and highly optimized libraries and frameworks.

Of course, there are exceptions. ClickHouse implemented dozens of variations of HashTable just to squeeze out as much performance as possible. The algorithms used in ClickHouse came from many recent papers that are heavy and deep on math, which few people could even understand. That said, that's just exception instead of norm.

Don't get me wrong. Having a stable list of algorithms is arguably a hallmark of modern civilization and everyone benefits from it. It's just that I started studying CS in the early 2000s, and at that time we still studied Knuth because knowing algorithms in-depth was still a core advantage to ordinary programmers like me.

Re: Algorithms we develop software by

#49

Post by mempko »

dataflow wrote: post #27
mempko wrote: post #11

Earlier quoted context omitted.

Unit tests are a waste of time. Design by Contract + system tests are a far superior technique that take less time and find more bugs.

Confused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?

The client doesn't run your unit tests, but will run you contracts (because contracts deploy with you software while unit tests dont).

You might have realized users of software do things the engineers don't expect, which are not covered in unit tests.

Re: Algorithms we develop software by

#50

Post by dataflow »

mempko wrote: post #49
dataflow wrote: post #27

Earlier quoted context omitted.

Confused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?

The client doesn't run your unit tests, but will run you contracts (because contracts deploy with you software while unit tests dont). You might have realized users of software do things the engineers don't expect, which are not covered in unit tests.

> The client doesn't run your unit tests

That's kinda the whole point... you run them to catch bugs and fix them so your clients never see the bugs you caught in the first place.

> but will run you contracts (because contracts deploy with you software while unit tests dont).

So you'd prefer your contracts to blow up your bugs in your clients' faces, rather than catch bugs yourself prior to releasing the code to them?!

Post reply on HN