Skip to main content
Software Engineering

Return to Answer

added 714 characters in body
Source Link
Luaan
Luaan
  • 1.9k
  • 1
  • 13
  • 10

What if your leaders decide that you're going to port to C#, rather than Java? Not only does C# support overriding operators, but it's also the default - if you're going to require people to use e.g. obj.Equals(obj2) instead of obj == obj2, people are going to make mistakes all the time. Even if you keep only to the common features of the two languages, there are different expectations, a different culture. If you do something like if (myField == null) in C++, people are going to see you're a novice immediately. If you use if (null == myField) in C#, people are going to see you're not really C# native yet - the reasons C developers learned to use the "flipped" variant no longer exists in C#.

Using your logic, we should have stuck with machine code or assembly or COBOL, because why ever change to something like Pascal, when it just adds new features that your programmers will have to learn? Why would we ever use something like SQL, when it doesn't even have loops? Why would we ever use something else than SQL, when SQL doesn't have loops and X does?

Using your logic, we should have stuck with machine code or assembly or COBOL, because why ever change to something like Pascal, when it just adds new features that your programmers will have to learn? Why would we ever use something like SQL, when it doesn't even have loops? Why would we ever use something else than SQL, when SQL doesn't have loops and X does?

What if your leaders decide that you're going to port to C#, rather than Java? Not only does C# support overriding operators, but it's also the default - if you're going to require people to use e.g. obj.Equals(obj2) instead of obj == obj2, people are going to make mistakes all the time. Even if you keep only to the common features of the two languages, there are different expectations, a different culture. If you do something like if (myField == null) in C++, people are going to see you're a novice immediately. If you use if (null == myField) in C#, people are going to see you're not really C# native yet - the reasons C developers learned to use the "flipped" variant no longer exists in C#.

Using your logic, we should have stuck with machine code or assembly or COBOL, because why ever change to something like Pascal, when it just adds new features that your programmers will have to learn? Why would we ever use something like SQL, when it doesn't even have loops? Why would we ever use something else than SQL, when SQL doesn't have loops and X does?

Source Link
Luaan
Luaan
  • 1.9k
  • 1
  • 13
  • 10

Just because the syntax seems similar on the surface doesn't mean that the two languages are compatible.

1, 4 and 5 are really the same question:

Now, I'm no fan of C++, but saying "Code without C++ specific features is usually more maintainable" is just ridiculous - do you really believe that Java got everything right, and took all the good features while ignoring all the bad ones? Do you really believe there is something that's universaly a "bad" or "good" feature? If there is, why don't we have one language that is purely good? And no, Java certainly isn't that language. Does that mean that Java and C++ are useless? Of course not.

Using your logic, we should have stuck with machine code or assembly or COBOL, because why ever change to something like Pascal, when it just adds new features that your programmers will have to learn? Why would we ever use something like SQL, when it doesn't even have loops? Why would we ever use something else than SQL, when SQL doesn't have loops and X does?

C++ code certainly cannot be maintained by Java programmers. I can't understand where you got this idea - what exactly remains when you limit C++ to only the features that work exactly the same as in Java? You're not even going to get method calls - not even function calls. Again, just because both langauges use curly braces, doesn't mean that the languages are in any way interchangeable.

Converting Java-like C++ code is going to be extremely error prone no matter what you do. There's just too many differences. If you care about having to rewrite your application in a different language, think about reasonable ways to modularize everything, so that you can replace the parts without breaking the whole. But in the end, YAGNI - no matter what you do, there's going to be a significant cost to making your code "ready to convert to Java". That's time that's very likely better spent on adding or improving your features.

We use different languages because they give us a different set of tools to solve problems. If you need executables that work "everywhere", go with Java. If you want code that compiles "everywhere", C++ works fine. If you want code that's easy to understand and parse, go with LISP or whatever. But I can tell you one thing - writing code in one language as if you were writing it in another is always a mistake, and you will suffer. Not to mention that when you actually hire a C++ guy, he's going to run the second he sees that "Java-ish compatible" code. And... the Java guy is going to do the same. You know, even "knowing" both C++ and Java, I'd run like hell :)

I actually had to work on (plain) C code written by a Pascal developer who seemed to think like you do. He used #defines to redefine C to look and feel more like Pascal, complete with things like "BEGIN translates to {". The result was rather predictable - code that neither C nor Pascal developers can understand, and full of bugs that were a result of the leaking "abstraction" of Pascal on top of C. And Pascal and C are almost identical from today's point of view. Even going C <-> C++ is much more of a difference, and that's still peanuts to something like C++ <-> Java.