The Big Programming Thread - Page 390

On November 12 2013 02:37 Manit0u wrote:
And remember, extends are evil. Interface inheritance > implementation inheritance.

On November 11 2013 11:18 ArchmageKruzer wrote:
For science fair this year, one of my friends is trying to build a program to compare frequencies of chunks of various DNA codes (quite personally I don't really understand it myself, but it's basically you get ~ one million dna bases, and you pick out how many AGTGGACA are in there, rinse and repeat for a ton more chunks). So the obvious way is to just run a loop and compare the data, but that would take a long time as I understand it. Is there a more effective way to do this? (btw, I am really bad at coding. I am extremely good at logic stuff, but idk much syntax and terms and shit. i.e I'm in regular high school programming learning about java. we just got past karel, and are in the middle of if statements) please try not to use too much complicated syntax, or if you do, give me some sort of reference sheet so that I can look at it while I read you post. Ty!

#pragma omp parallel for
for (i=0;i<numberOfSubjects;i++)
  processSubject(subject[i]);

On November 12 2013 02:37 Manit0u wrote:
And remember, extends are evil. Interface inheritance > implementation inheritance.

On November 12 2013 01:52 Yoshi- wrote:


Yea that is bullshit
I all up for splitting code into smaller part, but saying that you should average between 3 to 5 lines is just ridiculous

On November 12 2013 02:37 Manit0u wrote:
And remember, extends are evil. Interface inheritance > implementation inheritance.

On November 12 2013 07:47 klo8 wrote:

I agree. Saying that 3-5 lines (or even 10 lines) per method should be your average doesn't even make much sense because it completely disregards how complicated the thing is the method does. You can't really do the A* algorithm in 10 lines and if you break it up into chunks of 10 LoC long methods, it would hurt readability more than it would help.

Also, in a lot of cases, more lines are actually more readable, especially in functional code where you might be tempted to do as much as you possibly can in one statement/expression, just because you can. (like chaining a map and a filter and a reduce in one line is cool when you're first learning it because you'd probably need at least 5-10 lines to do the same with loops, but IMO it hinders readability)

On November 12 2013 02:23 spinesheath wrote:
Breaking code up into smaller parts only makes sense if you can come up with good names for these parts. If you functions are small but their names don't clearly describe what they do, you made your code worse by splitting it up.

On November 12 2013 01:52 Yoshi- wrote:


Yea that is bullshit
I all up for splitting code into smaller part, but saying that you should average between 3 to 5 lines is just ridiculous

On November 12 2013 07:16 Frigo wrote:

components > delegation > mixins > interfaces > inheritance

On November 12 2013 08:17 KaiserJohan wrote:
It feels like a natural progression for a programmer is to start in merry OOP-land and then as you grow slowly realise how ugly it is and transition into more functional languages and paradigms

On November 12 2013 08:17 KaiserJohan wrote:
It feels like a natural progression for a programmer is to start in merry OOP-land and then as you grow slowly realise how ugly it is and transition into more functional languages and paradigms

On November 12 2013 08:13 sluggaslamoo wrote:


Functional programming is only hard to read when you don't understand it, otherwise its easier to read. Its almost like saying we shouldn't use object orientation because it makes the code more complicated than doing things in a structural (procedural) manner.



If you follow the proper principle of functional decomposition this will never happen.



"I don't know how to do it, therefore its bullshit"

You guys aren't trying hard enough. I always check the commit log and whenever a developer writes a function that is more than 10 lines long I can almost always find a way to break it up into more re-useable functions or find a better way to write it, this then cascades down into being used into his other functions and before you know it I end up deleting a hundred lines of code.

Most people just don't know how to break things down efficiently. I see this problem in almost all projects I start work in, I can immediately see far better abstractions but its just not worth fixing it unless there is very high test coverage.

If I had some sort of way to calculate lines of code per method in any of my contract projects you would get an average of 3 lines per method. Most of my model methods are a single line long, my controller methods about 3-5 lines. It makes it extremely readable and maintainable.

D.R.Y my friend

On November 12 2013 10:20 Shikada wrote:


It should be a natural progression to get at least interested in the functional style of programming, learn its advantages and disadvantages and then later use whichever style is superior to your task.

People disgruntled with the verbosity of Java will fall in love with dynamic languages, people that are more mathematically inclined love functional languages, but in the end, the best programmers choose their tools based on merits that are much less emotionally charged.

On November 12 2013 08:13 sluggaslamoo wrote:
"I don't know how to do it, therefore its bullshit"

You guys aren't trying hard enough. I always check the commit log and whenever a developer writes a function that is more than 10 lines long I can almost always find a way to break it up into more re-useable functions or find a better way to write it, this then cascades down into being used into his other functions and before you know it I end up deleting a hundred lines of code.

Most people just don't know how to break things down efficiently. I see this problem in almost all projects I start work in, I can immediately see far better abstractions but its just not worth fixing it unless there is very high test coverage.

If I had some sort of way to calculate lines of code per method in any of my contract projects you would get an average of 3 lines per method. Most of my model methods are a single line long, my controller methods about 3-5 lines. It makes it extremely readable and maintainable.

D.R.Y my friend

On April 30 2013 10:57 sluggaslamoo wrote:
As a whole, I'd say 95% of all developers in the world are absolutely atrocious because of the reason you gave. A very tiny fraction of developers actually know how to write good code and engage in computer science. I do not work with those kinds of developers and neither do my workmates because they are simply a waste of time.

I don't know why this is my loss, I get paid a substantially higher amount compared to your developers and get to work in a really good environment because of said reasons. Developers like yours would not even pass the interview of some of the companies I've worked in.

On November 12 2013 11:27 phar wrote:
Oh wait nevermind you're this guy:

On November 12 2013 11:41 Cyx. wrote:


So did like three whole days of posts get burned out of this thread, or is that from somewhere else? Because I went looking for context on that quote and there is nothing for the day before that date to the day after that date in this thread... and now I feel like I missed a good flame war

On November 12 2013 11:12 wherebugsgo wrote:


No offense, but you sound like a pain in the ass to work with. As other people have said, you can't just make the generalisation that all functions can be broken down into auxiliary functions of size X, or that even if they could, that it would necessarily be better. I can even think of examples right now that seem mathematically quite simple but are ugly as fuck if you try to decompose them too much. For example, writing a ray-object intersection test for a raytracer. Writing various prime factorization algorithms (e.g. Shanks or Dixon's). Writing anything with conditional cases in which calling auxiliary functions spreads the code too much-readability there comes from personal preference, really. If each auxiliary method is only one line or two lines long then you might as well leave it in the original function without separating it in the first place (since by making it auxiliary you need to define it somewhere else, adding lines and spreading out the code, making it more disorganised)

def generate_solutions
  all_possible_heating_systems.product(all_possible_cooling_systems).collect { |x, y|
    HvacSolution.new(etc)
  }.compact

Technically its a line long but lets say 3 lines

all_possible_X_systems is the same as above but the product of compatible plants, distributions and controls, takes about 3 lines of code max.

On November 12 2013 12:04 sluggaslamoo wrote:
Ill give a real example. A solution is a combination of a heating and cooling system, you have hundreds of each. Each system is a combination of a multitude of different parts, distribution, control and plant. You need to generate a system for every permutation of these parts, and then a solution for every permutation of these systems.