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
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 9 years ago.
Hello developers and designers,
I am very willing to learn WPF in which i use C# as the logic code.
Or i 'try' to anyway.
I have written a 2-page long code-behind in Forms-style though, so i know some syntaxes.
But that was a really cumbersome way of doing it.
The problem is that i am still lingering around the area of understanding at least the basic concept of object oriented programming. But 9 out of 10 times i am not getting the example-codes entirely because of that '1 little thing of which i don't even know what it's called'.
How do you even know if there is a command for the function you want to express and more importantly.... how it's called and where it located in what namespace?
Even the best video-examples aren't doing it for me, because when any code is typed, they never explain how the code exactly works. And most of the times it just doesn't even add up to what i know of logic code (of course i'm wrong).
In the early days i learned the Commodore64's Basic no problem.
Learning and writing Actionscript (Flash), within 2 months creating a 2D-shoot'em up
Learning and writing CMD, within 3 months writing 5000+ lines of code for all sorts of functions.
Why in Merlin's beard is WPF so hard?
Watching the "simplest" tutorial-video's are becoming more and more de-motivational.
Anyone recognizes this?
Thanks for reading,
Danny
Regarding WPF the articles I've found to be most useful are the overviews on MSDN, they might take quite some time to work through but they are concise and in-depth, see this page for a master-overview.
Why WPF is hard is a good question, one primary cause might be that it is simply huge, at least i perceive it that way. Aside from having all the code you also now have XAML markup which is a world of its own.
Someone from Microsoft who did a presentation on F# in 2008 said that if you know three of the keywords, let, fun & |>, you know the whole language, which is not even that much of an overstatement. WPF on the other hand is not a language, it is a sub-framework. If F# can be likened to 3 nanotechnology building blocks then WPF is a 50 meter workbench stacked with tools (the controls) and a dozen heavy duty machines (WPF mechanisms like dependency properties, data binding, commanding, data templating, etc.), and all of those come with a manual. So if you are facing a problem you pretty much need to know what all the tools and machines do so you know which to use, and then of course you also need to know how to use them, apart from their basic functionality each may even have its own kinks and peculiarities which are important to keep in mind.
So learning WPF requires a lot of raw knowledge of the framework but also experience so you know what is the best approach in a given situation and to get a feeling for what can be done and what cannot.
MVVM: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Learn it then use it.
I figured I'd add my $.02 since I've recently started using WPF. First off, you'll need to read that MVVM article mentioned by Fëanor, and DEAR GOD, download the sample code and learn what every line in that program does! Reading the article is great, but seeing the code, running it, changing it, etc, is INVALUABLE. I also echo the comments about the MSDN overviews, and the one about creating a side project rather than learning WPF via an existing project.
Other than that, don't expect to get WPF in a day, or even in a week. I've been using it for about a month now, and I've still got a ways to go. I had my "AHA!" moment about a week ago where everything started to click and it became apparent to me what I DIDN'T know which is important. A good strategy would be for you to pick a single concept such as Data Binding, or Data Templates, or Styles, and explore each in depth. It's a lot to chew on, so just remember that Rome wasn't built in a day. And if you're not already comfortable with data binding, I'd pick that up early on since it's pretty crucial.
Lastly, once you learn WPF, it's going to be REALLY hard to go back to using Windows Forms :)
Have Fun!
Q
I don't think that WPF is actually that hard. I think it's just that WPF definitely requires a slightly different way of thinking. You can tell that it was built with certain principles in mind (like MVVM, as another poster mentioned), and it's very different from most other frameworks. If you try to do it like you did Windows Forms or MFC or ASP.NET or whatever... you'll struggle. You need to be willing to change your mind on how things work.
Frankly, I think the only way to learn it is with experimentation. Come up with some side project to work on using WPF and try your hand at it. Learn a bit and refactor it. Get a good book, read the WPF disciples list, read anything that Sacha Barber writes, read the WPF section here on SO.
When you have your first "ah ha!" moment where you decide to write an Attached Property to solve some obscure problem you're having, you'll know you've finally understood it :)
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.
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.
In the corporate world, Is it better to be knowledgeable(by knowledgeable I mean not a expert or novice but with some coding experience) about multiple languages.
or
is it better to be an expert in one language(say c++ or java) but having just basic knowledge on others.
I ask this question because what I feel is languages can be differentiated based on the features they provide like Garbage collection etc..but this can be implemented in other languages...and why do people prefer one language over the other?
What is the general point of view on this board?
I'd say learn a couple of languages really well, but keep expanding your knowledge by studying other languages. Not for the languages themselves necessarily, but for the concepts and paradigms they implement and encourage. This'll make you a better programmer overall and better suited for finding the right tool for a larger set of problems.
I think it is more important to be able to learn new technologies, languages, paradigms, etc. etc. on the fly than to be an all out expert in just one of them. You can dedicate all your time, effort, blood, sweat, and tears to learning Java, but what are you going to do in the eventuality that it is no longer in wide spread use. This can happen to any language to be perfectly honest. Your base knowledge in the general principles of programming and programming practices and your WILLINGNESS to learn a new language are what will help you to advance in a corporate environment. If your boss comes to you and says "I need this done in C" and you reply either "I don't know C nor do I like it. How about Java or Python?" or "Sure, but C is not really suited for that task and will take additional effort. How about Java or Python?", that will be remembered next time layoffs or promotions come along.
be an expert in one language like C++ then if you want to be very good in PHP it would take you ~3-5 weeks instead of 3-5 years (C++), next - if you want to be very good in C# that will take you another 3-5 weeks, and after that you can learn everything else, like .NET/ASP/J#/VB/ very fast. i find it that only ASM is harder to learn, might take more time - 2-3 months, if you have the right books.
everything depends on passion / how much hours a day you read/write/test code...
but if you want to be an expert in any of these languages, experience is what you need, learning is not enough.
IMO - You must be Master of one, in order to have the capacity to learn multiple languages faster. so "Jack of all trades" but also Master of ONE.
Learn what you need
why learn ten languages if your only every going to use two? though you should still know what else is available, and what its good points are (and its bad points too), so if in the future you run into a problem you can't solve with what you know, you know where to look for something that can help.
If your looking for a job, it might help to know more languages, as it 'inflates' your CV, but being a jack of all trades probably won't get you hired.
Read this: http://www.paulgraham.com/avg.html It is not exactly what you wanted, but can give you another point of view.
One famous man said: "Person becomes real software development specialist only when he or she becomes an expert in more than one programming language".
So if you want to be a good programmer in Java or C learn Java or C deeply and completely.
If you want to become high qualified software developer not dependent on language and ready for changes in programming world - learn both of them and better not only them! :)
First expert in one one language. Then know more languages. (Pick a language per paradigm)
I believe it depends on your career aspirations. If you're looking long-term at being a consultant or maybe evening being an indepedent analyst, becoming and expert in your technology area is critical. You'll need to focus a lot of time mastering technology in your given area, and you don't have the spare time to become e generalist unless you choose not to sleep. I don't recommend that for the long-run.
Then again I cannot recall how many times I've seen an organization dump a perfectly good code base just to upgrade to the "next-thing" due to the career aspirations of project managers. So maybe it is out of our control?
In the end, I honestly feel that domain-critical knowledge is more important than technology skills. But that is maybe because I'm not only the front lines these days. I'm all for a general lemma that says you should know more than one programming language, but I seriously question those who claim to proficient in ten languages and ten frameworks and ten different operating systems.