OK, I'm also your typical Slashdotter, about 30 and a professional programmer. I also have a strong interest in design and presentation skills, and currently produce the publicity materials for a large, local not-for-profit organisation. Some of that is external, but a lot of it is just keeping a few thousand members of our club informed about which of the 50+ hours of activities we're organising this week they might be interested in.
None of this information can't be represented with ASCII text in Notepad either. I know: we send out plain text e-mails as part of our publicity. However, we also provide a web site, and printed matter, each of which is carefully designed to convey the content as efficiently, accurately and accessibly as possible.
We've been doing this for quite a while now (think decades) and we've collected a lot of feedback about the results you get via different media and different approaches to the presentation. The one thing that is absolutely clear, above all else, is that presentation matters.
If we provide a conveniently scannable diary of the current season's events, attendance at those events will go up. If an event is inadvertently missed off the scannable diary, even though all the details are present on a page of its own elsewhere, attendance will be poor.
If changes are made at short notice (same day) then a separate e-mail to all members is justified to highlight the surprise. But if you send a separate e-mail for every notice rather than combining the general reminders into a weekly digest, people start sending (usually polite) replies asking for a lower volume of mail.
If key information about activities we're trying to highlight is placed early in our brochure for the season and on the front page of the web site, the details will still get through, even if most of them are hidden in a box on page 15. But if you put too much in big letters and pretty colours, people stop reading, because they can't prioritise and then scan what's really important to them.
This is made even more challenging because different people have different interests, and consider different information more important. You have to make sure each interest group can find what they're looking for, without blinding them with what the guy next door wants to see.
Different people also process information different ways. Some people like a flow diagram to show them which activities depend on having done which others already. Others like a paragraph of text, or a table.
I'm rambling a bit now, but I hope the point is clear: with a large amount of content to provide, you will be much more effective if you can guide your reader quickly to the information they need, without encumbering them with the information they don't. That may mean highlighting some of the content, or even presenting the same content in different ways for different people.
You just can't do that as effectively with plain text as you can with a more thoughtful visual design.
You're missing the point. A desktop app can do everything web forms can do. And what's more, it doesn't permanently erase your last half hour's work when you accidentally hit escape while reaching for your coffee, and it doesn't become completely unusable because someone knocked a cable out of the router downstairs.
I don't know why so many people around here are advocating web forms so much lately. I'm sure there are niches where they are useful, but for most tasks they're just inflexible, ugly imitations of real software. One of the ACs around here just claimed no-one has given a single reason a web-based solution wouldn't be superior. I've just given you several, and I'm still looking for a single reason why it would be.
There's a lot more to a program than the results it outputs.
On the contrary; for practical purposes, there's nothing more to a program than the results it outputs. This is exactly what makes the examples you gave of daft programs daft: they don't output anything.
They are called standards, and they already exist.
We've done this one before: obeying robots.txt is not guaranteed.
Not that it helps much anyway, if the personal information about you was put on the Internet without your consent by someone else. Yes, of course that someone is ultimately responsible, but it doesn't help the victim when "services" like Google and the Wayback Machine start propagating it all over the Internet.
I hope CNet do this to every major public figure who hasn't worked out yet that privacy matters, starting with all the politicians who haven't voted strongly for data protection legislation, the executives of every supermarket with a loyalty card scheme, and the executives of every company that holds credit card data for one second longer than they need to in order to process a transaction and guarantee it's genuine.
Maybe then enough powerful people will start to understand that in a free society, it is not appropriate to allow the collection of large amounts of personal information without a very good reason. If ever there were a textbook case where the good of society as a whole should be placed ahead an uncertain benefit to an organisation, this is probably it.
I'd love to help you out, but you haven't actually told us what you want improved in C++.
OK, I'll play. Aside from the obvious need to dramatically simplify all the obscure cases, the biggest missing functionality is to do with functions. Many standard library algorithms rely on using crude class-based techniques to perform manipulations that would be trivial in any functional language.
Sure, some very clever tricks have been identified by the Boost crowd, but they all have limitations somewhere. As much as I agree with the philosophy of putting most new developments in the library, some things simply need language support. It would be useful to provide things like first order functions and lambda expressions. Without them, half the C++ standard library isn't worth the paper it isn't printed on.
Functional programming greatly simplifies the task of the programmer by removing execution order from the things that programmers have to keep track of.
Unfortunately, in the real world, execution order is frequently more than an implementation detail. Any I/O with the outside world necessarily depends on side effects, and that means sequential processing. Efficient implementations of many computations require mutable variables and looping.
The curse of functional programming languages is that in order to get many useful things done, you must sacrifice some of the purity, but the moment you do that, you lose half the benefits of using a FPL in the first place. Lazy evaluation in particular conflicts violently with side effects.
Just as garbage collection in Java got rid of the need to recycle memory manually, so in Haskell the execution order is a matter for the compiler to optimise rather than for the programmer to worry about.
That comparison is more apt than you seem to realise. Java's garbage collection is viewed as some sort of panacea by naive programmers, who promptly make numerous basic errors with managing other resources because they expect the compiler to do everything for them. FPLs are viewed as some sort of panacea by naive programmers, who promptly produce code that performs abysmally and still has errors where side effects are involved, also because they expect the compiler to do everything for them.
Personally, I'm waiting for imperative languages to nick all the good stuff typically found in the FPL world -- higher order functions, closures, disjunctive types and pattern matching, mostly declarative programming style, strong type systems, etc. -- and integrate them cleanly into a framework that can do real work as well. I believe such languages will rapidly become popular, because they can be based on clean underlying models and syntax, and bring most of the power that FP fans enjoy without all the down sides. I'm sure these were due about 15 years ago, but for some reason we're still thinking C# and Ruby are wonderful new things.
But is it as easy to keep Windows patched as it is to keep Linux patched?
I dunno. Joe User on Windows can set a single switch in Control Panel (WinXP SP2 even warns you if this isn't done) and then the machine will download and install patches from MS automatically with no user intervention. Experienced users who want more control can customise this by flicking that switch to a different setting and explicitly approving download/install of individual patches. System admins can update business machines centrally if required.
I don't see how keeping Windows patched could be any easier.
Is it so hard to go find a tall building in downtown D.C. and bring a camera with a zoom?
Probably not, but I bet if you start pointing things at the White House from a nearby window, you can expect at least a visit from a nice USSS agent asking you stop.
There are schools in London that overlook Parliament, and all the windows on one side are kept shut. That's not a coincidence. And the US is far more obsessed with presidential security than the UK is about the security of Parliament.
We're not talking about all of them, we're talking about nested conditions, which are logically equivalent to n-d arrays.
Now you're the one oversimplifying. We are -- are at least I am -- talking about nested code generally. In the sort of function I'm working with, most of the levels of nesting are either loops, or alternating loop-test-loop-test. You cannot reduce this to a finite series of independent tests known at compile-time.
You're proving my point...half a dozen nested function calls is harder to understand. Obviously you haven't selected a transformation that makes the algorithm easier to understand.
I was actually arguing against splitting out the code into separate functions (which is the usual dogmatic response I get from people who think quicksort is a difficult algorithm when I tell them about our deeply nested algorithms), so we appear to agree on this point. What nesting-reducing transform do you suggest instead?
Its a lot easier to think about a sparse matrix holding conditions representing different parts of the solution space than it is to do six level nesting.
No, it really isn't. All you will get is a lot of additional indirections via some sparse matrix type, which will cripple your performance and degrade the readability of the code, without improving either the complexity of the logic required or the clarity of the implementation.
Trust me, this is what we do. The entire company is based on libraries that are effectively a bunch of neat graph-based algorithms that no-one else worked out how to write efficiently enough yet. I work with some very clever people: I have an undergrad degree in maths and postgrad CS, and I'm still the office junior in terms of formal qualifications. The top technical guys are invited speakers at conferences. You get the idea. If getting rid of a large family awkward functions that none of us particularly likes was as simple as changing a data structure, we'd have done it a decade ago.:-)
I'm not going to reply to all the follow-ups in this thread, since many say the same thing, but I'll address the points raised by one of the ACs here.
As much as you seem to think that sadaam is a fun-loving guy that should be invited to everyone's graduation party..he killed 100's of thousands more than the U.S. invasion. But protesters seem to always forget this part.
We forget no such thing. And we're not protesting about removing Saddam per se. We do not think he is a nice man, nor support nor condone his actions against people in his own country and elsewhere. Please understand this.
What we're protesting about is our country being led into war against the wishes of the people by politicians who deliberately lied to us. Tony's cronies weren't acting for the people they're supposed to represent when they took us to war.
Even the "He was a bad man and it was our duty to remove him!" plea is pretty wet. We left him alone for a decade despite his continuing poor behaviour, and we continue to leave alone and even maintain diplomatic relations with countries and administrations that have records at least equally bad.
Also, the U.S. still has him captured..in prison. If it were any other country in the world, he would have been dead before even entering our soil.
Sure, the US is the very heart and soul of human rights, particularly in its conduct of the Iraq war and its aftermath. There have been no instances of holding people for years under dubious conditions without applying due process, nor any confirmed allegations of abuses by US troops on the ground in Iraq, and in none of those allegations that have not been made did US troops verifiably execute defenceless Iraqis, resulting in no disciplinary actions against troops serving in Iraq becoming matters of public record.
Also, while we're having such fun with trolls, the US is not the biggest state sponsor of terrorism in the world, certainly not including effectively installing both Saddam and Osama in their positions of power or supporting other governments in Arab states that have very poor records on both human rights and harbouring terrorists, all in the interests of promoting US oil interests. The US is also quite right to worry about the WMDs that we knew all along probably didn't exist in Iraq, being the only nation in the world ever to have actually used WMDs resulting in the loss of huge numbers of civilian lives.
I hope one day that the terrorists come in and destroy both the U.S. and england...so then I can say: "I told you so".
I don't normally descend to swearing on Slashdot, but on behalf of two people dear to me who were sitting next to one of the bombs that went off on 7 July and aren't here to say it themselves: fuck you.
The intelligence analysts warned the government before the war that going into Iraq would increase the risk of terrorist attacks on the UK. They had Osama in Afghanistan, yet let him go to divert troops to Iraq. The Iraq war did nothing to prevent terrorism; on the contrary, it has been the biggest rallying call for anti-western extremists for many years. And what's worse, our government pretty much knew it would be, and they went ahead and did it anyway.
Two million people marched in London to protest against the Iraq war.
Approximately 78% of the electorate did not vote for Tony Blair's Labour party at the recent UK general election.
Our troops still went into Iraq, and Blair is still in power.
If the biggest mass protest in recent history couldn't avert a war that has killed thousands, it's not going to do much about some random Eurocrap. We need to do something more than bitch on Slashdot, but apparently marching isn't it.
Thank you for that lesson in Data Structures 101. Please now turn to chapter 2, where you will discover the concept of a graph, and the limitations that apply when you're working with them. Not every data structure is an n-dimensional array, and not all functions operating on data structures can be conveniently reduced the same way.
Our algorithms are simple, for what they have to do: essentially they perform complex matching of subgraphs, an area of continuing mathematical research where there are few "good" solutions. Separating out the inner part of such a loop, which makes no sense out of context and has no independent value, into another function, would split a coherent whole algorithm into parts scattered between separate places. This would make it harder to understand and more difficult to maintain and adapt.
I'd rather work with half a dozen nested loops that I can at least see on a single piece of paper than half a dozen nested function calls with the same complexity but less clarity.
Is it all about other tools?
on
Visual Studio Hacks
·
· Score: 3, Interesting
A book on Visual Studio hacks has a lot going for it, but the examples in the review mostly sound like discussion of add-in tools, rather than VS itself.
Many people don't take advantage of even simple things like customising autoexp.dat for debugging, and don't know about undocumented UI tweaks like displaying a marker line at column N. Many of these little touches are what makes VS better than the alternatives for a lot of jobs, and why Microsoft never makes more of them I don't understand. Are things like the two examples above covered in the book?
For making non-standards-compliant, non portable, code that wont work in 4 years.
Erm... We write highly portable libraries in C and C++ at work. They have to compile on Windows, Linux, Solaris, HP-UX, AIX, MacOS X, and often under several different toolsets on each OS.
Our whole dev team is free to develop using whatever software we find helpful. We have GUI guys and CLI guys, Windows guys and Linux guys, emacs guys and vi guys, etc.
The one thing almost everyone has in common is that they use Visual C++ as their primary IDE. That's not because we're ill-informed or haven't tried the alternatives, it's because most of us think it's the best IDE available to help us do our jobs.
First of all, a good dev is not necessarily faster than a bad one.
That's a matter of perspective. If a "good" dev produces work that does the same thing in the same amount of time as an "average" dev, why is he a good dev? (Obviously this has to hold in the long run, and not just at the time of first writing, and usually this is where the difference lies. Clean designs and good documentation practices usually exhibit their greatest benefits during maintenance.)
Second of all, if you're five levels deep in the nested function, that's a good indicator that you're not good enough at software design.
Or that your algorithm is inherently complicated. I work with deeply nested logic all the time, yet the project I work on is very successful, and the developer team here has a good reputation. People who assume we're not good at design because we don't agree with their dogma annoy me.
Is this a stupid or impractical way of doing things? What am I missing?
Not stupid, but naive. Waterfall models went out with the 1980s, because they didn't work.
If there's one great truth the software industry has (mostly) successfully learned in recent years, it is that successful projects must be adaptable, because requirements change. With the possible exception of things like military and medical projects, it's almost never helpful to fix absolute requirements up-front. Any project whose plan involves the words "finished before the first line of code is written" is pretty much doomed to failure before it even starts.
Yes, get user feedback early and often. Yes, get someone who understands UI design to do the UI design, and have someone whose role is to co-ordinate the customer view and the developer view of the project. Yes, give the programmers a clear idea of what you want and letting them get on with providing it. These are all good things.
But you have to do them more than once. Whatever process you use, whether you prefer lightweight or very formal, it needs to be iterative and go in cycles. Unless you're prepared to increase your overheads by at least an order of magnitude, nothing else works.
But programming is supposed to be a science and a process.
Says who?
An engineering approach with good processes is certainly an advantage, but there are an awful lot of successful software companies who emphasise getting good people and doing everything they can to facilitate those people doing a good job, and an awful lot of not particularly successful software companies who emphasise heavyweight procedures and doing things "properly" at the expense of getting the best out of their people.
The point is that you are better off gaining insights from somebody who is more recognized by the developer community.
Why? What's wrong with reading someone's opinion, evaluating it critically in light of your own experience and your other reading, and drawing what insights and ideas you can from it? It's like no-one's got a degree any more.:-(
Personally, I find a lot of the most thought-provoking articles I read aren't by big names. Big names can rely on having a big name, and the kind of sheep you're talking about when you say "developer community" will believe anything they say. It's the guys behind the big names who have to convince people using old-fashioned techniques like presenting facts and making logical arguments.
I guess the main drawback of this is that most good programmers are often terrible teachers, but that might reflect the lack of a tradition in the field.
Something I've found in many aspects of life is that the people who are really good at something tend to be able to explain it, clearly and accurately, to someone less experienced. This is true of almost any field I've ever studied, from mathematics to martial arts, from driving to dancing.
It's interesting that in Japanese, there is little distinction between being very good/experienced at something, and being a teacher of it. If someone in Japan asks you whether you teach programming, and you're the 20 year veteran Senior Software Engineer at your company, the answer is yes even if you don't teach in the English sense. It's simply implicit that by being good at something, you will be teaching those around you as you do it.
I think the difference between someone who's really good at something and someone who's just OK usually comes down to a depth of understanding. One can follow a cookbook of techniques, or regurgitate information they've been fed in the past. The other writes the cookbook, because they've understood the information and worked out how it all fits together.
A corollary of this is that those who truly understand a subject tend to be better able to convey their understanding to others. Because they can see it from more than one point of view, they can adapt their explanation and examples to fit the knowledge and learning preferences of the person they're trying to teach. Those who never reach that level of understanding can repeat what they were told when they were learning themselves, perhaps even in multiple ways they learned from multiple sources, but they can't adapt it, can't see it from different perspectives and present it in different and original lights.
Thus I'm rather surprised that you think most good programmers are terrible teachers. Most programmers may be terrible teachers, but I question whether a good programmer who is unable to pass on that knowledge is really that good at all. It's unwise to generalise completely, because of course teaching requires skills all of its own, but I've met very few great practitioners in any field who weren't also outstanding teachers.
you want a point made, line the pockets of the politicians you voted into office.
I didn't vote them into office. In fact, only 22% of the voting population in the UK did, and in my country (England) they weren't even the majority party, all of which tells you something about how flawed our voting system is.
As for the US, we don't get to vote on the politicians there at all, unfortunately, or Kerry would have won a landslide.:-(
No, I'm not really going to use the overhyped T word for something as petty as business, but you get the point. Denmark and Poland represent a potential market of millions of people. If some megacorp wants to storm off and sulk about the business regs there, I'm betting there'll be plenty of home-grown, small, innovative companies willing to support the market in their place, meeting their requirements under business regs and probably doing a lot more for the local economy as well.
The correct response from both the Danish and Polish governments was, "Bye, then."
I agree with many of your points about Lisp, and the fact that these can be advantages. However, there is also an argument that having a very generalised core and almost inventing mini-languages using macros for every little thing makes code hard to find your way around at first.
Just as C projects rightly get attacked for needing UGLY_PROJECT_SPECIFIC_MACROS everywhere, and Perl takes flak for being able to write the same logic half a dozen different ways, and C++ takes flak for all the implicit behaviours it can hide, so Lisp takes flak for defining its own mini-languages all the time. In all of these cases, the power provided by the feature is useful to a good programmer, and won't unduly compromise readability and maintainability when used skilfully. Also in all of these cases, the power and flexibility result in dreadful code when used by less skilled programers, getting the feature a bad name.
Since, in the real world, a lot of programmers aren't great, there's some justification for that criticism in each case. But, in each case the negatives must be balanced against the need to provide real tools for real programmers. Personally, I'd much rather have a language like C++ or Perl or Lisp, where the developer has options available if they're needed, but then I'm also the kind of programmer who will make the effort to learn how to use each feature properly and how they interact before diving in. I get the feeling most programmers aren't.
It sounds like you have a lot better luck with "Go to definition" in VS.NET than I do. With the large C# projects I work on, it very rarely works.
FWIW, it's generally pretty good for C++. The only annoying bug I hit regularly is that sometimes it fails to parse what's under the cursor correctly, and offers you the wrong choices in the dialog; this can be avoided by highlighting the name you're searching on first.
As far Find References, I've just trawled through VS.NET 2003's menus and I think I've found it - is it the "Edit -> Find and Replace -> Find Symbol" option? I'll admit I hadn't seen that before. Thanks for pointing it out. Even though I prefer the way Eclipse does it (finding uses of that particular identifier, rather than any identifier with the same name) it's now not a big enough issue to get on the list, as it were:)
Yes, that's the one. The feature is context-sensitive, too: if you use the same label for multiple things, you should get a dialog box asking which one you want references for, and then only see references to that version of the label afterwards.
Oh, I forgot to mention something else which VS 2005 really should have pinched from Eclipse - the idea of combining class view and solution explorer.
I think quite a few of the... erm, sub-optimal... UI decisions in Visual Studio since 2002 have been driven by the need to support multiple languages. For example, as I mentioned earlier in the thread, they dropped the browse toolbar that worked so well in VC++ 6 during the move to Everything.Net, apparently because they couldn't yet support the equivalent functionality in VB or C#. I'm guessing the whole Solution Explorer thing is similar: since you have more than just classes in C++, you can't easily tie the UI to a fundamentally class-based design such as you mention to support C# better, say.
IMHO, this points to an unfortunate design decision that needs to be reversed. Not all languages work the same way, so not all IDEs should provide the same tools to view and manipulate code. I think the whole "making it all work the same way" approach has gone a bit too far now.
Slashdot Mirror
OK, I'm also your typical Slashdotter, about 30 and a professional programmer. I also have a strong interest in design and presentation skills, and currently produce the publicity materials for a large, local not-for-profit organisation. Some of that is external, but a lot of it is just keeping a few thousand members of our club informed about which of the 50+ hours of activities we're organising this week they might be interested in.
None of this information can't be represented with ASCII text in Notepad either. I know: we send out plain text e-mails as part of our publicity. However, we also provide a web site, and printed matter, each of which is carefully designed to convey the content as efficiently, accurately and accessibly as possible.
We've been doing this for quite a while now (think decades) and we've collected a lot of feedback about the results you get via different media and different approaches to the presentation. The one thing that is absolutely clear, above all else, is that presentation matters.
If we provide a conveniently scannable diary of the current season's events, attendance at those events will go up. If an event is inadvertently missed off the scannable diary, even though all the details are present on a page of its own elsewhere, attendance will be poor.
If changes are made at short notice (same day) then a separate e-mail to all members is justified to highlight the surprise. But if you send a separate e-mail for every notice rather than combining the general reminders into a weekly digest, people start sending (usually polite) replies asking for a lower volume of mail.
If key information about activities we're trying to highlight is placed early in our brochure for the season and on the front page of the web site, the details will still get through, even if most of them are hidden in a box on page 15. But if you put too much in big letters and pretty colours, people stop reading, because they can't prioritise and then scan what's really important to them.
This is made even more challenging because different people have different interests, and consider different information more important. You have to make sure each interest group can find what they're looking for, without blinding them with what the guy next door wants to see.
Different people also process information different ways. Some people like a flow diagram to show them which activities depend on having done which others already. Others like a paragraph of text, or a table.
I'm rambling a bit now, but I hope the point is clear: with a large amount of content to provide, you will be much more effective if you can guide your reader quickly to the information they need, without encumbering them with the information they don't. That may mean highlighting some of the content, or even presenting the same content in different ways for different people.
You just can't do that as effectively with plain text as you can with a more thoughtful visual design.
You're missing the point. A desktop app can do everything web forms can do. And what's more, it doesn't permanently erase your last half hour's work when you accidentally hit escape while reaching for your coffee, and it doesn't become completely unusable because someone knocked a cable out of the router downstairs.
I don't know why so many people around here are advocating web forms so much lately. I'm sure there are niches where they are useful, but for most tasks they're just inflexible, ugly imitations of real software. One of the ACs around here just claimed no-one has given a single reason a web-based solution wouldn't be superior. I've just given you several, and I'm still looking for a single reason why it would be.
On the contrary; for practical purposes, there's nothing more to a program than the results it outputs. This is exactly what makes the examples you gave of daft programs daft: they don't output anything.
We've done this one before: obeying robots.txt is not guaranteed.
Not that it helps much anyway, if the personal information about you was put on the Internet without your consent by someone else. Yes, of course that someone is ultimately responsible, but it doesn't help the victim when "services" like Google and the Wayback Machine start propagating it all over the Internet.
I hope CNet do this to every major public figure who hasn't worked out yet that privacy matters, starting with all the politicians who haven't voted strongly for data protection legislation, the executives of every supermarket with a loyalty card scheme, and the executives of every company that holds credit card data for one second longer than they need to in order to process a transaction and guarantee it's genuine.
Maybe then enough powerful people will start to understand that in a free society, it is not appropriate to allow the collection of large amounts of personal information without a very good reason. If ever there were a textbook case where the good of society as a whole should be placed ahead an uncertain benefit to an organisation, this is probably it.
OK, I'll play. Aside from the obvious need to dramatically simplify all the obscure cases, the biggest missing functionality is to do with functions. Many standard library algorithms rely on using crude class-based techniques to perform manipulations that would be trivial in any functional language.
Sure, some very clever tricks have been identified by the Boost crowd, but they all have limitations somewhere. As much as I agree with the philosophy of putting most new developments in the library, some things simply need language support. It would be useful to provide things like first order functions and lambda expressions. Without them, half the C++ standard library isn't worth the paper it isn't printed on.
Unfortunately, in the real world, execution order is frequently more than an implementation detail. Any I/O with the outside world necessarily depends on side effects, and that means sequential processing. Efficient implementations of many computations require mutable variables and looping.
The curse of functional programming languages is that in order to get many useful things done, you must sacrifice some of the purity, but the moment you do that, you lose half the benefits of using a FPL in the first place. Lazy evaluation in particular conflicts violently with side effects.
That comparison is more apt than you seem to realise. Java's garbage collection is viewed as some sort of panacea by naive programmers, who promptly make numerous basic errors with managing other resources because they expect the compiler to do everything for them. FPLs are viewed as some sort of panacea by naive programmers, who promptly produce code that performs abysmally and still has errors where side effects are involved, also because they expect the compiler to do everything for them.
Personally, I'm waiting for imperative languages to nick all the good stuff typically found in the FPL world -- higher order functions, closures, disjunctive types and pattern matching, mostly declarative programming style, strong type systems, etc. -- and integrate them cleanly into a framework that can do real work as well. I believe such languages will rapidly become popular, because they can be based on clean underlying models and syntax, and bring most of the power that FP fans enjoy without all the down sides. I'm sure these were due about 15 years ago, but for some reason we're still thinking C# and Ruby are wonderful new things.
I dunno. Joe User on Windows can set a single switch in Control Panel (WinXP SP2 even warns you if this isn't done) and then the machine will download and install patches from MS automatically with no user intervention. Experienced users who want more control can customise this by flicking that switch to a different setting and explicitly approving download/install of individual patches. System admins can update business machines centrally if required.
I don't see how keeping Windows patched could be any easier.
Probably not, but I bet if you start pointing things at the White House from a nearby window, you can expect at least a visit from a nice USSS agent asking you stop.
There are schools in London that overlook Parliament, and all the windows on one side are kept shut. That's not a coincidence. And the US is far more obsessed with presidential security than the UK is about the security of Parliament.
Now you're the one oversimplifying. We are -- are at least I am -- talking about nested code generally. In the sort of function I'm working with, most of the levels of nesting are either loops, or alternating loop-test-loop-test. You cannot reduce this to a finite series of independent tests known at compile-time.
I was actually arguing against splitting out the code into separate functions (which is the usual dogmatic response I get from people who think quicksort is a difficult algorithm when I tell them about our deeply nested algorithms), so we appear to agree on this point. What nesting-reducing transform do you suggest instead?
No, it really isn't. All you will get is a lot of additional indirections via some sparse matrix type, which will cripple your performance and degrade the readability of the code, without improving either the complexity of the logic required or the clarity of the implementation.
Trust me, this is what we do. The entire company is based on libraries that are effectively a bunch of neat graph-based algorithms that no-one else worked out how to write efficiently enough yet. I work with some very clever people: I have an undergrad degree in maths and postgrad CS, and I'm still the office junior in terms of formal qualifications. The top technical guys are invited speakers at conferences. You get the idea. If getting rid of a large family awkward functions that none of us particularly likes was as simple as changing a data structure, we'd have done it a decade ago. :-)
I'm not going to reply to all the follow-ups in this thread, since many say the same thing, but I'll address the points raised by one of the ACs here.
We forget no such thing. And we're not protesting about removing Saddam per se. We do not think he is a nice man, nor support nor condone his actions against people in his own country and elsewhere. Please understand this.
What we're protesting about is our country being led into war against the wishes of the people by politicians who deliberately lied to us. Tony's cronies weren't acting for the people they're supposed to represent when they took us to war.
Even the "He was a bad man and it was our duty to remove him!" plea is pretty wet. We left him alone for a decade despite his continuing poor behaviour, and we continue to leave alone and even maintain diplomatic relations with countries and administrations that have records at least equally bad.
Sure, the US is the very heart and soul of human rights, particularly in its conduct of the Iraq war and its aftermath. There have been no instances of holding people for years under dubious conditions without applying due process, nor any confirmed allegations of abuses by US troops on the ground in Iraq, and in none of those allegations that have not been made did US troops verifiably execute defenceless Iraqis, resulting in no disciplinary actions against troops serving in Iraq becoming matters of public record.
Also, while we're having such fun with trolls, the US is not the biggest state sponsor of terrorism in the world, certainly not including effectively installing both Saddam and Osama in their positions of power or supporting other governments in Arab states that have very poor records on both human rights and harbouring terrorists, all in the interests of promoting US oil interests. The US is also quite right to worry about the WMDs that we knew all along probably didn't exist in Iraq, being the only nation in the world ever to have actually used WMDs resulting in the loss of huge numbers of civilian lives.
I don't normally descend to swearing on Slashdot, but on behalf of two people dear to me who were sitting next to one of the bombs that went off on 7 July and aren't here to say it themselves: fuck you.
The intelligence analysts warned the government before the war that going into Iraq would increase the risk of terrorist attacks on the UK. They had Osama in Afghanistan, yet let him go to divert troops to Iraq. The Iraq war did nothing to prevent terrorism; on the contrary, it has been the biggest rallying call for anti-western extremists for many years. And what's worse, our government pretty much knew it would be, and they went ahead and did it anyway.
Two million people marched in London to protest against the Iraq war.
Approximately 78% of the electorate did not vote for Tony Blair's Labour party at the recent UK general election.
Our troops still went into Iraq, and Blair is still in power.
If the biggest mass protest in recent history couldn't avert a war that has killed thousands, it's not going to do much about some random Eurocrap. We need to do something more than bitch on Slashdot, but apparently marching isn't it.
Thank you for that lesson in Data Structures 101. Please now turn to chapter 2, where you will discover the concept of a graph, and the limitations that apply when you're working with them. Not every data structure is an n-dimensional array, and not all functions operating on data structures can be conveniently reduced the same way.
Our algorithms are simple, for what they have to do: essentially they perform complex matching of subgraphs, an area of continuing mathematical research where there are few "good" solutions. Separating out the inner part of such a loop, which makes no sense out of context and has no independent value, into another function, would split a coherent whole algorithm into parts scattered between separate places. This would make it harder to understand and more difficult to maintain and adapt.
I'd rather work with half a dozen nested loops that I can at least see on a single piece of paper than half a dozen nested function calls with the same complexity but less clarity.
A book on Visual Studio hacks has a lot going for it, but the examples in the review mostly sound like discussion of add-in tools, rather than VS itself.
Many people don't take advantage of even simple things like customising autoexp.dat for debugging, and don't know about undocumented UI tweaks like displaying a marker line at column N. Many of these little touches are what makes VS better than the alternatives for a lot of jobs, and why Microsoft never makes more of them I don't understand. Are things like the two examples above covered in the book?
Erm... We write highly portable libraries in C and C++ at work. They have to compile on Windows, Linux, Solaris, HP-UX, AIX, MacOS X, and often under several different toolsets on each OS.
Our whole dev team is free to develop using whatever software we find helpful. We have GUI guys and CLI guys, Windows guys and Linux guys, emacs guys and vi guys, etc.
The one thing almost everyone has in common is that they use Visual C++ as their primary IDE. That's not because we're ill-informed or haven't tried the alternatives, it's because most of us think it's the best IDE available to help us do our jobs.
That's a matter of perspective. If a "good" dev produces work that does the same thing in the same amount of time as an "average" dev, why is he a good dev? (Obviously this has to hold in the long run, and not just at the time of first writing, and usually this is where the difference lies. Clean designs and good documentation practices usually exhibit their greatest benefits during maintenance.)
Or that your algorithm is inherently complicated. I work with deeply nested logic all the time, yet the project I work on is very successful, and the developer team here has a good reputation. People who assume we're not good at design because we don't agree with their dogma annoy me.
Not stupid, but naive. Waterfall models went out with the 1980s, because they didn't work.
If there's one great truth the software industry has (mostly) successfully learned in recent years, it is that successful projects must be adaptable, because requirements change. With the possible exception of things like military and medical projects, it's almost never helpful to fix absolute requirements up-front. Any project whose plan involves the words "finished before the first line of code is written" is pretty much doomed to failure before it even starts.
Yes, get user feedback early and often. Yes, get someone who understands UI design to do the UI design, and have someone whose role is to co-ordinate the customer view and the developer view of the project. Yes, give the programmers a clear idea of what you want and letting them get on with providing it. These are all good things.
But you have to do them more than once. Whatever process you use, whether you prefer lightweight or very formal, it needs to be iterative and go in cycles. Unless you're prepared to increase your overheads by at least an order of magnitude, nothing else works.
Why not?
(I hope you're not about to argue incorrectly that it must be LZW...)
Says who?
An engineering approach with good processes is certainly an advantage, but there are an awful lot of successful software companies who emphasise getting good people and doing everything they can to facilitate those people doing a good job, and an awful lot of not particularly successful software companies who emphasise heavyweight procedures and doing things "properly" at the expense of getting the best out of their people.
Blockquoth the AC:
Why? What's wrong with reading someone's opinion, evaluating it critically in light of your own experience and your other reading, and drawing what insights and ideas you can from it? It's like no-one's got a degree any more. :-(
Personally, I find a lot of the most thought-provoking articles I read aren't by big names. Big names can rely on having a big name, and the kind of sheep you're talking about when you say "developer community" will believe anything they say. It's the guys behind the big names who have to convince people using old-fashioned techniques like presenting facts and making logical arguments.
This was an interesting observation:
Something I've found in many aspects of life is that the people who are really good at something tend to be able to explain it, clearly and accurately, to someone less experienced. This is true of almost any field I've ever studied, from mathematics to martial arts, from driving to dancing.
It's interesting that in Japanese, there is little distinction between being very good/experienced at something, and being a teacher of it. If someone in Japan asks you whether you teach programming, and you're the 20 year veteran Senior Software Engineer at your company, the answer is yes even if you don't teach in the English sense. It's simply implicit that by being good at something, you will be teaching those around you as you do it.
I think the difference between someone who's really good at something and someone who's just OK usually comes down to a depth of understanding. One can follow a cookbook of techniques, or regurgitate information they've been fed in the past. The other writes the cookbook, because they've understood the information and worked out how it all fits together.
A corollary of this is that those who truly understand a subject tend to be better able to convey their understanding to others. Because they can see it from more than one point of view, they can adapt their explanation and examples to fit the knowledge and learning preferences of the person they're trying to teach. Those who never reach that level of understanding can repeat what they were told when they were learning themselves, perhaps even in multiple ways they learned from multiple sources, but they can't adapt it, can't see it from different perspectives and present it in different and original lights.
Thus I'm rather surprised that you think most good programmers are terrible teachers. Most programmers may be terrible teachers, but I question whether a good programmer who is unable to pass on that knowledge is really that good at all. It's unwise to generalise completely, because of course teaching requires skills all of its own, but I've met very few great practitioners in any field who weren't also outstanding teachers.
I didn't vote them into office. In fact, only 22% of the voting population in the UK did, and in my country (England) they weren't even the majority party, all of which tells you something about how flawed our voting system is.
As for the US, we don't get to vote on the politicians there at all, unfortunately, or Kerry would have won a landslide. :-(
No, I'm not really going to use the overhyped T word for something as petty as business, but you get the point. Denmark and Poland represent a potential market of millions of people. If some megacorp wants to storm off and sulk about the business regs there, I'm betting there'll be plenty of home-grown, small, innovative companies willing to support the market in their place, meeting their requirements under business regs and probably doing a lot more for the local economy as well.
The correct response from both the Danish and Polish governments was, "Bye, then."
I agree with many of your points about Lisp, and the fact that these can be advantages. However, there is also an argument that having a very generalised core and almost inventing mini-languages using macros for every little thing makes code hard to find your way around at first.
Just as C projects rightly get attacked for needing UGLY_PROJECT_SPECIFIC_MACROS everywhere, and Perl takes flak for being able to write the same logic half a dozen different ways, and C++ takes flak for all the implicit behaviours it can hide, so Lisp takes flak for defining its own mini-languages all the time. In all of these cases, the power provided by the feature is useful to a good programmer, and won't unduly compromise readability and maintainability when used skilfully. Also in all of these cases, the power and flexibility result in dreadful code when used by less skilled programers, getting the feature a bad name.
Since, in the real world, a lot of programmers aren't great, there's some justification for that criticism in each case. But, in each case the negatives must be balanced against the need to provide real tools for real programmers. Personally, I'd much rather have a language like C++ or Perl or Lisp, where the developer has options available if they're needed, but then I'm also the kind of programmer who will make the effort to learn how to use each feature properly and how they interact before diving in. I get the feeling most programmers aren't.
FWIW, it's generally pretty good for C++. The only annoying bug I hit regularly is that sometimes it fails to parse what's under the cursor correctly, and offers you the wrong choices in the dialog; this can be avoided by highlighting the name you're searching on first.
Yes, that's the one. The feature is context-sensitive, too: if you use the same label for multiple things, you should get a dialog box asking which one you want references for, and then only see references to that version of the label afterwards.
I think quite a few of the... erm, sub-optimal... UI decisions in Visual Studio since 2002 have been driven by the need to support multiple languages. For example, as I mentioned earlier in the thread, they dropped the browse toolbar that worked so well in VC++ 6 during the move to Everything.Net, apparently because they couldn't yet support the equivalent functionality in VB or C#. I'm guessing the whole Solution Explorer thing is similar: since you have more than just classes in C++, you can't easily tie the UI to a fundamentally class-based design such as you mention to support C# better, say.
IMHO, this points to an unfortunate design decision that needs to be reversed. Not all languages work the same way, so not all IDEs should provide the same tools to view and manipulate code. I think the whole "making it all work the same way" approach has gone a bit too far now.