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/).
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.
Days ago I created a program in Python to download stuff from the Internet, doing HTTP POST and GET and parsing JSON objects. I noticed some slow performance and I was thinking about writing it from scratch using another language, so I started to write it in C++ to make it faster. Finally I give up, C++ wasn't made for the Internet and it's very difficult to get something working.
I was thinking about giving C# or Java a try, which would you recommend? (I need my program to be fully cross-platform, other programming languages are valid too)
Edit: You can check the source code here: http://code.google.com/p/grooveapi/
Rewriting an IO bound application in a different language is unlikely to make any difference in its execution speed.
If you need it to be cross-platform: (i.e. you just write it once and it can run anywhere) Then Java or Python are your only options. This is because any C variant will need compiling specifically for the platform you intend to use it on.
My suggestion: Out of the two I would suggest Python. I have be educated in Java at University, and have learnt Python myself. Python is the language I turn to for web programming projects (in the form of Django on a larger scale) and the language used at companies I have worked for inside of their web applications.
Before you switch to another language... are you sure the performance problems are due to the language itself? It can very well be possible the problem is in the program, or the network latency or any other reason.
Don't blame the language before you've profiled your application carefully, maybe you have a bottleneck somewhere. The cost of a new development will be always very high, specially compared to a few line changes if you've found a problem in your code.
how did you notice "slow performance" when using python? I mean, python is slow, ok, but for your use case it shouldn't matter. Did you profile the code? Can you paste the code here so we can take a look and maybe improve it?
I don't know what kind of performance issues you had with your program in python but it usually does great for me ( scripts parsing log files that are huge take really little time for instance...).
now It all depends on the general purpose of this. If its just a script, no gui etc.. then you should definitely look into optimizing python, or doing some perl or php-cli script.
I'm not familiar with it first hand but ruby seems to have a big following and seems very "internet" oriented aswel.
If you do want to create something more than a script you have lots of options, c# is one of them, but it won't be cross platform, i'd go with java.
In the end I'd recommend rechecking your python code, it seems odd that its not doing what you want performance wise.... python is really good.
You should choose the language you feel most comfortable with. In most cases the performance of the scripting language is not the bottleneck. It is more important to get things done quickly and keep it maintainable. I would recommend you to choose Ruby or Python. If you have to get Python faster you still can choose to use JIT implementation like PyPy. Actually quite high traffic webapps, like YouTube, use Python.
I'd go with the good, old PHP! It has proven time and time again, that it is more than capable of doing this, and is quite easy to learn.
So my advice: Go with PHP!
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 13 years ago.
C# is owned by Microsoft and Java is owned by Sun/Oracle. What dangers does that really expose to the users of these languages? Has anyone felt their code was "owned"? Do projects like Mono help keep the "owners" honest?
Please do not make this a holy war of languages. I just want to know if it's rational to avoid such languages or if that's just paranoia. An interview with the inventor of C++ got me thinking, but I also want to balance his thoughts with the thoughts of the community as a whole.
As compared to what? Since you put it in these terms, the original C and C++ languages are "owned" by Bell Labs.
Java is not "Owned", it is open source. If you find a bug in it that you absolutely cannot deal with, you CAN fix it. (There are both open source and closed source implementations, however)
I don't know if you can get the source code to C#, but since Mono copied it there IS an open source for that as well.
I don't know if there is a second source for the .net libraries.
As for the actual "Dangers" (Which was your real question, after all), it would be that the company decides not to release updates any longer--if they do, will the language wither and die or will it take off on it's own? Java is in the process of transition from one of these states to another. Sorry, don't know about C#.
There is also the (Perceived) danger I mentioned earlier about--can you fix it if you hundred-million dollar company absolutely needs it fixed in order to continue.
This was a more significant problem twenty years ago, these days the fact is that if it's a good stable language, this isn't something you ever need to worry about.
No such danger for C# language. It is an ISO standard. Formally it is owned by a committee. But Java is a trademark
Getting up in the morning is risky, but that doesn't keep the world under the covers.
I feel like this is one of those acceptable risks. In Java's case, companies have used it for the last 15 years or so to their benefit.
What's the alternative? Developing and maintaining your own language so you own it? That's what SAP did. It seems to have worked out for them, but it'd be interesting to calculate the cost they've incurred.
Bjarne Stroustrup is a brilliant man, but let's not forget that he has biases. He isn't happy that Java eclipsed C++ as the primary object-oriented language when it came out. He's attributed it to Sun's marketing, not conceding that it might have improved on C++.
It's a good practice to try and spot biases on the part of any speaker to make sure you're not swallowing someone's view whole. This is one of those cases.
If there are not two independent implementations, language is "Owned" and you are at the mercy of the vendor should he raise prices or can the product.
I don't like that.
EDIT: As often as not, you can count legally forkable codebases as two (the second is yourself).
Aren't all languages owned by a person/company/standards body. The only way I can think of where it isn't really owned by anybody is if the person who made it is anonymous and also public domain
hmm, well Xbox only supports C# for indie games, and no other platform supports it.
obviously the danger is that if you want to do multi platform code, you want the language supported by the most platforms, the more "owned" language is probably going to be supported by less platforms.
the only issue I have is support for the language, and how hard it is to convert from one to the other, for instance I would say c++ to c# is easier than the other way because of memory management.
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.
This might be a weird question. After all, most people want to jump OUT of PB not IN.
However, after careful analysis, I feel that Powerbuilder can get things done so much more rapidly than C# in the sense its a 4GL.
Now PB is becoming .NET enabled, I was thinking perhaps its a good tool.
My main focus is developing enterprise applications with alot of data entry/reporting/data representation.
I have tried the datagridview and its pretty bad compared to the datawindow. I initially wanted to buy and try the telerik solutions but due to lack of time, i just assume the implementation in C# is just as unwieldy.
Do you feel its a good idea to jump into Powerbuilder now since its the only 4GL committed to moving to .net?
Thanks so much all. Do not hesitate to critique my choice based on my crieria:
c# is very low level and theres alot of coding to be done concerning data bound controls and so on
powerbuilder is a 4gl and has excellent abstractions to avoid unneccessary coding. Sure, you give up a bit of control but how much control is required for an enterprise application? C# is an extremely powerful language and yes you can make literally anything in C#. But Powerbuilder is more limited, and more can be done in PB when making stuff in its scope: i.e. enterprise apps
powerbuilder is moving to .NET and it can be extended by using C# for more sophisticated stuff.
yes, i am aware theres a DataWindow.NET control which is excellent but however does not give assurances of longevity since Sybase may not continue supporting it after traction for PB.NET is seen. After all it will cannibalize sales for PB.NET
You are correct that PB can be very productive. And ultimately, the strategy of "using what works" is fine. That said, there are some things to be careful about.
It sounds like you are developing a brand new app. If so, that's good, you have a chance to build it as a .Net PB app from day 1. PB 12 is to C# what PB classic is to C++, so your reason (wanting a higher level entry point to .Net) to use PB is in line with what I think Sybase was intending.
Do it as part of an overall solution including the .Net integration you speak of, and definitely take advantage of the educational opportunity to learn C#. As a developer, .Net is better for future opportunities than PB.
Will you need to readily hire additional resources to help develop/support the application? It may be harder to find PB resources than .Net resources, given the language popularity trends. Note that I make no claims on the quality of the developers: PB or .Net, you'll find journeymen, hacks and stalwarts in both ranks.
I wouldn't worry too much about Datawindow .Net if you decide to use it. I don't expect it will go away but someone more familiar with it may be able to provide more context here.
Finally, although there is some value in having a higher level entry point to C#, you will have to learn something about both PB and C#. Managing two tools introduces more overhead than managing one tool. For typical CRUD apps where you are building a lot of data entry and reporting, the productivity gains and strong relationship between SQL and the datawindow may be worth it - that's up to you to decide.
If possible, I would suggest you wait some time to see how PB12 is really doing. What worries me is this:
Existing PB application can, theoretically, be compiled into native code. This works horribly. Or, to be precise, it doesn't work at all. How well is PB going to export to .NET is yet to be determined. They seem to be committed to that, but I wouldn't trust them without seeing some real-world proof that works.
Based on PB11.5 and below, Sybase has been doing a bad job with PB IMHO. They rush into new technologies, but the foundations are shaky. PB12 is a big change, and based on their quality of development, I would wait at least a few builds before using it.
PB can indeed be productive, but being a PB programmer, I just can't imagine someone actually getting into it now. You'll have a very small community, not much open source, and an unclear future. And, based on recent experience, Sybase's support is also quite lousy.
Finally, if you do go through with this, the best advice I can give you is this: design your project having in mind you might have to port it to another language one day. Can't say exactly how since I'm not a .NET programmer and I haven't used PB12 yet, but have that in mind. I wish our app, which goes back up to PB3 or even PB2, was portable.
thanks so much everyone.
I have decided to stick with C# due to a fear (perhaps irrational) that Sybase will be slow to catch up with future .NET upgrades
Because I am still young and working on greenfield applications, i prefer to choose a language that has longevity and support.
Nevertheless, I feel its a shame that Powerbuilder isnt as popular compared to other language, for I can see awesome producivity improvements and the datawindow control is one of the more impressive databound controls i have seen in a long while.
Thanks again, eran and Bernard!
I don't think you have to fear that PB will go away anytime soon, it has been around a long time ever evolving and it will continue to stick around. There is a very active user community and many larger corporations still use it.
I think also it is good to learn as many tools/languages as possible at least from perspective of coming in contact with different programming paradigms. PB is great for certain projects, C# for others - they don't necessarily cancel out each other.
You can take a look at the latest PB.NET (Beta2) here