问:
Alternatives to oDesk.com for contract work? or is oDesk already one of the best?

Possible Duplicate:

  Where can I find programming work online?

I saw oDesk.com being mentioned in one thread here for contract work and freelance work, and the people listed for hire is asking for $15/hour and up to $80 or $100/hour -- of the ones that I saw for development jobs.

I wonder what alternatives there are besides using oDesk.com for programming contract work?  (The fee it charges seems somewhat high, that for $80 / hour that I bill, it charges $8.89 / hour to the employer, so the employer needs to pay $88.89 / hour.)

答: A site that I think is consistently overlooked is Craigslist for your area. You'll be able to find work and pay 0 commissions. The other site I've used is VWorker which was formerly Rent-A-Coder.</p>


问:
Why do Chrome and Adobe use "download wizards" to install software?
Why do software companies use download wizards for large files instead of letting users download the file directly?

Is it so the user does not get discouraged by the waiting time, or is it something else?

答:
I'm not a big fan of them, but several reasons come to mind:

It allows them to more easily deliver the most recent build to the customer.

It allows them to speed up the download by only delivering to the user the pieces they want to actually install.

Huge downloads via HTTP often stall out. A download manager allows for a smaller initial download, and then to allow for the client app to more reliably download a large software package.

From a marketing standpoint, a 1 meg download may look less intimidating to a potential customer than a 200 meg download.

Another thought - it might prevent web spiders from sucking up all their bandwidth.

ContentLicense: CC BY-SA 3.0


问:
Finding all nearby points in a point cloud
What's the best way to store 3D point cloud data, optimising for time it takes to find all the points in a sphere of 3D space, and also for time it takes to insert new data points into the data set?

Background:

I have a cloud of 3D point data (with each point also including some further attached data), and need to be able to query it to quickly find all the points within a user-specified sphere of 3D space, as well as to quickly add points to the data set.

My current implementation uses a naive linear array of data points, but unsurprisingly, that's not scaling well as my data set grows.

My priority is speed, both for finding points in the cloud and for inserting new points into the cloud (I'd really like to avoid needing to rebalance trees after every insertion, if I can).  I never delete points from the data set, so speed for point removal isn't important at all.  Memory usage also isn't important -- I'm quite happy to throw memory at this problem, if it'll speed things up!

答:
Consider an octree :

An octree is a tree data structure in which each internal node has
  exactly eight children. Octrees are most often used to partition a
  three dimensional space by recursively subdividing it into eight
  octants. Octrees are the three-dimensional analog of quadtrees. The
  name is formed from oct + tree, and normally written "octree", not
  "octtree". Octrees are often used in 3D graphics and 3D game engines.


答: Look into Binary Space Partitioning trees. Bonus: most DBs have some sort of geometrical indexing, which means queries like 'find all points within distance D from point' (equivalent to a sphere) will be very fast. IOW probably no need to implement this yourself.</p>

Title: Finding all nearby points in a point cloud

Body:
What's the best way to store 3D point cloud data, optimising for time it takes to find all the points in a sphere of 3D space, and also for time it takes to insert new data points into the data set?

Background:

I have a cloud of 3D point data (with each point also including some further attached data), and need to be able to query it to quickly find all the points within a user-specified sphere of 3D space, as well as to quickly add points to the data set.

My current implementation uses a naive linear array of data points, but unsurprisingly, that's not scaling well as my data set grows.

My priority is speed, both for finding points in the cloud and for inserting new points into the cloud (I'd really like to avoid needing to rebalance trees after every insertion, if I can).  I never delete points from the data set, so speed for point removal isn't important at all.  Memory usage also isn't important -- I'm quite happy to throw memory at this problem, if it'll speed things up!


答:
To add to GrandmasterB's list above (btw, love the alias ! :)

A download wizard can figure stuff out for the user, like exact platform version, 32/64 bit, and then download the most appropriate version of the software

Some users are dumb and will do stuff like download the same browser over and over just to get it working. The download manager can save a lot of bandwidth this way. It can also look around the user's PC and see if any bundled software also needs updating.

Title: Why do Chrome and Adobe use "download wizards" to install software?

Body:
Why do software companies use download wizards for large files instead of letting users download the file directly?

Is it so the user does not get discouraged by the waiting time, or is it something else?


答: Plus, they will have better statistics on the number of installations.</p>


问:
What’s the opposite of abstraction?
As I understand it, abstraction is the term we use for when more meaning is created out of something simpler without altering it. It is derived from the latin verb abstrahere (to ‘draw away’). For instance, text is just one abstraction of binary data—as are bitmaps. So, in computers, text and bitmaps exist on top of (are implemented in terms of) binary data.

My question is: what is the opposite term? If I want to know the possible more basic things that bitmaps could be implemented in terms of other than binary data—things like tiles for a mosaic or fabric patches for a patchwork quilt—what am I asking for? Is there a word for that?

Abstraction has connotations of generalization and the opposite process of that is specialization. IDK whether that helps.

答:
Usually

Concretization - As in C++ Concrete class

and in some cases:

Specialization - As in C++ Template Specialization

Added 12-June-2012: This is a lovely term:

Reification - As in several programming languages

Title: What’s the opposite of abstraction?


问:
When do 'static functions' come into use?
OK, I've learned what a static function is, but I still don't see why they are more useful than private member functions. This might be kind of a newb-ish question here, but why not just replace all private member functions with static functions instead?</p>

答:
It's funny how nobody has been able to give a good answer yet. I'm not sure this one is either. You should probably take it as a hint that they should be used as little as possible. They're after all procedural rather than OOP.

Here are some more examples:

In Obj-C, where they're called class methods, they're commonly used as allocation wrappers where the object is put in the reference counting pool before being returned.

Another example from Obj-C is to register a new class in to a class collection. Let's say you have a set of classes each handling one type of file. When you create a new class for a new file type you could register it to the collection (a global variable) using a static method in the class that determines the type of file.

In C++ another use I can think of is to softly catch errors. Your constructor function can't fail, except by throwing an exception. You could set an error instance variable, but that's not always appropriate. Instead you can do the parts that might fail in a static wrapper and then allocate and return the new object, or NULL on failure.


答:
Let's say you want to compute the sinus of something.

Without static:

```<code>Math math = new Math()
double y = math.sin(x)
</code>```

With static:

```<code>double y = Math.sin(x)
</code>```

It makes no sense to make sin non-static. It is stateless and just processes the input.

Static functions are not tied to a particular objects. They are "general" functions that are independent of the internal state of the object.

Title: When do 'static functions' come into use?

Body: OK, I've learned what a static function is, but I still don't see why they are more useful than private member functions. This might be kind of a newb-ish question here, but why not just replace all private member functions with static functions instead?</p>

Body:
Let's say you want to compute the sinus of something.

Without static:

Math math = new Math()
double y = math.sin(x)

With static:

double y = Math.sin(x)

It makes no sense to make sin non-static. It is stateless and just processes the input.

Static functions are not tied to a particular objects. They are "general" functions that are independent of the internal state of the object.


问:
I don't understand the arguments against operator overloading
I just read one of Joel's articles in which he says:

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

```<code>i = j * 5;
</code>```

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it.

(Emphasis mine.) Scared of language features that hide things? How can you be scared of that? Isn't hiding things (also known as abstraction) one of the key ideas of object-oriented programming? Everytime you call a method a.foo(b), you don't have any idea what that might do. You have to find out what types a and b are, something which might be declared somewhere  altogether else. So should we do away with object-oriented programming, because it hides too much things from the programmer?

And how is j * 5 any different from j.multiply(5), which you might have to write in a language that does not support operator overloading? Again, you would have to find out the type of j and peek inside the multiply method, because lo and behold, j might be of a type that has a multiply method that does something terribly witty.

"Muahaha, I'm an evil programmer that names a method multiply, but what it actually does is totally obscure and non-intuitive and has absolutely nothing to do whatsoever with multiplying things." Is that a scenario we must take into consideration when designing a programming language? Then we have to abandon identifiers from programming languages on the grounds that they might be misleading!

If you want to know what a method does, you can either glance at the documentation or peek inside the implementation. Operator overloading is just syntactic sugar, and I don't see how it changes the game at all.

Please enlighten me.

答:
In addition to what has already been said here, there's one more argument against operator overloading. Indeed, if you write +, this is kind of obvious that you mean addition of something to something. But this is not always the case.

C++ itself provides a great example of such a case. How is stream << 1 supposed to be read? stream shifted left by 1? It is not obvious at all unless you explicitly know that << in C++ also writes to the stream. However, if this operation were implemented as a method, no sane developer would write o.leftShift(1), it would be something like o.write(1).

The bottom line is that by making operator overloading unavailable, the language makes programmers think about the names of operations. Even if the chosen name is not perfect, it is still harder to misinterpret a name than a sign.

ContentLicense: CC BY-SA 2.5


答: In the case of Chrome, it is probably also related to the way they can apply binary diffs to your already-installed version. A download manager / installer that knows things about the product can choose to download only the needed parts (check current version, check available version, request and download suitable diff, apply diff), as opposed to a generic downloader that would have to download the full release.</p>


答:
In the context of programming its reduction.

Reductionism

As in: "I have reduced the problem to its simplest terms."

Title: What’s the opposite of abstraction?

Body:
As I understand it, abstraction is the term we use for when more meaning is created out of something simpler without altering it. It is derived from the latin verb abstrahere (to ‘draw away’). For instance, text is just one abstraction of binary data—as are bitmaps. So, in computers, text and bitmaps exist on top of (are implemented in terms of) binary data.

My question is: what is the opposite term? If I want to know the possible more basic things that bitmaps could be implemented in terms of other than binary data—things like tiles for a mosaic or fabric patches for a patchwork quilt—what am I asking for? Is there a word for that?

Abstraction has connotations of generalization and the opposite process of that is specialization. IDK whether that helps.


答:
Let's start from scratch. First of all, what indeed is abstraction?

The Problem/Motive

When you program, you often have to solve very specifically detailed problems.

The primary motive for abstraction is when you might find yourself at a situation where your program handles the whole problem as a single unit, with many discrete little peculiarities that require attention and understanding. The problem here is that it it's hard for human beings to handle such huge amounts of data at once.

The Solution: Abstraction

In order for you to be able to understand just what you need to in order to implement your idea, you extract detailed solutions into simplified abstractions.

For example, let's look at ORM (Object-Relational Mapping), where SQL is abstracted into objects.

In order to insert a new item to a database without abstractions, a programmer has to know SQL. So to insert a new item a programmer needs to remember the SQL syntax for inserting a new item into a table:

```<code>INSERT INTO Items (field1, field2) VALUES (value1, value2)
</code>```

But with abstractions, the programmer only needs to be aware of the idea of what he wishes to do. An object-oriented abstraction might look like:

```<code>Item item = new Item(value1, value2)
</code>```

You can even go a bit further and think about the fact that SQL itself is a huge abstraction for tons of sophisticated data-storage structures and algorithms, which are fully at your fingertips for the price of learning a simple declarative language.

The Opposite of Abstraction

Based on what we now defined that abstraction is really all about making it sufficient to only know the quintessential concept at hand, we can easily deduce that the opposite of abstraction is in fact esoterica, where usage or understanding entails having some sort of specialized knowledge of the subject's peculiarities.

Title: What’s the opposite of abstraction?

Body:
Let's start from scratch. First of all, what indeed is abstraction?

The Problem/Motive

When you program, you often have to solve very specifically detailed problems.

The primary motive for abstraction is when you might find yourself at a situation where your program handles the whole problem as a single unit, with many discrete little peculiarities that require attention and understanding. The problem here is that it it's hard for human beings to handle such huge amounts of data at once.

The Solution: Abstraction

In order for you to be able to understand just what you need to in order to implement your idea, you extract detailed solutions into simplified abstractions.

For example, let's look at ORM (Object-Relational Mapping), where SQL is abstracted into objects.

In order to insert a new item to a database without abstractions, a programmer has to know SQL. So to insert a new item a programmer needs to remember the SQL syntax for inserting a new item into a table:

INSERT INTO Items (field1, field2) VALUES (value1, value2)

But with abstractions, the programmer only needs to be aware of the idea of what he wishes to do. An object-oriented abstraction might look like:

Item item = new Item(value1, value2)

You can even go a bit further and think about the fact that SQL itself is a huge abstraction for tons of sophisticated data-storage structures and algorithms, which are fully at your fingertips for the price of learning a simple declarative language.

The Opposite of Abstraction

Based on what we now defined that abstraction is really all about making it sufficient to only know the quintessential concept at hand, we can easily deduce that the opposite of abstraction is in fact esoterica, where usage or understanding entails having some sort of specialized knowledge of the subject's peculiarities.


答:
Abstraction does come from abs-trahere and I'd say it is best translated as "draw from" (although the literal translation would thus be de-traction). I've tried to explain that in a blog post.

Abstraction is the process of drawing the essence from something concrete. Concrete things are usually enormously complex. For example, if you look at the closest chair you can see, there's a lot of details, that actually constitute it. Its material, its structure, its shape, and so on. But none of these things is really are essential. What's essential is, that you can sit on it.

Your "abstract" of something is what you see, when you look at it. When you look at that chair, you see a chair. A wrestler might actually see a weapon instead.

So the result of abstraction really is the essence of something from a given perspective.

In the case of a bitmap or a text, the abstraction is, that you think of a given value as something fulfilling a specific purpose. Depending on the programming language at hand, you can represent your thinking within the language semantics.

But for you, it doesn't really matter, whether the underlying data is "binary". It would work just as well if it were read in real time from a roll of toiled paper, that has the data encoded with 13 bit hole punching pattern. You don't really care.

Of course implementing a concrete bitmap using binary data stored in memory has some obvious advantages and most people will prefer that. Yet, there's still a number of ways to actually encode bitmap information for example. And it might even make sense to use different approaches along side each-other. But except for the little piece of code, which chooses the representation based on a number of constraints, you do not want to have any knowledge about the concrete nature of the bitmap. You only care about what's essential from your perspective. In this example it's probably a number of methods to manipulate pixel data.

Because an abstraction is actually first and foremost an idea (as in an ideal model of something), the opposite might be called "incarnation". Since programming is rarely a carnal thing, one might go with "implementation", while abstractions are often represented as interfaces.

Concretization as said by @Lior, is also is a very suitable word, even though it focuses more on the means (i.e. rendering something concrete - which of course is inevitable) rather than the actual goal (i.e. to implement an idea).

Title: What’s the opposite of abstraction?


答:
Implementation.

Abstraction is short words, is the mental process of obtaining a (reduced) model of a real world thing, and "compact" into a concept or an idea.

So the opposite is to take a concept or an idea, and turn it, into a reald world thing ;-)

Title: What’s the opposite of abstraction?


答: "Concrete" is the opposite of "abstract", so the opposite of "abstraction" is logically "concretization". There isn't exactly a meaningful opposite however since you generally only talk about abstraction and rarely think about it's opposite.</p>

Title: What’s the opposite of abstraction?


问:
How can I translate ML code to F#?
Recently I found a book, Purely Functional Data Structures and all the examples in this book are given in ML with Haskell versions in its appendix. But I only know one programming language with the functional paradigm: F#. And after a bit of research, I found out that F# is (or was) the .NET port of CAML, which is derived from ML. I've heard it mentioned that CAML is just a dialect of ML.

Given that, is it possible to translate ML to F# without a lot of knowledge of ML? What are the key differences from the languages? Or is my best bet to just learn ML instead?

答:
I'm looking at my copy of the book here and the only things I think are not directly translatable to F# would be

The signatures used to describe some of the generic data-types.

The custom notation he uses for the lazy algos.

In both cases converting should be pretty straightforward if you know F# and can understand the meaning of the book (instead of just trying to copy-paste the codes)

I also don't think you need to be afraid of not understanding the ML. I never programmed in it but got used to the style after a while and was able to get through the book just fine. The languages are quite similar specially considering this is a didactic book that doesn't rely on the tiny corner cases of the languages involved (and ML is a very solid little language!).

Title: How can I translate ML code to F#?


问:
Stuff every programmer needs while working
I've been tasked with creating a fun and relaxing environment, one thing I know that I want is ergonomic mice and keyboards, others have suggested exercise balls and bands.

What is it that every programmer needs while working? What might not be necessary but would be nice to have anyway?

Note: this question was asked previously, but has been recommended to be posted here. See this link for the previous responses: https://stackoverflow.com/questions/3911911/stuff-every-programmer-needs-while-working-closed

答: Dual monitors

Body: Dual monitors


问:
LINQ to SQL - Business logic in another assembly?
So I am trying my hand at this whole tiered application thing with ASP.NET 4.  The software I've developed is a maintenance nightmare and it isn't very well organized.  I've done some looking around the web and can't seem to find an example of what I'm looking for here.  Someone please pick this design apart.

My Data Access Layer will be an assembly with LINQ to SQL.

I will have a Business Logic Layer that references the DAL assembly and does what BLLs do.  Very general and basic stuff.

Then I will have a business objects class that does some that is data-related but is more "work" type stuff - like generating documents, etc.

The web site will interact with the BLL and the business objects.

So:

```<code>    DAL
     |
     |
     |
    BLL----------BO
     |           |
     |           |
     |           |
    Web----------|
</code>```

Am I making this way too complicated?

Should I just put my business logic right in there with the LINQ classes in the DAL?  I'm not sure how a DataContext would work in a separate assembly with classes that inherit from LINQ classes.  Thoughts?

答:
That works fine.  Referencing and consuming your DataContext from the DAL is no different than dealing with any other kind of class.

I tend to create my own classes that mirror LINQ classes (usually as WCF entities) instead of trying to extend LINQ entities directly.  There is a lot of overhead in keeping LINQ objects around too long, it might be a non-issue for you in a web based environment if you're only keeping objects around for one request/response.

I have also seen DataContext's defined in their own assembly, then application-specific functionality grafted on to LINQ entities by way of a partial class and/or extension methods.  That works ok, so long as the DataContext/Entities don't change in an unexpected, critical way.

OwnerDisplayName: Mark Williams

OwnerDisplayName: Pete M


答:
The The Onion Architecture article inspired me a great deal regarding layered architectures.

According to it, you would define service and repository interfaces in your BLL project. Implementations of these are kept in a separate service implementation project (call it the DAL if you like). Your web project references both and injects the implementations into the BLL. The BLL does not reference any of the others and only containing the service layer code, business entities and service and repository interfaces.

You could say the web project is configuring the BLL (model) with appropriate service implementations.

Title: LINQ to SQL - Business logic in another assembly?

Body:
So I am trying my hand at this whole tiered application thing with ASP.NET 4.  The software I've developed is a maintenance nightmare and it isn't very well organized.  I've done some looking around the web and can't seem to find an example of what I'm looking for here.  Someone please pick this design apart.

My Data Access Layer will be an assembly with LINQ to SQL.

I will have a Business Logic Layer that references the DAL assembly and does what BLLs do.  Very general and basic stuff.

Then I will have a business objects class that does some that is data-related but is more "work" type stuff - like generating documents, etc.

The web site will interact with the BLL and the business objects.

So:

```<code>    DAL
     |
     |
     |
    BLL----------BO
     |           |
     |           |
     |           |
    Web----------|
</code>```

Am I making this way too complicated?

Should I just put my business logic right in there with the LINQ classes in the DAL?  I'm not sure how a DataContext would work in a separate assembly with classes that inherit from LINQ classes.  Thoughts?

OwnerDisplayName: TT.


问:
Is the concept of computational complexity important for software developers?
I was under the impression that the concepts of time and memory complexity are a must for graduates of compsci courses, but having studied engineering I have no knowledge if that is the case. I have recently been surprised to interview some graduates of a local college that do not even know the concept. I guess my question is:

Is the concept of computational complexity important for software developers? And should it be taught in undergraduate courses?

答:
In most universities, I assume (I hope!) that time and memory complexity is definitely part of their courses.

Now, these "complexities" are a very elastic topic. Whether people should really know all the theory like "ZPP is the complexity class of decision problems that can be solved with zero error on a probabilistic Turing machine in polynomial time." and such kind of stuff is questionable. I personally consider these advanced theories irrelevant to software development.

On the opposite, I consider that every developer should be aware of the time/space complexity of the data structures and algorithms they use.


答:
Yes

Understanding the basics of complexity is important and should be something that you learn as an undergrad.  In fact I think it is usually touched on in whichever class teaches you about data structures.  I can understand graduates not understanding or not remembering, but I can't see them not having been taught the basics of complexity.

Update: Why is it Important

I was on a database migration at a particular job.  We had a deadline for when the migration needed to get done.  The person who wrote the script didn't have any grounding in complexity.  Unfortunately, nobody else looked closely at the logic he used in in the script.  I don't remember the specifics other than he used a doubly nested loop instead of a hashtable.  After a week of the script running continuously we took at the look of the logic, realized the problem.  It took something like 5 hours to complete after the change.  We almost missed the deadline for migration completion as a result of someone not understanding complexity.

The point is it's easy to accidentally make something that is orders of magnitude slower, or will always run out of memory before the job completes.  While faster machines with more memory can mitigate small mistakes, they often cannot mitigate complexity issues.

Body:
I was under the impression that the concepts of time and memory complexity are a must for graduates of compsci courses, but having studied engineering I have no knowledge if that is the case. I have recently been surprised to interview some graduates of a local college that do not even know the concept. I guess my question is:

Is the concept of computational complexity important for software developers? And should it be taught in undergraduate courses?


答:
I find that asking whether it's "important or not" is rather vague.

You'll find many people evangelizing on how every smallest bit of knowledge in this world is strictly required in their opinion. But that's a bit pointless, because one can never know everything, and one should not be expected to unless it helps one to meet the requirements his job poses. I prefer to take a more pragmatic approach to educational prerequisites, in general, unless it's a matter of hobby or arbitrary personal preference.

Is it important for programmers that are expected to write extremely efficient code or innovative infrastructural algorithms? Yes.

Is it important for programmers who develop conventional web applications? They can manage without it or get efficient implementations in the open source world.

Is it important for programmers who develop GUIs for applications? Probably not, because successful GUI frameworks abstract all those small details away.

It's always nice to know, just like anything, but it doesn't keep many (or even most) programmers from simply doing their job to the satisfaction of their employers.

On the other hand, if one signed up for higher studies, in search of fundamental and theoretical education, one should be expected to learn subjects that are by definition more theoretical than practical. In my opinion, it is essential that CompSci. students learn about complexity, just as it's important they learn about calculus.

But anyway, since when do CompSci. programs teach people how to be good programmers? For that you have specialized training programs and practical experience (either yours or your fellow programmers who can share theirs with you).

Title: Is the concept of computational complexity important for software developers?


答: Coffee Machine

Title: Stuff every programmer needs while working

Body:
I've been tasked with creating a fun and relaxing environment, one thing I know that I want is ergonomic mice and keyboards, others have suggested exercise balls and bands.

What is it that every programmer needs while working? What might not be necessary but would be nice to have anyway?

Note: this question was asked previously, but has been recommended to be posted here. See this link for the previous responses: https://stackoverflow.com/questions/3911911/stuff-every-programmer-needs-while-working-closed

Body: Coffee Machine


答: Many beginners suffer from micro-optimization obsession. Learning comp. complexity steers students towards a much more practical way of estimating performance and scalability, in my experience.</p>


问:
What factors should be evaluated when determining a desktop software price?
What factors should be evaluated when determining a desktop software price?</p>

答:
Some factors to consider:

Is your market a small niche of users who really need this particular product, or mass market?

Can you divide the feature set into basic and premium (tiered pricing)

What are the obstacles to adoption, and what would it take to entice customers to dip their toe in the water?

Are there network effects, such that a high adoption rate makes the product more useful to other users, or is each customer isolated?

Are you trying to shift customers away from competing products or do you have an open field?

Will word of mouth or advertising be more effective at spreading the word?

Will you be providing frequent upgrades, and how will you distribute them?

What OS are you targeting?

Are the customers business, government, or consumer?

Can you sell subsidiary services, such as support, plugins, templates, etc.?

Can you leverage a community of users to help each other, and monetize the community via advertising etc., rather than the bits themselves.


问:
What are the pros and cons of Coffeescript?
Of course one big pro is the amount of syntactic sugar leading to shorter code in a lot of cases. On http://jashkenas.github.com/coffee-script/ there are impressive examples. On the other hand I have doubts that these examples represent code of complex real world applications. In my code for instance I never add functions to bare objects but rather to their prototypes. Moreover the prototype feature is hidden from the user, suggesting classical OOP rather than idiomatic Javascript.

The array comprehension example would look in my code probably like this:

```<code>cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...
</code>```

答:
Pros

view Trevor Burnham's answer.

plus, you can think of yourself as of hip guy, who is doing trendy stuff, instead of messing with the dirt of javascript.

Cons

CoffeeScript is nothing more than syntactic sugar and pink glasses.

For easy stuff - CoffeeScript is redundant, because doing easy stuff is easy in any language. And jQuery is probably even simpler than CoffeeScript.

For hard stuff - you must understand your medium. And your medium is HTML,DOM and CSS, Javascript is merely a tool to interconnect them, yet - all APIs are written specifically for Javascript. Using other language, which would then be compiled to "real" one - is quite risky, be it Java(GWT), Dart or CoffeeScript.

Anti-patterns or banal ignorance of language rules, can be fixed by reading one-two good books. And im quite sure Coffeescript  has its own anti-patterns.

IDE support for Coffeescript is even worse than for JS.


答:
Ergonomic chair

I think one would definitely need an ergonomic chair since most of your time is spent in front of the PC. If you are using a notebook then a notebook stand would be nice as well.

Sufficient light, not too much noise and coffee :)


答: This DAL and BLL gives me some definite headaches :-) . From my point of view, I would suggest you to learn ASP.NET MVC, it's way better organized and easy to maintain framework. You can have a different assembly for your domain objects and interface in another. The best thing about this is you don't need to manage too many things to achieve a loose coupled application. Just give it a go and i am definite, you will like it.</p>


问:
Does a mobile app need to poll external data sources or can it receive data in other ways?
I'm beginning the design stages of a mobile application. I'm looking for knowledge about common practices for user notifications. I understand that the SDK for the device will expose methods which will allow me to notify a user how and when I need it to. What I'm not sure about is how my application gets notified from a external data source. Is it common practice to poll a web service for data periodically? Or is it more likely that my application will have the facility to receive data at any time?

For example:
I have a website which asks users to fill out a contact form. I would like my mobile app to display a notification when one of these forms gets filled out. Should my app be polling my data server for updated records or should my site be notifying my app somehow of a new record?

Any opinions or advice are welcomed. Thanks.

答:
Normally network elements in a mobile data network do not allow establishing IP connections from the public internet. That anyhow would be rather difficult since a server on the internet does not know the mobile devices dynamic IP address.

It is possible to configure exceptions, i.e. equip mobile devices with fixed, non-NAT-ed IP addresses, in GSM network usually via a separate APN on the GGSN. An example would be machine-to-machine applications.

Talk to your mobile network operator. He usually will be interested only if there is a business case for him.


问:
Should you use C# and F# together
I know you can use C# and F# together in the same project however I'm not sure if its a good idea to do so.

It seems to me that mixing two very different coding styles (functional vs OOP) could cause a lack of cohesion in the design. Is this correct?

答:
There's nothing wrong with mixing languages in a product as long as you use each appropriately and they "play nice" together.

If there is part of your project that would be best coded using a functional language then it makes sense to code it in F#. Similarly for C#.

What would be pointless (at best) would be mixing languages for the sake of it.

Title: Should you use C# and F# together


问:
NoSQL Modify operations performance
I am working on the application which in near future (hopefully) will have to process tens or hundreds of thousands of items (item is currently one row in relational database table) per second.

If I understood it right NoSQL databases are superheroes of data retrieval thanks to map-reduce magic. But will NoSQL databases provide extra performance in comperatison to relational ones in my case?

答: I remember there is a feature in RavenDb that indexes are updated in separate threads. The advantage of this is higher performance of modification operations and disadvantage is that index is not always up-to-date. But I am not sure whether some relational databases have this feature.</p>

Title: NoSQL Modify operations performance


答:
From what I've seen, it seems that big-O notation and time and memory complexity are emphasized a lot in formal computer science education... however being self-taught, this perception is based on hearing and reading what people with such educations say and write.

Though I do believe the general ideas and concepts are important, I don't believe the formalization of it (such as big-O notation and various terminology) matters nearly as much, except for the purposes of communication.  Just because someone isn't familiar with the formal notation and terminology doesn't mean they can't see how and why one algorithm would be faster than another in a particular case.  People can see that the time taken to search a balanced binary tree relates to the base-2 logarithm of the number of nodes without first learning about complexity theory in any formal sense, if they understand how the tree works and have a reasonable grasp of high school math.  It's important to know when to pay attention to complexity and memory use, and to consider typical and worst cases, though... but some people don't.  Of course, a formal background in the theory might help, but not having it doesn't mean one can't apply the concepts.

The notation and terminology become important for communication.  They give a nice way to convey a quantification of the performance of an algorithm to someone else.  Because it comes up in papers and explanations frequently, it's useful to have at least a vague understanding of it so that they're easier to follow.

So yes, the concepts are important (though less so when resources and time are ample but data isn't).  But though the concepts are important, the formalization of them is often not so important -- and one needs to remember that the notation and terminology are not the same as the concepts themselves.

Edit:

I wouldn't claim to understand the concepts in as much detail as someone who's formally studied, but a lot of the general ideas just make sense.  I do think there's value in formally studying this, but some of that value can still exist without.

As for introducing the concepts (outside formal study), I think a good start is to encourage people to think about how much memory overhead the data structures have, what steps the algorithms involve, and how these things change with different data.

It also helps to consider hypothetical situations and changes, like considering what happens if a tree is balanced versus what happens if it's as unbalanced as possible, or how many levels into the tree most of the nodes would be, or how many more nodes it can hold if the depth is increased one level.  This way of thinking is generally useful for programmers anyway, not just when looking at complexity; and if applied to thinking about how algorithms and data structures perform under different circumstances it naturally points in the same direction as a more formal examination of complexity would.


答: An expensive but very good thing to have is an electrically height adjustable desk. Allows the developers to work sitting as normal or raise the desk (with the touch of a button) to a height that lets them work standing up.</p>


问:
How can a developer test himself for starting a development company on his own?
Ya !! you can say "out of work" people have these thoughts, but then, what can one do :-P . My question is somewhat deep thought.

How can someone evaluate himself as a developer and manager to understand whether or not, he is fit for starting a commercial venture on his own. Starting a development company doesn't need too much of an investment and neither it requires a big team. If one is capable developer, then he can definitely get the ball rolling on day one. And may be that's the reason why there are so many freelancers around the world.

Doubts are severe thing and once they creep-in, they make travel tough. So, can there be some things or self-assessment kinda test that one must evaluate and pass to boost his idea of development venture.

答:
Start an open source project.  This will test a lot of your skills, such as judging and meeting the needs of a market, managing collaboration, marketing, self-discipline, keeping up with changing needs and maintenance, etc.  </p>

<p>Yeah, it won't bring in money right away.  If you need income this second, you're in a bit of a bind, though something like ODesk might help you there.  What it will do is keep your skills fresh, help develop new ones, and build your reputation. It's a good resume enhancer too, if the project is even a little successful.  And, if it's very successful, there's ways to pull some income from it (write the how-to book on it, charge for support, etc.) If it works, and you like doing it, you can start a proprietary company either building on that, or with something else. </p>

Body:
Start an open source project.  This will test a lot of your skills, such as judging and meeting the needs of a market, managing collaboration, marketing, self-discipline, keeping up with changing needs and maintenance, etc.

Yeah, it won't bring in money right away.  If you need income this second, you're in a bit of a bind, though something like ODesk might help you there.  What it will do is keep your skills fresh, help develop new ones, and build your reputation. It's a good resume enhancer too, if the project is even a little successful.  And, if it's very successful, there's ways to pull some income from it (write the how-to book on it, charge for support, etc.) If it works, and you like doing it, you can start a proprietary company either building on that, or with something else.


答:
I think maybe being a great developer is like being a great chef: the fact that you can run a kitchen doesn't mean you can run a restaurant. So first maybe you should think about whether you enjoy business as much as you enjoy development, because they are very different things, and running a business will take a lot away from you being a developer, too. Also, with freelancing, all you have is yourself to worry about. When you become an actual business with an EIN, employees, etc. you have to consider legal matters and other things, which could potentially be very expensive and also emotionally draining.

I like kylben's idea about starting an open-source project first. Because to make money at it the key is reputation; unless have plenty of people to support you and plenty of momentum already, you shouldn't be considering a startup yet, I think.

Title: How can a developer test himself for starting a development company on his own?

Body:
Ya !! you can say "out of work" people have these thoughts, but then, what can one do :-P . My question is somewhat deep thought.

How can someone evaluate himself as a developer and manager to understand whether or not, he is fit for starting a commercial venture on his own. Starting a development company doesn't need too much of an investment and neither it requires a big team. If one is capable developer, then he can definitely get the ball rolling on day one. And may be that's the reason why there are so many freelancers around the world.

Doubts are severe thing and once they creep-in, they make travel tough. So, can there be some things or self-assessment kinda test that one must evaluate and pass to boost his idea of development venture.


答:
The reason Operator Overloading is scary, is because there are a large number of programmers that would never even THINK that * doesn't mean simply "multiply", whereas a method like foo.multiply(bar) at least instantly points out to that programmer that someone wrote a custom multiply method.  At which point they would wonder why and go investigating.

I have worked with "good programmers" who were in high level positions that would create methods called "CompareValues" that would take 2 arguments, and apply the values from one to the other and return a boolean.  Or a method called "LoadTheValues" that would go to the database for 3 other objects, get values, do calculations, modify this and save it to the database.

If I am working on a team with those types of programmers, I instantly know to investigate things they have worked on.  If they overloaded an operator, I have no way at all of knowing that they did it except to assume they did and go looking.

In a perfect world, or a team with perfect programmers, operator overloading is probably a fantastic tool.  I have yet to work on a team of perfect programmers though, so that's why it's scary.

Title: I don't understand the arguments against operator overloading

Body:
I just read one of Joel's articles in which he says:

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

```<code>i = j * 5;
</code>```

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it.

(Emphasis mine.) Scared of language features that hide things? How can you be scared of that? Isn't hiding things (also known as abstraction) one of the key ideas of object-oriented programming? Everytime you call a method a.foo(b), you don't have any idea what that might do. You have to find out what types a and b are, something which might be declared somewhere  altogether else. So should we do away with object-oriented programming, because it hides too much things from the programmer?

And how is j * 5 any different from j.multiply(5), which you might have to write in a language that does not support operator overloading? Again, you would have to find out the type of j and peek inside the multiply method, because lo and behold, j might be of a type that has a multiply method that does something terribly witty.

"Muahaha, I'm an evil programmer that names a method multiply, but what it actually does is totally obscure and non-intuitive and has absolutely nothing to do whatsoever with multiplying things." Is that a scenario we must take into consideration when designing a programming language? Then we have to abandon identifiers from programming languages on the grounds that they might be misleading!

If you want to know what a method does, you can either glance at the documentation or peek inside the implementation. Operator overloading is just syntactic sugar, and I don't see how it changes the game at all.

Please enlighten me.


问:
Why do languages such as C and C++ not have garbage collection, while Java does?
Well, I know that there are things like malloc/free for C, and new/using-a-destructor for memory management in C++, but I was wondering why there aren't "new updates" to these languages that allow the user to have the option to manually manage memory, or for the system to do it automatically (garbage collection)?

Somewhat of a newb-ish question, but only been in CS for about a year.

答:
"All" a garbage collector is is a process that runs periodically checking to see if there are any unreferenced objects in memory and if there are deletes them. (Yes, I know this is a gross oversimplification). This is not a property of the language, but the framework.

There are garbage collectors written for C and C++ - this one for example.

One reason why one hasn't been "added" to the language could be because of the sheer volume of existing code that would never use it as they use their own code for managing memory. Another reason could be that the types of applications written in C and C++ don't need the overhead associated with a garbage collection process.


答:
I don't have the exact quotes but both Bjarne and Herb Sutter says something along the lines:

C++ doesn't need a garbage collector, because it has no garbage.

In modern C++ you use smart pointers and therefore have no garbage.

Title: Why do languages such as C and C++ not have garbage collection, while Java does?

Body:
Well, I know that there are things like malloc/free for C, and new/using-a-destructor for memory management in C++, but I was wondering why there aren't "new updates" to these languages that allow the user to have the option to manually manage memory, or for the system to do it automatically (garbage collection)?

Somewhat of a newb-ish question, but only been in CS for about a year.


答:
A Do Not Disturb option

I actually like working in a place where I am not isolated all day long, where I am in tune with what else is going on in the office.  But sometimes the thing I need most is the ability to shut out all the noise, and to send a strong " do not interrupt me unless there's a fire" signal.


答:
Garbage collection requires data structures for tracking allocations and/or reference counting. These create overhead in memory, performance, and the complexity of the language. C++ is designed to be "close to the metal", in other words, it takes the higher performance side of the tradeoff vs convenience features. Other languages make that tradeoff differently.  This is one of the considerations in choosing a language, which emphasis you prefer.  </p>

<p>That said, there are a lot of schemes for reference counting in C++ that are fairly lightweight and performant, but they are in libraries, both commercial and open source, rather than part of the language itself.  Reference counting to manage object lifetime is not the same as garbage collection, but it addresses many of the same kinds of issues, and is a better fit with C++'s basic approach. </p>

Body:
Garbage collection requires data structures for tracking allocations and/or reference counting. These create overhead in memory, performance, and the complexity of the language. C++ is designed to be "close to the metal", in other words, it takes the higher performance side of the tradeoff vs convenience features. Other languages make that tradeoff differently.  This is one of the considerations in choosing a language, which emphasis you prefer.

That said, there are a lot of schemes for reference counting in C++ that are fairly lightweight and performant, but they are in libraries, both commercial and open source, rather than part of the language itself.  Reference counting to manage object lifetime is not the same as garbage collection, but it addresses many of the same kinds of issues, and is a better fit with C++'s basic approach.


问:
Should one define an interface and code an adapter for it whenever a dependency is found?
Given a particular third-party class/library you want to make use of, the simplest thing to do would be to just hardcode API calls to it through your application.

On the other hand you have the possibility of defining a interface that generically dictates what you want -not how-, and then follow the Adapter pattern to bind your interface to the third-party class.

I currently feel inclined to the second option because:

It creates a single point of change if you ever want to replace the functionality provider

In a similar way, it allows you to add more providers without changing your application code

It permits following your own naming conventions, simpler method signatures, etc

The thing is, I'm not experienced with this approach and I don't know how complicated or inconvenient it can get. I'd also like to know if are there any common errors when following this pattern.

In my particular case I don't want to wrap either a giantic library -e.g. a GUI- or a small function. Also there are actual possiblities I'll change my provider in the future, so this is not a YAGNI.

Thank you

答:
You've identified one common error - wrapping the entire interface when you only need a part of it. This will drastically increase the code you write and have to maintain when the dependency changes.

By only wrapping the API calls you actually need you are also defining exactly what it is you want from the dependency. This will help keep things manageable and also allow you to more easily evaluate new providers - do they implement at least the functions you already use?


答:
Because, when using the power of C++, there is no need.

Herb Sutter: "I've haven't written delete in years."

see Writing modern C++ code: how C++ has evolved over the years    21:10

It may surprise many experienced C++ programmers.

ContentLicense: CC BY-SA 4.0


问:
Could it be more efficient for systems in general to do away with Stacks and just use Heap for memory management?
It seems to me that everything that can be done with a stack can be done with the heap, but not everything that can be done with the heap can be done with the stack. Is that correct? Then for simplicity's sake, and even if we do lose a little amount of performance with certain workloads, couldn't it be better to just go with one standard (ie, the heap)?

Think of the trade-off between modularity and performance. I know that isn't the best way to describe this scenario, but in general it seems that simplicity of understanding and design could be a better option even if there is a potential for better performance.

答: Simula used the heap for everything. Putting everything on the heap always induces one more level of indirection for local variables, and it puts additional pressure on the Garbage Collector (you have to take into account that Garbage Collectors really sucked back then). That's partly why Bjarne invented C++.


答:
In comparison to spelled out methods, operators are shorter, but also they don't require parentheses. Parentheses are relatively inconvenient to type. And you must balance them. In total, any method call requires three characters of plain noise compared to an operator. This makes using operators very, very tempting.

Why else would anyone want to this: cout << "Hello world"?

The problem with overloading is, that most programmers are unbelievably lazy and most programmers cannot afford to be.

What drives C++ programmers to the abuse of operator overloading is the not its presence, but the absence of a neater way to perform method calls. And people are not just afraid of operator overloading because it's possible, but because it's done.

Note that for example in Ruby and Scala nobody is afraid of operator overloading. Apart from the fact, that the use of operators is not really shorter than methods, another reason is, that Ruby limits operator overloading to a sensible minimum, while Scala allows you to declare your own operators thus making avoiding collision trivial.


答:
There are garbage collectors in C++ and C. Not sure how this works in C, but in C++ you can leverage RTTI to dynamically discover your object graph and use that for garbage collection.

To my knowledge, you cannot write Java without a garbage collector. A little search turned up this.

The key difference between Java and C/C++ is that in C/C++ the choice is always yours, whereas in Java you're often left without options by design.


问:
Is the agile approach too much of a convenient excuse for cowboys
I believe that an agile approach is best for projects where the requirements are fuzzy and a lot of interaction is required to help shape the end user's ideas.

However... In my professional work, I keep ending up at companies where an "agile" approach is used as an excuse as to why no effort was put into an up front design; when the requirements are well understood.

I can't help but thinking that if the agile approach wasn't around, I'd be sitting here with a nice high-level specification and not having to revisit the same screen and functionality every second day when something else crops up or so and so hadn't thought of that.

Are the benefits of agile methodologies really enough to outweigh the excuse for being lame it gives to cowboy technical leads?

Update: Ironically I'm now a certified Scrum Master. One of the papers presented on the Scrum course observed that the best development process was one where there was a single expert or guru making the design decisions, however that has obvious weaknesses. Scrum shifts the responsibility for producing quality software to the "Team" which means a sub-standard team can get away with churning out spaghetti which I guess is no different to other Agile and non-Agile development processes.

答:
I am seeing defenses of Agile Development saying that it is not responsible for failures caused by cowboys. Success with Agile requires diligence and intelligence.

This seems a reasonable position, as long as you apply the same concession to other methodologies. If you can't blame Agile for project failures caused by cowboys, you can't blame non-Agile methodologies for project failures caused by cowboys.

We can then argue whether there is a correlation (not causation!) between Agile and cowboys. With only anecdotal evidence, I believe there is. Is it perceived as a good way to get by with cowboy practices without being detected by management?

Of course, if we accept that cowboys may not be evenly spread across methodologies, and we accept that cowboys undermine the successful use of a process, we have made it very difficult to test whether a process is successful. The claim that one process is better (within a context) becomes close to unfalsifiable. This is one of the issues that makes me hang my head in shame about my profession - the lack of scientific underpinning of many of the claims.

(By the way, I hate calling the alternative(s) to Agile "waterfall", because waterfall processes seems to be a strawman that everyone attacks, but very few people ever actually used without any iteration.)


答:
"efficient" in terms of you writing code maybe, but certainly not in terms of your software efficiency.  Stack allocations are essentially free (it takes only a few machine instructions to move stack pointer and reserve space on the stack for local variables).

Since stack allocation takes almost no time, an allocation even on a very efficient heap will be 100k (if not 1M+) of times slower.

Now imagine how many local variables and other data structures a typical application uses. Every single little "i" that you use as a loop counter being allocated a million times slower.

Sure if the hardware is fast enough, you could write an application that only uses heap.  But now imaging what kind of application you could write if you took advantage of heap and used the same hardware.

Title: Could it be more efficient for systems in general to do away with Stacks and just use Heap for memory management?

Body:
It seems to me that everything that can be done with a stack can be done with the heap, but not everything that can be done with the heap can be done with the stack. Is that correct? Then for simplicity's sake, and even if we do lose a little amount of performance with certain workloads, couldn't it be better to just go with one standard (ie, the heap)?

Think of the trade-off between modularity and performance. I know that isn't the best way to describe this scenario, but in general it seems that simplicity of understanding and design could be a better option even if there is a potential for better performance.


答:
Heaps are bad at fast memory allocation and deallocation. If you want to grab many tiny amounts of memory for a limited duration, a heap is not your best choice. A stack, with its super-simple allocation / deallocation algorithm, naturally excels at this (even more so if it is built into the hardware), which is why people use it for things like passing arguments to functions and storing local variables - the most important downside is that it has limited space, and so keeping large objects in it, or trying to use it for long-lived objects, are both bad ideas.

Getting rid of the stack completely for the sake of simplifying a programming language is the wrong way IMO - a better approach would be to abstract the differences away, let the compiler figure out which kind of storage to use, while the programmer puts together higher-level constructs that are closer to the way humans think - and in fact, high-level languages like C#, Java, Python etc. do exactly this. They offer almost identical syntax for heap-allocated objects and stack-allocated primitives ('reference types' vs. 'value types' in .NET lingo), either fully transparent, or with a few functional differences which you must understand to use the language correctly (but you don't actually have to know how a stack and a heap work internally).


答:
How is the call stack going to work on a heap? Essentially, you would have to allocate a stack on the heap in every program, so why not have the OS+hardware do that for you?

If you want things to be really simple and efficient, just give the user their chunk of memory and let them deal with it. Of course, nobody wants to implement everything their self and that is why we have a stack and a heap.


答: Stacks are extremely efficient for LIFO data, such as the meta-data associated with function calls, for instance. The stack also leverages inherent design features of the CPU. Since performance at this level is fundamental to just about everything else in a process, taking that "small" hit at that level will propagate very widely.  In addition, heap memory is moveable by the OS, which would be deadly to stacks.  While a stack can be implemented in the heap, it requires overhead that will affect literally every piece of a process at the most granular level. </p>


答:
Strictly speaking, there is no memory management at all in the C language. malloc() and free() are not keywords in the language, but just functions that are called from a library. This distinction may be pedantic now, because malloc() and free() are part of the C standard library, and will be provided by any standard compliant implementation of C, but this wasn't always true in the past.

Why would you want a language with no standard for memory management? This goes back to C's origins as 'portable assembly'. There are many cases of hardware and algorithms that can benefit from, or even require, specialized memory management techniques. As far as I know, there is no way to completely disable Java's native memory management and replace it with your own. This is simply not acceptable in some high performance/minimal resource situations. C provides almost complete flexibility to choose exactly what infrastructure your program is going to use. The price paid is that the C language provides very little help in writing correct, bug free code.


答: C was designed in an era when garbage collection was barely an option.  It was also intended for uses where garbage collection would not generally work - bare metal, real time environments with minimal memory and minimal runtime support.   Remember that C was the implementation language for the first unix, which ran on a pdp-11 with 64*K* bytes of memory.  C++ was originally an extension to C - the choice had already been made, and it's very hard to graft garbage collection onto an existing language.  It's the kind of thing that has to be built in from the ground floor.


答:
No

The stack area in C++ is incredibly fast in comparison. I venture no experienced C++ developers would be open to disabling that functionality.

With C++, you have choice and you have control. The designers were not particularly inclined to introduce features that added significant execution time or space.

Exercising that choice

If you want to build a library or program which requires that every object is allocated dynamically, you can do that with C++. It would execute relatively slowly, but you could then have that 'modularity'. For the rest of us, the modularity is always optional, introduce it as needed because both are required for good/fast implementations.

Alternatives

There are other languages which require that storage for each object is created on the heap; it is quite slow, such that it compromises designs (real world programs) in a way that is worse than having to learn both (IMO).

Both are important, and C++ gives you the power use both effectively for each given scenario. Having said that, the C++ language may not be ideal for your design, if these factors in your OP are important to you (for example, read up on higher level languages).


答:
Then for simplicity's sake, and even if we do lose a little amount of
  performance with certain workloads, couldn't it be better to just go
  with one standard (ie, the heap)?

Actually the performance hit is likely to be considerable!

As others have pointed out stacks are an extremely efficient structure for managing data that obeys LIFO (last in first out) rules. Memory allocation/freeing on the stack is usually just a change to a register on the CPU. Changing a register is almost always one of the fastest operations a processor can perform.

The heap is usually a fairly complex data structure and allocating/freeing memory will take many instructions to do all the associated bookkeeping. Even worse, in common implementations, every call to work with the heap has to the potential to result in a call to the operating system. Operating system calls are very time consuming! The program typically has to switch from user mode to kernel mode, and whenever this happens the operating system may decide that other programs have more pressing needs, and that your program will need to wait.


答: Simply put, a stack isn't a little bit of performance. It's hundreds or thousands of times faster than the heap. In addition, most modern machines have hardware support for the stack (like x86) and that hardware functionality for e.g. the call stack cannot be removed.</p>


问:
When can you call yourself good at language X?
This goes back to a conversation I've had with my girlfriend. I tried to tell her that I simply don't feel adequate enough in my programming language (C++) to call myself good. She then asked me, "Well, when do you consider yourself good enough?"

That's an interesting question. I didn't know what to tell her. So I'm asking you.

For any programming language, framework or the like, when do you reach a point were you sit back, look at what you've done and say, "Hey, I'm actually pretty good at this."? How do you define "good" so that you can tell others, honestly, "Yeah, I'm good at X".

Additionally, do you reach these conclusions by comparing what others can do?

Additional Info

I have read the canonical paper on how it takes ten-thousand hours before you are an expert on the field. (Props to anybody that knows what this paper is called again)

I have also read various articles from Coding Horror about interviewing people. Some people, it was said, "Cannot function outside of a framework." So they may be "good" for that framework, but not otherwise in the language. Is this true?

答: There's a few good answers to this already, so I'll just contribute this:


答:
Proper Lighting

Either Natural, incandescent or indirect/diffused lighting is a big plus for me. Flourescent lighting makes me feel like I'm in a sweatshop and gives me a headache.


答:
Both stack and heap are required. They are used in different situations, for example:

Heap allocation has a limitation that sizeof(a[0])==sizeof(a[1])

Stack allocation has a limitation that sizeof(a) is compile-time constant

Heap allocation can do loops, graphs etc complex data structures

Stack allocation can do compile-time sized trees

Heap requires tracking of ownership

Stack allocation and deallocation is automatic

Heap memory can be easily passed from one scope to another via pointers

Stack memory is local to each function and objects need to be moved to upper scope to extend their lifetime(or stored inside objects instead of inside member functions)

Heap is bad for performance

Stack is pretty quick

Heap objects are returned from functions via pointers that take ownership. Or shared_ptrs.

Stack objects are returned from functions via references that do not take ownership.

Heap requires matching every new with correct kind of delete or delete[]

Stack objects use RAII and constructor initialization lists

Heap objects can be initialized any point inside a function, and cannot use constructor parameters

Stack objects use constructor parameters for initialization

Heap uses arrays and array size can change on runtime

Stack is for single objects, and size is fixed on compile-time

Basically the mechanisms cannot be compared at all because so many details are different. The only thing common with them is that they both handle memory somehow.


答:
The dependency inversion principle suggests you should:

High-level modules should not depend on low-level modules. Both should
  depend on abstractions.

You should write your code against a clear and simple abstraction of whatever external services you may need (i.e. a complex GUI toolkit in your case) and then just write implementations, whether that is by hand or as an adapter for 3rd party components.

Title: Should one define an interface and code an adapter for it whenever a dependency is found?

Body:
Given a particular third-party class/library you want to make use of, the simplest thing to do would be to just hardcode API calls to it through your application.

On the other hand you have the possibility of defining a interface that generically dictates what you want -not how-, and then follow the Adapter pattern to bind your interface to the third-party class.

I currently feel inclined to the second option because:

It creates a single point of change if you ever want to replace the functionality provider

In a similar way, it allows you to add more providers without changing your application code

It permits following your own naming conventions, simpler method signatures, etc

The thing is, I'm not experienced with this approach and I don't know how complicated or inconvenient it can get. I'd also like to know if are there any common errors when following this pattern.

In my particular case I don't want to wrap either a giantic library -e.g. a GUI- or a small function. Also there are actual possiblities I'll change my provider in the future, so this is not a YAGNI.

Thank you


问:
Could I learn more about programming from deconstructing drupal rather than continuing with ZF?
When I was deciding how to go about learning to design PHP web applications, it made sense to sort of shoot toward the middle and go with Zend Framework so that I could be closer to the lower level, but I would be able to get down to business fairly easily, too, while learning about design patterns, etc.

That seemed to work out pretty well, but now I'm wondering if I wouldn't have learned more about design from a more top-down approach, like creating a drupal site and deconstructing it.

I realize that the degree of topness vs. bottomness in this context is pretty negligible in the spectrum of all programming experiences, but I think it matters very much where you start, especially at the very beginning, because your world is small; it's home base, and how you develop your personality there "at home" can determine how you approach other problems in the future--I believe people tend to try to repeat their successes, which often means adopting a preference for what's familiar to them.

I didn't want to "learn myself into a corner," so to speak, so I tried to aim for a level that would prepare me for the greatest amount of other experiences. LAMP with ZF seemed like a well-rounded, holistic choice, because I'd be learning about database design, patterns, web app development, server configuration, and a C-based programming language all at once.

Okay, great, but I haven't really progressed as far as I had hoped I would, honestly. And now I'm starting to wonder if I've done myself a disservice for wanting to start nearer to the bottom vs. learning to produce as much as possible right away. My instincts at the time were that, "sure, a CMS will get you up and running, producing stuff right away, but you'll eventually hit a wall and need to learn the lower-level stuff anyway, and you'll probably hit it sooner than later so you might as well start there. Don't eat dessert first."

But now I'm thinking "what would have stopped me from digging into the gears of a CMS?" Maybe I would have learned more from seeing a more complete implementation and deconstructing it rather than reinventing the wheel. Or, I could be exactly where I should be having only started in December?

And I just don't know the answer. I want to start a new project (redoing my website--I'm actually a composer (of music)). I know the basics of Zend Framework, and I'm fairly sure I could code a simple CMS for myself for my purposes, but would I learn more from deconstructing an out of the box CMS like drupal?

答:
In my opinion you can learn better about design pattern and, in general, software engineering reading some good books. Of course is cool to deconstruct great projects like Drupal, Joomla and so on but before do this, you have to have good theoretical knowledge.

For example, the best book about desing pattern (I really suggest to read it) is this: http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612


答:
We have a somewhat large JavaScript codebase and about a month ago we desided to give CoffeeScript a try. One of our developers started with migrating one of our modules from JS to CS using http://js2coffee.org/. This tool was rather handy and it took about two or three hours to port a 1000-something lines of JavaScript. Some observations we've noticed at that point:

The resulting CoffeeScript code was quite readable.

We compiled it back to JavaScript and it was pretty easy to navigate and to debug. While we were porting that module another developer from our team found a bug in it. These two developers fixed that bug in our old JavaScript code and in new JavaScript code that came out of CS compiler. They worked independently and it took them about the same amount of time (15-20 minutes).

Because of the fact that it was a port the resulting code were not using Coffee-specific features that were appropriate or desirable. If we would write in CoffeeScript from scratch the code would be more idiomatic. Because of that later we decided that we won't port the existing code.

In general readability of shorter function and smaller object increased to some extend. However, for longer methods that wasn't the case at all. The biggest bloat savings came from -> and explicit return, but other than that our code hadn't got significantly shorter or simpler. Some pieces of syntax seemed quite confusing, especially object literals. CS omits curly braces around member definitions and combined with "everything-is-an-expression" and implicit return that made some bits of code pretty hard to read.

Here's JavaScript:

```<code>var rabbitGenerator = {
    makeRabbit: function(rabbitName, growCarrots) {
        if (growCarrots) {
            carrots.growMore(10);
        } else {
            carrots.ensureSupply();
        }
        return {
            name: rabbitName,
            height: 0,
            actions: {
                jump: function (height) {
                    this.height += height;
                },
                eatCarrot: function () {
                    // etc
                }
            }
        };
    },
    // more members
}
</code>```

And here's what the corresponding CoffeeScript code would look like:

```<code>rabbitGenerator =
  makeRabbit: (rabbitName, growCarrots) ->
    if growCarrots
      carrots.growMore 10
    else
      carrots.ensureSupply()
    name: rabbitName // (*)
    height: 0
    actions:
      jump: (height) ->
        @height += height

      eatCarrot: ->
</code>```

As it is now it's pretty difficult to figure out that the return statement starts at (*) line. In our project we heavily rely on object literals: we pass them as function parameters and return them from other functions. In many cases these objects tend to be quite complex: with members of different types and several levels of nesting. In our case the overall feeling was that CoffeeScript code was actually harder to read than plain JavaScript code.

Although debugging CoffeeScript turned out to be easier than we expected editing experience has degraded quite a bit. We couldn't find a good editor/IDE for this language. We haven't standardized on editor/IDE for client-side code for our project and in fact we all use different tools. In fact everyone in a team agrees that when they switch to CoffeeScript they get a rather poor support from their tool. IDE and editor plugins are in very early shape and in some cases they can't even give us a proper syntax highlighting or indentation support. Not talking about code snippets or refactoring. We use WebStorm, Eclipse, NetBeans, VisualStudio, Notepad++, and SublimeText2.

Speaking of tools I should mention that CoffeScript compiler itself comes as a Node JS package. We are primary a Java/.NET shop so everybody is developing on Windows boxes. Until recently Windows support was almost non-existent in Node. We couldn't make CoffeeScript compiler running on Windows so for the time being we decided to stick with

Title: What are the pros and cons of Coffeescript?

Body:
Of course one big pro is the amount of syntactic sugar leading to shorter code in a lot of cases. On http://jashkenas.github.com/coffee-script/ there are impressive examples. On the other hand I have doubts that these examples represent code of complex real world applications. In my code for instance I never add functions to bare objects but rather to their prototypes. Moreover the prototype feature is hidden from the user, suggesting classical OOP rather than idiomatic Javascript.

The array comprehension example would look in my code probably like this:

```<code>cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...
</code>```

Body:
We have a somewhat large JavaScript codebase and about a month ago we desided to give CoffeeScript a try. One of our developers started with migrating one of our modules from JS to CS using http://js2coffee.org/. This tool was rather handy and it took about two or three hours to port a 1000-something lines of JavaScript. Some observations we've noticed at that point:

The resulting CoffeeScript code was quite readable.

We compiled it back to JavaScript and it was pretty easy to navigate and to debug. While we were porting that module another developer from our team found a bug in it. These two developers fixed that bug in our old JavaScript code and in new JavaScript code that came out of CS compiler. They worked independently and it took them about the same amount of time (15-20 minutes).

Because of the fact that it was a port the resulting code were not using Coffee-specific features that were appropriate or desirable. If we would write in CoffeeScript from scratch the code would be more idiomatic. Because of that later we decided that we won't port the existing code.

In general readability of shorter function and smaller object increased to some extend. However, for longer methods that wasn't the case at all. The biggest bloat savings came from -> and explicit return, but other than that our code hadn't got significantly shorter or simpler. Some pieces of syntax seemed quite confusing, especially object literals. CS omits curly braces around member definitions and combined with "everything-is-an-expression" and implicit return that made some bits of code pretty hard to read.

Here's JavaScript:

var rabbitGenerator = {
    makeRabbit: function(rabbitName, growCarrots) {
        if (growCarrots) {
            carrots.growMore(10);
        } else {
            carrots.ensureSupply();
        }
        return {
            name: rabbitName,
            height: 0,
            actions: {
                jump: function (height) {
                    this.height += height;
                },
                eatCarrot: function () {
                    // etc
                }
            }
        };
    },
    // more members
}

And here's what the corresponding CoffeeScript code would look like:

rabbitGenerator =
  makeRabbit: (rabbitName, growCarrots) ->
    if growCarrots
      carrots.growMore 10
    else
      carrots.ensureSupply()
    name: rabbitName // (*)
    height: 0
    actions:
      jump: (height) ->
        @height += height

      eatCarrot: ->

As it is now it's pretty difficult to figure out that the return statement starts at (*) line. In our project we heavily rely on object literals: we pass them as function parameters and return them from other functions. In many cases these objects tend to be quite complex: with members of different types and several levels of nesting. In our case the overall feeling was that CoffeeScript code was actually harder to read than plain JavaScript code.

Although debugging CoffeeScript turned out to be easier than we expected editing experience has degraded quite a bit. We couldn't find a good editor/IDE for this language. We haven't standardized on editor/IDE for client-side code for our project and in fact we all use different tools. In fact everyone in a team agrees that when they switch to CoffeeScript they get a rather poor support from their tool. IDE and editor plugins are in very early shape and in some cases they can't even give us a proper syntax highlighting or indentation support. Not talking about code snippets or refactoring. We use WebStorm, Eclipse, NetBeans, VisualStudio, Notepad++, and SublimeText2.

Speaking of tools I should mention that CoffeScript compiler itself comes as a Node JS package. We are primary a Java/.NET shop so everybody is developing on Windows boxes. Until recently Windows support was almost non-existent in Node. We couldn't make CoffeeScript compiler running on Windows so for the time being we decided to stick with <script type="text/coffeescript"> tags and browser-based on-the-fly compiler.

The compiler is quite fast and doesn't increase the startup time much. The downside is that the resulting JavaScript gets evaled and it's a little bit hard to put breakpoints in it in browsers' developer tools (especially in IE8). If we have hard time with the debugging we pre-compile CoffeeScript code with the same migration tool that I listed above but that's still not very convenient.

Other promises of CoffeeScript like automatic var insertion or semi-transparent management of this with fat arrow operator (=>) turned out not giving as much gain as we hoped to. We already use JSLint as part of our build process and we write code in ES3 x ES5-Strict subset of the language. Anyway, the fact that Coffee produces the same kind of "clean" code is a good thing. I wish every server-side framework produced valid HTML5 and CSS3 markup, too!

That said I wouldn't say that CoffeeScript saves a lot of time by putting var keywords for me. Missing vars are easily caught by JSLint and are easily fixable. Moreover, once you get corrected by it for some time you start writing good JavaScript automatically anyway. Thus I wouldn't say Coffee is really that helpful in this regard.

We evaluated CoffeeScript for about a week. All team members were writing code in it and we shared our experiences with each other. We wrote some new code with it and ported some existing code when we saw fit. Our feelings about the language were mixed.

In general I would say that it didn't sped up our development but it haven't slowed us down either. Some speed gains due to less typing and less error surface were offset by slowdowns in other areas, mostly tool support. After a week we decided that we won't mandate the use of CoffeeScript but we won't prohibit it either. Given a free choice, in practice no one uses it, at least for now. From time to time I think of prototyping some new feature in it and then convert the code to JavaScript before integrating with the rest of the project to get a faster start but I haven't tried that approach yet.


答:
Paper and pencil and eraser!

There are things that you just can't help but express better on paper. Initial drawings, sketches, etc.


问:
Is garbage collection necessary?
Do any languages really need garbage collection? Is there not a way to figure out when a object should be destroyed? I haven't had leaks in C++ and i dont use smart pointers or reference counters or anything special. I confirm this by attaching something for leak detection: whether its built in to the IDE or a header that uses magic (defines) to overloads new/free.

Is garbage collection necessary, or is it possible to have a leak-free application in a language without placing the memory burden on the programmer?

答:
What do you mean by necessary? You can certainly manage the memory with smart pointers and that takes minimal effort too (although the occasional cyclic reference can be a problem but that's not too hard to fix in most cases). Garbage collection is just another way of freeing unneeded memory. </p>

<p>One additional thing that garbage collectors can do is defragmenting the memory (if they use another level of indirection). If you have lots of allocations and deallocations of small objects, the memory can become fragmented and even if there is enough physical memory available in total, paging still occurs. I have never seen such thing happening, but it's possible (if you are developing to constrained hardware). </p>

Title: Is garbage collection necessary?

Body:
What do you mean by necessary? You can certainly manage the memory with smart pointers and that takes minimal effort too (although the occasional cyclic reference can be a problem but that's not too hard to fix in most cases). Garbage collection is just another way of freeing unneeded memory.

One additional thing that garbage collectors can do is defragmenting the memory (if they use another level of indirection). If you have lots of allocations and deallocations of small objects, the memory can become fragmented and even if there is enough physical memory available in total, paging still occurs. I have never seen such thing happening, but it's possible (if you are developing to constrained hardware).


答:
It seems that you've answered your own question. No, of course garbage collection isn't necessary, and the very existence of languages without GC such as C and C++ show that.

Garbage collection can be a nice feature, however. It removes the burden of properly managing memory from the programmer, thereby making a language both easier to use and more reliable.

GC isn't the only way to lighten the programmer's load with respect to memory management. For example, Apple has recently added Automatic Reference Counting (ARC) to Objective-C. Previously, Objective-C programmers could manage memory manually using Objective-C's reference counting mechanism (retain/release), or (on the MacOS X platform) they could opt for garbage collection. ARC basically combines the two: a static analyzer looks at the code and automatically inserts calls to the appropriate memory management methods. This frees the programmer from having to manually manage memory, but eliminates the need for a garbage collector.

Title: Is garbage collection necessary?

Body:
Do any languages really need garbage collection? Is there not a way to figure out when a object should be destroyed? I haven't had leaks in C++ and i dont use smart pointers or reference counters or anything special. I confirm this by attaching something for leak detection: whether its built in to the IDE or a header that uses magic (defines) to overloads new/free.

Is garbage collection necessary, or is it possible to have a leak-free application in a language without placing the memory burden on the programmer?


答: If you have a heap, allocated memory must be released.  In practice, this is little more than a bookkeeping entry, but new allocations can only use unallocated memory.  If your language is not designed to have deterministic deallocation, you have to clean it up some other way. The reason not to have deterministic deallocation is that it makes the access to objects easier and less constraining.  For the purposes of some languages, this is an advantage.  It is one that would not be advantageous to C++.  But you do have to do one or the other. </p>

Title: Is garbage collection necessary?


答:
Garbage collection is really a way of simplifying the problem of memory management for the programmer.  So when you ask whether a language "really needs garbage collection", you are actually asking whether the programmer needs help.

And the answer to that is that it depends on:

how complex are the problems that the programmer is trying to solve,

how good is the programmer at dealing with this, and

whether the programmer has the time to deal with this.

While you believe that C and C++ don't need garbage collection based on your experiences, maybe this is telling you that your experiences are limited.  My experience is that garbage collection makes my life a lot simpler when writing complex software, and that there are certain kinds of problem that I would not dream of implementing in a non-GC'ed language.

The other point is that garbage collection (supported at the language level) does memory management safely.  It removes the risk of some bit of code will accidentally free an object twice, use an object after it has been freed, or write beyond the end of an object / array and trampling something else.  (OK, the particularities of this depend on the language we are talking about.  But the properties of safety and GC go hand in hand in a typical GC'ed language.)

i mean if the language can figure out when to delete/free so we have no leaks (rather then it using a collector)

There are three known effective ways to automate memory reclamation:

The compiler figures out that certain objects can never be used once a scope has exited, and emits code to free them.  (Or allocates them on the stack).  This is only applicable in certain cases.

The compiler (or the programmer via "smart pointers") uses reference counting and frees objects when their reference counts reach zero.  This approach doesn't work when there are reference cycles.

A garbage collector traverses the graph of reachable objects and throws away those that are not reachable.  This works provided that the application doesn't keep references to objects that are not needed.

I'm not aware of any other ways of automating memory management.

(Note that even GC'ed languages are vulnerable to certain kinds of storage leak.)

Title: Is garbage collection necessary?


答: There is no reason to have a modern language which does not come with its own memory management. These days languages attempt to optimize developer productivity and the less things we have to worry about, the better.

Title: Is garbage collection necessary?


问:
Is It OK to Develop Against a 3rd Party Library You Discover?
If you find out a way to interact with a web service API that is not publicly documented as available, and can emulate it within an application you develop, is it illegal to do so?  Furthermore is it illegal to charge for a product that you build to interact with these services (maybe all that's needed is a reference to the 3rd party)?

An example would be, lets say, Google didn't advertise how to do a search in your program, but you found out how and made it so people could do the search differently than how Google presents it, can you build against the service you discovered and sell a version of it?

答:
No one answer fits all.

IANAL, but, I would suggest:

If you find out by reverse engineering/decompiling a program, it could be illegal based on copyright.

If you find out by proxy/intercepting or just knowing of it's existence, it would be legal as you have not actually done anything to their service or products... but, it could still be morally a grey area.

In any case, if you were to use something that was undocumented and you really did "find" it legally, you could always document it for the good of others.

If you charge or similar, it doesn't really change the facts above - however - you will be responsible to your customers and there is a high chance that they will close it at any time without letting you know.

If it was me and I found something that worked, I would ask the people and try to negotiate with them.

OwnerDisplayName: Benny

OwnerDisplayName: wilhil


答:
Garbage collection is not necessary any more than variables, types, or loops. These are all conveniences for expressing different kinds of problems. The job of garbage collection is to simulate a machine with infinite memory. Some languages heavily encourage using it; others offer it merely to make the programmer’s life easier.

Tracing garbage collection is not the only approach to automated memory management. Reference counting is the dual to tracing, and most production garbage collectors include features of both—e.g., generational tracing and cycle-detecting RC. Some languages even obviate the need for runtime garbage collection by predicting resource allocation at compile time. This can be done with substructural types.

Title: Is garbage collection necessary?


问:
Stuff every programmer needs while working
I've been tasked with creating a fun and relaxing environment, one thing I know that I want is ergonomic mice and keyboards, others have suggested exercise balls and bands.

What is it that every programmer needs while working? What might not be necessary but would be nice to have anyway?

Note: this question was asked previously, but has been recommended to be posted here. See this link for the previous responses: https://stackoverflow.com/questions/3911911/stuff-every-programmer-needs-while-working-closed

答: A nice note book for taking notes with a pen or a pencil. As much as I love computers, I find having a nice note book for writing down ideas, taking notes during meetings, diagram drawings, etc. absolutely indispensable.