答:
Ruby does seem to fit your requirements with respect to portability across platforms (Windows, Linux, MAC), and ability to automate different kind of applications. AFAIK you can automate browsers and command line apps using ruby libraries but I am not sure about GUI based tools (Some platforms like .NET have Ruby bindings that may be helpful in this regard).

Ruby has large number of libraries so you should be able to automate lot of tasks suitable for scripting. For example, you can manipulated files in different textual formats, access network, database, and so on. However, it may not be best to do some tasks in native ruby - for example, encoding videos (but you can always invoke other tools using Ruby to do that).

If you are comparing it against BATCH and Shell Scripts, ruby can be used to perform almost any tasks these scripts can do. The disadvantage could be:

You may need additional installation.

Others may need to learn ruby to maintain your scripts.

If a tool has binding with some other scripting language, ruby may not be able to match that in terms of performance or even ability to access the functionality. For example, you may not be able to do everything that can be done via JavaScript from inside a browser when you are automating it via Ruby.

Title: Can I use Ruby to automate everything?

Body:
I face various types of applications (web-based, GUI-based, command-line, etc.) on various platforms (Windows, Linux, etc.) to operate everyday. There is a great opportunity for me to automate tasks by scripting. But almost every type of application and platform has its native scripting language or tools (such as VBScript and PowerShell for Windows, Bash scripts for Linux, Selenium for web applications, and AutoIt for GUI applications, etc.). It kills me to learn and maintain so many scripting languages.

I have a feeling that Ruby can interoperate with various platforms easily, and it is very expressive. So my question is:

It is possible to use Ruby to script everything?

If it is, what are the main disadvantages compared to the native scripting language of each platform?


问:
For what reasons  should I choose C# over Java and C++?
C# seems to be popular these days. I heard that syntactically it is almost the same as Java. Java and C++ have existed for a longer time. For what reasons should I choose C# over Java and C++?</p>

答:
Well C# has some nice built-in features like LINQ and delegates. It is getting the best from both worlds - Java and C++. Look here for a full comparison.

But I like the Java world better - much more open source frameworks and it runs on every platform. And don't tell me about Mono - it is not a reliable option.

ContentLicense: CC BY-SA 3.0


答:
If you do a search you are likely to stumble upon discussion on top programming languages. Here is one of the search results - http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html - Java still seems to be the most popular language.

Java tried to remove some of the shortcomings of C++ (and making the programmers life simpler for non-real-time and non-critical applications). C# being the late-comer to the party, avoided some of the shortcomings of the Java language. C# has made a lot of progress (as Microsoft has lot of control over it) while advances in Java were blocked for a considerable period of time due to conflict between it's stakeholders.

Body: C# seems to be popular these days. I heard that syntactically it is almost the same as Java. Java and C++ have existed for a longer time. For what reasons should I choose C# over Java and C++?</p>


问:
Do we still have a case against the goto statement?

Possible Duplicate:

  Is it ever worthwhile using goto?

In a recent article, Andrew Koenig writes:

When asked why goto statements are harmful, most programmers will say something like "because they make programs hard to understand." Press harder, and you may well hear something like "I don't really know, but that's what I was taught." For that reason, I'd like to summarize Dijkstra's arguments.

He then shows two program fragments, one without a goto and and one with a goto:

```<code>if (n < 0)
    n = 0;
</code>```

Assuming that n is a variable of a built-in numeric type, we know that after this code, n is nonnegative.

Suppose we rewrite this fragment:

```<code>if (n >= 0) goto nonneg;
n = 0;
nonneg: ;
</code>```

In theory, this rewrite should have the same effect as the original. However, rewriting has changed something important: It has opened the possibility of transferring control to nonneg from anywhere else in the program.

I emphasized the part that I don't agree with. Modern languages like C++ do not allow goto to transfer control arbitrarily. Here are two examples:

You cannot jump to a label that is defined in a different function.

You cannot jump over a variable initialization.

Now consider composing your code of tiny functions that adhere to the single responsibility principle:

```<code>int clamp_to_zero(int n)
{
    if (n >= 0) goto n_is_not_negative:
    n = 0;
n_is_not_negative:
    return n;
}
</code>```

The classic argument against the goto statement is that control could have transferred from anywhere inside your program to the label n_is_not_negative, but this simply is not (and was never) true in C++. If you try it, you will get a compiler error, because labels are scoped. The rest of the program doesn't even see the name n_is_not_negative, so it's just not possible to jump there. This is a static guarantee!

Now, I'm not saying that this version is better then the one without the goto, but to make the latter as expressive as the first one, we would at least have to insert a comment, or even better yet, an assertion:

```<code>int clamp_to_zero(int n)
{
    if (n < 0)
        n = 0;
    // n is not negative at this point
    assert(n >= 0);
    return n;
}
</code>```

Note that you basically get the assertion for free in the goto version, because the condition n >= 0 is already written in line 1, and n = 0; satisfies the condition trivially. But that's just a random observation.

It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code.

So, do we still have a case against the goto statement, other than that it is not particularly useful? I haven't written a goto in at least a decade, but it's not like I was running away in terror whenever I encountered one. 1 Ideally, I would like to see a strong and valid argument against gotos that still holds when you adhere to established programming principles for clean code like the SRP. "You can jump anywhere" is not (and has never been) a valid argument in C++, and somehow I don't like teaching stuff that is not true.

1: Also, I have never been able to resurrect even a single velociraptor, no matter how many gotos I tried :(

答:
IMHO

```<code>if (n < 0)
  n = 0;
</code>```

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly or confusing: could the author have faced some strange compiler/optimization bug at this point???

I consider the variant using goto harder to understand than plain if. This of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same. Thus even if I got used to goto, it would make the code harder to maintain in the long run.

It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code.

All of the legacy programs I have seen so far contain many, many functions of hundreds (or sometimes even thousands) of lines of code. So I am very happy that at least they don't contain gotos :-) You are right that in a small, clean method goto can't make a big problem; however, if you try to draw a fuzzy line like "you can use goto in functions shorter than n lines", it is inevitably going to be abused by "clever" developers. Not to mention that functions tend to grow over time; what do you do when your originally short and clean function bloats to double its size? Do you remove the gotos then, or refactor? Will your successor a few years down the line remove the gotos, or refactor the code too?... OTOH Dijkstra's rule is clear, and has much less potential to be abused.

Last but not least, your function's name does not express its intent; renaming it to e.g. make_non_negative would leave no doubt about what it does.

YMMV.

Body:
IMHO

if (n < 0)
  n = 0;

makes it perfectly clear that after that, n >= 0, so a comment explaining this would violate the DRY principle, and an assertion I would consider downright silly or confusing: could the author have faced some strange compiler/optimization bug at this point???

I consider the variant using goto harder to understand than plain if. This of course may simply be the effect of not being used to seeing gotos in code; but then again, most of my (current and future) coworkers aren't either, so they probably feel the same. Thus even if I got used to goto, it would make the code harder to maintain in the long run.

It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code.

All of the legacy programs I have seen so far contain many, many functions of hundreds (or sometimes even thousands) of lines of code. So I am very happy that at least they don't contain gotos :-) You are right that in a small, clean method goto can't make a big problem; however, if you try to draw a fuzzy line like "you can use goto in functions shorter than n lines", it is inevitably going to be abused by "clever" developers. Not to mention that functions tend to grow over time; what do you do when your originally short and clean function bloats to double its size? Do you remove the gotos then, or refactor? Will your successor a few years down the line remove the gotos, or refactor the code too?... OTOH Dijkstra's rule is clear, and has much less potential to be abused.

Last but not least, your function's name does not express its intent; renaming it to e.g. make_non_negative would leave no doubt about what it does.

YMMV.


答:
Gotos are not the problem.  They never were.  The problem is programmers who use gotos in such a way that it makes code extremely difficult to follow, and possibly places code into an indeterminate state (remember, not every language will be as strict as C++ is).  Gotos are just the gun - but the programmer is the one who points it at his foot and pulls the trigger.

In the past I've used gotos on occasions where I concluded it was the best course of action (or, more usually, the least risky course).  There's nothing wrong with doing that so long as you are aware of the possible consequences.  But new coders don't necessarily have that sense and can make a major mess of things.  So I suspect it's far simpler to just teach them never to use gotos.

Title: Do we still have a case against the goto statement?

Body:
Possible Duplicate:

  Is it ever worthwhile using goto?

In a recent article, Andrew Koenig writes:

When asked why goto statements are harmful, most programmers will say something like "because they make programs hard to understand." Press harder, and you may well hear something like "I don't really know, but that's what I was taught." For that reason, I'd like to summarize Dijkstra's arguments.

He then shows two program fragments, one without a goto and and one with a goto:

```<code>if (n < 0)
    n = 0;
</code>```

Assuming that n is a variable of a built-in numeric type, we know that after this code, n is nonnegative.

Suppose we rewrite this fragment:

```<code>if (n >= 0) goto nonneg;
n = 0;
nonneg: ;
</code>```

In theory, this rewrite should have the same effect as the original. However, rewriting has changed something important: It has opened the possibility of transferring control to nonneg from anywhere else in the program.

I emphasized the part that I don't agree with. Modern languages like C++ do not allow goto to transfer control arbitrarily. Here are two examples:

You cannot jump to a label that is defined in a different function.

You cannot jump over a variable initialization.

Now consider composing your code of tiny functions that adhere to the single responsibility principle:

```<code>int clamp_to_zero(int n)
{
    if (n >= 0) goto n_is_not_negative:
    n = 0;
n_is_not_negative:
    return n;
}
</code>```

The classic argument against the goto statement is that control could have transferred from anywhere inside your program to the label n_is_not_negative, but this simply is not (and was never) true in C++. If you try it, you will get a compiler error, because labels are scoped. The rest of the program doesn't even see the name n_is_not_negative, so it's just not possible to jump there. This is a static guarantee!

Now, I'm not saying that this version is better then the one without the goto, but to make the latter as expressive as the first one, we would at least have to insert a comment, or even better yet, an assertion:

```<code>int clamp_to_zero(int n)
{
    if (n < 0)
        n = 0;
    // n is not negative at this point
    assert(n >= 0);
    return n;
}
</code>```

Note that you basically get the assertion for free in the goto version, because the condition n >= 0 is already written in line 1, and n = 0; satisfies the condition trivially. But that's just a random observation.

It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code.

So, do we still have a case against the goto statement, other than that it is not particularly useful? I haven't written a goto in at least a decade, but it's not like I was running away in terror whenever I encountered one. 1 Ideally, I would like to see a strong and valid argument against gotos that still holds when you adhere to established programming principles for clean code like the SRP. "You can jump anywhere" is not (and has never been) a valid argument in C++, and somehow I don't like teaching stuff that is not true.

1: Also, I have never been able to resurrect even a single velociraptor, no matter how many gotos I tried :(

ContentLicense: CC BY-SA 4.0


答:
The question should be "Which language is better suited for modern, typical application development?".

Edit: I addressed some of the comments below. A small remark: consider that when you have a lot of things natively, as idioms, it's a big difference than implementing or downloading and using them yourself every time. Almost everything can be implemented in any of these languages. The question is - what the languages natively provide you with.

So off the top of my head (some arguments apply to both languages)...

C# is better than C++ in that:

It has native  garbage-collection.

It allows you to treat class-methods' signatures as free functions (i.e. ignoring the statically typed this pointer argument), and hence create more dynamic and flexible relationships between classes. edit if you don't know what this means, then try assigning a member method returning void and accepting void to a void (*ptr)() variable. C# delegates carry the this pointer with them, but the user doesn't always have to care about that. They can just assign a void() method of any class to any other void() delegate.

It has a huge standard library with so much useful stuff that's well-implemented and easy to use.

It allows for both managed and native code blocks.

Assembly versioning easily remedy DLL hell problems.

You can set classes, methods and fields to be assembly-internal (which means they are accessible from anywhere within the DLL they're declared in, but not from other assemblies).

C# is better than Java in that:

Instead of a lot of noise (EJB, private static class implementations, etc) you get elegant and friendly native constructs such as Properties and Events.

You have real generics (not the bad casting joke that Java calls generics), and you can perform reflection on them.

It supports native resource-management idioms (the using statement). Java 7 is also going to support this, but C# has had it for a way longer time.

It doesn't have checked exceptions :) (debatable whether this is good or bad)

It's deeply integrated with Windows, if that's what you want.

It has Lambdas and LINQ, therefore supporting a small amount of functional programming.

It allows for both generic covariance and contravariance explicitly.

It has dynamic variables, if you want them.

Better enumeration support, with the yield statement.

It allows you to define new value (or non-reference) types.

Edit - Addressing comments

I didn't say C++ doesn't support native RAII. I said Java doesn't have it (you have to explicitly do a try/finally). C++ has auto pointers which are great for RAII, and (if you know what you're doing) can also substitute garbage-collection.

I didn't say anything about emulating free functions. But for example if you need to access a field by a this pointer, and bind the method that does it to a generic function pointer (i.e. not in the same class), then there's simply no native way to do it. In C#, you get the for free. You don't even have to know how it works.

By "treating member methods as free functions" I meant that you can't, for example, natively bind a member method to a free function signature, because the member method "secretly" needs the this pointer.

The using statement, obviously along with IDisposable wrappers, is a great example of RAII. See this link. Consider that you don't need RAII as much in C# as you do in C++, because you have the GC. For the specific times you do need it, you can explicitly use the using statement. Another little reminder: freeing memory is an expensive procedure. GC have their performance advantage in a lot of cases (especially when you have lots of memory). Memory won't get leaked, and you won't be spending a lot of time on deallocating. What's more, allocation is faster as well, since you don't allocate memory every time, only once in a while. Calling new is simply incrementing a last-object-pointer.

"C# is worse in that it has garbage collection". This is indeed subjective, but as I stated at the top, for most modern, typical application development, garbage collection is one hell of an advantage.

In C++, your choices are either to manually manage your memory using new and delete, which empirically always leads to errors here and there, or (with C++11) you can use auto pointers natively, but keep in mind that they add lots and lots of noise to the code. So GC still has an edge there.

"Generics are way weaker than templates" - I just don't know where you got that from. Templates might have their advantages, but in my experience constraints, generic parameter type-checking, contravariance and covariance are much stronger and elegant tools. The strength in templates is that they let you play with the language a bit, which might be cool, but also causes lots of headaches when you want to debug something. So all in all, templates have their nice features, but I find generics more practical and clean.

Title: For what reasons  should I choose C# over Java and C++?


问:
What are the arguments against parsing the Cthulhu way?
I have been assigned the task of implementing a Domain Specific Language for a tool that may become quite important for the company. The language is simple but not trivial, it already allows nested loops, string concatenation, etc. and it is practically sure that other constructs will be added as the project advances.

I know by experience that writing a lexer/parser by hand -unless the grammar is trivial- is a time consuming and error prone process. So I was left with two options: a parser generator à la yacc or a combinator library like Parsec. The former was good as well but I picked the latter for various reasons, and implemented the solution in a functional language.

The result is pretty spectacular to my eyes, the code is very concise, elegant and readable/fluent. I concede it may look a bit weird if you never programmed in anything other than java/c#, but then this would be true of anything not written in java/c#.

At some point however, I've been literally attacked by a co-worker. After a quick glance at my screen he declared that the code is uncomprehensible and that I should not reinvent parsing but just use a stack and String.Split like everybody does. He made a lot of noise, and I could not convince him, partially because I've been taken by surprise and had no clear explanation, partially because his opinion was immutable (no pun intended). I even offered to explain him the language, but to no avail.

I'm positive the discussion is going to re-surface in front of management, so I'm preparing some solid arguments.

These are the first few reasons that come to my mind to avoid a String.Split-based solution:

you need lot of ifs to handle special cases and things quickly spiral out of control

lots of hardcoded array indexes makes maintenance painful

extremely difficult to handle things like a function call as a method argument (ex. add( (add a, b), c)

very difficult to provide meaningful error messages in case of syntax errors (very likely to happen)

I'm all for simplicity, clarity and avoiding unnecessary smart-cryptic stuff, but I also believe it's a mistake to dumb down every part of the codebase so that even a burger flipper can understand it. It's the same argument I hear for not using interfaces, not adopting separation of concerns, copying-pasting code around, etc. A minimum of technical competence and willingness to learn is required to work on a software project after all. (I won't use this argument as it will probably sound offensive, and starting a war is not going to help anybody)

What are your favorite arguments against parsing the Cthulhu way?*

*of course if you can convince me he's right I'll be perfectly happy as well

答:
I am not well versed in parsing algorithms and the like, but I think the proof of the pudding is in the eating. So if all else fails, you could offer him to implement the parser his way. Then

compare the time invested in either solutions,

run both solutions through a comprehensive acceptance test to see which has less bugs, and

have an independent judge compare the resulting code in size and clarity to yours.

For the testing to be really fair, you might want to have both solutions implement the same API, and use a common testbed (or a unit testing framework known by both of you). Both of you could write any number and kind of functional test cases and ensure that his own solution passes all of them. And of course, ideally neither of you should have access to the other's implementation before the deadline. The decisive test would then be to cross-test both solutions using the test suite developed by the other developer.


答:
The critical difference between the two approaches is, that the one he considers to be the only correct way is imperative and yours is declarative.

Your approach explicitly declares rules, i.e. the rules of the grammar are (almost) directly encoded in your code, and the parser library automatically transforms raw input into parsed output, while taking care of state and other things that are hard to handle. Your code is written within one single layer of abstraction, which coincides with the problem domain: parsing. It's reasonable to assume parsec's correctness, which means the only room for error here is, that your grammar definition is wrong. But then again you have fully qualified rule objects and they are easily tested in isolation. Also it might be worth noting, that mature parser libraries ship with one important feature: error reporting. Decent error recovery when parsing went wrong is not trivial. As proof, I invoke PHP's parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM :D

His approach manipulates strings, explicitly maintains state and lifts up the raw input manually to parsed input. You have to write everything yourself, including error reporting. And when something goes wrong, you are totally lost.

The irony consist in that the correctness of a parser written with your approach is relatively easily proven. In his case, it is almost impossible.

There are two ways of constructing a software design: One way is to
  make it so simple that there are obviously no deficiencies, and the
  other way is to make it so complicated that there are no obvious
  deficiencies. The first method is far more difficult.

C. A. R. Hoare

Your approach is the simpler one. All it precludes is for him to broaden his horizon a bit. The result of his approach will always be convoluted, no matter how broad your horizon.

To be honest, it sounds to me, that the guy is just an ignorant fool, who is suffering from the blub syndrome, arrogant enough to assume you are wrong and yell at you, if he doesn't understand you.

In the end however, the question is: who is going to have to maintain it? If it's you, then it's your call, no matter what anybody says. If it's going to be him, then there's only two possibilities: Find a way to make him understand the parser library or write an imperative parser for him. I suggest you generate it from your parser structure :D

Title: What are the arguments against parsing the Cthulhu way?

Body:
I have been assigned the task of implementing a Domain Specific Language for a tool that may become quite important for the company. The language is simple but not trivial, it already allows nested loops, string concatenation, etc. and it is practically sure that other constructs will be added as the project advances.

I know by experience that writing a lexer/parser by hand -unless the grammar is trivial- is a time consuming and error prone process. So I was left with two options: a parser generator à la yacc or a combinator library like Parsec. The former was good as well but I picked the latter for various reasons, and implemented the solution in a functional language.

The result is pretty spectacular to my eyes, the code is very concise, elegant and readable/fluent. I concede it may look a bit weird if you never programmed in anything other than java/c#, but then this would be true of anything not written in java/c#.

At some point however, I've been literally attacked by a co-worker. After a quick glance at my screen he declared that the code is uncomprehensible and that I should not reinvent parsing but just use a stack and String.Split like everybody does. He made a lot of noise, and I could not convince him, partially because I've been taken by surprise and had no clear explanation, partially because his opinion was immutable (no pun intended). I even offered to explain him the language, but to no avail.

I'm positive the discussion is going to re-surface in front of management, so I'm preparing some solid arguments.

These are the first few reasons that come to my mind to avoid a String.Split-based solution:

you need lot of ifs to handle special cases and things quickly spiral out of control

lots of hardcoded array indexes makes maintenance painful

extremely difficult to handle things like a function call as a method argument (ex. add( (add a, b), c)

very difficult to provide meaningful error messages in case of syntax errors (very likely to happen)

I'm all for simplicity, clarity and avoiding unnecessary smart-cryptic stuff, but I also believe it's a mistake to dumb down every part of the codebase so that even a burger flipper can understand it. It's the same argument I hear for not using interfaces, not adopting separation of concerns, copying-pasting code around, etc. A minimum of technical competence and willingness to learn is required to work on a software project after all. (I won't use this argument as it will probably sound offensive, and starting a war is not going to help anybody)

What are your favorite arguments against parsing the Cthulhu way?*

*of course if you can convince me he's right I'll be perfectly happy as well


答:
A parsing expression grammar (such as the Packrat parser approach) or parser combinator isn't reinventing parsing. These are well established techniques in the functional programming world and, in the right hands, it can be more readable than the alternatives. I've seen a pretty convincing demonstration of PEG in C# a few years back that would actually make it my tool of first resort for relatively simple grammars.

If you have an elegant solution using parser combinators or a PEG, it should be a relatively easy sell: it's fairly extensible, usually relatively easy to read once you get over your fear of functional programming, and is sometimes easier to read than typical parser generator tools offer, though that depends very much on the grammar and the level of experience you have with either toolset. It's also pretty easy to write tests for. Of course, there are some grammar ambiguities that can result in pretty awful parsing performance in worst case scenarios (or lots of memory consumption with Packrat), but average case is pretty decent and actually some grammar ambiguities are better handled with PEG than LALR, as I recall.

Using Split and a stack works with some simpler grammars than a PEG or can support, but it's highly likely that over time you'll either be reinventing recursive descent badly, or you'll have a flaky set of behaviors that you'll band-aid into submission at the cost of extremely unstructured code. If you only have simple tokenization rules it's probably not so bad, but as you add complexity, it will probably be the least maintainable solution. I'd reach for a parser generator instead.

Personally, my first inclination when I need to build a DSL would be to use something like Boo (.Net) or Groovy (JVM), since I get all of the strength of an existing programming language and incredible customizability by building macros and simple adjustments to the compiler pipeline, without having to implement the tedious stuff that I'd end up doing if I started from zero (loops, variables, object model, etc.). If I were in a shop doing Ruby or Lisp development, I'd just use the idioms that make sense there (metaprogramming, etc.)

But I suspect your real issue is either about culture or egos. Are you sure your coworker wouldn't equally have freaked out if you had used Antlr or Flex/Bison? I suspect that "arguing" for your solution may be a losing battle; you may need to spend more time doing a softer approach that uses consensus building techniques rather than appealing to your local management authority. Pair programming, and demonstrating how quickly you can turn out adjustments to the grammar without sacrificing maintainability, and doing a brownbag to explain the technique, its history, and so on, may go further than 10 bullet points and a "rude Q&A" at some confrontational meeting.


答:
According to some sources (see e.g. http://www.indeed.com/jobtrends) C# is still less popular than Java, and as popular as C++.

C# does provide features that Java lacks, e.g. direct support for certain programming idioms like properties, functional programming style, and so on. C# has a higher level of abstraction than C++, which is an advantage when development time is more important that program speed.

Personally, I still prefer the Java / C++ worlds. As Petar Minchev said, Java has more open-source frameworks and applications, it runs everywhere, is less tied to a particular vendor and operating system. C++ has similar advantages, even though code often needs adaptations going from one platform to another. Since I prefer to develop on Linux and, to my knowledge, I cannot have fully fledged C# on Linux, I never got a real interest in C# because my programming needs are covered by C, C++, Java, Scala.

On the other hand, for many developers being tied to a particular vendor is not a problem: Microsoft has a dominant position in the operating system market and C# gives lots of job opportunities. Therefore, IMO many developers adopt C# because, besides being a feature-rich language, it is also a good investment.


答:
Ideally, I would like to see a strong and valid argument against gotos that still holds when you adhere to established programming principles for clean code

goto can be used instead of an if, a switch, for, while, break, return, and many, many other features of the language that all serve different purposes. But there's a reason languages have acquired so many branching and looping constructs: They make it easier to grasp what the code does. Using goto gives up this important feature and leaves you with Assembler-like code to decipher.

A goto is therefore inferior to all those structured language constructs.

I have been following this goto debate for almost two decades now, and in C++ I have yet to see a piece of code that could be made easier to understand by applying a goto, but would not become even easier to understand by applying RAII, introducing additional (inlined) functions, or using one of the above mentioned constructs. (It's different for C, which has no RAII.)


答:
A couple of things that have not already been mentioned:

C# is better than C++ because:

It does away with header files, which translates to great simplicity.

C# is better than Java because:

It supports both reference-type (class) and value-type (struct) user-defined types, which, if you know what you are doing, can yield significant performance benefits.

It supports delegates, which are like single-method interfaces, thus greatly simplifying the coding of frequently occurring constructs that involve single-method objects.


答:
```<code>I heard that syntactically they are almost the same.
</code>```

Syntactically? Who gives a flying monkeys about syntax? Syntax is good for only one thing: allowing faster migration from syntactically similar languages. That's it.

C# is vastly better than Java. Consider their generic and functional programming support- C# is way ahead of Java. Not to mention operator overloads, and other good stuff- C# is vastly better featured. There's no way that Java could possibly be considered better than C#.

C++ and C# is more of a contest. C++ has an incredibly annoying archaic compilation model and a bunch of legacy diseases from C, but it's templates are vastly more powerful than generics, and it's resource managing approaches are much more flexible and powerful in general, as using is a complete failure, and it executes faster.

Body:
I heard that syntactically they are almost the same.

Syntactically? Who gives a flying monkeys about syntax? Syntax is good for only one thing: allowing faster migration from syntactically similar languages. That's it.

C# is vastly better than Java. Consider their generic and functional programming support- C# is way ahead of Java. Not to mention operator overloads, and other good stuff- C# is vastly better featured. There's no way that Java could possibly be considered better than C#.

C++ and C# is more of a contest. C++ has an incredibly annoying archaic compilation model and a bunch of legacy diseases from C, but it's templates are vastly more powerful than generics, and it's resource managing approaches are much more flexible and powerful in general, as using is a complete failure, and it executes faster.


答:
There is nothing wrong with using goto correctly. For example:

```<code>for(int i = 0; i <= 10; ++i)
{
   for(int j = 0; j <= 10; ++j)
   {
      // ..
      if(condition)
        goto end;
      // ..
   }
}

end:
</code>```

The problem is using goto in a way that makes no sense such as in your example:

```<code>if (n >= 0) goto nonneg;
n = 0;
nonneg: ;
</code>```

I've never ever seen this in real code (and I've seen a lot of nasty stuff) so I don't know what's all the fuss and the hate about.

Using goto that way is equivalent to:

```<code>for(int i = 0; n < 0 && i < 1; ++i)
    n = -5;
</code>```

instead of

```<code>if(n < 0)
    n = -5;
</code>```

This doesn't mean that for is bad, just like goto isn't.

Body:
There is nothing wrong with using goto correctly. For example:

for(int i = 0; i <= 10; ++i)
{
   for(int j = 0; j <= 10; ++j)
   {
      // ..
      if(condition)
        goto end;
      // ..
   }
}

end:

The problem is using goto in a way that makes no sense such as in your example:

if (n >= 0) goto nonneg;
n = 0;
nonneg: ;

I've never ever seen this in real code (and I've seen a lot of nasty stuff) so I don't know what's all the fuss and the hate about.

Using goto that way is equivalent to:

for(int i = 0; n < 0 && i < 1; ++i)
    n = -5;

instead of

if(n < 0)
    n = -5;

This doesn't mean that for is bad, just like goto isn't.


答:
The Environment

.NET Framework and Windows clients

Windows is the dominating Operating System on client computers. The best GUI frameworks for Windows applications is Winforms and WPF together with .NET Framework. The best programming language to work with the .NET Framework and it's APIs is C#. Java is not an alternative for this. And C++ is an older language without automatic memory management. C# is similar to C++ but has automatic memory management and you don't have to work with pointers, which make you more productive. C++ can still be the best option for some cases, but not for form-intensive database applications that is common in business.

IIS and Windows Server

If you are used to work in the Windows environment and with C#, you will need the least investment to learn IIS for server programming and  Windows Server for basic administration.

Active Directory and Windows Server

If you are developing software that is going to be deployed in company networks, it's likely that they use an Windows centered environment using a Windows Server with Active Directory. In such an environment it's easist to integrate and deploy an solution made in C# and .NET Framework.

Personally, I'm a Java developer, not a C# developer, but I work with the web. I would switch to C# if I were developing network applications for Windows network. But I prefer Java for Linux based web servers. I would choose C++ for embedded systems were I don't won't many dependecies.

Yes, C# is a better language with more modern features than C++ and Java, but that is not the most important thing for choosing C#.

Summary

The environment for your software is most important for choosing C#. If you work in an environment with Windows clients, Windows servers, Active Directory, IIS and maybe SQL Server then C# is the far best language with the .NET Framework.

If you work in a Unix environment with e.g. web services, Java would be my choice. And if you work with embedded systems or have to integrate with hardware devices C++ would be a good choice.


答: There is simple reason why goto's are unnecessary. It's because line numbers are not available any longer. The original reason to add goto statement to basic programming language was the line numbers. The problem was that the line numbers were fixed, and you couldn't change the numbers. Goto was needed when you run out of available line numbers. Fill in all lines from 1-10, and adding new line inside that range required replacing line 7 with goto statement to line 330, moving the old line 7 to line 330, then writing some code to 331-380, and then adding goto from 380 to line 8. Now if you have thousands of blocks like this, the program will look somewhat awful and difficult to follow.</p>


问:
How do you maximise the knowledge that you gain from a programming book?
Not because I care how long it takes someone to read a book, but more because I'm interested in how people get the knowledge from a book (or I guess other sources) into their brains in the best, most efficient way.

Personally I take a multi-pass approach (from my answer to the original question):

Skim through contents, dip in and read anything with an interesting looking heading and finally gawp at any nice diagrams and illustrations. I won't take much in at this stage, but it gives me a mental view of the book (an hour or so at most)

First pass through the book, generally I'll read the opening chapters thoroughly for a book that is either very heavy going or introduces something completely new. For books that cover a subject I already know about I'll skim or skip bits that seem trivial. The remainder of the book I'll go through reasonably quickly but not so quickly that I'm just page flipping. (about a week)

Not all books that I read make it this far, but if I find a book interesting or useful enough I'll then study it properly. I will go through the book at a slower pace and do some or all of the examples, try out code, etc. I will often skip entire chapters here unless the book is really good (1-3 weeks depending on the book).

Finally when I've finished reading it and am reading other books I will often dip into it again and again to cross-reference, compare, look things up, browse, etc - so many of my favourite books don't just end up gathering dust on the bookshelf.

I rarely take notes when reading (although I may do some planning on paper if I'm working through something like a code sample). I've also considered starting to use a personal kanban for organising my progress, but have never quite got around to using that technique. Mindmaps are another thing I like the idea of but rarely do.

What other methods to people have? How successful do you find them? Are there any commonly recommended techniques that you feel are a waste of time?

答:
Do the exercises.

If there aren't any, invent some.

ContentLicense: CC BY-SA 2.5


答:
It has already been said that things such as if and while and for are merely fancy gotos (albeit well-structured and understandable).

But the interesting thing is that many gotos appear where we'd ideally use something like return. @Krelp's answer is a good example:

```<code>... start of big function
for(int i = 0; i <= 10; ++i)
{
   for(int j = 0; j <= 10; ++j)
   {
      // ..
      if(condition)
        goto end;
      // ..
   }
}
end:
... rest of big function
</code>```

On the very rare occasion I've used goto (temporarily) it where I would have liked to use lightweight nested functions. It would be nice to be able to put these for loops inside a nested function and replace the goto with a return.

```<code>void big_function() {
    ... start of big function
    // next few lines declare a nested function
    void nested_function() { // shall be permitted access to the locals in the parent function
        for(int i = 0; i <= 10; ++i)
        {
           for(int j = 0; j <= 10; ++j)
           {
              // ..
              if(condition)
                return;
              // ..
           }
        }
    }
    nested_function(); // actually call it
    ... rest of big function
}
</code>```

I'd really like to see this sort of thing in C and C++, maybe lambdas will allow it. In fact, maybe global functions should be deprecated and everything should be seen as a lambda! (PS: Don't some C compilers already allow something like this?)

Body:
It has already been said that things such as if and while and for are merely fancy gotos (albeit well-structured and understandable).

But the interesting thing is that many gotos appear where we'd ideally use something like return. @Krelp's answer is a good example:

... start of big function
for(int i = 0; i <= 10; ++i)
{
   for(int j = 0; j <= 10; ++j)
   {
      // ..
      if(condition)
        goto end;
      // ..
   }
}
end:
... rest of big function

On the very rare occasion I've used goto (temporarily) it where I would have liked to use lightweight nested functions. It would be nice to be able to put these for loops inside a nested function and replace the goto with a return.

void big_function() {
    ... start of big function
    // next few lines declare a nested function
    void nested_function() { // shall be permitted access to the locals in the parent function
        for(int i = 0; i <= 10; ++i)
        {
           for(int j = 0; j <= 10; ++j)
           {
              // ..
              if(condition)
                return;
              // ..
           }
        }
    }
    nested_function(); // actually call it
    ... rest of big function
}

I'd really like to see this sort of thing in C and C++, maybe lambdas will allow it. In fact, maybe global functions should be deprecated and everything should be seen as a lambda! (PS: Don't some C compilers already allow something like this?)


答:
Your example is only true in trivial functions, where I can see the whole thing at once. In longer functions, it's not so trivial.

The if statement guarantees no control freakouts within the scope of one statement. I only need to comprehend that one statement to know that nothing funny happens.  The goto statement guarantees no control freakouts within the scope of one function. Therefore, it's inherent that goto is harder to read than if.


答:
Then we must consider the great man's arguments. See a transcription of his original paper for references.

My first remark is that, although the programmer’s activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to effectuate the desired effect, it is this process that in its dynamic behaviour has to satisfy the desired specifications. Yet, once the program has been made, the “making” of the corresponding process is delegated to the machine.

So it is the run-time that is all-important.

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost best to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

(my emphasis)

More specifically, our aim is to ensure that our conceptual image of the running program matches the actual as far as possible.

And finally

... The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. ...

In my opinion nothing has changed, and n'or will it ever change. goto does make it harder to describe the process progress. And since it has also been proved that any algorithm making use of goto can be rewritten to not use it, my case rests.

Just because you can use goto in a less harmful way that doesn't violate too many rules doesn't mean you should use goto. Dijkstra was right, and still is, you must maximise the simplicity of your code. Simple enough is not acceptable.


答:
I am using coding guidelines which allow goto (in Pascal: GOTO exit;) to drop out of a procedure or function in case of some serious error, or when no further processing is possible for whatever reason. Just to jump to the end of a routine, clean up some of the mess (free memory, unlock resources) and then exit. In fact, when including a procedure or function template in the source to code a new routine, the label 'exit' is declared per default.

About the multiple returns: I am in favour of using a local variable to assign the return value to. This can be done on multiple locations. At the end of the function, only one return is required. Together with goto, this can make code more readable, because not so many nested IF statements are required to get to the end of the routine.

However, there will always be people that tell you not to use it, but those are in most cases the ones that do not need to maintain the code.


答:
Your examples are not very convincing. There are many other cases when goto is much better than any other option.

One is implementing virtual machines with the computed goto extension in GCC (see OCaml bytecode interpreter for example).

Another (very broad) case is code generation. For example, it is much more efficient (and much easier to comprehend as well) to generate a Packrat parser code from higher level, declarative PEG, using goto to escape from the failing parsing branches. If your language can be used as a target for code generation or if it is a meta language allowing to implement new language features, goto is a must have.

And a third case - state automatons. Here, goto is a natural representation of a concept of moving from one state to another, and therefore a goto-based implementation is much more readable than anything else.

But, unfortunately, many programmers were taught to a nearly religious hate and fear of the goto, and for this reason none of the above arguments are convincing enough for this lot.


问:
When a task can be accomplished by either Javascript or CSS, is it better to use CSS?
I always veto JavaScript by using CSS as much as possible.

i.e. I create tabs and rollover buttons using CSS rather than JavaScript.

I have seen some solutions—specifically the Wt web-framework—which advocate JavaScript; but gracefully downgrade to CSS if the browser isn't capable/js-disabled.

I know CSS and JavaScript have different purposes, however there is overlap; which is the bourne of this question.

Should I continue using CSS as much as possible over JavaScript?

答:
Yes.

CSS purpose is layout, look and feel and animations

JavaScript purpose is interaction.

If you are doing layout, use CSS, if you are setting the look and feel use CSS, if your doing animation use CSS3

If you attach event handlers or reacting to user input use JavaScript.

Note that people use JavaScript instead of CSS for browser support. There are other solutions like emulating CSS features using javascript.


答: JavaScript is a real computer language, meaning that it has state and control of program execution. As such, there is no upper limit to how complex it can get, and anything you write in it is bound to have a substantial bare minimum of complexity. CSS is a descriptive code; its complexity is limited to the level of complexity that a recipe can have. Therefore, if something can be done both in CSS and JavaScript, I would much rather use CSS, as it is bound to be less complex.</p>

Title: When a task can be accomplished by either Javascript or CSS, is it better to use CSS?

Body:
I always veto JavaScript by using CSS as much as possible.

i.e. I create tabs and rollover buttons using CSS rather than JavaScript.

I have seen some solutions—specifically the Wt web-framework—which advocate JavaScript; but gracefully downgrade to CSS if the browser isn't capable/js-disabled.

I know CSS and JavaScript have different purposes, however there is overlap; which is the bourne of this question.

Should I continue using CSS as much as possible over JavaScript?


答:
Well, that's actually a pretty interesting question.  I'm trying to think of how you would even do a benchmark on something like this, especially since most of the time neither CSS or JavaScript are going to be doing really computationally intensive things on a web page.

My gut feel would say that use CSS as much as possible, but don't make it into a hard and fast rule.

```<code>a:hover {
  background-color: green;
}
</code>```

is better semantically then

```<code>$('a').onmouseover(function() {
  $(this).css('background-color','green');
})
</code>```

BUT

```<code>$('a').onmouseover(function() {
  if (somethingelsehappened) {
    $(this).css('background-color','green');
  }
})
</code>```

would be difficult (though not impossible) in CSS.  You could do it in this way.

```<code>$('a').onmouseover(function() {
  if (somethingelsehappened) {
    $(this).addClass('Green');
  }
})

a.green {
  background-color: green;
}
</code>```

This would really be a slightly more awkward way to do what could have been done in JavaScript directly, but I've been thinking about it for a couple of minutes, and even here, the right solution may very well be a CSS, for example if you were setting a lot of attributes when doing the hover.

** Please note that none of this code is expected to work, these are just for demonstration purposes only.**

Body:
Well, that's actually a pretty interesting question.  I'm trying to think of how you would even do a benchmark on something like this, especially since most of the time neither CSS or JavaScript are going to be doing really computationally intensive things on a web page.

My gut feel would say that use CSS as much as possible, but don't make it into a hard and fast rule.

a:hover {
  background-color: green;
}

is better semantically then

$('a').onmouseover(function() {
  $(this).css('background-color','green');
})

BUT

$('a').onmouseover(function() {
  if (somethingelsehappened) {
    $(this).css('background-color','green');
  }
})

would be difficult (though not impossible) in CSS.  You could do it in this way.

$('a').onmouseover(function() {
  if (somethingelsehappened) {
    $(this).addClass('Green');
  }
})

a.green {
  background-color: green;
}

This would really be a slightly more awkward way to do what could have been done in JavaScript directly, but I've been thinking about it for a couple of minutes, and even here, the right solution may very well be a CSS, for example if you were setting a lot of attributes when doing the hover.

** Please note that none of this code is expected to work, these are just for demonstration purposes only.**


问:
How far has process-i-fi-cation of SW engineering come in the past 10 years?
I read a UML book a long time ago (15 or so years ago) by the inventors which said something like "software engineering should be like building a house".  Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.

When I read it, it seemed reasonable, but from my perspective - I don't think much progress has been made to that end.  It might be that the goal was wrong, or unrealistic - I'm not sure...

答:
Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.

I'd say we've reached that point decades ago: We produce blueprints (the source code) and specialized "workers" (code generators, compilers, setup software, but also people like translators, designers, documentation writers) produce their part of the end result (the final software, running on the users machine).


答:
Consider if you will the following from the Yahoo Developer Network:

"After crunching the numbers, we found a consistent rate of JavaScript-disabled requests hovering around 1% of the actual visitor traffic, with the highest rate being roughly 2 percent in the United States and the lowest being roughly 0.25 percent in Brazil. All of the other countries tested showed numbers very close to 1.3 percent."

With percentages so low (as a maximum) it seems hardly worth it (unless your websites users come primarily from that 2%) to worry about the case where users have their javascript turned off.  The average user doesn't know how to turn javascript off and likely doesn't care to.  If you're developing a tech website you may want to consider the possibility that they will have disabled javascript, however if they have they're likely used to websites not functioning correctly as many websites do use javascript heavily.

All that being said I have found many cases where javascript development makes what I'm trying to accomplish much easier and other cases where css does the same.

In the end each "language" has its appropriate place in web development and used wisely can enhance both development and user experience.  Learn what those uses are (I recommend experience learning) and apply wisely.  In my experience, set in stone rules such as "Never use JS when a CSS solution exists" (paraphrased) are rarely best in the practical world.


问:
Project managers: Do you encourage any sort of task division between morning and afternoon?
I haven't read about this anywhere, but here are my thoughts: programming is inherently intellectually hard. I remember reading in Code Complete something that stuck with me: the author pushing and working on something long hours only to spend the rest of the week fixing it.

This is something managers don't understand. For example, in the last company I worked in, we were expected to switch between tasks and projects as if we were switching from tightening bolts to painting in an assembly line. Getting into a project or fixing a bug, especially with the terrible code we had to maintain, has a lot of momentum and takes a while to get all the needed information in your head and start getting things done.

I was thinking it would be good to concentrate design and coding in the early hours when we tend to stay more alert and do training, administration or meetings in the afternoon. Has anyone thought about this before? any studies?

答:
First off, I'd suggest that other that organizing when items need to be delivered, project managers should stay out of the business of telling the development team when to perform certain activities.   The team should be able to figure out for themselves when they need to do what, based on the priorities the project manager makes.

That said, meetings are necessary, and the best recommendation that I've seen and followed is to designate a small time frame in which meetings should occur, so that the team can focus on its tasks the rest of the day.  Generally, I like to see "meeting time" nestled near the lunch hour, so that the morning people have had their most productive stretch already, and the evening people will have time in the afternoon.

I wouldn't put much credence in there  being one good time for design.

Also, the scenario you present sounds like a prime example of an organization needing to do TDD. I hope that''s not too contradictory, based on what I said above (mandating tests first).


问:
Does object-orientation really affect algorithm performance?
Object orientation has helped me a lot in implementing many algorithms. However, object-oriented languages sometimes guide you in "straightforward" approach and I doubt if this approach is always a good thing.

OO is really helpful in coding algorithms fast and easily. But could this OOP be a disadvantage for software based on performance i.e. how fast does the programm executes?

For example, storing graph nodes in a data structure seems "straightforward" in the first place, but if Node objects contain many attributes and methods, could this lead to a slow algorithm?

In other words, could many references between many different objects, or using many methods from many classes, result in a "heavy" implementation?

答:
In theory, it could lead to slowness, but even then, it would not be a slow algorithm, it would be a slow implementation. In practice, object orientation will allow you to try various what-if scenarios (or revisit the algorithm in the future) and thus provide algorithmic improvements to it, which you could never hope to achieve if you had written it the spaghetti way in the first place, because the task would be daunting. (You would essentially have to rewrite the whole thing.)

For example, by having divided the various tasks and entities to clean-cut objects, you may be able to easily come in later and, say, embed a caching facility between some objects, (transparent to them,) which could yield a thousand-fold improvement.

Generally, the types of improvements you can achieve by using a low-level language (or clever tricks with a high-level language) give constant (linear) time improvements, which do not figure in terms of big-oh notation. With algorithmic improvements you may be able to achieve non-linear improvements. That's priceless.


问:
Where can I find an algorithm for creating 3D anaglyphs using a depth map image?
I'm looking for a generic algorithm to calculate a red/cyan anaglyph starting from the original image and its black/white depth map, as in this example?

That algorithm is used, for example, in Photoshop but I can't find a readable explanation to reproduce it.

答:
Here's an explanation of the Photoshop gag: http://www.threadless.com/profile/433934/elleevee/blog/493381/Threadless

Basically they're using the displace filter to shove only the red channel or the blue+green channels of an image left or right. The heightmap just attenuates the distance that you displace each pixel. I believe the displace filter interpolates the inbetween values, i.e. if the pixel at (10,0) was displaced to the left by 3 pixels, and pixel (11,0) was displaced to the left by only 1, then the two pixels in between the target pixels would be interpolated from the two original values at 66% and 33%.

That interpolation effectively is covering for missing data: if you really had two viewpoints of your scene, then these pixels would represent information hidden in the single view. I can imagine an upgrade to the method outlined above, where reconstruction algorithms similar to Photoshop's content aware fill could take a better stab at filling in the missing information.


答:
That's not really about object orientation as about containers. If you used a double linked list to store pixels in your video player it's going to suffer.

However if you use the correct container there is no reason a std::vector is slower than an array, and since you have all the common algorithms already written for it - by experts - it's probably quicker than your home rolled array code.

Title: Does object-orientation really affect algorithm performance?

Body:
Object orientation has helped me a lot in implementing many algorithms. However, object-oriented languages sometimes guide you in "straightforward" approach and I doubt if this approach is always a good thing.

OO is really helpful in coding algorithms fast and easily. But could this OOP be a disadvantage for software based on performance i.e. how fast does the programm executes?

For example, storing graph nodes in a data structure seems "straightforward" in the first place, but if Node objects contain many attributes and methods, could this lead to a slow algorithm?

In other words, could many references between many different objects, or using many methods from many classes, result in a "heavy" implementation?


答:
I don't think there is a "good time" and a "bad time" for a specific type of task throughout the day for anybody that you could apply universally. For example I'm not much of a morning person but sometimes I wake up in the early morning and remote in because something's just clicked and I realised exactly what needed to be done. On most days, you really don't to talk to me before 10am, and you really don't want be one of those people who are all chirpy and chipper at 6am :) if you need to talk to me that early.

Point being, people are different and the best thing you can do as a manager is to recognise that and cater to it to the extent it doesn't cause problems within the team - you still need to make sure that there is enough overlap in people's hours so they can communicate and don't have someone waiting half a day to get an answer from Joe because Joe doesn't start work until eight hours after Jill came in (assuming they're working in the same timezone).

The most important thing you can do to increase programmer productivity (apart from getting programmers to learn how to touch type) is to ensure a minimum of context switches and interruptions. So point them in the direction they need to go, put the goals in front of them (when it needs to be done, what needs to be done) and ensure that they do stay on course and don't wander off into the wilds.

Title: Project managers: Do you encourage any sort of task division between morning and afternoon?

Body:
I haven't read about this anywhere, but here are my thoughts: programming is inherently intellectually hard. I remember reading in Code Complete something that stuck with me: the author pushing and working on something long hours only to spend the rest of the week fixing it.

This is something managers don't understand. For example, in the last company I worked in, we were expected to switch between tasks and projects as if we were switching from tightening bolts to painting in an assembly line. Getting into a project or fixing a bug, especially with the terrible code we had to maintain, has a lot of momentum and takes a while to get all the needed information in your head and start getting things done.

I was thinking it would be good to concentrate design and coding in the early hours when we tend to stay more alert and do training, administration or meetings in the afternoon. Has anyone thought about this before? any studies?


答:
Object orientation may prevent certain algorithmic optimizations, because of encapsulation. Two algorithms may work particularly well together, but if they are hidden behind OO interfaces, the possibility to use their synergy is lost.

Look at numerical libraries. A lot of them (not only those written in the 60s or 70s) are not OOP. There is a reason for that -- numerical algorithms work better as a set of decoupled modules than as OO hierarchies with interfaces and encapsulation.


问:
Why is the Unit of Work pattern considered fast and efficient when working with an ORM?
In working with Doctrine 2 I came across the following paragraph.

In fact, since Doctrine is aware of all your managed entities, when
  you call theflush() method, it calculates an overall changeset and
  executes the most efficient query/queries possible. For example, if
  you persist a total of 100 Product objects and then subsequently call
  flush(), Doctrine will create a single prepared statement and re-use
  it for each insert. This pattern is called Unit of Work, and it's used
  because it's fast and efficient

I am not up to speed on relational databases and ORM theory so I was wondering why is the Unit Of Work pattern  considered fast and efficient?

答:
I think that one uses the unit of work pattern with ORMs because it is a pattern that is easy to translate from your code to database transactions as both have the same logical boundaries. You can test your unit of work without a database.

Speed and efficiency is really an implementation detail.

OwnerDisplayName: Peter Kelly


问:
Ways of marking changes being made to a file
I am looking for a lightweight way to notate changes made to a file. The obvious answer to this is a version control system. But this is more robust than necessary for what I would like to do. All I want is the functionality to compare an edited file to its original in a lightweight manner.</p>

答:
Many text editors have this functionality built-in. Emacs is one example. If you set

```<code>(setq version-control t)
</code>```

it will keep numbered backup files around. For a file named foo, Emacs will then create foo.i for integers i. By default, Emacs will keep the two oldest and two newest versions around, but this can of course be configured, just like everything else in Emacs can be configured :-)

Body:
Many text editors have this functionality built-in. Emacs is one example. If you set

(setq version-control t)

it will keep numbered backup files around. For a file named foo, Emacs will then create foo.i for integers i. By default, Emacs will keep the two oldest and two newest versions around, but this can of course be configured, just like everything else in Emacs can be configured :-)


答:
Javascript is a scripting language, meaning it has capability to add some logic. CSS is used to describe the look and style of a document. It was designed primarily to separate the document structure from the formatting and layout (presentation).

You can use Javascript to modify the look of a webpage but since CSS was intended to do that, I'd go with CSS for the site style and leave the rest to Javascript.

Wikipedia:

Javascript use:

Opening or popping up a new window with programmatic control over the size, position, and attributes of the new window (e.g.
  whether the menus, toolbars, etc., are visible).

Validating input values of a web form to make sure that they are acceptable before being submitted to the server.

Changing images as the mouse cursor moves over them: This effect is often used to draw the user's attention to important links
  displayed as graphical elements.

UPDATE. As for the third point, the W3C says regarding CSS:

The :hover pseudo-class applies while the user designates an element
    with a pointing device, but does not necessarily activate it. For
    example, a visual user agent could apply this pseudo-class when the
    cursor (mouse pointer) hovers over a box generated by the element.

CSS use:

Prior to CSS, nearly all of the presentational attributes of HTML
  documents were contained within the HTML markup; all font colors,
  background styles, element alignments, borders and sizes had to be
  explicitly described, often repeatedly, within the HTML. CSS allows
  authors to move much of that information to a separate style sheet
  resulting in considerably simpler HTML markup.


答:
C# and Java

C# is a very good language if:

You want to do general purpose object oriented development. It's a classic, statically typed OOP language.

You are targeting Microsoft platforms only (it's worth remembering that Microsoft effectively cloned Java to create C# because they wanted a Java-like language that would lock people into Windows. They could have used Java, but that would have enabled people to easily run applications on other platforms....)

C# as a language is nicer than Java in various ways (better syntax for properties, value types, reified generics etc.). I prefer C# as a language to Java but in the grand scheme of things they are fairly similar languages and suitable for similar applications.

On the other hand, Java has some big advantages as well:

Huge open source ecosystem - the libraries for Java that you can get for free are by far the best of any language. It is hard to overstate the importance of this - from the point of getting things done, Java is very effective.

Tools - the Java tools are in my view better than what you can get the the .Net world. e.g. Maven (once you have mastered it!) is particularly impressive.

Maintainability - Java has been around a while and has been successful in big companies precisely because it is relatively stable and there has been a lot of effort put into backwards compatibility. The simple and slightly verbose syntax also helps Java here - it's easier to read and maintain code if the code is very clear and explicit.

New languages - The JVM has some amazing new languages (Scala, Clojure, Groovy etc.) that are the future of the Java platform. This is where much of the language innovation is happening, and it's happening much faster than in either Java or C#.

So Java vs. C# is a pretty close call and it really comes down to whether you want to be in the Microsoft camp or the Open Source / cross-platform camp.

Personally, I prefer Java because:

The library ecosystem is in my view much more important that the fact that C# has nicer syntax than Java

In the long run, I want all my code to be properly cross-platform and able to run on big clusters of cheap linux machines on the cloud.

Clojure is IMHO the most promising language in the world right now, and if I stick with the JVM platform I'll be able to transition my code and skills easily into Clojure over time.

C/C++

C/C++ is basically a different beast entirely. I would not recommend it for general purpose application development nowadays for the following reasons:

Memory management - for most general purpose programming nowadays, you don't want to be managing your own memory. Garbage collection in C# or Java is much better for your productivity and sanity than any of the explicit memory management techniques you will have to use in C/C++

Complexity - C++ in particular is an extremely complex language. It takes a long time to master and the code itself can also be fiendishly complex. (C++ templates for example are particularly hairy....)

Productivity - most of the time and all else being equal it will take you longer to get things done in C/C++.

However it is undoubtably a great choice in a certain limited number of special domains, in particular:

Operating systems - you probably want to use C/C++ if you are writing an operating system.

Games development - nearly all the best commercial game engines are C/C++. It's still the best choice if you are developing a demanding AAA title (C# and Java are perfectly fine for less demanding / casual games)

High performance computing - optimised C/C++ is probably the best way to create very high performance code. For most applications doing this level of optimisation isn't worth the effort, but in certain domains it can be extremely valuable (high frequency trading for example)

Hardware access - You need direct access to the hardware (e.g. for an embedded system)

So basically, C/C++ is a great choice if and only if you are focused on one of the domains where it is particularly well suited.


答:
Make sure that you apply some of the techniques in your day-to-day programming as soon as possible.

I find that if I don't immediately apply things I've learnt I have to re-visit them when I do actually need them.

Title: How do you maximise the knowledge that you gain from a programming book?

Body:
Not because I care how long it takes someone to read a book, but more because I'm interested in how people get the knowledge from a book (or I guess other sources) into their brains in the best, most efficient way.

Personally I take a multi-pass approach (from my answer to the original question):

Skim through contents, dip in and read anything with an interesting looking heading and finally gawp at any nice diagrams and illustrations. I won't take much in at this stage, but it gives me a mental view of the book (an hour or so at most)

First pass through the book, generally I'll read the opening chapters thoroughly for a book that is either very heavy going or introduces something completely new. For books that cover a subject I already know about I'll skim or skip bits that seem trivial. The remainder of the book I'll go through reasonably quickly but not so quickly that I'm just page flipping. (about a week)

Not all books that I read make it this far, but if I find a book interesting or useful enough I'll then study it properly. I will go through the book at a slower pace and do some or all of the examples, try out code, etc. I will often skip entire chapters here unless the book is really good (1-3 weeks depending on the book).

Finally when I've finished reading it and am reading other books I will often dip into it again and again to cross-reference, compare, look things up, browse, etc - so many of my favourite books don't just end up gathering dust on the bookshelf.

I rarely take notes when reading (although I may do some planning on paper if I'm working through something like a code sample). I've also considered starting to use a personal kanban for organising my progress, but have never quite got around to using that technique. Mindmaps are another thing I like the idea of but rarely do.

What other methods to people have? How successful do you find them? Are there any commonly recommended techniques that you feel are a waste of time?


答:
What determines performance?

The fundamentals: data structures, algorithms, computer architecture, hardware. Plus overhead.

An OOP program can be designed to align exactly with the choice of data structures and algorithms that is deemed optimal by CS theory. It will have the same performance characteristic as the optimal program, plus some overhead. The overhead can usually be minimized.

However, a program that is initially designed with only OOP concerns, without concerning the fundamentals, may be initially sub-optimal. The sub-optimality is sometimes removable by refactoring; sometimes it is not - requiring a complete rewrite.

Caveat: does performance matter in business software?

Yes, but time-to-market (TTM) is more important, by orders of magnitude. Business software place the emphasis on the adaptability of the code to complex business rules. Performance measurements should be taken throughout the development life cycle. (See section: what does optimal performance mean?) Only marketable enhancements should be made, and should be gradually introduced in later versions.

What does optimal performance mean?

In general, the issue with software performance is that: in order to prove that "a faster version exists", that faster version must come into existence first (i.e. no proof other than itself).

Sometimes that faster version is first seen in a different language or paradigm. This  should be taken as a hint to improvement, not a judgment of inferiority of some other languages or paradigms.

Why are we doing OOP if it may hinder our search for optimal performance?

OOP introduces overhead (in space and execution), in return for improving the "workability" and hence the business value of the code. This reduces the cost of further development and optimization. See @MikeNakis.

Which parts of OOP may encourage an initially sub-optimal design?

The parts of OOP that (i) encourages simplicity / intuitiveness, (ii) use of colloquial design methods instead of fundamentals, (iii) discourages multiple tailored implementations of same purpose.

KISS

YAGNI

DRY

Object design (e.g. with CRC cards) without giving equal thoughts to fundamentals)

Strict application of some OOP guidelines (encapsulation, message passing, do one thing well) will indeed result in slower code at first. Performance measurements will help diagnose those issues. As long as the data structure and algorithm aligns with the theory-predicted optimal design, overhead can usually be minimized.

What are the common mitigations to OOP overheads?

As previously stated, using data structures that are optimal to the design.

Some languages support code inlining which can recover some runtime performance.

How could we adopt OOP without sacrificing performance?

Learn and apply both the OOP and the fundamentals.

It is true that strict adherence to OOP may prevent you from writing a faster version. Sometimes a faster version can only be written from scratch. This is why it helps to write multiple versions of code using different algorithms and paradigms (OOP, generic, functional, mathematical, spaghetti), and then use optimization tools to make each version approach the observed maximal performance.

Are there types of code that will not benefit from OOP?

(Expanded from the discussion between [@quant_dev],  [@SK-logic] and [@MikeNakis])

Numerical recipes, which originate from mathematics.

The mathematical equations and transforms themselves can be understood as objects.

Very sophisticated code transformation techniques are needed to generate efficient executable code. The naive ("white-board") implementation will have abysmal performance.

However, today's mainstream compilers are unable to do so.

Specialized software (MATLAB and Mathematica, etc) have both JIT and symbolic solvers able to generate efficient code for some sub-problems. These specialized solvers can be seen as special-purpose compilers (mediators between human-readable code and machine-executable code) which will themselves benefit from an OOP design.

Each sub-problem requires its own "compiler" and "code transformations". Therefore, this is a very active open research area with new results appearing every year.

Because research takes long time, software writers have to carry out optimization on paper and transcribe the optimized code into software. The transcribed code might indeed be unintelligible.

Very low level code.

*


答:
What about "Which Software Development Framework, that includes a programming language" its better ?

You forgot to include other stuff, like the "environment" you will work with.

Are you going to work only for Windows O.S., but, doesn't have to be low level, and have a lot of memory and other resources ?

Choose .NET as framework over Windows, and use C#.

Are you going to work only for Windows, but, doesn't have to be low level, BUT, doesn't have a lot of resources ?

Choose the Delphi Framework (and Object Pascal Delphi programming language or Lazarus Object Pascal programming language)

Is your app. required to support several platforms, like a game, in different mobiles ?

Choose the Java Framework, and the Java programming language.

Is it Linux with KDE as graphic interface ?

Choose QT framework, with C++

Is it Linux with Gnome as graphic interface ?

Choose GObject/GLib framework, with C++

Are you going to work with a lot of low level operations, like developing drivers?

Plain C or C++ its used for several Operating Systems, with standard libraries, as a framework.

Just my 2 cents.


答:
Its related, and often overlooked.

Its not an easy answer, its depends on what do you want to do.

Some algorithms are better in performance using plain structured programming, while others, are better using object orientation.

Before Object Orientation, many schools teach (ed) algorithm design with structured programming. Today, many schools, teach object oriented programming, ignoring algorithm design & performance..

Of course, there where schools that teach structured programming, that didn't care about algorithms, at all.


答:
Perhaps working on a good DSL semantics is also important (the syntax matters, but also the semantics). If you are not familiar with these issues, I would suggest reading some books, like Programming Languages Pragmatics (by M.Scott) and
Christian Queinnec. Lisp In Small Pieces. Cambridge University Press, 1996.

Reading recent papers in the DSL conferences, e.g. DSL2011 should also help.

Designing & implementing a Domain Specific Language is difficult (and most of the difficulty is not parsing!).

I don't really understand what you mean by parsing the Cthulhu way; I guess you just mean to parse in a somehow bizarre fashion.


答:
Performance all comes down to CPU and memory cycles in the end.  But the percentage difference between the overhead of OOP messaging and encapsulation and a more wide open programming semantic may or may not be a significant enough percentage to make a noticeable difference in your application's performance.  If an app is disk or data-cache-miss bound, any OOP overhead may be completely lost in the noise.

But, in the inner loops of real-time signal and image processing and other numerical compute bound applications, the difference may well be a significant percentage of CPU and memory cycles, which can make any OOP overhead much more costly to execute.

The semantics of a particular OOP language may or may not expose enough opportunities for the compiler to optimize away those cycles, or for the CPU's branch prediction circuits to always guess correctly and cover those cycles with pre-fetch and pipelining.


答:
OOP is obviously a good idea, and like any good idea it can be over-used.
In my experience it is way over-used.
Poor performance and poor maintainability result.

It has nothing to do with the overhead of calling virtual functions, and not much to do with what the optimizer / jitter does.

It has everything to do with data structures that, while having the very best big-O performance, have very bad constant factors.
This is done on the assumption that if there is any performance-limiting problem in the app, it is elsewhere.

One way this manifests is the number of times per second new is performed, which is assumed to have O(1) performance, but can execute hundreds to thousands of instructions (including the matching delete or GC time).
That can be mitigated by saving used objects, but that makes the code less "clean".

Another way it manifests is the way people are encouraged to write property functions, notification handlers, calls to base class functions, all kinds of subterranean function calls that exist to try to maintain consistency.
For maintaining consistency they are of limited success, but they are wildly successful at wasting cycles.
Programmers understand the concept of normalized data but they tend to apply it only to database design.
They do not apply it to data structure design, at least partly because OOP tells them they don't have to.
As simple a thing as setting a Modified bit in an object can result in a tsunami of updates running through the data structure,
because no class worth its code takes a Modified call and just stores it.

Maybe the performance of a given app is just fine as written.

On the other hand, if there is a performance problem, here's an example of how I go about tuning it.
It's a multi-stage process.
At each stage, some particular activity accounts for a large fraction of time and could be replaced by something faster.
(I did not say "bottleneck". These are not the kinds of things that profilers are good at finding.)
This process often requires, in order to get the speedup, wholesale replacement of data structure.
Often that data structure is there only because it's recommended OOP practice.


答:
You have asked this as if you have a technical question, but as you probably already knew, there is no technical question here.  Your approach is vastly superior to hacking something up at the character level.

The real problem is that your (presumably more experienced) colleague is insecure, and feels threatened by your knowledge.  You will not persuade him with technical arguments; that will just make him more defensive.  Instead you will have to find some way to alleviate his fears. I can't offer many suggestions, but you might try showing high regard for his knowledge of the legacy code.

Finally, if your manager agrees with his specious technical arguments and discards your solution, then I think you are going to have to look for another position.  Clearly you would be more valuable, and more highly valued, in a more sophisticated organization.


问:
What are the similarities between Perl and Java?
I have my mind set that I'm learning Java as my second language (I am a Perl developer). But just from reading a little of the online tutorials, I really can't find any similarities between the two. What will I have an easy time understanding when learning Java?</p>

答: Well, they both use a C like syntax - semicolons, curly braces and the like. Personally, when I tried to make a switch from Perl to Java a number of years ago - the biggest thing that tripped me up was object oriented programming. I had developed some objects in Perl, but it hurt my head to try to imagine life in the Kingdom of Nouns.</p>


问:
How to go about "taking over" an open-source project?
There's an open-source project that I'm interested in and use regularly. It's licensed under the Apache License 2.0 and it has basically no activity any more. It's hosted on Google Code and I'm interested in continuing it's development. I'm new to the open-source process and I'm trying to figure out the appropriate way to go about this. Can I just check it out and push it to github so I can continue it's development in the open there? Should I contact the project "owner" first? Also, do I leave all the author information at the top of the classes, etc even though I'm going to be making changes..(I'm assuming the answer is yes)?

Also, how do I practically adhere to the license requirement of "all modifications are clearly marked as being the work of the modifier"? Do I place a comment by every change I make?

Any guidance on what's the normal course/standard here would be greatly appreciated?

答:
Recently, I took over an open-source project. The steps that I followed are:

Contact the original author

Let him/her know my intentions

Get acknowledged by him/her (you will either get the rights to the original repository or you will get to clone it)

Retain original authorship (will be adding myself when I make further changes)

By "Retain original authorship"... I mean to credit the original author above myself in all cases as it is originally his/her work.

OwnerDisplayName: LuxuryMode

OwnerDisplayName: Alan Haggai Alavi


答:
You should fork the project, perhaps into GitHub.

Alternatively, you can try to contact the original author.

Title: How to go about "taking over" an open-source project?

Body:
There's an open-source project that I'm interested in and use regularly. It's licensed under the Apache License 2.0 and it has basically no activity any more. It's hosted on Google Code and I'm interested in continuing it's development. I'm new to the open-source process and I'm trying to figure out the appropriate way to go about this. Can I just check it out and push it to github so I can continue it's development in the open there? Should I contact the project "owner" first? Also, do I leave all the author information at the top of the classes, etc even though I'm going to be making changes..(I'm assuming the answer is yes)?

Also, how do I practically adhere to the license requirement of "all modifications are clearly marked as being the work of the modifier"? Do I place a comment by every change I make?

Any guidance on what's the normal course/standard here would be greatly appreciated?

OwnerDisplayName: SLaks


问:
GPL: terms of license
I'd like to use the VLC's DLL in one of my programs.
VLC is under the GPL license.
Do I have to redistribute all the sources under GPL or can I redistribute only the modified sources of VLC under these terms while redistributing the rest of my program in the license I want?

Thank you,
Sébastien

Edit: And what if I only use the DLL of VLC in case they are installed on the user's computer ?

答: libvlc has recently been re-licensed under the LGPL. It may now be used with closed source applications. </p>

OwnerDisplayName: Sébastien

Title: GPL: terms of license


问:
In c/c++, are block-scope variables stacked only if the block is executed?
Suppose this:

```<code>void func()
{
 ...
 if( blah )
 {
  int x;
 }
 ...
}
</code>```

Is the space for x reserved on the stack immediately when func is entered, or only if the block is actually executed?

Or is it the compiler's choice?

Do C and C++ behave the same about this?

答:
Who said the compiler will reserve any space (could be register only).

This is completely undefined.

All that you can say is that it (x) can only be accessed from inside the inner block.

How the compiler allocates memory (on a stack if it even exists) is completely upto the compiler (as the memory region may be re-used for multiple objects (if the compiler can prove that their lifespans do not overlap)).

Is the space for x reserved on the stack immediately when func is entered

Undetermined.

or only if the block is actually executed?

Undetermined.

But if x was a class object then the constructor will only be run if the block is entered.

Or is it the compiler's choice?

The compiler may not even allocate memory.

Do C and C++ behave the same about this?

Yes


问:
Starting off with web dev with php
I'm currently working with Java / C++. I'm interested in web development and am planning to shift my stream. I heard that PHP is a good platform to start off and also it does not require that much of knowledge in technologies like JSP / Servlets or frameworks like springs / struts / hibernate.

I have basic ideas about HTML and Javascript as well. I have gone through previous posts in SO and found out the relevant resources as well:

http://net.tutsplus.com/tutorials/php/the-best-way-to-learn-php/

http://www.webhostingtalk.com/archive/index.php/t-1028265.html

http://www.killerphp.com/

http://phpforms.net/tutorial/tutorial.html

http://www.php5-tutorial.com/ etc.

Now, my question is: I heard of PHP frameworks like CodeIgniter, Zend Frameworkd and Yii.

Doesn't learning PHP & MySql implicitly makes us aware of these frameworks?

Am I making a good choice in stating with PHP?

Is it a good idea to shift streams?

答:
PHP is fine to start with.  You wont necessarily encounter frameworks.  I've been coding in PHP for over 10 years now and have never used a 3rd party framework.

What I would recommend, is rather than immediately diving deeply into the language, is instead put a lot of emphasis on learning HTML, JavaScript, an CSS.  The whole point, after all, of using PHP is generally to output something to a browser.  The more you know the client side technologies, and understand them, the better off you'll be.  The side benefit of that is those technologies are the same, regardless of the language you use on the server side.

Title: Starting off with web dev with php


答:
Perl is a high-level, general-purpose, multi-paradigm, interpreted, dynamic programming language.
Java is a high-level, general-purpose, mostly single-paradigm, statically typed programming language.

So, both are high-level:

A high-level programming language is a programming language with strong abstraction from the details of the computer.

and general-purpose:

In computer software a general-purpose programming language (GPL) is a programming language designed to be used for writing software in a wide variety of application domains.

In essense this means that everything you can do with Perl, you can also do with Java. And as @KyleHodgson mentions, both their syntaxes derive from C and C++ and the syntax for simple stuff like for loops and if statements is essentially the same - and as @DipanMehta notes, both are garbage collected. And of course both are extremely popular and have vibrant communities.

But that's where the similarities stop. Perl is multi-paradigm, supporting a wide range of programming paradigms:

Functional programming,

Imperative programming,

Class based object-oriented programming,

Reflective programming,

Procedural programming, and

Generic programming

Perl does not encourage one single paradigm, they are essentially equal and you are free to choose whichever you think best suits whatever you're building, without of course limiting you to a single paradigm, you can mix and match. On the other hand, Java is mostly a class based object oriented language. There is support for generic programming, but as a beginner you should think of Java as strictly a class based object oriented language.

So Perl allows more than one ways to structure your code1, whereas Java just one. That's not a bad thing (or a good thing), it's just different. If you haven't written any object oriented Perl code, Java might seem a little bit alien at first. Don't be discouraged, object orientation is something that you will eventually have to learn, if you are considering a career in software development, and learning Java is a good way of learning the basic concepts of object orientation - not a perfect way, but definately a good way.

And as you know, Perl is interpreted, whereas Java is... well... a different beast entirely. In Java you write your code as you would in Perl, and then you compile it. The result is not an executable, but Java bytecode. This intermediatery format is executed (finally!) in the Java Virtual Machine, which is somewhat analogous to the Perl interpreter. A JVM must be installed beforehand for a Java program to run, simirarly on how you need to install a Perl interpreter to execute a Perl script2.

Coming from a Perl background, the most important thing to remember is the compilation to bytecode step: Every time you make a change to a Java source file you need to re-compile it. It might sound crazy at first, but compilation has a very nice consequence: Your code is checked for a variety of errors at this stage, and the compiler refuses to finish the process if there are any, and sometimes will help you pinpoint the errors with helpful messages (There are always messages, but only sometimes they are helpful).

Which brings us to the last major difference:

Perl is dynamic3:

Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution.

and dynamically typed4:

A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time.

and Java is statically typed:

A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time.

Which, to put it as simply as possible, means that in Java you have to declare the type of your variables and methods before using them. There are other differences, but I wouldn't want to spoil the fun of discovering them by yourself :)

And, finally, there is one very important difference: Java is the sweetheart language of the academia5 and the corporate world, while you will rarely meet Perl in an academic setting anymore (where I first met her), and its career perspectives are shrinking (still quite a few jobs, but nowhere near as many as Java, .Net languages or PHP). I will not comment on the reasons, I'm just stating the (sad) facts. Since you are still very young, by learning Java you will be a little bit more prepared for a Computer Science degree, if you chose to follow that path.

Don't give up on Perl, of course, but do explore Java. The fact that they are more different than similar also means that you will learn quite different approaches and programming mentallities, it's a hard path but one that will ultimately make you a better programmer.

1 "Tim Toady"

2 The Perl community is actively exploring the possibillity of a Perl virtual machine, via Parrot.

3 Dynamic doesn't always mean dynamically typed.

4 Perl is dynamically typed for user defined types, statically typed with respect to distinguishing arrays, hashes, scalars, and subroutines, and strongly typed via use strict, so essentially it's a variable type system language, but to keep some sense of sanity let's call it dynamically typed.

5 To the point of abuse, as Joel Spolsky writes in The Perils of JavaSchools.

Title: What are the similarities between Perl and Java?

Body: I have my mind set that I'm learning Java as my second language (I am a Perl developer). But just from reading a little of the online tutorials, I really can't find any similarities between the two. What will I have an easy time understanding when learning Java?</p>