答:
There are two approaches to development:

Get the tool, then built something with it

Have an idea, want to build something, so, find an appropriate tool

The first approach is much less constructive and productive than the second one. In the first method, you simply wander the web world, surfing web pages one after the other, till you find an open source project (for example Joomal), then you decide to build a website with it. Not really good, if you're a game developer for example, or if you're interested in jQuery development.

Thus, I strongly suggest you first specify what do you want to do. Do you want to become JavaScript developer? An iOS developer? A project manager? What do you want to do?

With all the options and project available, especially the size of
  most of them, Open Source can be pretty daunting for a newbie to it
  all.

Of course, it would be daunting. Because you haven't filtered it yet. You first should specify what you want to do. Then you see that it's becoming narrower and narrower, till you only have 2 or 3 open source solutions at hand, and here, you're fine to go.


问:
What is the biggest support a boss can give to his/her developers?
Buying the best hardware, paying the most precious bonus or reward, treating them politely, provide the opportunity for improvement, etc.?

We want to improve the productivity of our development team. We want to see what can be regarded the biggest support (or generally a good support), so we can start from there.

答:
Money has been proven not to be a strong motivator, though too little money is a strong demotivator. Pay enough to take money off the table as an issue. Any more won't help, in fact it may hurt.

This video suggests that the most powerful motivator is autonomy and I have found that to be true. However, you can go too far. Developers like their code to be perfect and if you give them room to make it such, there will be a cost in terms of getting stuff done.

Peopleware is about one-third dedicated to the environment that "thought-workers" spend their day in, for good reason. Lots of natural light, lots of space, lots of freedom to arrange things the way they want. However, it does focus very strongly on silence and I think you can go too far with that too. As Uncle Bob says in Agile Software Development, Principles, Patterns, and Practices, an Agile team is vibrant and communicative. My theory is that, within sensible limits, a constant noise is fine; it's sudden noises that drag people out of the zone.

Two things that I've found to be very powerful motivators in my own experience are good tools and good teammates.

Anything which slows people down is a demotivator. Roy Osherove of 5whys talks a lot about this and suggests that every team leader should see their only role as "Bottleneck Ninja".

And developers love to learn, preferably from each other, preferably all day long. If you can get a team of good solid developers and put them in a room together, they'll do a lot of the motivating themselves.

Finally, respect. There is little more important to geeks. Understand that you are dealing with intelligent people and act accordingly. Don't force them into asinine team-building sessions and company picnics. Just treat them with respect, put the job in front of them and (as much as possible) let them go at it. Ask for visibility, by all means, but do not micromanage.

ContentLicense: CC BY-SA 3.0


问:
How to retain student/intern programmers?
We have a small team in our department and typically employ 1-3 students/interns.  The problem we have is retention.  We like to hire a student that will stick around as part of the team for more than just a summer quarter.  The problem is though the last 4 students we hired, up front we discussed this with them and they all ended up leaving earlier than we would have liked.

The relationships all ended in a good fashion, the students either obtained teaching assistant or research positions within the university, or went on to bigger and better things.  This is all understandable and we do not hold it against them for doing what is best for them.

But my perspective is different as I worked within our department for 2 years during undergraduate at which point I was brought on full time upon graduation.

How can we retain students?  We give them hardware they need/want, we provide them with problems to solve in anyway they see fit (within reason).  All in all to me this type of job for a student programmer is so flexible and awesome I cannot see how anyone would want to leave.

Thoughts ?

答:
I'm currently working at a web development company part time while going to university.

  Although I enjoy that it keeps me afloat while paying for school I don't think I would stick around for long after graduating.  The main reason is that with a CIS Degree under my belt I would suddenly be worth a fair bit more than just a 'student'.  So changing jobs is a good way to get a signifigant pay raise, likely more than what I would get if I just ask for a raise.   Plus I kind of tired of maintaining code from other past students who sometimes do wierd things.

I want try new things and see what interesting things I can do.  Doing the same thing after university that you were doing before kind of defies the point of university, which is to change who you are.

ContentLicense: CC BY-SA 2.5


问:
How much should Developers interact with Clients?
A philosophical discussion has come up in my department that I'd like p.se's opinion on. We're a 6 person development department inside a 60 person IT shop. All other departments are growing FAST, and ours has been the same size (and not fully booked at that size) for a few years.

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey. (My words, not his.)

His boss, the owner of the company, told him this morning that every single person in the company needs to think of themselves as an extension of the sales department, and needs to be listening all the time for upsell opportunities. To this end, he thinks clients ought to have more or less full access to developers directly, in part so that devs have the opportunity to hear sales opportunities.

I'm somewhere in the middle, myself. I think it's nice to shield devs from clients to some extent, but in practice that will never be total. And yes, every single job in the company includes sales, but that doesn't necessarily mean that everyone has the same opportunity for it.

EDIT: We're not an agile shop. Some of us (cough) would like to head that direction, but for now assume this is a traditional fixed-bid-contract shop.

EDIT2: The autism joke wasn't funny. Got it. Entirely possible that autism jokes never are. That said: there are developers who have a capacity to represent themselves and their employers well and developers who don't (currently) have that capacity. My manager has a real concern about how the company would be represented if all developers were structurally empowered to be company representatives.

It's also getting increasingly clear from reading your responses that the real push-and-pull here is between waterfall and agile.

答:
It sounds as if your PM is a fan of the waterfall-process while you're more in the "agile" development camp.

I'm not sure if there's a right and a wrong side here, but I definitely like the "agile" side better. I talk to users at least once a week, look at what they're doing, listen to their problems. If it's something the service department can handle, I'll tell them, but often enough I see a real usability problem or a missing feature that would probably never have reached me had communication went through multiple filters of service/sales/project management.

I did work at companies where developers were shielded from clients. The result was that developers delivered software that met the letters of the contracts, but wasn't always useful. Worse, developers took pride in things that had no business value. (Who needs great keyboard navigation on a system with a touchscreen and no keyboard? Who needs scripting functionality, if the users of the software don't have the background or the time or the need to use scripting?) The implicit, unwritten goals of the development team were never "in sync" with what the users actually needed. And unless your "developers" are just code monkeys who aren't allowed to make any decisions, this leads to lots wasted developer time.


问:
Is Groovy going away?
I am sure this question has been asked many times. However, I like to ask it again with the intention of what is the future of these languages.

I was first introduced to Groovy and really liked it. I felt the syntax was simpler and it was much closer to Java and I was able to quickly learn Grails.

Then there was Scala, and the web frame work Lift. I am still learning Scala and I find the syntax very difficult at times.

However, I still wonder what is the future of Groovy. When the author of Groovy says he would have never created groovy if he knew about Scala, then it makes me wonder if there is a future at all. Of course Groovy has came a long way and Grails is used today by many large companies.

If one was to look at Grails vs Lift today, then Grails would be clear winner. More companies are using it.  But given everything I have said so far, I am interested to know if one should invest in Groovy? Is Groovy going away and Scala the better choice? If the CEO of BMW says he drives a Mercedes then one would wonder why shouldn't we all drive Mercedes too, right?

(I understand if this question is really broad and might be closed. I hope to make it an open Wiki for others though.)

答:
As well as @The Legend of 1982's comments:

Groovy will continue to stick around as it's the dynamic alternative to Java with syntax that is close enough to Java to allow many developers to make the switch (or at least dabble in it).

Grails is constantly in the top 2 frameworks whenever Matt Raible does his massive JVM language web framework comparison charts/analysis.  His is probably the most complete analysis out there.

GPars is a new concurrency lib/API which brings Groovy very much up Scala's capabilities there.

The issue with speed will improve over time as Groovy figures out how to use invokedynamic and other compiler tricks.

Title: Is Groovy going away?


问:
How can a borderline beginner jump into open source?
With all the options and project available, especially the size of most of them, Open Source can be pretty daunting for a newbie to it all. My question is, how can I start helping and learning from open sourced software? Where do I start? Which files do I read first? Any advice to help a programmer above beginner level start contributing? </p>

答:
I think the most important thing is to find a project you are passionate about then start learning everything you can about it.

Subscribing to all the mailing lists will give you a good idea about how the community interacts with each other and don't be afraid to jump in and ask or answer questions. Just make sure you do your research and ask intelligent well thought out questions.

How to contribute:

Help other users on support forums

Find and report bugs

Write or update documentation

Submit a patch

Test beta versions and early releases (again report bugs)

Develop a plugin

Note: The above links all pertain to the WordPress open source project but could apply to just about any large open source software project.


答:
My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey. (My words, not his.)

That he holds this opinion is not because he's old school mainframe, and your comments about your fellow coders lack respect in my view.

That being said, there are various schools of thought in terms of service management regarding who should be dealing with the users/business layers and they are not necessarily dependent on what culture your management comes from but what was in fashion the last time you had business consultants in.

Your owner's position is untenable because it will almost certainly cause serious project scope screep the more you allow developers to sell features to users without going through some sort of prioritisation process. I'm not really in favour of it. What you probably do need is some layer - not necessarily the project manager - but like a business account manager whom you can go to suggest features that can be sold on to your users or customers if they are practical, and someone whom you can also go to if you need input from the users.

Title: How much should Developers interact with Clients?

Body:
A philosophical discussion has come up in my department that I'd like p.se's opinion on. We're a 6 person development department inside a 60 person IT shop. All other departments are growing FAST, and ours has been the same size (and not fully booked at that size) for a few years.

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey. (My words, not his.)

His boss, the owner of the company, told him this morning that every single person in the company needs to think of themselves as an extension of the sales department, and needs to be listening all the time for upsell opportunities. To this end, he thinks clients ought to have more or less full access to developers directly, in part so that devs have the opportunity to hear sales opportunities.

I'm somewhere in the middle, myself. I think it's nice to shield devs from clients to some extent, but in practice that will never be total. And yes, every single job in the company includes sales, but that doesn't necessarily mean that everyone has the same opportunity for it.

EDIT: We're not an agile shop. Some of us (cough) would like to head that direction, but for now assume this is a traditional fixed-bid-contract shop.

EDIT2: The autism joke wasn't funny. Got it. Entirely possible that autism jokes never are. That said: there are developers who have a capacity to represent themselves and their employers well and developers who don't (currently) have that capacity. My manager has a real concern about how the company would be represented if all developers were structurally empowered to be company representatives.

It's also getting increasingly clear from reading your responses that the real push-and-pull here is between waterfall and agile.


问:
Why is Objective-C not widely used beyond Cocoa environments?
Objective-C features nice object orientation, simplicity, elegance, and (as a superset of C), low level ability. It could seem like the simple, modern alternative to C++ that many people look for and try to find in Go. But it is just used at Cocoa and post-NextSTEP environments, and even in this case is seen more as a burden for historical reasons than as an optimal choice.

Why it's not more widely used then? What are its problems?

答:
IMO, the problem with Objective-C isn't so much massive shortcomings, as minor shortcomings (especially early on) and lack of perceived advantages.

Objective-C was a pure superset of C, so C code could transition to Objective-C easily. The mindset to use Objective-C, however, differed from the C mindset a lot. The transition from C to Objective-C is easy for code but not easy at all for many programmers. A C programmer can't easily just pick a few new convenience features in Objective-C and get better productivity almost immediately -- he needs to learn a lot of new "stuff" before he can get anywhere at all.

C++ made the transition for some code a little more difficult, but the transition for most programmers much easier. C programmers who are accustomed to dealing with every detail of their code could still do so in C++ to exactly the extent they wanted. C++ also made it easy to use some new features (e.g., adding a ctor to automatically initialize members of your struct) without really changing your way of thinking. A lot of OO purists pushed radical changes in thinking, but lots of C programmers switched to C++ without doing anything of the sort (at least right away -- and often ever, from the looks of things).

C++ also looked much more familiar to most C programmers. It added a few new keywords, but (especially early on) the code still mostly looked fairly familiar. Despite its "pure superset" status, most Objective-C code looks fairly foreign to most C programmers. A lot of C++ is also fairly easy to explain and understand in terms of how things work in C. Switching to Objective-C has a lot more places that about all you can say is "just trust me and forget everything you think you know."

Many of the design decisions in Objective-C also made it (somewhat) slower than C++, especially on relatively old machines with slow processors, limited memory, etc. Rightly or wrongly, it was also seen largely as a single-company product, where C++ was freely available for anybody and everybody to implement.

These all led to C++ being adopted quickly enough early on that it achieved "critical mass" fairly quickly, so (among other things) it became the obvious choice for a lot of projects just because it was already a widely-used, well-known quantity.

Objective-C has never reached that point. In fact, it was well on its way toward fading into obscurity when Apple revived it by nearly forcing it on anybody who wanted to develop for their systems. Apple's market share isn't large enough for that to really give it critical mass either though -- just a larger niche. It's a "default" choice only where/because Apple makes it so.

I'd also add that at least in my opinion, Objective-C's Smalltalk-like object model means that in effect it's much more a direct competitor to Java than C++. Yes, it still has the C underpinnings, and yes you can still write low-level code without using a separate language -- but pure C and real Objective-C are enough different that it's less like a single language than two completely different languages that happen to both be handled by a single compiler (though it is handy that the two can talk to each other without something like JNI to join them).


问:
Advantages of a left to right language syntax
I've been watching an interview with Herb Sutter on Channel9 and he mentioned at the end of the video that left to right language syntax would be on the top on his whishlist for a future C++ standard(although he acknowledges that modifying C++ in that way would pretty much make for a completely different beast).

Apart from:

more understandable by humans, clearer to the naked eye;e.g.

```<code>//C syntax

/*pointer to function taking a pointer to function(which takes 2 integers as

arguments and returns an int), and an int as arguments and returning an int*/

int (*fp)(int (*ff)(int x, int y), int b)

//Go analogous syntax which is left to write

f func(func(int,int) int, int) int
</code>```

easier to parse(leads to better tool support as mentioned in the video - e.g. code refactoring)

what other advantages are there with a "left to right" syntax in a programming language.
I know only of Pascal and Go employing that kind of syntax(and Go does not even go the full way as I understand from this blog post from which I took also the examples)
Would it be feasible to have a systems programming language with that kind of syntax?

答:
The basic advantage is that parsing is simpler and unique. Note that after the line is parsed, the compiler will know what the exact type is, so from there on, how the type was defined is irrelevant.

Any function that returns an argument of array type, or function pointer type are hard to read currently:

```<code>// common way of obtaining the static size in elements of an array:
template <typename T, int N>
char (&array_size_impl( T (&)[N] ))[N];
// alternative parser:
template <typename T, int N>               // this would probably be changed also
array_simple_impl function( T [N] & ) char [N] &;
</code>```

And there would be less chance for misunderstanding (as the most-vexing-parse):

```<code>// Current C++
type x( another_type() );      // create an instance x of type passing a
                               // default constructed another_type temporary?
                               // or declare a function x that returns type and takes as argument
                               // a function that has no arguments and returns another_type
// How the compiler reads it:
x function( function() another_type ) type;

// What many people mean:
x type { another_type{} };
</code>```

Using a similar approach to uniform initialization in C++0x (i.e. {} to identify initialization). Note that with a left to right approach it is much clearer what we are defining. Many people (me for sure) have been bitten at any point by this parsing error in the past (more than once), and that would not be the case with a left-to-right syntax.

OwnerDisplayName: celavek

Body:
The basic advantage is that parsing is simpler and unique. Note that after the line is parsed, the compiler will know what the exact type is, so from there on, how the type was defined is irrelevant.

Any function that returns an argument of array type, or function pointer type are hard to read currently:

// common way of obtaining the static size in elements of an array:
template <typename T, int N>
char (&array_size_impl( T (&)[N] ))[N];
// alternative parser:
template <typename T, int N>               // this would probably be changed also
array_simple_impl function( T [N] & ) char [N] &;

And there would be less chance for misunderstanding (as the most-vexing-parse):

// Current C++
type x( another_type() );      // create an instance x of type passing a
                               // default constructed another_type temporary?
                               // or declare a function x that returns type and takes as argument
                               // a function that has no arguments and returns another_type
// How the compiler reads it:
x function( function() another_type ) type;

// What many people mean:
x type { another_type{} };

Using a similar approach to uniform initialization in C++0x (i.e. {} to identify initialization). Note that with a left to right approach it is much clearer what we are defining. Many people (me for sure) have been bitten at any point by this parsing error in the past (more than once), and that would not be the case with a left-to-right syntax.

OwnerDisplayName: David Rodríguez - dribeas


问:
What parts of your coding standard contribute to quality code?
In response to This Question, I ask:   What are the best parts of your coding standard?

What are the best practices that help with code quality, reliability, maintainability, readability, etc.

Please include the language, the item from the standard, and the reason it improves your code.

答:
For C++ inheritance. Pointing out that,

Multiple Inheritance: Only very rarely is multiple implementation inheritance actually useful.

For other things.

Preprocessor Macros: Be very cautious with macros. Prefer inline functions, enums, and const variables to macros.

Smart Pointers: If you actually need pointer semantics, scoped_ptr  is great. You should only use std::tr1::shared_ptr  under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr.


问:
Should I use try catch in my test methods?
I am doing unit testing.

I am trying to test one function.

I call it from my test component. But If remote function cannot handle the exception then my tester component will also get exception, I guess.

So should I worry about getting exception in my tester component?

Thanks.

EDIT:

PS:

Throwing an error is good, but only for other functions, not to end users until its a last option!

OMG I wrote a programming quote!!

答:
(In contrast to mcottle's answer) Long answer: NO... most of the time

When you say that you expect a test to raise a particular exception, you will know when ANY line in that test raises that particular exception.

That's not quite the same thing as knowing that the method under test throws the exception.

If your test involves setting up an object or context (within the test, not within your framework's version of SetUp), you might be better off wrapping the single line you actually want to test in a try/catch, possibly with a helper.

For instance,

```<code>public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}
</code>```

and then

```<code>[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}
</code>```

If this test fails, I know that my method under test threw the exception, and not something in the random setup stuff.

(You should try and avoid random setup stuff. Sometimes, it's easier to have some setup code in the test.)

Body:
(In contrast to mcottle's answer) Long answer: NO... most of the time

When you say that you expect a test to raise a particular exception, you will know when ANY line in that test raises that particular exception.

That's not quite the same thing as knowing that the method under test throws the exception.

If your test involves setting up an object or context (within the test, not within your framework's version of SetUp), you might be better off wrapping the single line you actually want to test in a try/catch, possibly with a helper.

For instance,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

and then

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

If this test fails, I know that my method under test threw the exception, and not something in the random setup stuff.

(You should try and avoid random setup stuff. Sometimes, it's easier to have some setup code in the test.)


问:
Do dynamic typed languages deserve all the criticism?
I have read a few articles on Internet about programming language choice in the enterprise. Recently many dynamic typed languages have been popular, i.e. Ruby, Python, PHP and Erlang. But many enterprises still stay with static typed languages like C, C++, C# and Java.

And yes, one of the benefits of static typed languages is that programming errors are caught earlier, at compile time, rather than at run time. But there are also advantages with dynamic typed languages. (more on Wikipedia)

The main reason why enterprises don't start to use languages like Erlang, Ruby and Python, seem to be the fact that they are dynamic typed. That also seem to be the main reason why people on StackOverflow decide against Erlang. See Why did you decide "against" Erlang.

However, there seem to be a strong criticism against dynamic typing in the enterprises, but I don't really get it why it is that strong.

Really, why is there so much criticism against dynamic typing in the enterprises? Does it really affect the cost of projects that much, or what? But maybe I'm wrong.

答:
Dynamically typed languages tend to be slower than their statically typed cousins.

Errors are harder to catch and can be harder to debug

The compiler/interpreter tends to be a lot less fastidious about what you can and can't do. i.e., you pretty much only catch syntax errors at the compilation stage

If you're not very careful with the design of a dynamically typed language, you end up with Javascript, which is the language of code-smells

EDIT: I should mention that my main programming language at the moment is Python, which is dynamically typed. Personally, I love the freedom that comes with not having to pre-declare variables, but at times, it would be nice to specify (for example) what kind of parameters a function takes to catch errors early rather than late.


答:
I would say go easy with technical questions in the interview. I interviewed at a company straight out of university, with zero commercial experience.  I didn't handle the technical interview well, but they gave me the role anyway.  A year later I was a technical lead at the company.

Spotting motivation to learn, and passion for the industry will be keen.

Title: How to retain student/intern programmers?

Body:
We have a small team in our department and typically employ 1-3 students/interns.  The problem we have is retention.  We like to hire a student that will stick around as part of the team for more than just a summer quarter.  The problem is though the last 4 students we hired, up front we discussed this with them and they all ended up leaving earlier than we would have liked.

The relationships all ended in a good fashion, the students either obtained teaching assistant or research positions within the university, or went on to bigger and better things.  This is all understandable and we do not hold it against them for doing what is best for them.

But my perspective is different as I worked within our department for 2 years during undergraduate at which point I was brought on full time upon graduation.

How can we retain students?  We give them hardware they need/want, we provide them with problems to solve in anyway they see fit (within reason).  All in all to me this type of job for a student programmer is so flexible and awesome I cannot see how anyone would want to leave.

Thoughts ?


问:
Why isn't the line count in Visual Studio zero-based?
This just struck me as an oversight by Microsoft.  Since arrays and other data-structures within the .NET framework begin from zero (zero-based) why don't we have a line 0 within the code view in Visual Studio?

Ponder that one :-)

答:
All arrays and data-structures are indexed based on zero, not just in .NET.

Array indexes are numbered for the computer, text lines in a document are numbered for us.

See screenshot :)


答: Because it is not natural to assume that the first line is the 0th line. Much like it's not natural either that arrays first element is at 0. However that's the first number that can be used in an unsigned integer to index an array with. So instead of wasting one element we use it.

Title: Why isn't the line count in Visual Studio zero-based?

Body:
This just struck me as an oversight by Microsoft.  Since arrays and other data-structures within the .NET framework begin from zero (zero-based) why don't we have a line 0 within the code view in Visual Studio?

Ponder that one :-)


问:
Introducing "20% time" at a workplace
20% time it's the culture of an employer allowing it's employees to spend 20% of their time working on projects that they find interesting - it may be inventing a new app, or improving an existing process, etc. Some people may know this as skunk work, however that term may not mean anything (or something entirely different) to you.

There are many documented cases of great products being born out of 20%/skunk work at a company. It seems like a win/win situation; the company potentially gain a great new product or application, and the developer has the opportunity to flex his/her creative muscles and innovate.

I tried on numerous occasions to introduce some form of 20%/Skunk working at my previous employer with no success.

How can I better justify it to management? What's the "right" way to approach this kind of work arrangement?

答:
From my small experience, a lot of our projects actually started in this fashion.  We had free time and bandwidth to take on new projects, we got together and came up with potential cool/forward thinking ideas for our department.  In our spare time we developed a prototype and once it was fairly polished, presented to upper level and usually they see the benefit.

It seems to me that upper level knows what they want if they see it but does not know they need/want it until they see it.  Prototyping has allowed us to create our own projects, propose them and then once approved divert more time to them to complete.

Title: Introducing "20% time" at a workplace


问:
What Features of an IDE Would Make It More Useful Than A General Purpose Editor
I am authoring a IDE for the Lua language. I find that many programmers do not like to use IDE  and prefer VIM (which is in vogue at the moment), SCiTE, or .

In trying to win some mind-share I am interested in what features an IDE could provide that would make it a compelling alternative to a general purpose editor.

Is there a "killer-app" so to speak for an IDE that would make it a "must-have"?

This could be thought of as the reverse of

Most useful features of VIM that aren't standard in a IDE

I won't link to my IDE unless someone asks - but you can pretty much just Google my name and find it.

EDIT: My IDE is actually a language plugin for an existing IDE, so I do inherit many features from the host IDE - at some level though my language support is an IDE in and of itself - at least as far as the language specific aspects are concerned.

答:
The big difference between an IDE and a general text editor is that IDE's understand the programming language you are working with and can autocomplete functions/methods, check for errors like wrong type and incorrect grammar. An IDE also has tools like a compiler integrated so that you can compile and run your program with commands in your IDE.

But I think VIM can do more than a general text editor, maybe you can see it as an IDE in some cases.


答:
Refactoring facilities (Renaming affects dependencies/Extract Method/Extract interface etc.)

Intellisense (or any other code completion functionality)

Error checking (the IDE actually knows its symbols)

No setup hassle

Integrated compiler

Integrated debugger

Better navigation to and from references/declarations

Project templates / file templates

GUI builders

Can autogenerate boilerplate code

It's intuitive and can be used without knowing all the magic keys (hey, that's why GUIs became successfull in the first place)

Overall, as @Thomas Owens stated, the biggest advantage of the IDE is tool integration with its synergy effects as a whole, while it's still intuitive and easy to use.

Title: What Features of an IDE Would Make It More Useful Than A General Purpose Editor

Body:
I am authoring a IDE for the Lua language. I find that many programmers do not like to use IDE  and prefer VIM (which is in vogue at the moment), SCiTE, or .

In trying to win some mind-share I am interested in what features an IDE could provide that would make it a compelling alternative to a general purpose editor.

Is there a "killer-app" so to speak for an IDE that would make it a "must-have"?

This could be thought of as the reverse of

Most useful features of VIM that aren't standard in a IDE

I won't link to my IDE unless someone asks - but you can pretty much just Google my name and find it.

EDIT: My IDE is actually a language plugin for an existing IDE, so I do inherit many features from the host IDE - at some level though my language support is an IDE in and of itself - at least as far as the language specific aspects are concerned.


答:
Refactoring Tools

The only reason why I'm not using my favorite general purpose text editor for coding. Because if you need to macro-up common code refactorings in your favorite general purpose then you might as well be using an IDE that has these tools installed.

Least to say that most IDE's have the useful functionality that emacs has, it's just buried down in some arbitrary key stroke combination.


问:
Should the usage of DI/IoC remove all occurrences of the "new" keyword?
Should the usage of Dependency Injection and an Inversion of Control container remove all occurrences of the "new" keyword from your code?

In other words, should every object/dependency, no matter how simple or short-lived, be "registered" within your IoC container and injected into the method/class that needs to use them?

If no, where do you draw the line between which dependencies/objects get registered in the IoC container, versus what gets created "in-line" as a concrete reference, via the new keyword ?

答:
Avoid dogma. Do what feels right.

I prefer to use "new" for data structures which have no behavior.

If the class does have behavior, I then look at the scope of that behavior. If it is stateless and has no dependencies, I lean towards "new". I only begin refactoring towards DI when I need to add a dependency to stateful resources (such as a database or a file), or to other classes with such resources.


问:
When writing a library, how much should the end user do?
First off, this question goes beyond my example (don't want this to be too localized or migrated to Stack Overflow) but I've come across this when thinking about something I wanted to try in C so I thought I'd use that as an example.

So my idea is to create a generic linked list in C and started it last night and it is coming along pretty well for being new in C. The issue I ran into is type casting and it leads me to this question: how much work should a library designer expect the end user to do when using the library?

If you take my example, right now, I don't perform any casts and return an Object (which is a typedef of void*). Is it reasonable to make sure that the end user keeps track of their types or should the library designer make sure that the list is type safe (I think I have a general idea on how to implement that for at least the built in data types)? Is it reasonable, when designing a library to expect a certain amount of work on the end users part to use the library or should it be dumbed down as much as possible? Are there factors that would affect this decision, such as language?

答:
I have been through exactly the same phaseI really think you should check out the Linux kernel implementation of linked lists, found in include/linux/list.h

You can find a really nice description of the use and implementation of this list here

Plus, be sure to check out the Linux sources. The idea is ingenious, nodes contain pointers to lists, and not the other way round!! This small turnaround makes the implementation type independent.

regards,

Yati


答:
Clearly depends on the language you use. If your language forces you to use objects to represent both actual object and records (value object, structs), then the answer is most likely no.

Speaking purely of "real" objects, there is nothing wrong with creating an instance explicitly. What you must bare in mind however is, that all classes should follow the single responsibility principle. It should not be the responsibility of a class to choose the implementor of a service it relies on. However there are classes who's have that very responsibility, i.e. to provide implementors of certain services. An IoC might be such class. In fact any type of factory is such a class.

So to summarize: Only such classes should directly instantiate objects, who's responsibility it is to choose which classes to instantiate.

You might find these criteria helpful: http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Creator

Title: Should the usage of DI/IoC remove all occurrences of the "new" keyword?

Body:
Should the usage of Dependency Injection and an Inversion of Control container remove all occurrences of the "new" keyword from your code?

In other words, should every object/dependency, no matter how simple or short-lived, be "registered" within your IoC container and injected into the method/class that needs to use them?

If no, where do you draw the line between which dependencies/objects get registered in the IoC container, versus what gets created "in-line" as a concrete reference, via the new keyword ?


答:
"new" is not a forbidden keyword. My personal rules:

All "services" (I call a service a class designed to provide one or more methods related to one and only one thing ; for example: access the database, retrieve/update data related to a given domain) are registered in the IOC container. No class should have to make the decision on how to obtain the implementation of a given service it needs to use. Therefore, whenever you need to use an existing service, you should configure your class and the IOC container to provide it to you. Imagine that you are not aware how your implementation works, it could be a web service, you don't care.

All beans, or models are to be created with the "new" keyword or with an IOC-registered factory when I need them to have some default properties enabled.
There is also the particular case of utility classes containing only static methods (for example: a mathematical utility service). If they are totally standalone and do not need any database connection or another IOC-registered service, I leave them out of the IOC and they are to be called statically.
However, if one such class needs to use an existing IOC-registered service, I change it to a singleton class and register it in the IOC.


答:
Nice to have features of an IDE that is not found in text editor:
1. Intellisense (auto complete & suggestions)

Integration with compiler

Integration with debug system

Integration with version control

Integration with database system

On-the-fly syntax checking and help

Syntax coloring

Handles projects not only files of code

Finds where a method is used and draws a chart (not found in most IDEs to-date)

Registers components (depending on your language)

Integration with GUI Editor(s)

Bookmarks code segments

Source safety and sharing across developers

Project restore to previous versions

Multiple project configurations (test, development, production)

The IDE features can be configured

Intelligent source code compare

Automatic renaming of vars, methods, etc.

I don't think creating a new IDE is useful.


答:
In my book, I provide the distinction between Stable and Volatile Dependencies. It's most important to use DI with Volatile Dependencies, but often you can achieve even looser coupling by also abstracting and injecting Stable Dependencies.

Keep in mind that the application of DI should not rely on a DI Container. In the case where Poor Man's DI is in use, no new keywords are removed - they are just moved to the Composition Root.

Some people actually prefer Poor Man's DI over DI Containers. The maintenance cost may be higher, but you get compile-time safety in return. As I recently heard Dan North say: "new is the new new" :)

What is meant by this is simply that instead of implementing the Composition Root with a DI Container, it'd just contain a whole bunch of nested new statements.

ContentLicense: CC BY-SA 4.0


答:
I think you somewhat missed the point when you focused on the left-to-right bit.

The problem of C and C++ are the horrendous grammar they have, which is difficult to both read (humans) and parse (tools).

Having a more consistent (or regular) grammar makes it easier on both. And easier parsing mean easier tooling: most current tools do not get C++ right, not even the latest plugin of Eclipse as they sought to reinvent the wheel... and failed, and they probably have more people than the average OS project.

So you probably nailed it when focusing on reading and parsing... and that's a big deal :)

Title: Advantages of a left to right language syntax

Body:
I've been watching an interview with Herb Sutter on Channel9 and he mentioned at the end of the video that left to right language syntax would be on the top on his whishlist for a future C++ standard(although he acknowledges that modifying C++ in that way would pretty much make for a completely different beast).

Apart from:

more understandable by humans, clearer to the naked eye;e.g.

```<code>//C syntax

/*pointer to function taking a pointer to function(which takes 2 integers as

arguments and returns an int), and an int as arguments and returning an int*/

int (*fp)(int (*ff)(int x, int y), int b)

//Go analogous syntax which is left to write

f func(func(int,int) int, int) int
</code>```

easier to parse(leads to better tool support as mentioned in the video - e.g. code refactoring)

what other advantages are there with a "left to right" syntax in a programming language.
I know only of Pascal and Go employing that kind of syntax(and Go does not even go the full way as I understand from this blog post from which I took also the examples)
Would it be feasible to have a systems programming language with that kind of syntax?


问:
Why are data structures so important in interviews?
I must confess that I was not so strong in data structures when I graduated out of college. Throughout the campus placements during my graduation, I've witnessed that most of the biggie tech companies like Amazon, Microsoft etc focused mainly on data structures. It appears as if data structures is the only thing that they expect from a graduate.

To be honest, I felt bad about that. I write good code. I follow standard design patterns of coding, I do use data structures but at the superficial level as in Java exposed APIs like ArrayList, LinkedList etc. But the companies usually focused on the intricate aspects of Data Structures like pointer based memory manipulation and time complexities.

Probably because of my Java background, back then, I understood code efficiency and logic only when talked in terms of Object Oriented Programming like objects, instances, etc but I never drilled down into the level of bits and bytes. I did not want people to look down upon me for this knowledge deficit of mine in Data Structures.

So really why all this emphasis on Data Structures?

答:
In generally algorithms and data structures is regarded as two of the most "hard core" topics in programming. This is because there's a huge body of work and research regarding them in computer science. They also attract the typical "left-lobe"-programmers that like things like math and science (which is a whole lot of programmers)

That being said, knowledge of these might affect your career in terms of interviewing, especially if you interview at engineering-oriented workplaces like google. Other companies might now however care about that aspect at all.

In my experience algorithm/data structure demands can sometimes come across as "programmer elitism" where alpha geeks are jockeying to show who's the smartest.  Its always good to know what's out there, but there are great many different programming jobs where you never will need to know how to use a red/black tree or code a boyer-moore search.

I'd recommend learning more about the topics if you find them interesting and have some personal project where you can tinker with them, otherwise you can probably get by without them for now

PS. Profiency with rudimentary data structures (linked lists, dictionaries, hashtables etc) should be a mandatory knowledge for any programmer DS.


答:
Because they did a good job at separating the user model from the programming model, that's why. The same reason why most apps don't ask you, for example,

Please enter a varchar(200) representing your name.

Take a lesson from that.


答:
To build on what @Pelshoff says, it is to show that you know what you're doing. If you use a LinkedList for everything, that may show you don't know what you're doing or you don't care to stop and think about the problem. On top of that, at least the data structures course I took covered, basic, complexity theory of those data structures which, when dealing with large data sets is very important. That would be why companies like Amazon or Microsoft would do such a thing.

I must say, before I took a data structure class I thought that they weren't important but at least being able to recongnize when a linked list (or ArrayList) isn't practical or what the draw backs of them are is important.

Title: Why are data structures so important in interviews?

Body:
I must confess that I was not so strong in data structures when I graduated out of college. Throughout the campus placements during my graduation, I've witnessed that most of the biggie tech companies like Amazon, Microsoft etc focused mainly on data structures. It appears as if data structures is the only thing that they expect from a graduate.

To be honest, I felt bad about that. I write good code. I follow standard design patterns of coding, I do use data structures but at the superficial level as in Java exposed APIs like ArrayList, LinkedList etc. But the companies usually focused on the intricate aspects of Data Structures like pointer based memory manipulation and time complexities.

Probably because of my Java background, back then, I understood code efficiency and logic only when talked in terms of Object Oriented Programming like objects, instances, etc but I never drilled down into the level of bits and bytes. I did not want people to look down upon me for this knowledge deficit of mine in Data Structures.

So really why all this emphasis on Data Structures?


答:
I am a quick learner and I can learn new frameworks, APIs or even programming languages within considerably short amount of time.

Not to sound too harsh, but any half-decent developer will be able to pick up a new language or framework in a relatively short period of time.

Data structures are universal, they are a fundamental building block of computer science -- a red-black tree is basically the same, whether it's implemented in Java, Python, PHP or whatever. So rather than testing specific languages, or specific frameworks, an employer (at least, an employer looking for stand-out developers) will test whether you know the fundamentals of computer science, rather than just whatever flavour-of-the-month they're currently using.

(at least, they should be testing the fundamentals in addition to whatever they're currently using... no point hiring a computer-science wizard if he's never written a line of code in his life)


答:
One important point about data structures is that they are universal and timeless, at least for practical purposes. Anyone who's been a developer in the last 30 years should know basic data structures like single/double linked lists, binary trees or graphs. If you ask two developers about them, you can compare the developers' knowledge by their answers. This can hardly be said for frameworks or even languages: If you ask two developers about Rails, and one knows a lot more than the other, what does that tell you, really? As you say in the question, a smart developer can learn a new framework quickly enough, so testing their current knowledge doesn't make much sense.

Does, Not having knowledge in Data Structures really effect one's career in programming?

Yes. Definitely. Unless you want to spend all your life writing CRUD applications.

Or is the knowledge in this subject really a sufficient basis to differentiate a good and a bad programmer?

No, it's not sufficient. But there are few things you can ask in a job interview that are sufficient. And I'd say algorithms knowledge is one of the better indicators, at least for people fresh out of school, where you can't ask about work experiences.


答:
3 things always decide whether or not I will use a particular IDE:

Autocomplete

A visual GUI builder

Data tools for some sort of integrated ORM

I generally use the IDE that has the most of these features, or that does them best. These are the three things that tend to increase produductivity the most by reducing boilerplate coding (GUI and DAL) and by reducing think time (autocomplete allows me to skip a lot of API fumbling).


答: They are fundamental, but also, what would you quiz graduates on? They may or may not have experience outside of their course work. Their course may have covered Microsoft technologies more than say Java, or vice versa. Data structrues are common ground. </p>


答:
Data structures are building blocks of many things you want to do.
If you know the uses for each data structure, its weaknesses and strong points then you can easily solve problems.

For example, we had a requirement to manage thousands of objects. Every once in a while we need to update an object's timestamp according to its ID. Every once in a while we needed to remove the objects that were not updated for more than X minutes.

If you know your data structures you can easily define the problem, and it is also very easy to come up with a solution. When a programmer that don't know enough data structures tried to come up with a solution, his solution was awkward. He was like you - smart, code programmer, able to learn frameworks quickly. But without a knowledge in data structures he had to invent the wheel by himself. More then that - he had hard time understanding simpler solutions since they were based on data structures he did not understand such as red-black trees (your old TreeMap in Java).

So, I'd say that the important thing is to know how and when to use each data structure without having to think about it. But I don't think there is any way of achieving that without actually understanding how they work.


答:
There is a difference between counting and indexing. The index can start at any number (some languages support that), but for many reasons it is most often practical to have it start at zero.
Counting also starts at zero, but as soon as one does count a set that is not empty, the first element is 1, and so on.</p>


答:
Do you believe that F1 racers just drive fast cars? No, they understand the car they drive and they work with the mechanics/engineers to tune it. Of course, a normal driver just drives.

You can be a normal/average programmer that just writes code. You don't understand what's behind. You get things done. That's all, see you next day.

But many companies look for F1 developers. People that will develop knowing what is behind their code. People that will also help the company to build something better.

It's quite good to know data structures not only because you will use them in a "pre cooked" form a lot. It's also good because you will create something that derives from their idea.


问:
can we do scaling by throwing ruby stone

I heard developers at my office discussing Ruby language can be used for following purposes: Desktop apps,Web Apps,and may be handheld devices.
Actually,we are in phase of selecting technology to have scalability of  the following:

I have - Ruby made Desktop apps on each inventory unit of the big firm.
And wish to synchronize all relevant data from those desktop apps to a web app DWarehouse like Dropbox for some ontology and mining work.
And wish to have some wireless chat app also on handsets like whatsapp to assist in faster communication between inventory unit managers.

So,can we get a faster good build of Desktop apps,web apps and handset chat apps using ruby technology.

And I know ruby can't be scaled up for large workload,then what we can do later,should we get some java or php support to scale the application base or there is some cloud option present for ruby.

答:
Your architecture scales, not your language.

Ruby has many frameworks and tools that help with building an scalable architecture. But it's on you how you will use them.

Rails seems to easily scale for web apps and have a bunch of web servers. But abuse of session  data (like adding 1MB things into the session), or machine specific information and your app won't be able to scale so easily.


答:
In my class on data structures, the very first thing the professor said was: This class is not about being able to search really fast. We then spent half a year finding the best possible data structures and algorithms to search really fast.

Still, he remained right. Being able to analyse data structures, apply the right data structure to a given problem or even come up with new data structures requires many qualities of an engineer:

Finding abstractions to model a concrete problem

Being able to decompose problems

Being able to reason logically/formally

Creativity

etc.

When Amazon and Microsoft hire people, they don't ask questions on data structures because they hope to invent the next quicksort. They want to make sure they hire someone with the above-mentioned qualities.

Of course it's possible to have a large set of these qualities and still suck at data structures. But then, if that's the case, it won't take you long to become an expert in data structures.

That being said, there is still the problem that ArrayList just doens't quite scale. When systems get large, better adapted solutions are required to perform the job. And without a good grasp of data structures, you won't be able to find and compose structures and algorithms which scale at large in your concrete scenario.


答: Formatting - especially Indentation! I'm using Delphi and the first thing to do when I get code not formatted to my usage I reformat it. The built-in formatter in Delphi serves as one of the most used fetaures in these cases.</p>

Title: What parts of your coding standard contribute to quality code?

Body:
In response to This Question, I ask:   What are the best parts of your coding standard?

What are the best practices that help with code quality, reliability, maintainability, readability, etc.

Please include the language, the item from the standard, and the reason it improves your code.


问:
What is the biggest support a boss can give to his/her developers?
Buying the best hardware, paying the most precious bonus or reward, treating them politely, provide the opportunity for improvement, etc.?

We want to improve the productivity of our development team. We want to see what can be regarded the biggest support (or generally a good support), so we can start from there.

答:
Regular 1:1's.

If done right (The Update, The Vent, and The Disaster), it will help to figure which of buying best hardware, paying the most precious bonus or reward, treating them politely, providing the opportunity to improve etc will bring the most... and which of these won't matter.

To me, this one looks as close to proverbial silver bullet as it gets.


答:
By convention, normal humans count starting from 1, while many programmers and some mathematicians count starting from 0.

The question you have raised about line numbers is not specific to Microsoft Visual Studio. It applies to every other text editor tool, because counting lines from 1 has been adopted as a universal convention in software.

The countless other tools that count text lines from 1 include Windows Notepad, IDE text editors, text editors on Linux, Firefox's JavaScript console, compiler error messages, and so on and so forth.

While it wouldn't be wrong to count lines starting from 0, it would break the established convention and cause a massive amount of confusion to everyone involved, from the developers to the users.

See also:

Why are structs/arrays zero based? (SE Programmers)

Defend zero-based arrays (Stack Overflow)


答:
How We Got Here

The C syntax for declaring function points was intended to mirror usage. Consider a regular function declaration like this from <math.h>:

```<code>double round(double number);
</code>```

To have a point variable you can assign that to with type safety using

```<code>fp = round;
</code>```

you’d need to have declared that fp point variable this way:

```<code>double (*fp)(double number);
</code>```

So all you have to do is look at how you would use the function, and replace the name of that function with a pointer reference, making round into *fp.  However, you need an extra set of parens, which some would say makes it a bit messier.

Arguably, this used to be easier in the original C, which didn’t even have function signature, but let’s not go back there, ok?

The place it becomes especially nasty is figuring out how to declare a function that either takes as an argument or returns a pointer to a function, or both.

If you had a function:

```<code>void myhandler(int signo);
</code>```

you could pass it to the signal function(3) this way:

```<code>signal(SIGHUP, myhandler);
</code>```

or if you want to keep the old handler, then

```<code>old_handler = signal(SIGHUP, new_handler);
</code>```

which is pretty easy. What is pretty easy — nor pretty, nor easy — is getting the declarations right.

```<code>signal(int signo, ???)
</code>```

Well, you just go back to your function declaration and swap the name for a point reference:

```<code>signal(int sendsig, void (*hisfunc)(int gotsig));
</code>```

Because you are not declaring gotsig, you might find it easier to read if you omit:

```<code>signal(int sendsig, void (*hisfunc)(int));
</code>```

Or maybe not. :(

Except that that is not good enough, because signal(3) also returns the old handler, as in:

```<code>old_handler = signal(SIGHUP, new_handler);
</code>```

So now you have to figure out how to declare all those.

```<code>void (*old_handler)(int gotsig);
</code>```

is enough for the variable you’re going to assign to. Note that you are not really declaring gotsig here, only old_handler. So this is really enough:

```<code>void (*old_handler)(int);
</code>```

That brings us to a correct definition for signal(3):

```<code>void (*signal(int signo, void (*handler)(int)))(int);
</code>```

Typedefs to the Rescue

By this time, I think everyone will agree that that’s a mess. Sometimes it’s better to name your abstractions; often, really.  With the right typedef, this becomes much easier to understand:

```<code>typedef void (*sig_t) (int);
</code>```

Now your own handler variable becomes

```<code>sig_t old_handler, new_handler;
</code>```

and your declaration for signal(3) becomes just

```<code>sig_t signal(int signo, sig_t handler);
</code>```

which is suddenly comprehensible. Getting rid of the *’s also gets rid of some of the confusing parentheses (and they say parens always make things easier to understand — hah!).  Your usage is still the same:

```<code>old_handler = signal(SIGHUP, new_handler);
</code>```

but now you have chance of understanding the declarations for old_handler, new_handler, and even signal when you first encounter them or need to write them.

Conclusion

Very few C programmers, it turns out, are capable of devising the correct declarations for these things on their own without consulting reference materials.

I know, because we once had this very question on our interview questions for people doing kernel and device driver work. :)  Sure, we lost a lot of candidates that way as they crashed and burned on the whiteboard. But we also avoided hiring people who claimed they had previous experience in this area but couldn’t actually do the work.

Because of this widespread difficulty, though, it is probably not just sensible but indeed reasonable to have a way to go about all those declarations that no longer require you  to be a triple-alpha geek programmer sitting three sigmas above the mean just to use this sort of thing comfortably.

Body:
How We Got Here

The C syntax for declaring function points was intended to mirror usage. Consider a regular function declaration like this from <math.h>:

double round(double number);

To have a point variable you can assign that to with type safety using

fp = round;

you’d need to have declared that fp point variable this way:

double (*fp)(double number);

So all you have to do is look at how you would use the function, and replace the name of that function with a pointer reference, making round into *fp.  However, you need an extra set of parens, which some would say makes it a bit messier.

Arguably, this used to be easier in the original C, which didn’t even have function signature, but let’s not go back there, ok?

The place it becomes especially nasty is figuring out how to declare a function that either takes as an argument or returns a pointer to a function, or both.

If you had a function:

void myhandler(int signo);

you could pass it to the signal function(3) this way:

signal(SIGHUP, myhandler);

or if you want to keep the old handler, then

old_handler = signal(SIGHUP, new_handler);

which is pretty easy. What is pretty easy — nor pretty, nor easy — is getting the declarations right.

signal(int signo, ???)

Well, you just go back to your function declaration and swap the name for a point reference:

signal(int sendsig, void (*hisfunc)(int gotsig));

Because you are not declaring gotsig, you might find it easier to read if you omit:

signal(int sendsig, void (*hisfunc)(int));

Or maybe not. :(

Except that that is not good enough, because signal(3) also returns the old handler, as in:

old_handler = signal(SIGHUP, new_handler);

So now you have to figure out how to declare all those.

void (*old_handler)(int gotsig);

is enough for the variable you’re going to assign to. Note that you are not really declaring gotsig here, only old_handler. So this is really enough:

void (*old_handler)(int);

That brings us to a correct definition for signal(3):

void (*signal(int signo, void (*handler)(int)))(int);

Typedefs to the Rescue

By this time, I think everyone will agree that that’s a mess. Sometimes it’s better to name your abstractions; often, really.  With the right typedef, this becomes much easier to understand:

typedef void (*sig_t) (int);

Now your own handler variable becomes

sig_t old_handler, new_handler;

and your declaration for signal(3) becomes just

sig_t signal(int signo, sig_t handler);

which is suddenly comprehensible. Getting rid of the *’s also gets rid of some of the confusing parentheses (and they say parens always make things easier to understand — hah!).  Your usage is still the same:

old_handler = signal(SIGHUP, new_handler);

but now you have chance of understanding the declarations for old_handler, new_handler, and even signal when you first encounter them or need to write them.

Conclusion

Very few C programmers, it turns out, are capable of devising the correct declarations for these things on their own without consulting reference materials.

I know, because we once had this very question on our interview questions for people doing kernel and device driver work. :)  Sure, we lost a lot of candidates that way as they crashed and burned on the whiteboard. But we also avoided hiring people who claimed they had previous experience in this area but couldn’t actually do the work.

Because of this widespread difficulty, though, it is probably not just sensible but indeed reasonable to have a way to go about all those declarations that no longer require you  to be a triple-alpha geek programmer sitting three sigmas above the mean just to use this sort of thing comfortably.


答:
Data structures, time complexity, memory manipulation, and pointers are all fundamentals that someone who calls themselves a Computer Scientist should innately know.  Any code monkey can learn a language and learn how to use it, but where CS professionals and students should set themselves apart is knowing not just how to use a linked list or a hash map, but WHY.

The WHY is what really sets us all apart from the basic script kiddie, code monkey, and grunt of the computing world.  WHY use a hash table instead of a linked list, WHY should my hash table be at a cluster density of roughly .6-.8, WHY should I use a circularly linked list here instead of a doubly linked list.  WHY should my code be running at efficiency 'x' in the worst case and 'y' in the average case.

These basic data structures and knowledge of not just the HOW they are used (the how should be in every programmers repritoire anyway) but the language agnostic WHY they are used, which tends to be more of what they're looking for in these cases.

Many places will make you write the code in a language that you're firmiliar with, but that's more of a generality, seeing as C is really not the langua franca of the programming world anymore, and structuring pseudo code can be a mishmash and all over the place and, in most cases with pseudo code/p&p code not really being taught, down right impossible to deal with.


答:
A link which counters some of Dijkstra's points (in an article which is sooner or later gonna come out in this discussion).

Why numbering should start at one


答:
One word: No.

More words: Dependency injection is exactly that. It is a means by which you introduce resources that another object depends on, but shouldn't know the intricate details of, from another source. Using DI does not mean that NOTHING in your program should know how to create any other object; in fact, I posit that it is highly infeasible for a non-trivial program to avoid the "new" keyword (or reflection-based alternatives) entirely. However, DI does mean that objects that shouldn't HAVE to know how to create complex objects that require a lot of dependencies that will tightly couple this object to the other, shouldn't have all this tightly-coupling knowledge.

I would study the two major theories of O/O software design, GRASP and SOLID. GRASP will tell you to study the object's purpose, and ask yourself, "Should this object be responsible for creating new objects of this other type? Is that part of the 'job description' of this object?" SOLID goes one step further: The "S" stands for the "Single Responsibility Principle", which states unambiguously that an object should have one job, and it should be the only object in the program that does that specific job.

So, GRASP would generally encourage you to look through your existing classes for which creating these new objects, and find one for which the task of creating this object fits with what the object already does, while maintaining your desired level of "cohesion". SOLID will tell you that cohesion is key; the task of creating these objects should be given to some factory that should be injected into your class. I think you'll find, as the complexity of your program continues to grow, that adherence to either of these methodologies, with a willingness to refactor, will result in very similar architectures.


问:
What traits do the best managers you've worked for have in common?
I have been listening to Scott Hanselman and Rob Conery's podcast, This Developer's Life.

In the latest episode, they discuss personality traits:

1.0.4 - Being Mean.

What makes people mean in our
  industry? What about aggressive?
  Confident? What's the difference?
  Would you rather have a drill sergeant
  for a boss, or a zen master? We talk
  to Cyra Richardson and Giles Bowkett.

It got me thinking, what traits did the best managers you've worked for have in common?

EDIT: Just to clarify, as there have been a few close votes, I'm interested in whether there are traits common to managers of developers that are not necessarily those traits that a manager of some other profession requires.

As for whether this is programming related or not, well I don't want to ask this question on a site that isn't about programming because, frankly, I'm not as interested in what people who make cans of soup for a living want from their managers as I am interested in what developers want from their managers.

答:
Credit where credit due and enough knowledge to be able to assign it

I'd have added listens well but upvoted that instead.

If there's someone who constantly takes credit for features found in libraries either developed in-house, open source or third party then that should get shot down, not rewarded.

If someone is being assigned all the bug responsibilities because he's actually writing unit tests and finding them then he should be rewarded, not punished.  Finding bugs is not the same as writing them in the first place.

If a develop or a group of developers bust ass to make deadlines, they should be lauded, not the managers for coming up with the deadlines in the first place.


问:
Why isn't Java used for modern web application development?
As a professional Java programmer, I've been trying to understand - why the hate toward Java for modern web applications?

I've noticed a trend that out of modern day web startups, a relatively small percentage of them appears to be using Java (compared to Java's overall popularity).  When I've asked a few about this, I've typically received a response like, "I hate Java with a passion."  But no one really seems to be able to give a definitive answer.

I've also heard this same web startup community refer negatively to Java developers - more or less implying that they are slow, not creative, old.

As a result, I've spent time working to pick up Ruby/Rails, basically to find out what I'm missing.  But I can't help thinking to myself, "I could do this much faster if I were using Java," primarily due to my relative experience levels.

But also because I haven't seen anything critical "missing" from Java, preventing me from building the same application.

Which brings me to my question(s):

Why is Java not being used in modern web applications?

Is it a weakness of the language?

Is it an unfair stereotype of Java because it's been around so long (it's been unfairly associated with its older technologies, and doesn't receive recognition for its "modern" capabilities)?

Is the negative stereotype of Java developers too strong? (Java is just no longer "cool")

Are applications written in other languages really faster to build, easier to maintain, and do they perform better?

Is Java only used by big companies who are too slow to adapt to a new language?

答:
In my experience, Java for web applications is overkill for small applications. A simple blog with one database table hold blog entries, for example, could be done in something much simpler.

I have usually seen Java do much better in much larger web applications (think banks and insurance companies) that communicate with a number of other systems (such as mainframe back-ends and databases and peer web-services background batch-processing systems... all in the same application).

From what I've seen, the architecture of a JavaEE web application is just usually more than is needed for small/simple web applications.


答:
Often times the best code avoids reinventing low level data structures. This is especially true in high level languages.  I have noticed a trend towards low level data structure questions even in CRUD jobs. YMMV, but it seems the emphasis on hacker scientist expertise has overshadowed the other skills that make a great developer:

project/time management: being able to keep up with the real world that is driven by business, not a new linked list that operates 1% faster.

a minimum amount of social skills: a developer that is arrogant and cannot get along is nothing but an anchor.

the ability to learn new things quickly and continuously: data structures hardly change over the years...but everything else does. Data structures are great fundamentals and every developer should know them pretty well, but an accountant does not get tested on their long division skills when they go in for an interview. Great developers are the type of people who can figure out new things and like it.

Data structures are great. Data structures are important. Every programmer should have an understanding of them. However, we have become obsessed with pushing these fundamentals outside of their place. It is not ALL about data structures, and in 99% of cases there is no need to ask questions beyond the basics of data structures. If you are interviewing an accountant, sure ask them what 81 divided by 9 is, but if you keep asking "What's the cube root of 98425454242412 * 4512324?...without a calculator!" then you will be frightening a good percentage of the reasonable, smart, talented, and agreeable people you could have had. Ask if they can build a basic relational data model, ask if they can use the enhanced array structures provided by the relevant framework, and ask if they can explain when a binary search is faster than flat search, but there is not much point going too far beyond that. If they can do those things, then start looking for the nicest, most professional, most creative one of the bunch.

I love Joel's writing, but I think his "Java Schools" thing is dead wrong. There are plenty of things that can prove someone is smart beyond mastering C++. Think about it, you can talk to someone for 10 minutes, without asking them about pointer arithmatic, and get a pretty good idea of whether or not they are the type who can get things done and figure stuff out. We don't need to be like this:

Interviewer: "Tell me about your accomplishments."

Coder: "In my last position I was the sole developer for a custom ERP system for a billion dollar financial firm. We delivered months ahead of schedule, and the system has been in production for the past 3 years."

Interviewer: "Let me clarify. Tell me about your programming accomplishments"

Coder: "Umm..."

Interviewer: "For example, have you ever made your own linked list?"

Coder: "...[walking out]"


答: An addition to the FrustratedWithFormsDesigner's answer: Since I guess that your question more targets towards smaller sites, there is an important aspect that you need to consider for a lot of people: Hosting is ubiquitous for PHP but its harder for Java or ASP sites. This however is not a defect of those languages.

Title: Why isn't Java used for modern web application development?

Body:
As a professional Java programmer, I've been trying to understand - why the hate toward Java for modern web applications?

I've noticed a trend that out of modern day web startups, a relatively small percentage of them appears to be using Java (compared to Java's overall popularity).  When I've asked a few about this, I've typically received a response like, "I hate Java with a passion."  But no one really seems to be able to give a definitive answer.

I've also heard this same web startup community refer negatively to Java developers - more or less implying that they are slow, not creative, old.

As a result, I've spent time working to pick up Ruby/Rails, basically to find out what I'm missing.  But I can't help thinking to myself, "I could do this much faster if I were using Java," primarily due to my relative experience levels.

But also because I haven't seen anything critical "missing" from Java, preventing me from building the same application.

Which brings me to my question(s):

Why is Java not being used in modern web applications?

Is it a weakness of the language?

Is it an unfair stereotype of Java because it's been around so long (it's been unfairly associated with its older technologies, and doesn't receive recognition for its "modern" capabilities)?

Is the negative stereotype of Java developers too strong? (Java is just no longer "cool")

Are applications written in other languages really faster to build, easier to maintain, and do they perform better?

Is Java only used by big companies who are too slow to adapt to a new language?


问:
why is it easy to break verification images if they are not distorted to the extent that humans can get them wrong too?
I don't understand why people like to say "Images had to be distorted otherwise they would be easily cracked". I'm talking about those verification images that we had to type to identify that we are humans.

Exactly what steps must we take to break even a simple image? like this:

Ok so i'm guess we had to read all the bytes of the image and try to draw some sense out of those bytes? because if that's really how it is done it does seem really pretty tough (so what's with that comment that it's easily cracked), or is there a better way to crack images (that make it so easy after-all) ?

答:
If not distorted, using OCR it is quite easy.

By the way, there was a question on OCR yesterday (OCR - starting point) where I posted a link to Google's OCR tool.
I also posted another link that may be interesting for you, in which they explain how the OCR tool treats words it cannot read, http://allspammedup.com/2011/01/google-recaptcha-cracked, excerpt:

"When a word in a book scan can’t be recognized by Google’s OCR software, it’s sent to the reCAPTCHA pool. So when a person enters a reCAPTCHA phrase into a form, Google can discover what its OCR program couldn’t, without having to hire human editors to review scanning results."

So: CAPTCHA --> OCR --> CAPTCHA. The circle is complete :-)


答:
So really why all this emphasis on Data Structures?

Two reasons.

For one thing, it shows you can think about the problem in abstract terms, rather than in terms of a specific programming language.  Do you know why a hash table may be a better or worse choice than a red-black tree in a given situation, regardless of the underlying implementation?

For another, there are a scary number of people out there interviewing for jobs who simply lie about their experience and have very little if any programming ability; data structures questions are a quick way of weeding these people out.


答:
Well, I recently met with a Java guy that was really excited by the new Spring Data project, because of how little code it takes to get basic CRUD access to your DB going.

I can build a CRUD app using Rails (not just db access, but views and controllers) with a few commands.

(Off the top of my head: new project, 1 scaffold command per entity, 1 command to migrate the database, 1 command to start the server.)

It has nothing to do with the language, it's all about the tools. And it seems that dynamic languages tend to have the tools and frameworks that remove a lot of boilerplate code. (To make up for our lack of powerful IDEs that generate boilerplate for us.)

Also I feel that dynamic languages tend to make writing such tools and frameworks a lot easier. I can grok the code for say, Padrino or Rails (ruby web frameworks) a lot more easily than I can grok the code for say Spring Roo.
This could be due to the fact that I know Ruby a lot better than I know Java, though.


答:
Being a good programmer is not about being able to learn languages and frameworks.  It is about being able to build solutions to complex problems.  For these solutions to be efficient and reliable will almost always rely on good algorithms and appropriate use of data structures.  Knowing the data structures exist is not enough.  You need to understand the data structures will enough to use the right one for the problem.  Lists and maps offer some valuable features, but they come with costs, and using the wrong one can significantly undermine the performance of your software.

A good interviewer knows this and is trying to determine if you can be valuable to his team or company.  The language(s) you will be using 2 years from now may be very different, but the need for effective algorithms and data structures will not change.


问:
Why applications don't have constraint-based security?
In almost any security system I've ever seen, what is controlled is that which person has access to which part.

However, in real life, in many situations, security systems also consider when and where a person is permitted to do something.

For example, you can drive fast in day, but you can't drive fast in night, or you can marry a homosexual officially in X, but you can't marry the same gender in Y.

Does constraint-based security has any meaning in the context of software. For example, a system can prevent you from entering in certain times of the day (after work for example), or another system can let you stay signed in, only if you type fast enough, or another system can let you enter data, only if you are currently located in the USA (Geolocation API), etc.

Why computer security systems don't match real life scenarios?

答:
Constraint based security systems have too many flaws in the general case that you stated that implementing it in computers would be terrible.  Just from your examples:

Driving: I CAN follow the speed limits for my time of day and place, but I don't have to, and usually don't - it's impossible to get anywhere in Montana driving the speedlimit.  Not only is this an example of not following the constraint (law) it's also showing an imperitive where I wouldn't want to.

Marriage rights: I CAN get married to group 'x' in state 'y' but will state 'z' recognize my marriage to group 'x' because they outlaw the marriage of group 'x' in their state.  This is an example of constraint inconsistency, and can be hazardous to employees, in the effect that it can limit their ability to perform their basic tasks with which they are charged based on location (geolocation that you stated later), and can hurt the overall ability of the company.

ToD Restrictions: Is this a server side or client side qual, because if the computer doesn't have to check in with the server for time, someone can easily get into the bios of the client side computer (assuming it's not locked, they usually aren't) and change the time such that they can log on.

Typing Speed Restrictions: This would just be dumb, much akin to laws like No selling alcohol to Moose - Alaska.  Most employees aren't in a situation where typing is ALWAYS an imperitive, what am I supposed to do when I want to research a method in python, sit and hold the space key while I read?

The problem with constraint based restrictions in general is the fact that just because there's a constraint doesn't mean that someone won't go around it, and in worst cases that the constraints aren't uniform so people don't want to deal with them in that manner.  Secondly, the reason that you see constraints in society but not so much in computer systems is that constraints in society show up in the form of laws and rules that are PHYSICALLY enforcable, as opposed to computer systems where everything is a little more grey and murky.


答: Unique naming method, does not matter on the language. For example.. G = Global, L = Local ,P = Parameter. Now when you have a variable like G_strFoo I know that it's definition can be located in my global file. Helps with keeping up with all the variables in my programs.</p>


答:
Traditional web applications on Java, though well structured, are very far from "rapidly developed".  Though I've only ever written one full web application (Java/Tomcat/Struts), it was extremely picky, took longer than expected to debug, and was generally painful when implementing the business logic layer.  In Java's potential defense, it was the only web application I had written in Java (though I'm used to programming systems-level applications in Java), and I believe I could write another web application slightly faster the second time around.

Having said that, I've also written applications in PHP and C#, and they just work better, and are far more forgiving than Java.  More than that, Ruby on Rails was written specifically for rapid application development, which, like Robbie said, allow easy CRUD access to databases.  The problem is that most web sites you will be developing on your own do not need the level of customization that Java offers (and requires you to perform).  Additionally, every DB connection object must be written by hand and isn't that easy to templateize.  There may be a better framework around, especially one that takes advantages of Java 7's new dynamic language support features, but I haven't done the research yet.


问:
How far can I push refactoring without changing external behavior?
According to Martin Fowler, code refactoring is (emphasis mine):

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

What is "external behaviour" in this context? For example, if I apply move method refactoring and move some method to other class, it looks like I change external behaviour, doesn't it?

So, I'm interested in figuring out at what point does a change stop being a refactor and becomes something more. The term "refactoring" may be misused for larger changes: is there a different word for it?

Update. A lot of interesting answers about interface, but wouldn't move method refactoring change the interface?

答:
"Move method" is a refactoring technique, not a refactoring by itself. A refactoring is the process of applying several refactoring techniques to classes. There, when you say, I applied "move method" to a class, you do not actually mean "I refactored (the class)", you actually mean "I applied a refactoring technique on that class". Refactoring, in it most pure meaning is applied to design, or more specific, to some part of application design that can be viewed as a black box.

You could say that "refactoring" used in the context of classes, means "refactoring technique", thus "move method" does not break the definition of refactoring-the-process. On the same page, "refactoring" in the context of design, does not break existing features in the code, it only "breaks" the design (which is its purpose anyway).

In conclusion, "the boundary", mentioned in the question, is crossed if you confuse(mix :D ) refactoring-the-technique with refactoring-the-process.

PS: Good question, btw.


答:
Modern day startups need to hit the market as soon as possible. They don't need to spend about six months in order to release their Java web application.

Twitter for example was built using Rails/Ruby but once it became unscalable, they migrated to the JVM.

Not to mention that the development process isn't productive: code -> compile -> deploy while it is in frameworks like (Rails/Django/Grails): run testing server -> code -> change things and see what happens.

The good news is that JRebel  lets you see code changes instantly.


答: Understanding what programming consists of. You would be surprised on how many managers know nothing about the matter.

Title: What traits do the best managers you've worked for have in common?

Body:
I have been listening to Scott Hanselman and Rob Conery's podcast, This Developer's Life.

In the latest episode, they discuss personality traits:

1.0.4 - Being Mean.

What makes people mean in our
  industry? What about aggressive?
  Confident? What's the difference?
  Would you rather have a drill sergeant
  for a boss, or a zen master? We talk
  to Cyra Richardson and Giles Bowkett.

It got me thinking, what traits did the best managers you've worked for have in common?

EDIT: Just to clarify, as there have been a few close votes, I'm interested in whether there are traits common to managers of developers that are not necessarily those traits that a manager of some other profession requires.

As for whether this is programming related or not, well I don't want to ask this question on a site that isn't about programming because, frankly, I'm not as interested in what people who make cans of soup for a living want from their managers as I am interested in what developers want from their managers.


答:
Data structures are the fundamental bedrock of all programs. You don't necessarily need to have a deep understanding of them, but you absolutely must know how they work.

Why? Because all of your code interacts with and manipulates data. If the data set cannot be stored in a structure, then it cannot be used. Data is like the building materials of a house. Until you put it together into a structure, you just have a useless pile of boards.

Once you have decided on how to think about and define your data set, then you can start using it to do things, the classic algorithm part of the duo. Every single program you write uses a data structure, though in many cases this structure is so simplistic as to almost not exist. A few variables for state data and we are done!

Once you move beyond trivial programs, almost everything requires a data structure. Which would you prefer, a professional architect who designs your skyscraper with best practices and math, or uncle joe bob who immediately starts building?


答: Since you mentioned web development and Java, many people tend to forget that at the beginning using Java Applets in a web browser did not preform well, not only that, but the "sandbox" for the applets were not fully developed and there were security issues with Java Applets being able to run in the browser and access local machine data (aka client side security issue).  Sure Java was solid in the backend and stand-alone applications but I think associating Java the language with Java applets (run on the browser) together kinda screwed up some perceptions about Java as a web development component.  I don't think they ever recovered from that. </p>


答:
most of the biggie tech companies like Microsoft focus mainly on data structures. It appears as if data structures is the only thing that they expect from a graduate.

No, there's more. For example, we also expect that you be a quick learner who can learn new frameworks, APIs or even programming languages within a short amount of time. That's a bare minimum bar. Someone who takes a long time to learn a new framework, API or language will not be a successful developer on most teams at Microsoft.

And of course there are many more aspects that we focus on in interviews other than just raw knowledge of data structures. Ability to deal with ambiguous specifications, for example, or ability to recognize coding patterns that produce insecure code, or a dozen other things. But ability to understand data structures certainly is a very big one.

It is particularly the case that interviews are biased towards testing knowledge of data structures for recent CS graduates. Recent graduates, most of whom do not have a lot of real-world experience, are not expected to be good at the same sorts of things that someone with fifteen years of industry experience would be good at.

I must confess that I was not so strong in data structures

It's good that you know that about yourself. If you're unable or unwilling to change that about yourself then my recommendation is that you don't apply for a job that requires facility with data structures.

there is this general perspective that a good programmer is necessarily a one with good knowledge about data structures.

It's tautological that a good programmer is a programmer who is good at building the sorts of programs that need to be built. Lots of programmers work on tasks that do not require deep knowledge of data structures. Some of them work on tasks that require a deep knowledge of user interface design, for example. Or database normalization. Or whatever. Those people can still be "good programmers" in their domains.

why all this emphasis on Data Structures?

I ask interview questions about data structures because on my team the developers design, implement and manipulate complex data structures all day every day. Yesterday we had four hours of meetings in which a half-dozen developers argued the pros and cons of adding single Boolean field to a particular tree node. There is probably no skill on my team more important than ability to understand data structures at a deep level. It would be foolish to not ask interview questions about it, since that's what we do.

Does not having knowledge in Data Structures really affect one's career in programming?

Well it certainly will prevent you from getting a job on my team. But like I said before, programming is a huge field. There are lots of kinds of computer programming that don't require knowledge of data structures.

is the knowledge in this subject really a sufficient basis to differentiate a good and a bad programmer?

No. But it is almost always sufficient to detect developers who are unlikely to be successful at Microsoft. Since that is what I am primarily interested in detecting, knowledge of data structures is one of the factors I test for in interviews.


问:
Where is java3d used?
The idea of java3d is very interesting, but I don't see any desktop or web applications built using java3d. Where is it used and what perspectives does it have? </p>

答:
World Wind lets you zoom from satellite altitude into any place on Earth. Leveraging Landsat satellite imagery and Shuttle Radar Topography Mission data, World Wind lets you experience Earth terrain in visually rich 3D, just as if you were really there.

It is very much like Google Earth, but written 100% in Java.

Title: Where is java3d used?


问:
Languages to complement C++
I primarily work in C++.  My question is, for a C++ developer, what languages are beneficial to learn, from a job-profile point of view.  For example, I see a lot of work combining C++ and Php these days.  Conversely, I don't see a lot of work combining Ruby and C++ (unfortunately).

Of course, learning another language is beneficial regardless of whether it compliments a language.

答:
Shell/Bash scripting I see is a great thing to have in your tool belt.

PHP as you said is a good one.

C programming is also fair game as far as I am concerned.

Title: Languages to complement C++


答: I would just like to add to the existing answers that were brought up earler, new is perfectly fine to create objects that are pure value objects (i.e. have only properties/getters/setters).  See the Google Testing Blog for more detail.


答: I would love to have an IDE with a fully customizable editor like Emacs.  I don't want to write plugins and then restart the IDE to test them.  I want to define actions in a scripting language (e.g python, ruby) and be able to use them immediately, bind them to key sequences, etc.  The language should be able to manipulate the entire workspace.</p>