simple C# example:
public void Foo(int x) {
Func<int,int> square = o => o * 0;
Console.Write(square(x));
}
I use that as an example only because i'm a bit rusty on my python and scala.. But python and scala actually have much better support for nested functions, being able to do something along the lines of:
def Foo(int x):
def Square (int i): i * i
Square(x)
No, he has no good point. And you just lost prestige.
A function has a name. And the name expresses what the function does. If I see one writing a function/method wich is larger than one screen he gets brain washed, heavily. In fact I want them to write functions less than 15 lines. No need to call them multiple times, once is enough!
I admit it's more situational than I implied (careful reading of the word "may", for instance, goes a long way here). But it's important to note that there's very little few instances where code can't be refactored to less than a page without resorting to arbitrarily breaking it up into separate functions. If you absolutely can't break it down with code reuse or at least separation of concerns, there's a few options available. One of my personal favorites, discussed earlier in the thread, is nested functions (the advantage is that you're not crowding your namespace with one-offs, and it helps keep the code easy to find). Another is to separate your large function into regions.
The point here is that, contrary to what you may think, it is *not* easier to read a bunch of tightly coupled functions that are arbitrarily split than it is to read one big function. It's like reading a heavily footnoted paper -- you spend all your time looking up the source and forget what you're doing.
Most higher level languages in common use? C, C++, Java don't have them. What other language is in "common use" these days? PHP?
Actually, the latest C++ and Java implementations do support it, as do C#, VB, Lisp variants, Python, and Scala, and most any pure functional language. Anything that supports closures supports this to some degree (the readability of the solution varies, however).
Breaking even a single operation into smaller blocks it a good thing, if it spans hundreds of lines.
I miss nested functions - they were very useful for just that sort of thing. It also clarifies that nested function g() exists only to implement something in enclosing function f(), which is often the case when breaking thinks up for clarity rather than trying to write reusable functions. Since a nested function can access the locals of its enclosing function, it also often avoids having to pass very long argument lists.
Nested functions were a standard feature of Algol family languages, but unfortunately died w/ C (though gcc supports nested functions as an extension). These days many people seem unaware that there even is such a thing as nested functions.
Nested functions are quite nice, and are actually supported by most higher level languages in common use these days. It's a much more appropriate way to break up code than putting bits and pieces all over the place just to reduce the size of a single code block.
Reuse, and breaking a problem in simpler logical blocks are both valid reasons to use functions, the latter helps in understandability and limits scope since you can more clearly determine what the inputs and outputs , and intent of a function is (as long as you name it right). You can also read the main function easier.
...
int id = findIndex(name,table);...
reads much easier than:
...
int id = -1;
for (int i = 0; i < table.size; i++) {
if (strcmp(name,table.data[i].name) == 0) {
id = i;
break;
}
}
...
My guess is you're going to use findIndex more than once in your programming career though, making it a prime candidate for function from code reuse standpoint. I consider this a poor example. It's hard to find a good counter-example, because there have been very, very few times in my career where I've written code that I couldn't reuse. In my experience moving code off to a separate function for no other reason than to clarify the code only helps clarify the code for the initial author, not for those who have to dig through all of his nested one-use functions to figure out what's actually going on.
I will concede that separation of concerns is a good reason to break apart single-use operations. But not arbitrarily based on code size.
No, he wouldn't have a good point. Breaking even a single operation into smaller blocks it a good thing, if it spans hundreds of lines.
Generally speaking, yes. But you do that by identifying code re-use points and separations of concerns. Not by arbitrarily breaking down an irreducibly complex algorithm into complex subroutines that only exist to move code off to separate locations. My guess is that, if you're dealing with a function that is hundreds of lines long, you missed out on a whole lot of points for code reuse.
Compare.NET code to the compiled machine code.
Which is easier to understand and work on? The.net runtime is nothing but a set of functions in a separate file. using simple functions means main()can be an outline of the program, for example .
By any measure, Linus Torvalds is an incredibly successful programmer. His guideline is 6-8 lines per function or so.
Consider these two example programs:
Stand
Turn left
Walk four steps
Turn right
Walk two steps
Turn right... 1000 more lines
Vs:
heatlunch()
readslashdot()
Even if the function heatlunch() is used nowhere else, using it makes the program far more understandable than inlining the walking code to get to the microwave.
But you forget you also have to walk back to your desk.. At that point, you have two usages of a pathing algorithm.. Which means you're repeating code, which means that using a function to enable code re-use instead makes sense. I'm hardly an advocate for complex functions (most of my code are 1 or 2 liners), but there are times when you simply cannot express something concisely in a short function, and the answer to that is *not* to artificially reduce it into code that does nothing but resides in a different location.
One of the programmers I work with complains when you use more than 1 function to do a job. Even if it means writing a 20 page function. His code is unmaintainable because you can't change even a tiny part of it without breaking something 3 pages down. He cries that my code is too complex because I break things down into small simple functions and multiple files and build complex behaviors out of them so he has to swap between files.
He used to work on IE at Microsoft, so that might tell you something.
Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point.
You operate under the assumption that libertarians want to do whatever they want, government be damned. That's a rather stupid assumption considering that most simply want government to stop over-regulating and return to a smaller and less-intrusive form of itself. But then, you lib[ertarian]s always were more than happy to operate on bad assumptions (or rather, just parrot what you're told to).
What?
When he says "libs" he's speaking of liberals, not libertarians. His point is not non-nonsensical, just myopic and asinine.
Just for reference, if you look at the summary you'll see that what he's released is that trove... encrypted. The idea is that if he gets arrested, he yells out the passphrase, but until then this might as well be 1.7TiB of/dev/random
My family had moved to a rural area. With no friends nearby and lots of time over the summer in 5th grade, I read my dad's C++ books and started coding on my off-brand 486.
There is 0 proven incidents of fraking causing water to be set on fire. Yes, there are well-stated claims of such incidents. However, not only is the link between fraking and water being set on fire not true, but a stronger statement is actually justified: it has been definitively proven that fraking does not cause release of methane into drinking water (the methane in drinking water is what created the water-on-fire incidents).
Good thing we have all those scientists paid to disprove such claims by the oil and gas companies! Otherwise how would we ever know for sure?
Did anyone else just see still images when they flashed quickly in the middle of the video (not the beginning or the end, when they showed motion for longer periods)? I've always had some weird visual delay issues, but I'm curious if they were really just moving that quickly or if I just perceive that slowly.
We can solve those traveling salesman problems that have been plaguing our society for hundreds of years!
I realize you're joking, but they actually are important problems to solve. If you have 10,000 solder points, and you need your equipment to solder as fast as possible, what route do you take?
So you can certainly learn to code, and probably just as well as someone right out of school (that whole "learning is easier when you're young" thing is a crock of shit). The problem is that you will be *perceived* as "over the hill", "set in your ways", "too expensive", or just plain "too old" when interviewing for jobs. Ageism is rampant in the software development world -- I got a taste or two of it before I had even turned 30. That said, you might as well go for it, as it doesn't sound like you have better options, and with enough effort you *can* succeed, despite the ageism you'll face.
Lock contention is just another algorithm problem. You can avoid it pretty well with producer/consumer queues or even something like an actor model. Young vs old is again irrelevant, though the young guy might have the upper hand if he took one of the parallel programming courses they teach nowadays.
Will a new programmer know "this works well for this kind of problem", compared to "I can find a library that does this but I don't know/care how it works (and it really sucks at speed)".
If the new programmer paid attention in his algorithms class, he should know the answer to that one just as well as the old guy..
Any other excuse for not hiring them is a smokescreen
Here's my excuse: Any old fart is going to have a deep network of contacts. If they have a good reputation, then they can use these contacts to quickly find new employment. So any old fart trying to find a job by replying to web ads is almost certainly a turd. I have hired plenty of old farts that I knew professionally, or were referred by people I trust, and have mostly been happy with them. I have never interviewed an old fart random responder that I wanted to hire.
I had an old fart come in as a contractor after retiring as a manager in a government agency. One of the best coders we ever had. I had another kid come right out of school, another great coder. We also had a slew of good, bad, and mediocre programmers, all with varying ages. Age has nothing to do with it.
I'm a long-time Googler. Part of the job is conducting technical interviews. Which means that I spend many hours each week talking to people who, despite their impressive resumes and academic degrees from world-class institutions, *can't program a fucking computer*.
Don't talk to me about a sufficiency of trained workers until one of them shows up for an interview with some grasp of the fetch-execute cycle.
Are you really doing that much assembly coding at google? Maybe you are, but if I was going for a google interview I would brush up on things like time complexity, tree structures, and combinatorics, and would probably fail your test because I don't memorize the names of all the steps of "look at the register, increment the register and load the memory address in another register, execute the memory in that register, repeat".
If companies want to stop paying people like me too much money they should be hiring young (cheap) workers to put downward pressure on wages. That doesn't happen because it's seen as easier to just go off-shore.
Exactly what the company I work for did. Dumped the offshore workers and their appalling work and hired a ton of entry level developers mostly right out of college with low pay. The young devs are out the door as soon as they get 1-2 years of experience.
Did you try increasing their pay to match their increased productivity from their increased skillset?
I think creativity,problem solving, and math are the most important aspects of a good SE. Everything else can be learned pretty quickly. The basics of time complexity and data structures can be learned in a weekend. OOP/Design Patterns/SD Processes are something a new grad would still be learning anyway, and aren't terribly difficult. Tons of other skills are easy to learn as well. I'd like to know specifically what skills you think would require so much learning that it would be unfeasible to make the transition from hard science with programming experience to software engineering.
I totally agree that we should retrain, but having a PhD in Astronomy says almost nothing about that persons ability to become a competent software engineer. They are two completely different disciplines. Some would love it and be excellent at it, others would hate it and suck at it.
Generally speaking, someone with a PhD in Astronomy has done a fair amount of coding to implement their ideas. It's not far to go from scientific computing to Software Engineering, and in fact such a person would likely have a better math background than most of his fellow SEs.
So you are saying that we need more 3l33t Astronomers because the job market for them is terrible?
"Lumping these folks together with the legions of code hackers is ridiculous."
When you learn the difference between a Software Engineer and a "code hacker" you might be able to make an intelligent post. Until then, you are just another clueless guy without a job spitting out sour grapes because we don't need as many pie in the sky theorists as we do people who actually produce useful technology that solves today's problems.
I'd be willing to bet that someone with a PhD in astronomy could become a software engineer in a relatively short time... Maybe we should retrain our existing workforce instead of importing indentured servants?
In fact, I'm one of those meritocratic boogeymen that thinks our borders should be open with nothing more than a background check into your criminal record before you're granted entrance to the United States
TPTB would never allow it. If imported talent weren't tied to a sponsoring corporation, they would be free to better their lot through job movement and wages would rise.
Can't be having that.
I would say we should only have this arrangement with countries that agree to the same conditions. It's worked out well for the Commonwealth nations, and I don't see why it wouldn't work for us.
Slashdot Mirror
that c# example square lambda should read:
Func square = o => o * o;
simple C# example:
// Foo(5) result = 25
public void Foo(int x) {
Func<int,int> square = o => o * 0;
Console.Write(square(x));
}
I use that as an example only because i'm a bit rusty on my python and scala.. But python and scala actually have much better support for nested functions, being able to do something along the lines of:
def Foo(int x):
def Square (int i): i * i
Square(x)
No, he has no good point. And you just lost prestige. A function has a name. And the name expresses what the function does. If I see one writing a function/method wich is larger than one screen he gets brain washed, heavily. In fact I want them to write functions less than 15 lines. No need to call them multiple times, once is enough!
I admit it's more situational than I implied (careful reading of the word "may", for instance, goes a long way here). But it's important to note that there's very little few instances where code can't be refactored to less than a page without resorting to arbitrarily breaking it up into separate functions. If you absolutely can't break it down with code reuse or at least separation of concerns, there's a few options available. One of my personal favorites, discussed earlier in the thread, is nested functions (the advantage is that you're not crowding your namespace with one-offs, and it helps keep the code easy to find). Another is to separate your large function into regions.
The point here is that, contrary to what you may think, it is *not* easier to read a bunch of tightly coupled functions that are arbitrarily split than it is to read one big function. It's like reading a heavily footnoted paper -- you spend all your time looking up the source and forget what you're doing.
Most higher level languages in common use? C, C++, Java don't have them. What other language is in "common use" these days? PHP?
Actually, the latest C++ and Java implementations do support it, as do C#, VB, Lisp variants, Python, and Scala, and most any pure functional language. Anything that supports closures supports this to some degree (the readability of the solution varies, however).
Breaking even a single operation into smaller blocks it a good thing, if it spans hundreds of lines.
I miss nested functions - they were very useful for just that sort of thing. It also clarifies that nested function g() exists only to implement something in enclosing function f(), which is often the case when breaking thinks up for clarity rather than trying to write reusable functions. Since a nested function can access the locals of its enclosing function, it also often avoids having to pass very long argument lists.
Nested functions were a standard feature of Algol family languages, but unfortunately died w/ C (though gcc supports nested functions as an extension). These days many people seem unaware that there even is such a thing as nested functions.
Nested functions are quite nice, and are actually supported by most higher level languages in common use these days. It's a much more appropriate way to break up code than putting bits and pieces all over the place just to reduce the size of a single code block.
Reuse, and breaking a problem in simpler logical blocks are both valid reasons to use functions, the latter helps in understandability and limits scope since you can more clearly determine what the inputs and outputs , and intent of a function is (as long as you name it right). You can also read the main function easier. ...
int id = findIndex(name,table); ...
reads much easier than:
...
int id = -1;
for (int i = 0; i < table.size; i++) {
if (strcmp(name,table.data[i].name) == 0) {
id = i;
break;
}
}
My guess is you're going to use findIndex more than once in your programming career though, making it a prime candidate for function from code reuse standpoint. I consider this a poor example. It's hard to find a good counter-example, because there have been very, very few times in my career where I've written code that I couldn't reuse. In my experience moving code off to a separate function for no other reason than to clarify the code only helps clarify the code for the initial author, not for those who have to dig through all of his nested one-use functions to figure out what's actually going on.
I will concede that separation of concerns is a good reason to break apart single-use operations. But not arbitrarily based on code size.
No, he wouldn't have a good point. Breaking even a single operation into smaller blocks it a good thing, if it spans hundreds of lines.
Generally speaking, yes. But you do that by identifying code re-use points and separations of concerns. Not by arbitrarily breaking down an irreducibly complex algorithm into complex subroutines that only exist to move code off to separate locations. My guess is that, if you're dealing with a function that is hundreds of lines long, you missed out on a whole lot of points for code reuse.
Compare .NET code to the compiled machine code.
Which is easier to understand and work on? The .net runtime is nothing but a set of functions in a separate file. using simple functions means main()can be an outline of the program, for example .
By any measure, Linus Torvalds is an incredibly successful programmer. His guideline is 6-8 lines per function or so.
Consider these two example programs:
Stand
Turn left
Walk four steps
Turn right
Walk two steps
Turn right ... 1000 more lines
Vs:
heatlunch()
readslashdot()
Even if the function heatlunch() is used nowhere else, using it makes the program far more understandable than inlining the walking code to get to the microwave.
But you forget you also have to walk back to your desk.. At that point, you have two usages of a pathing algorithm.. Which means you're repeating code, which means that using a function to enable code re-use instead makes sense. I'm hardly an advocate for complex functions (most of my code are 1 or 2 liners), but there are times when you simply cannot express something concisely in a short function, and the answer to that is *not* to artificially reduce it into code that does nothing but resides in a different location.
One of the programmers I work with complains when you use more than 1 function to do a job. Even if it means writing a 20 page function. His code is unmaintainable because you can't change even a tiny part of it without breaking something 3 pages down. He cries that my code is too complex because I break things down into small simple functions and multiple files and build complex behaviors out of them so he has to swap between files.
He used to work on IE at Microsoft, so that might tell you something.
Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point.
You operate under the assumption that libertarians want to do whatever they want, government be damned. That's a rather stupid assumption considering that most simply want government to stop over-regulating and return to a smaller and less-intrusive form of itself. But then, you lib[ertarian]s always were more than happy to operate on bad assumptions (or rather, just parrot what you're told to).
What?
When he says "libs" he's speaking of liberals, not libertarians. His point is not non-nonsensical, just myopic and asinine.
Just for reference, if you look at the summary you'll see that what he's released is that trove... encrypted. The idea is that if he gets arrested, he yells out the passphrase, but until then this might as well be 1.7TiB of /dev/random
My guess is it's 1.7GB of /dev/random anyway.
My family had moved to a rural area. With no friends nearby and lots of time over the summer in 5th grade, I read my dad's C++ books and started coding on my off-brand 486.
There is 0 proven incidents of fraking causing water to be set on fire. Yes, there are well-stated claims of such incidents. However, not only is the link between fraking and water being set on fire not true, but a stronger statement is actually justified: it has been definitively proven that fraking does not cause release of methane into drinking water (the methane in drinking water is what created the water-on-fire incidents).
Good thing we have all those scientists paid to disprove such claims by the oil and gas companies! Otherwise how would we ever know for sure?
Did anyone else just see still images when they flashed quickly in the middle of the video (not the beginning or the end, when they showed motion for longer periods)? I've always had some weird visual delay issues, but I'm curious if they were really just moving that quickly or if I just perceive that slowly.
We can solve those traveling salesman problems that have been plaguing our society for hundreds of years!
I realize you're joking, but they actually are important problems to solve. If you have 10,000 solder points, and you need your equipment to solder as fast as possible, what route do you take?
So you can certainly learn to code, and probably just as well as someone right out of school (that whole "learning is easier when you're young" thing is a crock of shit). The problem is that you will be *perceived* as "over the hill", "set in your ways", "too expensive", or just plain "too old" when interviewing for jobs. Ageism is rampant in the software development world -- I got a taste or two of it before I had even turned 30. That said, you might as well go for it, as it doesn't sound like you have better options, and with enough effort you *can* succeed, despite the ageism you'll face.
Lock contention is just another algorithm problem. You can avoid it pretty well with producer/consumer queues or even something like an actor model. Young vs old is again irrelevant, though the young guy might have the upper hand if he took one of the parallel programming courses they teach nowadays.
Will a new programmer know "this works well for this kind of problem", compared to "I can find a library that does this but I don't know/care how it works (and it really sucks at speed)".
If the new programmer paid attention in his algorithms class, he should know the answer to that one just as well as the old guy..
Any other excuse for not hiring them is a smokescreen
Here's my excuse: Any old fart is going to have a deep network of contacts. If they have a good reputation, then they can use these contacts to quickly find new employment. So any old fart trying to find a job by replying to web ads is almost certainly a turd. I have hired plenty of old farts that I knew professionally, or were referred by people I trust, and have mostly been happy with them. I have never interviewed an old fart random responder that I wanted to hire.
I had an old fart come in as a contractor after retiring as a manager in a government agency. One of the best coders we ever had. I had another kid come right out of school, another great coder. We also had a slew of good, bad, and mediocre programmers, all with varying ages. Age has nothing to do with it.
I'm a long-time Googler. Part of the job is conducting technical interviews. Which means that I spend many hours each week talking to people who, despite their impressive resumes and academic degrees from world-class institutions, *can't program a fucking computer*.
Don't talk to me about a sufficiency of trained workers until one of them shows up for an interview with some grasp of the fetch-execute cycle.
Are you really doing that much assembly coding at google? Maybe you are, but if I was going for a google interview I would brush up on things like time complexity, tree structures, and combinatorics, and would probably fail your test because I don't memorize the names of all the steps of "look at the register, increment the register and load the memory address in another register, execute the memory in that register, repeat".
If companies want to stop paying people like me too much money they should be hiring young (cheap) workers to put downward pressure on wages. That doesn't happen because it's seen as easier to just go off-shore.
Exactly what the company I work for did. Dumped the offshore workers and their appalling work and hired a ton of entry level developers mostly right out of college with low pay. The young devs are out the door as soon as they get 1-2 years of experience.
Did you try increasing their pay to match their increased productivity from their increased skillset?
I think creativity,problem solving, and math are the most important aspects of a good SE. Everything else can be learned pretty quickly. The basics of time complexity and data structures can be learned in a weekend. OOP/Design Patterns/SD Processes are something a new grad would still be learning anyway, and aren't terribly difficult. Tons of other skills are easy to learn as well. I'd like to know specifically what skills you think would require so much learning that it would be unfeasible to make the transition from hard science with programming experience to software engineering.
I totally agree that we should retrain, but having a PhD in Astronomy says almost nothing about that persons ability to become a competent software engineer. They are two completely different disciplines. Some would love it and be excellent at it, others would hate it and suck at it.
Generally speaking, someone with a PhD in Astronomy has done a fair amount of coding to implement their ideas. It's not far to go from scientific computing to Software Engineering, and in fact such a person would likely have a better math background than most of his fellow SEs.
So you are saying that we need more 3l33t Astronomers because the job market for them is terrible?
When you learn the difference between a Software Engineer and a "code hacker" you might be able to make an intelligent post. Until then, you are just another clueless guy without a job spitting out sour grapes because we don't need as many pie in the sky theorists as we do people who actually produce useful technology that solves today's problems.
I'd be willing to bet that someone with a PhD in astronomy could become a software engineer in a relatively short time... Maybe we should retrain our existing workforce instead of importing indentured servants?
In fact, I'm one of those meritocratic boogeymen that thinks our borders should be open with nothing more than a background check into your criminal record before you're granted entrance to the United States
TPTB would never allow it. If imported talent weren't tied to a sponsoring corporation, they would be free to better their lot through job movement and wages would rise.
Can't be having that.
I would say we should only have this arrangement with countries that agree to the same conditions. It's worked out well for the Commonwealth nations, and I don't see why it wouldn't work for us.