A significant amount of programming is done by superstition • Hacker News Board

Re: A significant amount of programming is done by superstition

#151

Post by gdrulia » Thu, Mar 26, 2015, 6:34 AM UTC

shpx wrote: post #120

krick wrote: post #106

That's right, but I guess we're missing the real problem here. The real gold are these words: > You've really read the LSB specification for init scripts and your distribution's distro-specific documentation? If so, you're almost certainly a Debian Developer or the equivalent specialist for other distributions. Many of us would agree, that it's true. But why is it true? Shouldn't that make us suspicious in the first…

I think for a lot of people reading man pages is not as fun and satisfying as just making things and watching them work. It's a form of instant gratification.

from my own personal experience I can tell that most of the time I prefer stackoverflow instead of man pages simply because I need to achieve one task and stackoverflow contains answer of how to do it, man pages can teach me how to do all sorts of a tasks, then I have to choose the right one from those that I have learned.

On top of that, to be able to use man page, I need to know command in the first place, while google will digest my broke english question and point me to the right stackoverflow answer most of the time.

Re: A significant amount of programming is done by superstition

#152

Post by hackmiester » Thu, Mar 26, 2015, 6:37 AM UTC

cplease wrote: post #134

mgob wrote: post #119

Earlier quoted context omitted.

http://bropages.org to the rescue!

Thanks for reminding me why I hate ruby. Nothing against the language, it's the garbage dump of the software community misfits since it left Japan. bro.

Can you expand upon what you mean?

Re: A significant amount of programming is done by superstition

#153

Post by bostik » Thu, Mar 26, 2015, 6:37 AM UTC

krick wrote: post #106

That's right, but I guess we're missing the real problem here. The real gold are these words: > You've really read the LSB specification for init scripts and your distribution's distro-specific documentation? If so, you're almost certainly a Debian Developer or the equivalent specialist for other distributions. Many of us would agree, that it's true. But why is it true? Shouldn't that make us suspicious in the first…

There is a balance to be struck.

Progress depends on humans being lazy. We have inventions and innovations precisely because humans are so good at finding ways to make their (own) lives easier - usually by eliminating repetitive tasks via some kind of work-around or alternate approach.

There is a well known quote about insanity [0] and blind repetition that occasionally gets associated with idiocy too. If everyone was always starting from first principles, we could argue that humanity, as aggregate, is insane. (Which might still be true!)

Repeating experiments to verify results is good. Doing the same things over and over again likely means you're not learning.

0: http://en.wikiquote.org/wiki/Insanity (search for "different results")

Re: A significant amount of programming is done by superstition

#154

Post by Peaker » Thu, Mar 26, 2015, 6:41 AM UTC

mrspeaker wrote: post #32

Peaker wrote: post #27

Earlier quoted context omitted.

A lot of us find Yoda conditions easier to read: if(0 == very_long_function_name_here(param1, param2)) { Tells me a lot after I've read a little of the line, whereas: if(very_long_function_name_here(param1, param2) == 0) { Makes the == 0 part easy to miss, and buried behind a lot of clutter.

eh, you just end up having to parse if (VERY_LONG_AND_SPECIFIC_ENUM_NAME_HERE == func(param1)) { } Makes the function called easy to miss and buried behind a lot of clutter ;)

That's why my rule is shorter first :-)

Re: A significant amount of programming is done by superstition

#155

Post by Peaker » Thu, Mar 26, 2015, 6:42 AM UTC

klibertp wrote: post #65

ericb wrote: post #54

Earlier quoted context omitted.

Explicit function naming requires slightly longer function names, but you can actually read a program and get a sense of what is happening. Give me long function names over short ones any day. In my book, 5 words is a little long, but not out of bounds.

If you take a closer look at my example you'll see that the long name is there of course, it's still very close to the point where it's used. It's only aliased for a moment in this single section of code and because of lexical scoping there's no danger of name collision. Of course, doing this in a global namespace makes no sense. How long identifiers are acceptable depends on a language. With languages without namesp…

The alias is just adding confusion. If I see such an alias in code, I would wonder where else that function is used in the function, and be confused that it isn't.

Not to mention it becomes more verbose once you make that alias a const ptr (which we do on all of our local variables).

Re: A significant amount of programming is done by superstition

#156

Post by Peaker » Thu, Mar 26, 2015, 6:44 AM UTC

depsypher wrote: post #47

Peaker wrote: post #27

Earlier quoted context omitted.

A lot of us find Yoda conditions easier to read: if(0 == very_long_function_name_here(param1, param2)) { Tells me a lot after I've read a little of the line, whereas: if(very_long_function_name_here(param1, param2) == 0) { Makes the == 0 part easy to miss, and buried behind a lot of clutter.

Re: "buried behind a lot of clutter" If your code has a lot of clutter it's usually telling you something about your design. For readability a better way of handling it might be for the function could return a boolean instead of an int: if (is_valid(param1, param2)) { self documenting code and all that.

You're assuming the information being returned is a boolean. As a static typing fanatic, I would not return an int to indicate a boolean result.

  if (0 == number_of_students(context, classroom))

Re: A significant amount of programming is done by superstition

#157

Post by jnem » Thu, Mar 26, 2015, 6:52 AM UTC

I hate to call myself out, but I envy most of you. It sounds as if many here get the opportunity to work on interesting problems from end to end. As such, first principles matter, and approaching something from scratch makes sense. I however have been stuck in a segment of the market that doesn't appreciate the right solution, but rather just wants a solution as fast as possible. To be clear, I'm talking about a more consumer audience. My clients expect things done quick, and quick means leveraging cms, ecommerce platforms (magento, woo commerce, etc.). To be frank I find such work unsatisfying, and often need to hack things together to meet the requirements set forth within the constraints of the budgets I'm working with. I'd love to be able to work in an environment where doing things right mattered, but the plain fact is the deliverables aren't measurable based on quality, but expedition.

While I'm on a soap box, I'd like to point out to those in the positions where they're work is evaluated by professionals and peers how lucky they are. I'd kill for a job/client where my code is evaluated by other developers. This community sometimes forgets they are the 1% of the development world. Those who work for the googles, facebooks, and visionary startups with leaders who came from the same cloth. The rest majority of us are laboring away under management that have never produced a lick of code, or even design, for that matter.

I guess the Tl;DR is: appreciate the fact that you even get to consider the finer points, and pray for the rest of us.

Re: A significant amount of programming is done by superstition

#158

Post by ycombobreaker » Thu, Mar 26, 2015, 7:11 AM UTC

superuser2 wrote: post #132

copsarebastards wrote: post #60

I'm surprised by the number of people who don't see this as a problem. I've worked pretty recently as the most senior developer on a team, and I saw tons of issues caused by copy/pasted code. It results in a lot of issues. Subtle bugs around `==` versus `===` in JavaScript, unecessary variables that obfuscate the code, Python that isn't Pythonic, C that was written as an example and therefore doesn't include the erro…

>doesn't include the error handling that is constantly necessary in C I mean, I'm sure there are some cases, but how many C programs are capable of gracefully recovering from a malloc failure? Probably very few. If the program is going to crash anyway...

... best to do it deterministically and immediately! Easier to test, and no chance that an obscure preallocation leads to crashes elsewhere in the program.

Re: A significant amount of programming is done by superstition

#159

Post by yason » Thu, Mar 26, 2015, 7:13 AM UTC

In my view, a lot of this is just trying to avoid learning yet another system. Learning systems is hard and takes time, and it's only worth it if you're going to be using the system a lot in the future.

For example, creating a new init script or a Debian package description is something I don't do all the time. I don't want to learn all that stuff because by doing so I'd basically push out something else from my mind. Copying an existing configuration or script and making modifications without trying to create something original is an excellent pattern for things outside your immediate expertise target.

The "avoiding creating something original" part does indeed carry a sort of "superstition". It's like relying on a new culture by merely mimicking it, because you don't really know it well enough to break the rules correctly. You don't know why things are done the way they are but your best bet is just to copy and adapt. This creates a sphere of fuzzy knowledge where intents and black magic seem to alternate.

Re: A significant amount of programming is done by superstition

#160

Post by ycombobreaker » Thu, Mar 26, 2015, 7:23 AM UTC

ackalker wrote: post #105

danbruc wrote: post #95

This does not resonate with me at all. I can not stand having things in my code I don't fully understand. Without reading the source code of libraries, without reading relevant standards, without understanding the mathematics behind algorithms, there is always this feeling I may make really dumb mistakes. Really understanding all the bits and pieces obviously does not make your code bug free, but I am usually pretty…

This piques my interest. When was the last time anyone read the source code of (g)libc "cover to cover" before using it? Does anyone know the precise implications of (not) defining any of the myriad sensible permutations of its "feature test macros"? Is anyone even sure that those implications are actually implemented correctly before relying on them?

There's no reason to read it "cover to cover", and the GP did not really ask for that. There are many functions in glibc which can be read and understood in relative isolation. I find myself reviewing stable library code (glibc, ncurses, zlib C++ STL) in fits and spurts, several times a year. Sometimes that is paranoia (download the source to make sure the code matches the behavior described in man pages), but mostly it is spelunking to verify something impementation-specific.