You save 10 milliseconds per compile cycle (likely at the expense of not properly tracking dependencies, thus breaking parallel compilation). Good luck finding a situation when this is not actually slower in the end.
Why do you need to see a definition? What information does it contain, other than format? Of what use is it without the rest of documentation?
It's the same thing that was attempted with Hungarian notation. Programmers could not remember types of their variables, and compiler constantly annoyed them with errors wen they got those types wrong. So they found great solution -- embed types into variable names. Now, a glance at a variable is sufficient to write code that is guaranteed to not produce any compiler errors. Too bad, a programmer who doesn't know the type is guaranteed to also not know how the variable actually works. But in the culture of "it compiles -- ship it!" that's not a problem. Who cares if the code is wrong -- argument types match, everything should work, right?
Oh yes, it's possible to use IDE as if it is an editor with project manager and "build" button. But then it's a shit editor with shit build manager, and who in his right mind needs that?
It's the same kind of argument as defense of C# and.NET infrastructure -- it's possible to claim that it has somewhat useful features, but not a single programmer in the world uses it for those features, everyone who uses it, uses it for Microsoft libraries and interfaces that it provides access to. (and this is why Mono is a stupid, pointless project with no excuse for its existence).
And the user will be completely confused about the whole thing, because that "definition" explains absolutely nothing, and gives no information about possible variations of things that affect the macro definition (if, by any chance, anything is conditional). Better yet, plenty of modern libraries have a layer written in this very style.
So my position on this is still:
1. The only solution that actually helps the developer when dealing with complex system of libraries is plain old documentation, where those things are explained in plain English (or whatever language the programmer prefers). One does not need IDE to do that -- middle button is usually more than sufficient.
2. If programmer needs tools to navigate declarations and macros in his own code, he is too disorganized to either remember what he is doing, or document his work in a way that he can understand. What means, the project already accumulated massive numbers of mistakes and must be abandoned as unmaintainable.
No, really, the only difference is that we code faster than you and more efficiently.
And what have you built with those supposedly superior tools? I worked on all kinds of software from bootloaders to phone call processing applications and from Linux drivers to real-time DSP, on architectures from PDP-11 to Intel, ARM and MicroBlaze. Each of those projects was a great success. At no point anyone complained about quality or timing of my work. Someone in this thread, possibly you, already found my resume and said something stupid about it, so it should be easy to verify all that. What about you? Wait, don't answer that. I already know the answer.
We've worked with worse tools before. We've grown and moved on. It is sad that you cannot, but don't confuse this with being a better programmer.
Just because you are saying so, does not make it true. Let's see how convincing it will sound with some words substituted:
We've tried to walk without crutches before. We've grown and moved on. It is sad that you cannot, but don't confuse this with being a better marathon runner.
Just about as convincing, and just about as valid.
You're the same average programmer as anyone else,
I am not an average programmer. Average programmer is an ignorant hack who has no business doing anything that involves logic, algorithms or data. In 90's hundreds of millions of those creatures were produced by crash course schools all over the world. Average programmers would destroy civilization if there weren't non-average programmers constantly fixing the problems they create, and it's a miracle that anything still works at all with those people still present.
except you refuse to use better tools.
Your "better tools" are in the same pile of crap that Hungarian notation was 5-10 years ago -- then retards such as yourself were telling me that I refuse their great programming techniques that vastly expand their capability for keeping track of your project. Now, even Microsoft, where that crap originated, banned it. Before that it was "rapid prototyping". Then Microsoft that also was among the greatest proponents of it, banned it. Just a few years ago it was "managed code" that was touted as a panacea, and Microsoft, a major proponent and originator of the term, is already falling over itself to purge it from its products.
This is all that there is to it -- all those "technologies", "methods" and "products" are injected into your mind by Microsoft, a company that constantly claims that it found a way for stupid people to do something smart, and just as constantly is proven to be wrong about it.
Visual Studio (and please don't tell me that you mean anything else by "IDE" -- you judge quality of all other IDEs by how closely it imitates Visual Studio) is one of those idiotic "get-our-product-and-it-will-make-you-smarter" products, and idiots never stop falling for those things. In reality it's at best a crutch that is only useful for a cripple, at worst an influence that turns a healthy person into a cripple.
Windows RT doesn't run the same programs as x86 Windows, therefore the markets are distinct.
Neither does Xbox and PS. Nor do different generations of the same consoles.
But purpose is the same, and Microsoft is at least trying to make things source-compatible this time, so the same products are supposed to be on both desktop and tablet versions of the OS.
You wouldn't need those IDEs (and wouldn't write as many bugs, and certainly wouldn't call software development "cutting the code") if you studied software development without them.
This is one of the problems with "convenient" tools -- people who would otherwise spend additional 2-3 weeks before they produce the first result and eventually learn to develop software in an efficient and safe manner, pick up the tool, get semi-working result immediately, and are forever stuck at the amateur level. In production environment it causes everything from inefficiency to massive disasters.
At the amateur level (what, I believe, more people can notice) the same happens with Arduino and its super-retarded monolithic environment.
Seriously, what the fuck is going on here? The comment about supported platform is from more than a month ago, the rest of the responses are about resolving it.
There are often root privilege escalation bugs that are found and affect thousands of systems that take a while for all people to patch...
And those are the actual problem. However they are getting patched long before there are any exploits found (and most of those bugs aren't exploitable at all).
for example Amazon because they run Xen, they would not let you run your own kernel.
For all I know, they could run everything under Windows ME and rm -rf random virtual machines for the lulz. This has nothing to do with operating systems.
P.S. In the above example it's still visible that the resulting function most likely does not do what the programmer expects -- arg2 that looks like destination is passed by value, but then the pointer to it is cast to void* and passed to another function. This will only work if the type of the argument (milli) is a pointer to something, and convert_wrap_to() treats its argument as a pointer to pointer, what is a stupid and counterintuitive thing to do, as one pointer would be sufficient and unambiguous:
#define define_frob(a,b) \
int convert_from_ ## a ## _to_ ## b(a arg1, b *arg2) { \
return call_func_2(convert_wrap_to,(void*)arg2,b, \
call_func_1(convert_wrap_from,(void*)&arg1,a)); \
}
But this is only visible because function body is straightforward -- in other cases, when types and dereferences are generated by other macros, it may be not.
It still doesn't matter. Ultimately, there's always a single line of code where all those macros are combined to produce something that the compiler can parse as a function definition. That line of code would correspond to the definition. It doesn't matter if there are a dozen nested macros producing it, what matters is where it all comes together.
#define define_frob(a,b) \
int convert_from_ ## a ## _to_ ## b(a arg1, b arg2) { \
return call_func_2(convert_wrap_to,(void*)&arg2,b, \
call_func_1(convert_wrap_from,(void*)&arg1,a)); \
}
define_frob(tera,milli)
becomes: int convert_from_tera_to_milli(tera arg1, milli arg2) { return (convert_wrap_to(((void*)&arg2),"milli",(convert_wrap_from(((void*)&arg1),"tera")))); }
Assuming, all three lines in the source come from different files included one after another, and their particular choices are determined by conditionals (say, type identifiers are not always strings). milli and tera are also "processed" in a some manner.
This is a very simple example of preprocessor use, and yet jumping between source lines in search for convert_from_tera_to_milli() definition results with nothing but confusing gibberish.
There's also some social policy (because we don't want people starving on the streets), and some incentive to the bankrupt party to cooperate.
But the whole point of Capitalism is that people we don't care about should starve on the streets, so people we do care about, get rich and build empires. For every John Rockefeller there were thousands of people who thought exactly what he thought and did exactly what he did -- but they starved on the streets, so no one knows about their failures, and fruits of their work were picked up by Standard Oil for free, contributing to its enormous power. They acted as a risk sink because their misery was not propagated to other members of society.
My whole point is, Apple crippled iPad to the extent that it becomes debatable if it is "general-purpose" anything at all. This means, Apple may be not even in the same market as Windows tablets, and Android is the only noticeable competitor of Windows-on-tablets.
Why would that matter? There's always a definite point at which the function declaration is, no matter how the identifier was obtained.
That "point" is in a human-unreadable output of the preprocessor. Sources may contain nothing but preprocessor macros, and identifier will be a combination of multiple such macros -- possibly from multiple files.
A preprocessor conditional would depend solely on preprocessor symbols - either intrinsics, or the one that you yourself define. There's no reason why the IDE can't know both and use them to compute things in exact same way as your build does.
Except they are generated as a part of build script by running some program and passed on the command line. Ex: any autoconfiguration mechanism. Until that program is built, IDE can't possibly know what is where. Worse yet, for a programmer it's not important to know what would happen on THIS system -- it's important to know what will happen on all other systems his software is going to be built.
No matter what, language is complex because it is supposed to express many things and be used for many purposes. Any "simplification" reduces it to a much simpler model that is supposedly easy to use in some condition, but cripples flexibility that is necessary for more sophisticated uses. Just imagine what would happen if every time you tried to say or write anything in English, a seven years old kid jumped in after every word with his "helpful suggestions". Would you be able to speak at all?
Slashdot Mirror
You save 10 milliseconds per compile cycle (likely at the expense of not properly tracking dependencies, thus breaking parallel compilation). Good luck finding a situation when this is not actually slower in the end.
Why do you need to see a definition? What information does it contain, other than format? Of what use is it without the rest of documentation?
It's the same thing that was attempted with Hungarian notation. Programmers could not remember types of their variables, and compiler constantly annoyed them with errors wen they got those types wrong. So they found great solution -- embed types into variable names. Now, a glance at a variable is sufficient to write code that is guaranteed to not produce any compiler errors. Too bad, a programmer who doesn't know the type is guaranteed to also not know how the variable actually works. But in the culture of "it compiles -- ship it!" that's not a problem. Who cares if the code is wrong -- argument types match, everything should work, right?
Oh yes, it's possible to use IDE as if it is an editor with project manager and "build" button. But then it's a shit editor with shit build manager, and who in his right mind needs that?
It's the same kind of argument as defense of C# and .NET infrastructure -- it's possible to claim that it has somewhat useful features, but not a single programmer in the world uses it for those features, everyone who uses it, uses it for Microsoft libraries and interfaces that it provides access to. (and this is why Mono is a stupid, pointless project with no excuse for its existence).
And the user will be completely confused about the whole thing, because that "definition" explains absolutely nothing, and gives no information about possible variations of things that affect the macro definition (if, by any chance, anything is conditional). Better yet, plenty of modern libraries have a layer written in this very style.
So my position on this is still:
1. The only solution that actually helps the developer when dealing with complex system of libraries is plain old documentation, where those things are explained in plain English (or whatever language the programmer prefers). One does not need IDE to do that -- middle button is usually more than sufficient.
2. If programmer needs tools to navigate declarations and macros in his own code, he is too disorganized to either remember what he is doing, or document his work in a way that he can understand. What means, the project already accumulated massive numbers of mistakes and must be abandoned as unmaintainable.
No, really, the only difference is that we code faster than you and more efficiently.
And what have you built with those supposedly superior tools?
I worked on all kinds of software from bootloaders to phone call processing applications and from Linux drivers to real-time DSP, on architectures from PDP-11 to Intel, ARM and MicroBlaze. Each of those projects was a great success. At no point anyone complained about quality or timing of my work. Someone in this thread, possibly you, already found my resume and said something stupid about it, so it should be easy to verify all that. What about you? Wait, don't answer that. I already know the answer.
We've worked with worse tools before. We've grown and moved on. It is sad that you cannot, but don't confuse this with being a better programmer.
Just because you are saying so, does not make it true. Let's see how convincing it will sound with some words substituted:
We've tried to walk without crutches before. We've grown and moved on. It is sad that you cannot, but don't confuse this with being a better marathon runner.
Just about as convincing, and just about as valid.
You're the same average programmer as anyone else,
I am not an average programmer. Average programmer is an ignorant hack who has no business doing anything that involves logic, algorithms or data. In 90's hundreds of millions of those creatures were produced by crash course schools all over the world. Average programmers would destroy civilization if there weren't non-average programmers constantly fixing the problems they create, and it's a miracle that anything still works at all with those people still present.
except you refuse to use better tools.
Your "better tools" are in the same pile of crap that Hungarian notation was 5-10 years ago -- then retards such as yourself were telling me that I refuse their great programming techniques that vastly expand their capability for keeping track of your project. Now, even Microsoft, where that crap originated, banned it. Before that it was "rapid prototyping". Then Microsoft that also was among the greatest proponents of it, banned it. Just a few years ago it was "managed code" that was touted as a panacea, and Microsoft, a major proponent and originator of the term, is already falling over itself to purge it from its products.
This is all that there is to it -- all those "technologies", "methods" and "products" are injected into your mind by Microsoft, a company that constantly claims that it found a way for stupid people to do something smart, and just as constantly is proven to be wrong about it.
Visual Studio (and please don't tell me that you mean anything else by "IDE" -- you judge quality of all other IDEs by how closely it imitates Visual Studio) is one of those idiotic "get-our-product-and-it-will-make-you-smarter" products, and idiots never stop falling for those things. In reality it's at best a crutch that is only useful for a cripple, at worst an influence that turns a healthy person into a cripple.
And people NEVER thought about measuring food and environmental contamination with radioactive isotopes, separately from external exposure.
Oh, wait, this is what I did at work! Twenty years ago!
How much energy do you think, a cell has to absorb for any of this "oxidative stress" crap to happen?
My parents did just that.
And into all those places, money come mostly from credit.
This is factually incorrect.
Where else does it come from?
Don't say individual savings from mattresses.
Windows RT doesn't run the same programs as x86 Windows, therefore the markets are distinct.
Neither does Xbox and PS.
Nor do different generations of the same consoles.
But purpose is the same, and Microsoft is at least trying to make things source-compatible this time, so the same products are supposed to be on both desktop and tablet versions of the OS.
Except for all of the times when they're not. Venture money comes from all sorts of places.
And into all those places, money come mostly from credit.
good software
What is that "good software" that you are talking about?
You wouldn't need those IDEs (and wouldn't write as many bugs, and certainly wouldn't call software development "cutting the code") if you studied software development without them.
This is one of the problems with "convenient" tools -- people who would otherwise spend additional 2-3 weeks before they produce the first result and eventually learn to develop software in an efficient and safe manner, pick up the tool, get semi-working result immediately, and are forever stuck at the amateur level. In production environment it causes everything from inefficiency to massive disasters.
At the amateur level (what, I believe, more people can notice) the same happens with Arduino and its super-retarded monolithic environment.
O RLY?
But do you have anything to say relevant to your refuted claims?
"We" didn't have painless bankruptcies before, either.
Seriously, what the fuck is going on here? The comment about supported platform is from more than a month ago, the rest of the responses are about resolving it.
There are often root privilege escalation bugs that are found and affect thousands of systems that take a while for all people to patch...
And those are the actual problem. However they are getting patched long before there are any exploits found (and most of those bugs aren't exploitable at all).
for example Amazon because they run Xen, they would not let you run your own kernel.
For all I know, they could run everything under Windows ME and rm -rf random virtual machines for the lulz. This has nothing to do with operating systems.
Do you, guys, read what you are responding to, or just paste randomly-generated retorts without looking?
P.S. In the above example it's still visible that the resulting function most likely does not do what the programmer expects -- arg2 that looks like destination is passed by value, but then the pointer to it is cast to void* and passed to another function. This will only work if the type of the argument (milli) is a pointer to something, and convert_wrap_to() treats its argument as a pointer to pointer, what is a stupid and counterintuitive thing to do, as one pointer would be sufficient and unambiguous:
#define define_frob(a,b) \
int convert_from_ ## a ## _to_ ## b(a arg1, b *arg2) { \
return call_func_2(convert_wrap_to,(void*)arg2,b, \
call_func_1(convert_wrap_from,(void*)&arg1,a)); \
}
But this is only visible because function body is straightforward -- in other cases, when types and dereferences are generated by other macros, it may be not.
It still doesn't matter. Ultimately, there's always a single line of code where all those macros are combined to produce something that the compiler can parse as a function definition. That line of code would correspond to the definition. It doesn't matter if there are a dozen nested macros producing it, what matters is where it all comes together.
No.
Behold:
#define call_func_1(a,b,c) (a((b),#c))
#define call_func_2(a,b,c,d) (a((b),#c,d))
#define define_frob(a,b) \
int convert_from_ ## a ## _to_ ## b(a arg1, b arg2) { \
return call_func_2(convert_wrap_to,(void*)&arg2,b, \
call_func_1(convert_wrap_from,(void*)&arg1,a)); \
}
define_frob(tera,milli)
becomes:
int convert_from_tera_to_milli(tera arg1, milli arg2) { return (convert_wrap_to(((void*)&arg2),"milli",(convert_wrap_from(((void*)&arg1),"tera")))); }
Assuming, all three lines in the source come from different files included one after another, and their particular choices are determined by conditionals (say, type identifiers are not always strings). milli and tera are also "processed" in a some manner.
This is a very simple example of preprocessor use, and yet jumping between source lines in search for convert_from_tera_to_milli() definition results with nothing but confusing gibberish.
There's also some social policy (because we don't want people starving on the streets), and some incentive to the bankrupt party to cooperate.
But the whole point of Capitalism is that people we don't care about should starve on the streets, so people we do care about, get rich and build empires. For every John Rockefeller there were thousands of people who thought exactly what he thought and did exactly what he did -- but they starved on the streets, so no one knows about their failures, and fruits of their work were picked up by Standard Oil for free, contributing to its enormous power. They acted as a risk sink because their misery was not propagated to other members of society.
Apart from their creditors, you mean?
Their creditors are banks -- if more loans default, they jack up interest rates so other people will pay for it.
Not if he's invested some of his own money.
And when does this happen at any significant scale?
By what mechanism?
See above. Failures now mean higher interest rates later (unless they are already calculated into risks so it means higher interest rates now).
What?
My whole point is, Apple crippled iPad to the extent that it becomes debatable if it is "general-purpose" anything at all. This means, Apple may be not even in the same market as Windows tablets, and Android is the only noticeable competitor of Windows-on-tablets.
Why would that matter? There's always a definite point at which the function declaration is, no matter how the identifier was obtained.
That "point" is in a human-unreadable output of the preprocessor. Sources may contain nothing but preprocessor macros, and identifier will be a combination of multiple such macros -- possibly from multiple files.
A preprocessor conditional would depend solely on preprocessor symbols - either intrinsics, or the one that you yourself define. There's no reason why the IDE can't know both and use them to compute things in exact same way as your build does.
Except they are generated as a part of build script by running some program and passed on the command line. Ex: any autoconfiguration mechanism. Until that program is built, IDE can't possibly know what is where. Worse yet, for a programmer it's not important to know what would happen on THIS system -- it's important to know what will happen on all other systems his software is going to be built.
No matter what, language is complex because it is supposed to express many things and be used for many purposes. Any "simplification" reduces it to a much simpler model that is supposedly easy to use in some condition, but cripples flexibility that is necessary for more sophisticated uses. Just imagine what would happen if every time you tried to say or write anything in English, a seven years old kid jumped in after every word with his "helpful suggestions". Would you be able to speak at all?