Hopefully more controversial programming opinions • Hacker News Board

Re: Hopefully more controversial programming opinions

#81

Post by aguynamedrich » Thu, Aug 30, 2012, 1:32 PM UTC

raverbashing wrote: post #57

kamaal wrote: post #43

Earlier quoted context omitted.

Actually its all the 'design' craze. Most architects think drawing UML diagrams on mspaint to be a sign of technical superiority. The real issue I think is heavy OO programmers(read java) can't live without. 1. Design patterns- The art of bloating already heavily bloated code. 2. Avoiding meta programming of any kind. 3. Love towards getters/settters and absolutely anything that lends to code bureaucracy. Why get/set…

So much this 100 lines of python can be turned into a hundred men-hours / 6-digit budget project in Java

So, the language choice of a piece of software determines the amount of time and money that is required to build the system?

Re: Hopefully more controversial programming opinions

#82

Post by raverbashing » Thu, Aug 30, 2012, 2:08 PM UTC

aguynamedrich wrote: post #81

raverbashing wrote: post #57

Earlier quoted context omitted.

So much this 100 lines of python can be turned into a hundred men-hours / 6-digit budget project in Java

So, the language choice of a piece of software determines the amount of time and money that is required to build the system?

Of course it does. Why is this surprising?

Try building a (safe) web app in C and see how long it takes.

Re: Hopefully more controversial programming opinions

#83

Post by peapicker » Thu, Aug 30, 2012, 2:23 PM UTC

jbrechtel wrote: post #72

enjo wrote: post #68

Earlier quoted context omitted.

Pretty code is readable and readable code is pretty. If you can render your code as a nice pdf and distribute it as a paper, it's about as readable as it will ever be. Even if you can't, remember that aesthetics aren't random--there is a reason why pretty code is pretty. I'll restate this: "Every programmer should know more than a little bit about typography". I was amazed at how much learning design fundamentals imp…

Can you suggest any books?

I recommend "The Elements of Typographic Style" by Robert Bringhurst.

Re: Hopefully more controversial programming opinions

#84

Post by yarrel » Thu, Aug 30, 2012, 2:29 PM UTC

aguynamedrich wrote: post #81

raverbashing wrote: post #57

Earlier quoted context omitted.

So much this 100 lines of python can be turned into a hundred men-hours / 6-digit budget project in Java

So, the language choice of a piece of software determines the amount of time and money that is required to build the system?

So where you live has no bearing on crime levels?

Re: Hopefully more controversial programming opinions

#85

Post by d--b » Thu, Aug 30, 2012, 2:29 PM UTC

alexchamberlain wrote: post #15

hansbo wrote: post #7

It's a mistake to introduce new programmers to OOP before they understand the basics of breaking down problems and turning the solutions into code. Given how well I remember my classmates with little-to-none programming experience struggled with understanding pointers while not being able to write the simplest algorithms, I thought this was a no-brainer. Is it really a controversial opinion?

I've never understood what's confusing about pointers...

It's the abstraction that's difficult to get in the first place. In Basic, a variable represents at the same time the data and its memory address, the two concepts are not separated. When you introduce pointers, you split that concept in two: address and data, and to complicate you say address is some form of data. In Basic, the variables are the memory. Each variable you manipulate is equivalent to a piece of memory you can store things in or get things out. With pointers, you loose that equivalence: memory becomes invisible through the code. I can have a memory block that exists in my memory that is no longer pointed by any variable. This means that you get a separation between the way memory is and the way the code looks like. What is difficult when learning pointers is to get that extra level of abstraction: you have to look at the code as an access route to the memory, not as the memory itself.

Re: Hopefully more controversial programming opinions

#86

Post by AndrewDucker » Thu, Aug 30, 2012, 2:44 PM UTC

UK-AL wrote: post #24

InclinedPlane wrote: post #18

I would go farther in regard to the Computer Science point. CS programs should be burnt to the ground. And in their place we should build up three separate things. First, software trade schools that are actually good (e.g. not ITT). Second, for reals software engineering majors at colleges, that are heavy on things like practical programming, tools (version control, issue tracking, automated build systems), refactori…

The problem with software trade schools, even though you may not require a pure maths focus, I still expect people who program professionally to be good at maths. I would expect most programmers to analyse algorithms in a formal manner if they have to. And the people capable of doing maths at that level are not the people that traditionally go to trade schools.

I know almost no programmers who analyst algorithms in a formal manner.

Most coding doesn't require it - certainly not the kind of thing that most large companies want coders for.

Re: Hopefully more controversial programming opinions

#87

Post by ajuc » Thu, Aug 30, 2012, 2:53 PM UTC

kamaal wrote: post #46

ajuc wrote: post #42

Earlier quoted context omitted.

Because understanding exactly what program should do is more important than understanding what are best practices in CS, or how to abstract things. If you can keep all interactions of your app in your head, then it doesn't matter how badly designed the code is. Architecture is only important because it makes it possible to change things without understanding the whole thing. And complete understanding with bad archit…

>Architecture is only important because it makes it possible to change things without understanding the whole thing. And for that you need to understand the architecture, ofcourse. You always need to understand something_(n-1) to understand something_n, ad infinitum

It's a fractal, yes, but you can do with only understanding your branch in the highest resolution, you don't need all the details of the whole system (if it's well designed).

Re: Hopefully more controversial programming opinions

#88

Post by walrus » Thu, Aug 30, 2012, 2:54 PM UTC

johnpattiyson wrote: post #58

walrus wrote: post #48

> Purely functional programming doesn't work, but if you mix in a small amount of imperative code then it does. That isn't controversial nor is it an opinion. It's just the truth. Purely functional code has no side effects. The entire point of a program is to have side effects.

Not true. For example, a compiler can be a pure function. It accepts input that is the source code, and outputs the machine code. There's no side effect there. I admit it needs minor scaffolding to always read all of stdin first, and write all to stdout at the end, but the programme, as written by the programmer, is a pure function. This is one of several ways that Haskell worked before there was an IO monad [1], all…

Yes, the 'minor scaffolding' has side effects. That's why I said it wasn't controversial.

Re: Hopefully more controversial programming opinions

#89

Post by kenmazy » Thu, Aug 30, 2012, 3:24 PM UTC

tikhonj wrote: post #9

Here's my version of his opinions, probably even more controversial :P. CS should be offered as a major by itself. All the most interesting stuff is CS-specific with indirect applications. Working on something like automatic programming is far more exciting than working on biology or art or what have you. (I can't think of anything more awesome or more CS-only than automatic programming.) It is a mistake to introduce…

Not sure how you can love automatic programming but dismiss biology. Humans are an operating system that is not only time dependent, but spatial and gradient dependent self mutating automatic programming with asynchronous message passing that is also time/spatial/gradient dependent.

Oh yea, and inserting breakpoints and print statements not only take months, but also change your code in a case-by-case fashion.

It's like reverse engineering for masochists.

Re: Hopefully more controversial programming opinions

#90

Post by kstenerud » Thu, Aug 30, 2012, 3:33 PM UTC

loup-vaillant wrote: post #80

Sandman wrote: post #74

Earlier quoted context omitted.

I'm sorry, but your comment is really not much more than pointless, cynical Java bashing. Java has it's share of problems, and it's definitely not as modern (regarding language features) as some of the other languages today (although that seems to be changing too), but if you're going to attack it, then at least do it for it's bad characteristics, not because you personally dislike/don't understand certain features,…

I read the grandparent as criticizing Java programmers . A sufficient number of bad programmers seem to fall in these trap often enough that the result is a mess. Design pattern: I wouldn't be surprised if they are used too much. Love towards getters/setters. Not the fault of the language, that's just bad practice. And no, you don't have encapsulation. Rarely, getters and setters do some verifications or filtering, b…

"In your example, I'd say the overly long name comes from an overly narrow functionality. For something that specific, you should use a description string." - What use is a description string when you're staring at a code listing, trying to figure out what it does?

"a good IDE let you manage and tolerate higher levels of complexity." - Which is a good thing.

"You'll also be less encouraged to simplify your code." - Simplifying code is a discipline that can just as easily be avoided by people writing in Notepad. Simpler code comes with experience, not through tool abstinence.

"You may not even notice when it becomes too complex for a humble vi user." - If your tools don't get the job done, switch tools. If you find yourself saying "My tools would work fine if only OTHER PEOPLE would ...", you're using the wrong tools.