Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have the task of developing an application to pull data from remote REST services and generating Excel reports. This application will be used by a handful of users at the company (10-15). The data load can reach 10,000-200,000 records. I have been debating whether to use Python or C#...
The only reason I am considering Python is because I am familiar with it and it would be less of a risk.
Personally I want to try use C# since this would be a good opportunity to learn it. The application is not too complicated so the overhead of learning it won't be too much... I think.
Are there any issues with C# that I should be concerned about for this type of program? The users run Windows XP... would users not having .NET installed be a major concern?
Thanks in advance.
EDIT:
I guess I need to stress the fact that the end users should be able to run the application without installing additional libraries/frameworks.
Why not IronPython which merges the two worlds together?
If you want to learn C# and you don't have such a limited time constraint, now might be a good time to try it. Also, though I haven't done Excel work with either Python or C#, I would expect it to be easier to work with Excel files with a Microsoft product rather than Python. If you're just dumping data in CSV format to a file, though, either Python or C# will work fine.
If you want to try something even crazier, you can use IronPython such that you'll have .NET resources available but you can still write in Python.
I would normally say, use what you know.
However, here you may have some performance issues using an interpreted language. I, myself, would use C#. If you want to learn it, now is as good of a time as any.
However, if your own cost/benefit analysis reveals that you would be better off in python, use that.
.NET will be required for C# on windows, but you can use the .NET Client Profile to make the install pretty painless.
I realize this is an old post but I guess I have some pertinent information for anyone coming across this in more recent times, as I have.
The Python library, Openpyxl has worked well for me for manipulating and creating excel files in my desktop based automation scripts.
http://openpyxl.readthedocs.io/en/default/usage.html
It is accessing the file directly from my understanding, unlike the Interop technique in c#. So wherever it runs, you wouldn't need Excel installed. If you're trying to get something on a server it might be an issue getting a licensed copy of Excel or ensuring it exists if your user is running this locally.
Using C# you have the full features of visual studio to help code, such as the code completion, debugging tools and error highlighting. However you can get most of that with Python in Visual Studio, though I've found it more complicated trying to get the right version of python tied to the project and whatnot.
In C# you can easily compile an executable whereas I believe you'll need to mess with loading some Python libraries to get close to a similar local executable with dependencies comparable to the C# output.
If the users have to install a C# client then not having .NET installed would be an issue. You can package the installer so it downloads the .NET runtime, but depending on what features you use it could be quite a big download.
If your application is web based then all the C# code runs on the server and just delivers HTML to the browser so whether .NET is installed or not shouldn't matter.
Integration with Excel will almost certainly be simpler from C#. Given the requirements "Windows only" and "Integrates with Excel", it would seem a simple choice that C# is better suited to this individual problem.
And, no, users' not having .NET is not a concern compared with Python as the alternative. The Dot Net framework is a standard part of Microsoft Update. In contrast, Python will almost certainly not be there on the average end users' machine. In your case, with an internal app, that last point might not matter of course.
If you are doing any kind of HTTP work with C# make sure you take a look at the new HttpClient library that is in WCF REST Starter Preview2. Ignore the name of that download, the HttpClient part can be used independently of WCF.
It is a WAY better client than just using HttpWebRequest.
If you do a web based application not having installed .NET in the client machine wont be a problem .. but I suppose you dont want to try both C# and web development at the same time
It is easy with Python to pull data from a web server, parse the JSON or XML, and generate some kind of report. If you need really good Excel integration (for example, your output is supposed to be an Excel spreadsheet that includes numerous graphs) C# might be better, but Python is still possible; there is PyExcelerator for writing rich spreadsheet files, and there is Python support for COM if you want to use COM to talk to Excel.
With Python it is also very easy to make a stand-alone executable, for example with py2exe.
This sounds like a batch tool, one that won't have a GUI; I think I would write it in Python if I were you, unless I really wanted a fun project to help me learn C#. But anything with a GUI, C# is probably better. (I haven't done GUI development with Python, but I have seen comments here and elsewhere that the performance of Python GUIs tend to be slow.)
The answer probably has more to do with the circumstances than the question of which is the better language for the task at hand.
If you have no prior C# experience, it's probably not a good idea to jump into it now and learn it as you go along. Syntax differences are trivial to learn, mastery is defined by knowing the dirty details and how to use the language's strengths to get the job done.
If you have plenty of time and starting over a lot is NOT an issue, or you have experience with a language that is paradigmatically very similar to C# (say, Java or C++), you could probably afford to take the risk and adapt to the new language very quickly.
If you don't care about efficiency (e.g. it's a pet project, you don't care much about your job or efficiency simply isn't important), try C# just to learn something new (always a good thing) or stick to Python to make sure you won't have to adjust your thinking too much (always a source of vulnerabilities and misunderstandings).
If you definitely want to use C#, you should play around with it in your "free time" (not necessarily at home, but preferably at work when there's nothing else to do) and thus build a skillset you can use once you have to start with the actual project. This way you'll already be familiar with the paradigm (to use the term loosely) and encounter less problems where they count.
Related
Environment
Windows 8.1 64bit
Microsoft Visual Studio
C#
What I'm trying to do
To implement a mini language in C#
My job in my company is to make a software which automates evaluation of the performance of company products. The evaluation involves opening valves, flowing chemicals, fetching signals from sensors, calculating some values, etc...
The issue is when a user wants to change the procedure and parameters like how long the reaction time is, the order of opening valves, whether reaction conduit is flushed out or not, the programmer has to change the source code and build another software every time the user requires it.
So I'm trying to implement a mini language in C#. A user can organize a procedure of measurement with the easy-to-understand language. The user writes a code in a txt file, my software reads it, parse each line of code, extract commands and parameters, call corresponding method in the software.
For example, a user writes a line of code like open_valve(3), my software reads the code and call an internal method send_commands_to_ADconverter(VALVE, 3) which sends appropriate commands to a target valve via an A/D converter connected to the computer. This is my conception.
However, due to lack of my programming skill, I have no idea where to start. What technology is available? What are the keywords to achieve the goal? How can I achieve this objective? Any help would be appreciated. Thanks.
Edit 1
c# - Adding scripting functionality to .NET applications - Stack Overflow doesn't refer to accessing external devices like sensors, valves via A/D converter which is crucial for my purpose, so it is unclear this is a duplicate question of the link above.
In order to create a language you need a "parser" of some sort. You will need to define a "grammar". Parsing your "progam" via the grammar will result in a structure that you can then call methods in your code that implement each feature of your language.
You are on a big learning curve here :) lots of strange things like EBNF. You will probably see lots of references to things like Gold and ANTLR. These are hugely capable but involve things like "compiler compilers" and add a level of complexity that can be confusing and require extra steps in you build pipeline.
Here are a couple of libraries I've used that allow you to define you grammar in c#.
https://github.com/picoe/Eto.Parse
https://irony.codeplex.com/
Irony is very good (I've used it for various projects) but hasn't been maintained for a while.
Eto.Parse is more recent. It also has built in parsers that allow you to create a Grammer by parsing BNF. This is very cool
If I understand, your goal is to parse a syntax written by your user and take a decision with what he typed.
I suggest you to use regular expression to match and split the user input.
There are several scripting languages which can be run directly from C#.
As your users doesn't seem to have programming knowledge it might help to use a verbose language like VBScript.
To run VBScript you can use the Scripting Control. See this question for samples: Use Microsoft Scripting Control to evaluate 'If' expressions (via c#)
IIRC the script control must be run as a 32bit application.
Well, the easiest option would be to use what you already have - C#.
You can compile C# code on the fly, and it's very easy and cheap with the new compiler, Roslyn. Then all you need to do is define your interface so that it's easy to use for the users, and put that code in a method you can call from your code. This allows you to easily support all the various development tools for C# as well, including Visual Studio/VS Code. In the simplest form, all you need to do is make your "script" implement some base class that has all the methods you want the users to have - there's certainly better approaches, but this one is very simple, which sounds like something you're looking for.
Of course, this only makes sense if you can trust your users. Making safely sand-boxed code in C# is a lot more complicated (though certainly possible), and you'd probably be better off using some ready scripting solution.
I know this is very vaque question but still I am asking.
Is there any one I can convert my existing WinForm built in c#.net and DB as SQLSERVER 2008, to andorid application ?
If no, then is thr any easier way to built an app as I am not familiar with any Mobile Application tools.
Generally, no. The languages are somewhat similar, but the way the UI is built is vastly different and will have to be rewritten from scratch. Also, database access differs. I actually doubt that Android have libraries required to "talk" to SqlServer. Even if it managed to talk over some generic ODBC layer, still the DB-access will also differ very much. I assume this would consist of more than 80% of your application - so it can safely be estimated that whole application cannot be converted, and a new application has to be written. Of course, some SQL queries might be reused, some application classes might be usable too (if written in an enough platform-independent way, so they can be translated to Java)..
No there is no way to do that in easy way.
Android development is similiar in UI level to WPF (you can find some simliarities) + you have completely different behavior model as you're talking about mobile development.
In short, if you want to continue with C#, you may think of picking Mono Droid.
It's payed.
This is not easy as far as I know. If you want the conversion for free you should rewrite it in Java using the Android SDK (run on Dalvik - a custom VM). As stated above, you will have little effort learning it if you already know C#, you could also use Mono Droid or hire a developer if you have the possibility to do so.
Good afternoon,
I thought about writing an application which I may or may not commercialize, depending on how good the final application is. It is like a personal project, with which I hope to learn many more things about programming, for currently I only know most about C and C#. That's why I thought about starting this project as an unmanaged C++ Win32 application. The problem is that it is most dificult to even show a simple window when compared to C#...
How many people/companies use the Win32 API & C++ in today's business world? How does it perform in comparison with C#?
The application in question may eventually be an IDE for a specific language but whith features like command recognition and spell checking already built in.
Thank you very much.
It seems that when performance is needed people are willing to give up C# for C++.
Have a look at this "success" story Lessons from Evernote’s flight from .NET.
On our test hardware, Evernote 4
starts five times faster, and uses
half the memory of Evernote 3.5.
Evernote chose WTL and Chromium Embedded Framework. Basically they've reused Google's Chrome in their application.
For your first project and w/o prior C++ and Win32 experience, I would STRONGLY recommend you use the C# , as it will be easier for you to get something done thereby gaining confidence and skill as you go.
I'm a huge fan of C++ under windows, I've been doing it most of my adult life. That said, if you have no experience of C++, and you want to write a windows application, I'd suggest going with the C# route under .NET. Whilst I love native C++, I really disliked C++/CLI, and the horrid ^ suffix for references.
Given this is a personal project, I wouldn't worry too much about whether businesses use C++ or C#, but I will say that it is easier to find a C# developer these days than it is a C++ developer. And no, I am not favouring one language over the other here, it just appears to be the reality (at least in my experience). As for C++/CLI developers? They're kind of thin on the ground :)
You'll definitely be up and running faster with C# than you would with Visual C++/MFC/some-other-gui, but remember there are certain things you may not be able to do in C# (and have to import the native win32 calls via DllImport), but I doubt you'll come across these fringe cases just yet.
C# is the easy route, and the route most-often pushed by Microsoft. What they don't tell you, though, is that all of their headline products (parts of Visual Studio excepted) are written in C/C++. I'd say, in fact, that most major software packages you are familiar with are written in C/C++.
I'd go with c# too, as it is far more common in a business world (on GUI side at least), than unmanaged c++/win32. You'll also get your desired results faster, especially if you don't know c++.
On the other hand, c++ performs better (if written properly) - so if you are planning some intensive work in your app - maybe c# just won't handle it (but I strongly doubt this is the case).
At last, but not the least - if you are planning for clients, that for some reason do not have and can not get .NET framework (or any other framework, i.e. Java) - then native code is your only solution.
I have only been using C++ for quite a few years, but I have never had to write any programs which required a User Interface. When I did, I tried to learn to use Qt, but found it to be somewhat of a pain and eventually gave up. I recently just started taking a class on C# .NET and in the first week I have already started developing a pretty advanced application for my companies billing system.
If you were already a seasoned C++ veteran and preferred it over C# .NET, then I would say by all means go for it. In this case however, I would strongly recommend you go with C# .NET for quite a few reasons.
1) The time is takes to do something in C# will probably be at the very least about 10x faster than doing it in C++ regardless of the API you used.
2) The learning curve of C++ on top of already trying to write an application with a UI (which is already very difficult in C++) will make this take an extremely long time.
I've been playing with Java for years as a means of developing quick and easy tools for repetitive tasks. I am not a true "developer" in the traditional sense, but I have lots of experience creating a wide assortment of tools and PoCs.
Unfortunately for me, I have noticed many shops are specifically looking for experience with C#, and not so many for Java. Even here on SO, there are more questions and more followers to C# related issues than Java. My preference will always be Java over C# simply for the cross-platform compatibility, but since the languages are so similar, I believe it would be beneficial for me to cross-train. I have already dabbled in other languages and scripts (VB and other BASIC flavors, Javascript, VBScript, ASP, JSP, PHP, etc.) so adding another isn't out of the question.
My current Java environment simply consists of a text editor (primarily jEdit for its plugins and layout) and homemade scripts to compile/jar my projects. I don't like to use IDEs because I want full control over my code and don't want a program writing code for me. (I also prefer to write my own code as opposed to using any sort of external library/package, if feasible. It helps me learn and greatly reduces unnecessary code.)
Therefore, what are my options for a non-IDE C# SDK? Libraries are obviously not that important to me. I've heard of Mono, which appears to separate the functions, but haven't tried it yet. What other SDKs exist that are similar to a simple Java SDK combined with a text editor?
Using an IDE doesn't have to mean anything writing code for you. I'm not generally keen on designer-generated code, but unless you decide to use a designer (or snippets etc), Visual Studio won't be writing code for you. Of course it will create a skeleton class for you when you create one, add the appropriate method signatures when you implement an interface etc - but is that boilerplate really something you want to write yourself?
I'd also suggest that your policy of not using external libraries is a bad one. I agree that it's useful for educational purposes to sometimes reimplement something, but it means that the code quality is likely to end up being worse... why would you not want to use code that has already been used and improved by many other people? Yes, you need to be careful about what libraries you use - but you really don't want to do everything yourself... not if you want to be productive, anyway.
I often use a text editor and command line myself for simple test code (e.g. for Stack Overflow questions) but I wouldn't dream of doing that for "real" code that I plan to keep.
Honestly, a lot of C# and .NET is about learning the tools; Visual Studio gives you a lot that you wouldn't be able to do with a text editor. There's a free version, and I highly suggest you check it out! People hiring will want to know that you're familiar with the tools they'll most likely be using.
You can just start with Notepad and csc.exe, the the command-line C# compiler that ships with the .NET SDK.
However, IDE is not necessarily synonym for code generator. I would download Visual Studio Express and start with empty Console projects.
Have fun!
Don't forget you can build/assemble C# projects using MSBuild and a .sln file if you really want. But the IDEs will make life a lot easier.
The IDE will not write code for you, it will help you writing code. Using libraries will help you concentrate on what you really want to program, not the things that already have been done.
Check into AvalonEdit, the text editor component of SharpDevelop. It is an open source text editor that has classes that could implement features such as intellisense and syntax highlighting. You would only have to use as much of it as you wanted and you could embed it anywhere you would use a text box control.
If you are familiar with Ant from Java then you could also check out NAnt to do your compile phase.
As far as I know, with Visual Studio you also get a command line C# compiler, csc. You could use a text editor and manually compile your C# code with that on the command line if you really want - that wouldn't be very practical however when your project contains more than a handful of source files.
If your project becomes bigger, you could use a tool like NAnt, which is a .NET version of the popular Java build tool Ant.
I agree with Jon Skeet about that your way of working is not very practical. If you are really looking for a software development job, you'd better learn to use the tools that other developers use. An employer will also not accept the fact that you'd want to write all the code yourself instead of using libraries. By using libraries instead of writing it all yourself you save lots of time, you are reusing well-tested code and your code will be much easier to maintain by other developers.
I intend to write a small application to scratch a personal itch and probably make the life of some colleagues easier. Here is what I have:
10+ years of experience in C
Plenty of experience in programming against the Win16/32 API in C from the Win3.1 to 2000 days.
C library written by myself already doing about 75% of what the application shall do.
What the application shall do:
open a binary, feed it into the mentioned library.
take the resulting text output and feed it into a new Excel Workbook.
apply some formating.
integrate nicely with the Windows environment (availability in "Open With...", remember some stuff using the registry etc.)
(maybe later) before giving the CSV data to Excel, parse it by looking up the meaning of some values in an XML file.
Except for the XML parsing part I have done all of that stuff before including COM / Office Automation in C/Win32. There is a lot of boilerplate code involved, but it is doable and the result will be a pretty small application without the need for an installer.
So why even think about C# / .Net?
no experience with parsing XML
the promise of less boilerplate code for the Windows and Excel stuff (yes, I have done C++ with OWL, MFC, ATL etc. but I am not going there anymore - not for free/fun)
Since I have also experience with C++, VB(not .Net) and a little Java / Objective-C I suppose learning C# will all be about the .Net libraries and not actually about the language.
My considerations so far:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net.
My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
Please advice.
Update: one thing I forgot to mention explicitly is that I am also worried about easy deployment of the tool to my co-workers. With Win32 I am pretty sure I can come up with an EXE file < 1Mb that can be easily emailed and does not require installation. With .Net not so much. Can I create the necessary MSI or whatever in Visual Studio Express (free) or do I need 3rd party tools?
as others have your question mostly covered, I'd just like to quickly comment on your considerations:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Totally agreed. It is definitely fun and usually it does result in less code. The investment you make now will certainly benefit you in future projects. It is way faster to program in .Net than in C. Not only it is easier, but it is also safer. You are isolated from many programming errors common in C mostly related to memory mismanagement. You also get a very complete managed API to do stuff you would usually need to build your own framework.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
Hence your indecision. :-)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net. My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
.Net is an entirely different beast from VB. Most of the things you wouldn't be able to do in VB, or at least do them easily, are supported by .Net. For instance, Windows Services are a snap to build in .Net. Socket programming is also supported, but there are very few reasons to do it yourself, as you've got loads of communication APIs with .Net. You've got web-services, .Net Remoting, MSMQ management, and more recently WCF. Proper multithreading is supported by .Net, unlike the idiotic apartment model in VB. In case you really need to go low level, you can also actually use pointers in C#, inside of unsafe code blocks, even though I would never advise to do so.
If you really need to do things in C, then integrating is also relatively easy. You can create COM objects and use interop to work with them from .Net. You can also interact directly with plain ol' dlls using DllImport. Using www.pinvoke.net makes it easier.
When I developed in VB, sometimes I also had to go back to C++ to do stuff that I wasn't able of doing in VB. Since I began programming in .Net, the only extremely rare scenarios I would need to go back to C++ were when I needed to use legacy COM components that used types I was having a hard time to marshal via interop. I wouldn't worry about history repeating itself.
If you're using COM, you may be interested in using C# 4.0 instead of earlier versions - the downside being that it's only in beta. But basically it makes COM stuff somewhat less ugly for various reasons.
I'd expect there to be plenty of good C libraries for XML parsing by now. I would expect the main benefit to actually be the knowledge gained. I doubt that you'll actually produce the code faster for this project, but the next one may well be a lot quicker.
How much do you care about learning new stuff?
It sounds like an ideal project for learning C# & .NET.
You know most of what you need to do so you can use that to gain a base level of understanding of C# & .NET which you can then apply to the stuff you need to learn.
As Rune says though, a key driver could be the timescales. If this is something you need in a hurry then coding it in C & using win32 directly might be the answer.
Sorry I couldn't be more definite.
I think you should use C#. With your experience the learning curve won't be too steep. The code will ultimately be cleaner (and less of it) than you probably could with C/Win32.
There is probably going to be no problem using your existing C-library with the [DllImport] attribute.
It depends. :-) It depends on whether you want to do this quickly or if you want to learn something new. It depends on whether you will be the only maintainer of the code or if others will maintain it in the future. It depends on how complex your xml handling will be and on how complex the COM automation is.
You will probably get a working application quicker if you do it in C than in C#. Both since you have much of the stuff needed already in place and since you know C well.
But this project sounds like a good match for C# and .Net. .Net has great support for XML and COM interop is easy but clumsy in C# (much better in the next version!). So if you are interested in learning C# and .Net this would be a good project to do so.
I would definitely do this in .Net and probably C# (but I am biased). Using .Net would probably result in code that is easier to read and maintain and most probably easier to write. So if you are interested in learning C# I would suggest you go for it!
Edit:
You worry about the size of the executable if you write it in .Net. I doubt that will be a problem, for most if not all of the libraries you will use for a project like this will already be installed on your computer. 1 Mb is rather large for a .Net executable, event for a big project.
a short notice on the installation. .NET is as default xcopy-able so you wouldn't need an installer for the exe to be usable. Mail it around (or with the next release of the .NET framework optionaly leave it on a network share)
You could look at building a hybrid system that uses C++/CLI and C#. C++/CLI provides a nice bridge between the two and lets you easily split different parts of the system between the managed and unmanaged worlds.
Not sure if the setup projects are included in the free versions of visual studio. But you could use clickonce (included with the framework) or WIX (open source XML based msi creation tool).
learning C# will all be about the .Net libraries and not actually about the language
No there are many things you need to learn about the language (delegates , events , generics ...) and also it is object oriented and it manages the memory by itself and yes no pointers :)
anyway C# and .NET are great all you need is some effort to get up to speed