As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What mainstream frameworks, patterns, and tools would you choose to develop two projects in parallel, one in C#, one in Java, in order to minimize the total effort. (Disregard the obvious cases of interchangeable or equivalent tools, like SCC, Unit Testing, etc. Also assume generic broad RDBMS support.)
"Mainstream" means the market in general won't disregard the result because it uses something untested they've never heard of, or arcane skills are required to implement and support it.
Assume a broadly applicable tactical business appication.
db4o uses an in house tool called sharpen to maintain one source repository (Java I think) and convert it automatically to C#.
As they say in thier blog post:
Before you start dreaming: sharpen is not a "magic wand". Don't expect to feed it an arbitrary Java app and receive a running .NET version at the push of a button. The translation process will require some design compromises on the Java side, and parts of the .NET code still have to be hand crafted and integrated into the converted sources.
However it is still quite a cool project. Also, I think it would work best for a new project. Released under the GPL but you have to register with developer.db4o.com to download it.
Edit: Here is an example blog post too.
That's tough. While there are some good libraries available ported to both platforms, when it comes to frameworks, there doesn't seem to be much commonality.
The drift I've gotten here on SO is that there isn't much deviation from the company line in the .NET world. It would be as if everyone in Java used only EJB, JSF, and JNDI, and never came up with Guice, Struts, or Hibernate.
If I could, I'd take a different tack: instead of developing the same system in parallel, develop one system, and put a wrapper around it to support the other platforms. The drawback to this is that the other platforms are doomed to lag behind the primary, e.g. Mono. This drawback also applies to ports of some libraries themselves, like Spring.net or Guice.net.
Or you could invent your own Wasabi.
I've read good things about Mainsoft applications, although I never had to use it myself.
Why would you want to develop for Java and C# in parallel?
You could just use Java and J#. The only problem is, that J# is stuck at Java 1.4 level, so you have two choices:
don't use this fancy stuff like enums, generics, for-each
use a tool like retroweaver to convert 1.5 back to 1.4
I've just finished building a mid-size application (about 80 classes / 30.000 lines) that runs nicely on Java and .NET this way.
As far as I know, the Java Classes compiled by J# are .NET-bytecode that is like any other .NET-bytecode, and can be used in C#. But you don't have to code your core classes twice.
Depending on the scale of the project I would suggest the following technologies and approaches:
Since UI in Java and C# are so different I would build an XML representation of UI for both projects... And then decide on one of two options
a) Static and single generatios of the source of UI classes for both projects on the basis of the common XML (this might be somehow integrated with your building process so that the whole process would ignite automatically)
b) Dynamic generation of UI in both cases (probably harder to realise)
To make the architecture of both project similar I would use Spring and Spring.NET
Also to draw as many similiarities I would decide on NHibernate and Hibernate
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for general opinion about which language would be best. Best in regards to many considerations.
I have a pretty strong background in c, c++, and objective-c. I feel quite comfortable with those 3. I have used very little c#. I've worked in firmware and middleware for over a decade and have moved into mobile apps lately. Mostly iOS, but now expanding to Windows RT.
I am about to write a version of my company's app for Windows Store (or Metro depending on what you want to call it). I did a proof of concept a couple months back using C++/CX. There were are few hurdles learning it (the syntax for ref classes, and the heavy use of namespaces), but that is in the past and I feel quite comfortable with it at this point.
Some drawbacks that I found were that most of the examples (both MSDN and private) of .net are in c# with fewer in c++. It also seemed to be a little tougher to get questions answered concerning .net frameworks with c++. Most of the time people would post a c# answer and I'd need to port it to c++ equiv. Sometimes this is easy, sometimes more difficult.
My question is: Would it be worth my time and my company's time to start over with c# instead of continuing in c++? I'd need to pick up c#, but I don't consider that a huge burden (actually looking forward to it). Some concerns are:
* Acquiring an more engineers down the road to work on this code. Our company will grow shortly. Will it be easier to find an engineer that knows c# vs MS's specialized c++/cx?
* Ease of getting help though examples, articles, and forums. If c# is much more common, that's useful.
* Compatibility between 3rd party libraries (Seems like WinRT components can be used from any of the main languages)
* Advantages of C# over C++? They both offer everything I need for this app, at least that I can see. What are some pitfalls of C#?
* Does c# use the continution/lambdas for asych programming in the same manner as C++/CX?
Are there any other pros/cons that I'm not thinking of?
What do YOU think? Also, what do YOU have experience with? Why do you back your answer?
C# would have the better online support (code examples, answers to questions), and the stronger base of engineers. I mean that in this specific situation, for this kind of strongly Microsoft APIs reliant software development. Windows Store highly important in Microsoft's overall strategy and C# is more important in their language strategy than C++. Thus, C# is the right fit, IMO.
*EDIT (Filip Skakun) I know reopening the question might be hard, so I can't answer it separately but I typed in all this text that could be useful, so I thought I'd add it below:
It is up to you to decide of course and it might be a very subjective choice depending on what you believe in, like if you think the higher potential productivity and better tooling and documentation support of C# outweighs the benefits of a faster, closer to the metal and (slightly subjectively) more portable C++ that you already know. C++ is still almost twice as popular as a language based on the tiobe index, so getting C++ developers might be easier than C# ones. C++/CX is something you only need to use for cross-assembly communication and talking to the WinRT library, but anything else you code should be done in the standard C++ based on all expert recommendations. Also note that C++/CX is not a managed language and you don't use it with .NET. It is highly similar in syntax though to C++/CLI which is a managed language. The good thing about WinRT is that you can use both languages if you want or need to. I use C# for all the XAML UI, networking, business logic etc. There are tons of samples for using C# with XAML while limited range of ones for C++ since it only became available and recommended for XAML platforms with WinRT. On the other hand for anything lower level like working with DirectX or CPU intensive tasks I use C++, since there is more documentation for straight DirectX than the open-source .NET wrappers for it and it performs better when you want to squeeze out all the potential power of the CPU or use the least energy from the battery.
C# is a bit cleaner language than C++ with less punctuation, the new async/await keywords that make async calls (which you must use in Windows 8 apps) a lot cleaner. It is also a managed language so in most cases you might not need to care about when memory gets released, about buffer overruns etc. Debugging C# code yields more deterministic results than C++ (I just spent 2 days debugging some C++ code and I still don't know how far along I am in finding the bug). It is also easier to maintain legacy code since debugging is so much easier.
C++ is faster, so it also uses less battery, your application will start faster and possibly use less energy. If you already know it well then you might have an advantage over the managed development crowd building apps out there. Because it doesn't use garbage collection - memory management is more deterministic and lightweight, so your animations will be more fluid.
Then there is also the motivation factor. If you really want to learn C# - you might be more happy, motivated and productive learning C# than the language you already know and will happily spend more hours learning it than you would be willing to spend writing another C++ app.
The underlying WinRT libraries are the same regardless of which language you use, but the .NET libraries are only available in .NET code and the standard C++ libraries are only available in native code.
Finally - regardless of what decision you make - you can always mix both languages. That could add to maintenance costs since whoever maintains the code in the future might need to know both languages and also the mixed language platform is very young, slightly less supported by the tools (you can't do mixed managed+native remote debugging for example) and potentially more buggy. It is a very good choice in many cases for the reasons I stated earlier though.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I've been using C# for a while now and I love it for its great integration with Windows. The Win32 API in C++ is a monster, but that's another story. Anyway, I was wondering, is C# a "good enough" language to use for larger projects? Does Microsoft use C# in any of their applications? I've always assumed C++ was the only choice for large projects because of its speed and has no need for the CLR.
What is your opinion on C#?
EDIT: By large I mean applications like Microsoft Project (first example that came to my mind). It could also mean mission-critical applications, as well.
Unless you're after extreme performance (eg gaming), C# is perfectly acceptable for almost any application - I've been developing enterprise-scale apps in it for years and as a general rule, the advantages far outweigh any (negligible) performance losses compared to C++ - especially when you factor in development time and the relatively low cost of improving CPU speed.
Since I've started using C#, it would take a VERY good reason to make me go back to something lower-level like C++ - There are simply so many advantages in terms of ease of development, memory management, a huge library (.Net framework), WCF, LINQ, etc.
I would personally consider C# before any other language when starting a new project
I've using c# since it came out and so far there were only a few things I couldn't do with it such as print drivers. Other than that I developed fairly complex multithreaded server-side applications that are both reliable and fast.
Also - you may want to define "large".
Yes, but I'd encourage you not to follow a Vendor Lock in pattern. Although you could argue that doesn't really apply to .net, but you would lose.
SharePoint and Dynamics (Microsoft products) (and several others) are written almost exclusively in .NET (C#). They would certainly be considered large, enterprise scale applications. Almost all internal project at Microsoft, with the exception or Windows and Office supposedly are written in C# these days (I think it's even a requirement for new projects).
You will incur larger startup times, as you have to load the .NET runtime. Other than that, performance is actually quite good for most things.
And with the garbage collection, memory leaks are less of an issue, so Java and C# both become good options for mission-critical applications (memory leaks grow over time, and can kill things that run for weeks or months at a time. With a more reliable memory footprint, you application can be more stable).
so... yes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
What aspects of Objective-C do you like and why (specially comparing with C#)? Has C# lost something on the way comparing to older languages as C, C++ and Objective-C
1. Memory Management
I'd say one of the biggest benefits is the explicit memory management that Obj-C requires. At least, there is a garbage collector but you have to opt-in knowingly. I can't tell you how much thread deadlock and memory leakage I had with C# because I expected the GC to do my work for me. What it taught me was to make pretty much all classes in C# implement IDisposable. No object should ever assume that mommy will clean his room for him.
2. Message Sending
Rather than the concept of a "method", "messaging" seems much more realistic to me. You send an object a message, telling it what to do. It's mainly semantics, but it can make all the difference in how you design classes.
3. Message Syntax
Some consider the verbose style of obj-c messages to be a downside, but I personally like it. I can look at a line of code, and instantly know what all the parameters are for, without having to consult metadata. It's almost like Ruby in the sentence-like construction, just not as succinct. For example, seeing if one class is a subclass of another is quite readable to strangers:
[animal isSubclassOfClass:organism]
In addition, this verbose syntax starts to make you really think about how your program should be designed in order to minimize the amount of cruft that builds up. I feel that my classes in objective-C are much smaller and more purposeful than in C#. It's not easy to build giant super-classes full of methods. So, it promotes good design.
4. Deployment
When jobs exist for a technology that are primarily for deploying software, there is a problem. As a developer, I should be able to cleanly package something with the click of a button, and have it ready for consumption by my clients. C# is a nightmare, and while much of that has to do with the way Windows is built as opposed to OSX, they could learn a lot from Apple. Packaging with XCode is a breeze. It's not a language feature, but it makes all the difference when it comes time to actually deploying what you've written. Spend your time coding good software, not making installers.
5. Interface Builder
Again, this isn't really a language feature as much as an IDE feature, but it should be included. Interface Builder promotes MVC from top to bottom. Presentation logic is 100% separate from controller or model logic by design. Plus, it's just dead easy to use.
Objective C is a pure superset of ANSI C. Thus you can port and reuse a huge amount of C library code, emulators, numerical libraries, etc. written for Linux/Unix.
Objective C is also unmanaged, so you can access and optimize the bits in memory to your hearts content, which is useful if you are trying to minimize every byte and battery-eating processor cycle. Memory management is also explicit, which allows a competent programmer to minimize memory usage without wasting processor cycles to do it less efficiently via garbage collection. Basically, you can learn how to develop code that is can offer much better battery life on tiny portable devices.
If you know and like C# just goto Mono for the Iphone (http://monotouch.net/).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
This is a trend I've noticed. There is a very large adoption of ruby from the java community. Is it that c# is such an awesome language + having good tools over java that most c# developers aren't as keen to switching to ruby permanently as java developers are?
What are your opinions?
C# is a modern, and quite powerful language, sporting:
Lambdas (closures)
Continuations (yield)
Value types
Properties
Type inference
Pass-by-reference
...just to name a few.
These features make a transition from C# to Ruby far less attractive than a transition from Java to Ruby.
Because .NET is part of a coherent environment which includes developer tools, database links, orm management GUI front ends, net front ends etc. etc.
Java is a language! There are losts of piecemeal bits and pieces which do all of the above, but, the quality varies considerably. From something like Apache POI which is a better interface to MS Office documents than MS provides to the abysmal J2EE stack which half does in a very complicated way what .NET does in a simple and elegant way.
Whereas for Enterprise level, millions of transactions, bullet proof, fast never lose your data all the extra work putting together J2EE, JDBC, Spring, Hibernate etc.etc. etc. is actually worth it, for a quick simple Web to Database app its just too painful, hence the attraction to ROR.
On the other hand while .NET can scale up to the big stuff (not as well as J2EE! ) it is still reasonably straightforward to do a small application.
I see two reasons:
It seems to me that the biggest benefits of switching to Ruby for a Java developer are closures and dynamic type inference. Both of these can be found in C#.
.NET benefits from a rather tight integration with the Windows platform - (COM interop, WPF, easy installation), making it more difficult to switch from .NET to something else.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
I want my code to be as secure as possible.
I do not think that the security of your source code is a good reason to choose between C # and Delphi. if you create an .Net executable you can protect it with a tool like .Net Reactor, on the othe hand the win32 executables are by definition very difficult to disassemble (get the original source code) unless you include debug information in them.
You should compare other features, in my opinion you should use the language with which you feel more comfortable and you have more skills.
In my case it always chooses delphi, because it has an excellent and fast compiler and thousands of third party components and in addition to generating executables without dependencies. ;)
You can check this question
What language or RAD IDE do you recommend for building shareware?
Also you can check this list of applications built with Delphi
Good Quality Applications Built With Delphi
Among them Skype, TOAD, FL Studio.
It depends on your needs. But in the absence of additional information: If it's a shareware program, I'd go for Delphi, mainly because it compiles into relatively small and fast native code executables.
Should you be concerned about modern (Delphi 2010) apps being less secure than older ones because of the new, enhanced RTTI - that can be turned off with a compiler switch.
Delphi is your best choice for shareware software : you can distribute your app in a single exe file , you can embed whatever resource you want to : html pages, images, even your dbserver (look for firebird embedded).
Lots of shareware software was developed with delphi : EMS products (EMS SQL Manager for MySQL, IB, Oracle...), Skype, 7zip...
Have fun with DELPHI
Best Regards
Deleting this because everyone is down arrowing my response simply because their opinion is different than mine. It was an answer to his question, but an unpopular one, so people decided to start taking points away from me.
That's not the purpose of the down arrow, to remove points from people who disagree with you. Your childish and ingnorant actions will subtract from the quality of this site.
In Delphi, you can use pointers (and sometimes they are necessary, for API calls for example) - so you are closer to C than with C#. There is a reason why Java and C# do not have pointers: security.
"Most studies agree that pointers are
one of the primary features that
enable programmers to inject bugs into
their code."
http://java.sun.com/docs/white/langenv/Simple.doc2.html
In the C# programming language,
pointers are supported only under
certain conditions: any block of code
including pointers must be marked with
the unsafe keyword.
http://en.wikipedia.org/wiki/Pointer_%28computing%29#C.23
"Pointers are like jumps, leading
wildly from one part of the data
structure to another. Their
introduction into high-level languages
has been a step backwards from which
we may never recover."
— C.A.R.Hoare "Hints on Programming Language Design", 1973, Prentice-Hall collection of essays and papers by Tony Hoare
Use C# just because it has more mainstream support. Plus it is sure to be backed by Microsoft. Which adds incremental features to the language from time to time.
Also, the main architect of C# in Microsoft is Anders Heilsberg which was the co-creator of Turbo Pascal and Delphi of Borland before he got pirated by Microsoft.
It doesn't really matter in which programming language you create your "secure" application as long as you know what you want keep working until you get the result.
If you build an application in python or any other scripting language for instance you can still have good security.
As a good friend of mine told me few times "it's all you! programming language is just an extension of your mind!"
Both are good. Both are secure. Plenty of people are around who work with either of them.
The support for "enterprise" features like heavy Web services, distributed applications and componentized applications is better using the .NET Framework. Similarly there's no direct equivalent to the vector-based forms possible with WPF.
But if your application will never need them - then go with what you feel most comfortable.
As with most of the posts here, I would agree that security is in how you write the program. Not is what language you use.
I use several different languages, depending on the project.
On top of asking your self which you would be more comfortable with, you should ask your self if you want to support multiple platforms.
My company does a lot of cross-platform development, and as such, we don't use C# on those projects.
There is the mono project that aims to allow .net code to run on mac and Linux, but between the two, Delphi, being pascal is somewhat more portable.
( On our cross platform projects, we use either C or C++ )
Use the language you are most familiar with. That way you can hopefully avoid pitfalls and gotchas of using an unfamiliar language.