How to Succeed as a Poor Programmer • Hacker News Board

Re: How to Succeed as a Poor Programmer

#191

Post by Impossible » Tue, Oct 01, 2019, 9:09 PM UTC

banachtarski wrote: post #186

Impossible wrote: post #183

Earlier quoted context omitted.

I've shaved 10 microseconds in large refactors and been told that's great ship it. Other fields might say that wasn't nearly enough to justify the code churn (performance vs. "programmer productivity" argument). A millisecond is a lifetime and can mean the difference between shipping and not shipping in some products.

Odd that we feel differently about hash tables then.

I didn't mention how I feel about hash tables (I'm not OP), but I think we feel the same? I definitely agree that arrays (potentially vector style growable arrays) should be a programmer's go to data structure, both for simplicity and performance. For my use cases I'd probably swap array and hash table usage with OP (70% array and 30% hash) but really it's probably more like 90, 10. Computing hash functions and resolving collisions can be very fast with the right hash table implementation, but it's absolutely not free. There is a reason why Lua tables can implement array like access and memory usage, even if from a language standpoint a Lua table looks like a hash table with some fancy features.

Re: How to Succeed as a Poor Programmer

#192

Post by banachtarski » Tue, Oct 01, 2019, 9:30 PM UTC

Impossible wrote: post #191

banachtarski wrote: post #186

Earlier quoted context omitted.

Odd that we feel differently about hash tables then.

I didn't mention how I feel about hash tables (I'm not OP), but I think we feel the same? I definitely agree that arrays (potentially vector style growable arrays) should be a programmer's go to data structure, both for simplicity and performance. For my use cases I'd probably swap array and hash table usage with OP (70% array and 30% hash) but really it's probably more like 90, 10. Computing hash functions and resol…

Ah didn't realize you weren't OP. I think any programmer that operates in the realms of microseconds probably would understand the overhead of both the hash function overhead as well as the coherency issue. I'm not a lua programmer but I remember studying the LuaJIT source pretty extensively.

Re: How to Succeed as a Poor Programmer

#193

Post by notacoward » Tue, Oct 01, 2019, 9:55 PM UTC

jmnicolas wrote: post #190

notacoward wrote: post #172

Earlier quoted context omitted.

He says he learned C++ in 1990, and never says anything about C, so it's still likely that he only has a distant memory of something like C. I have a distant memory of something like Ada, but I might struggle for a while if asked to program in Ada professionally.

I bet 1990 C++ was for most people C with classes.

Pretty much, IIRC. I wasn't exposed to it until about a decade later myself, but my wife was. Most or possibly even all C++ compilers were still front ends for C compilers. Exceptions either didn't exist or weren't considered reliable, so her company rolled their own using setjmp and longjmp - which don't do stack unwinding so forget about relying on destructors and RAII. Similar for templates, so no STL. Does anyone even remember the NIH class library any more? It was very stripped down compared to the cancer it has become.

So yeah, somebody who knew C++ in 1990 was probably within spitting distance of knowing C at the time ... but now, they know it the same way I know Lisp or Prolog, since I used those long ago too. But if they've stuck with C++ ever since, do they effectively know C today? Could they be productive in it more quickly than they could in Rust or Go which they'd never even seen before? That's not clear at all.

Re: How to Succeed as a Poor Programmer

#194

Post by overgard » Wed, Oct 02, 2019, 2:10 AM UTC

kibibu wrote: post #113

overgard wrote: post #77

The "Avoid Learning Anything New" advice is insane. (Well, practically all of it is, but that one really stands out). I think the exact opposite advice is far better: never assume the way you know how to do something is best, and always be on the lookout for what others are doing that might be better. Here's the thing about learning: the more you learn, the easier learning the next thing becomes. You form links, insi…

At risk of appealing to authority, I think you should look into exactly who Peter Shirley is before sounding off.

Yeah, I don't really care who he is. Nor do I think I should: his advice should either stand or not based on its own merits. There are plenty of successful people that give terrible advice.

Re: How to Succeed as a Poor Programmer

#195

Post by gabrielblack » Wed, Oct 02, 2019, 4:42 AM UTC

ensiferum wrote: post #145

gabrielblack wrote: post #72

> Only learn something new when forced This could be devastating, much more in little/medium company. I know of successful companies (I mean company with successful products ) with a C/C++ stack they considered "good enough" so they didn't change anything: the C++ standards, architecture, structures. Often that line of conduct was supported by a management looking any change or improvement as a cost. The result is al…

Just because something is old or uses old framework or old standard doesn't make it crap. Crappy code is crap, but it age doesn't make it crap. Code doesn't rust or detoriarate by itself. Example if you write good code now using C++14. If it's good code now it will continue to be good code 20 years later. There's no property that adds bugs or "crappiness" to the code as the years go past. The invention of a new "c++4…

The age make it "crap", but not in the way you think. I can speak about C++. C++ code wrote in the older standard, let say C++ pre-11, who are 20 or more years old make it difficult to maintain because new generation of programmers are not generally interested to legacy code or in learning old c++ standards and skilled programmers don't want be relegated to be eternally maintainer of old projects. For this reason projects die by asphyxia. We have that good code base in Cobol, ok, but the point is: who cares ? Who is important when you need new programmers. Besides, a part considerations on the language, the architecture is important we live in a world of microservices and old code not updated to modern paradigms could became "crap", even if if the most elegant code.

Re: How to Succeed as a Poor Programmer

#196

Post by kazinator » Wed, Oct 02, 2019, 7:01 AM UTC

jmnicolas wrote: post #190

notacoward wrote: post #172

Earlier quoted context omitted.

He says he learned C++ in 1990, and never says anything about C, so it's still likely that he only has a distant memory of something like C. I have a distant memory of something like Ada, but I might struggle for a while if asked to program in Ada professionally.

I bet 1990 C++ was for most people C with classes.

In the mid 90's, I was very surprised to discover that a popular telnet program widely distributed in Linux distros was written in C++, with cruft like abstract base classes with pure virtual functions and whatnot.

(I was looking at the source because the stupid thing would disconnect whenever the PPP connection went donw; it was over-reacting to EHOSTUNREACH errors on the socket, which are recoverable; I fixed that, at least for myself.)

Here it is: https://github.com/marado/netkit-telnet/tree/master/netkit-t...