Programming Questions | Repositories

[rkruger]

If you're not going to be using it on Windows at all, then yeah, I guess developing directly on Linux would be better. Linux Mint isn't designed for programming, so it might not have all the development tools you want installed at first, but it should work fine. For C# you'll need to use Mono, and MonoDevelop.

Let me introduce you to a new concept:
IDE != Programming
I think you are over-complicating things here.
The only things you really need are a text editor and a compiler/interpreter, that's it!

And as you said earlier:

It might just be because it's what I'm used to using, but I never found it as easy to get things going in Linux. Too many things to manually configure, too many things to go wrong.

This is probably because you are too focused on using an IDE for everything.

I would recommend Python; although it takes some more time to learn and adapt to it than other languages given it's sintax and some other pecualiarities, most C and C++ libraries have Python bindings , making a lot of things a lot easier than in other languages.

Again, I agree with going for Python.

And actually, many Linux distributions already comes pre-installed with a Python interpreter, since it's used for scripting tasks in the distribution itself.

[kitamesume]

all of the linux distributions? which language does python have a similarity to? seems interesting.

[asermax]

And actually, many Linux distributions already comes pre-installed with a Python interpreter, since it's used for scripting tasks in the distribution itself.

True that.
Nevertless, I recommend Debian since it's pretty easy to install/update things thanks to it's package managment system. I fell in love since I learned what a .deb file was.

which language does python have a similarity to? seems interesting.

I wouldn't know how to answer that since I only use a few languages, but I can tell you some particularities of the laguage:
- It uses and indentation based sintax to demarcate scopes, instead of curly braces ('{}') or end of block statements (e.g.: End If).
- It uses objects, but it's not purely object oriented. It allows "free functions" (functions not attached to any object) and they are objects themselves, so you can pass a function as an argument as if they were plain integers. This makes calling a callback procedure really easy.
- Python, as it has been noted before, is an interpreted language. There are multiple interpreters out there that compliant with the Python specification, and each one can access libraries of the implementing language very easily. Example: CPython (written in C) can acces C and C++ libraries directly, Jython (based on Java) can access java classes as if they were Python classes).
- List and Tuples are native datatypes.

Those are the most relevant IMO. You can find out more on the Python Documentation page ,the tutorial is a good start point to get an overview of the basics.
Btw, the version 3 of python is currently on development, and some libraries haven't been ported to it yet, so I would recommend you use the version 2.7, which is currently the most widespread version.

P.S.: You should check if there's an easy way to do what you intend with the USB port from python. I assume there's some kinda of C bindings or Python library to do that, but I couldn't tell for sure.

Edit: maybe this could work PyUSB

[Bob2004]

If you're not going to be using it on Windows at all, then yeah, I guess developing directly on Linux would be better. Linux Mint isn't designed for programming, so it might not have all the development tools you want installed at first, but it should work fine. For C# you'll need to use Mono, and MonoDevelop.

Let me introduce you to a new concept:
IDE != Programming
I think you are over-complicating things here.
The only things you really need are a text editor and a compiler/interpreter, that's it!

And as you said earlier:

It might just be because it's what I'm used to using, but I never found it as easy to get things going in Linux. Too many things to manually configure, too many things to go wrong.

This is probably because you are too focused on using an IDE for everything.

What I meant by "If you're not going to be using it on Windows at all, then yeah, I guess developing directly on Linux would be better." was that, if the application will not need to be used on Windows, just Linux, then he may as well program it in Linux to begin with, to save having to then port it over later. Obviously not really an issue with Java, since that works basically the same in every environment, but pretty much any other language it is a concern. It's easier to build it for your target platform in the first place than it is to code it for something else, then find half of it doesn't work when compiled for Linux and you have to spend ages changing it all.

The rest of that paragraph was a seperate point. Linux Mint isn't designed for programming, so it has fewer development tools. That has nothing to do with IDEs at all - the last time I used Mint, for example, it didn't have any version of the JDK installed, which means you couldn't do any Java development even in just a text editor. And it doesn't come with any of the Mono development tools either, which are needed to compile C# - regardless of any IDEs, if you don't even have a compiler, you can't do much. None of that is particularly hard to install of course, you just use Synaptic and it only takes a few minutes. I was just mentioning it.

On the IDE point, while a good IDE is definitely not a requirement to be able to program, it's certainly really, really helpful. Easy code management, snippets, templates etc come in handy, as do tools for easily integrating libraries into a project. But mostly, inline debugging! It is so, so, so much easier to debug code when you can step through it line by line, inspect variables at every stage of the process, and easily track down the exact location of any problems. Having to type stuff in a text editor, then manually call the compiler, with the only debug output being the name of the exception, the line number, and a call stack (and any debug output you manually add to your program).

When I was programming in Linux, I was using Java, before I switched to Windows (and Netbeans). I was basically just using gedit and javac to develop with, and it worked. Then I installed something totally unrelated (I can't remember exactly what), and it somehow broke my JDK install, which meant I couldn't get anything to compile. Even uninstalling Java, the JDK, and everything related then reinstalling them all again didn't fix it, I spent hours trying to work it out. Hours that would have been better spent getting some actual work done.

[rkruger]

What I meant by "If you're not going to be using it on Windows at all, then yeah, I guess developing directly on Linux would be better." was that, if the application will not need to be used on Windows, just Linux, then he may as well program it in Linux to begin with, to save having to then port it over later. Obviously not really an issue with Java, since that works basically the same in every environment, but pretty much any other language it is a concern. It's easier to build it for your target platform in the first place than it is to code it for something else, then find half of it doesn't work when compiled for Linux and you have to spend ages changing it all.

Well, in the case of Python, you don't need to compile it at all, since it's normaly interpreted directly.
As long as you don't utilize OS specific functions, you can just copy the same Python file to every platform and just run it.

The rest of that paragraph was a seperate point. Linux Mint isn't designed for programming, so it has fewer development tools. That has nothing to do with IDEs at all - the last time I used Mint, for example, it didn't have any version of the JDK installed, which means you couldn't do any Java development even in just a text editor. And it doesn't come with any of the Mono development tools either, which are needed to compile C# - regardless of any IDEs, if you don't even have a compiler, you can't do much. None of that is particularly hard to install of course, you just use Synaptic and it only takes a few minutes. I was just mentioning it.

I agree that Mint is probabaly not "designed for programming", but as other major Linux distributions I believe it includes out of the box support for C, C++, Perl, Tcl and Python.
Both of those languages you mention (C# & Java) are not good examples in this case, since they both rely on their own runtime environments (what you call "development tools"?), and not the native system libraries.

On the IDE point, while a good IDE is definitely not a requirement to be able to program, it's certainly really, really helpful. Easy code management, snippets, templates etc come in handy, as do tools for easily integrating libraries into a project. But mostly, inline debugging! It is so, so, so much easier to debug code when you can step through it line by line, inspect variables at every stage of the process, and easily track down the exact location of any problems.

Yes, and you can also integrate easily with revision control, bug tracking, and all that jazz. But does kitamesume really need all this? Maybe he does, but I'm just saying there is a simpler way.

Having to type stuff in a text editor, then manually call the compiler, with the only debug output being the name of the exception, the line number, and a call stack (and any debug output you manually add to your program).

Strangely enough, I find this to be enough information to track down most bugs.
And as for that manual debug output, it can be crucial if you are gonna run that program in a customer's production environment. Hint: They don't run your program in an IDE debugging session there when it crashes.

When I was programming in Linux, I was using Java, before I switched to Windows (and Netbeans). I was basically just using gedit and javac to develop with, and it worked. Then I installed something totally unrelated (I can't remember exactly what), and it somehow broke my JDK install, which meant I couldn't get anything to compile. Even uninstalling Java, the JDK, and everything related then reinstalling them all again didn't fix it, I spent hours trying to work it out. Hours that would have been better spent getting some actual work done.

Look on the bright side, you probably learned a few things about Java (good & bad) while looking into that problem.

[Freedom Kira]

Well, in the case of Python, you don't need to compile it at all, since it's normaly interpreted directly.
As long as you don't utilize OS specific functions, you can just copy the same Python file to every platform and just run it.

QFT. Python and Java are the main languages that Google uses as code samples in its coding competitions - the widespread support for both languages would clearly be the reason why. Of course, competitors can use whatever the heck they want. I think they even had LOLcode support.

I agree that Mint is probabaly not "designed for programming", but as other major Linux distributions I believe it includes out of the box support for C, C++, Perl, Tcl and Python.
Both of those languages you mention (C# & Java) are not good examples in this case, since they both rely on their own runtime environments (what you call "development tools"?), and not the native system libraries.

I'm running Ubuntu 11.10. While all Linux distros come with native support for C (practically by definition), I had to install interpreters for Perl and Python. I believe that Ubuntu used to come with Perl support, since I ran into a system bug with the Samba GUI, where the fix was to install a Perl interpreter. I never had this issue before, even on version 10.04, the previous version I was on and still am on another box. I am unsure about C++ and Tcl. If I could remember the command for the C++ compiler, I'd tell you. Was it gpp? If so, then my system doesn't have that installed.

I believe it did come with a JRE installed, but I'm not 100% certain. Whatever the case, it got installed anyway when I installed Eclipse.

Strangely enough, I find this to be enough information to track down most bugs.

I've always coded C in Mousepad (sometimes GEdit too). Segmentation faults were and are my biggest enemy. I also had some crashes before while attempting to run some memory-heavy simulation code, and the crashes often leave me with no messages to work with.

On the other hand, make was my best friend.

[rkruger]

I'm running Ubuntu 11.10. While all Linux distros come with native support for C (practically by definition), I had to install interpreters for Perl and Python. I believe that Ubuntu used to come with Perl support, since I ran into a system bug with the Samba GUI, where the fix was to install a Perl interpreter. I never had this issue before, even on version 10.04, the previous version I was on and still am on another box. I am unsure about C++ and Tcl.

Ok, I don't really keep track of what all the latest distros include by default now, I just remember that those 5 were fairly common before.
I guess Ubuntu just uses regular shell scripting (bash) for internal tasks then? Since it doesn't come with either Python or Perl...
But yeah, it's not really a problem, just install what you need with the distro's package managing system...

If I could remember the command for the C++ compiler, I'd tell you. Was it gpp? If so, then my system doesn't have that installed.

g++
It's part of the Gnu Compiler Collection, which as you said, is present in almost all Linux distributions.
(And by the way, GCC supports other languages as well, like Fortran, Ada and Objective-C to name some, but I'm not sure if you'll find that on all distributions though.

I've always coded C in Mousepad (sometimes GEdit too). Segmentation faults were and are my biggest enemy. I also had some crashes before while attempting to run some memory-heavy simulation code, and the crashes often leave me with no messages to work with.

Yeah, that can be a pain with C (and C++), but can be solved by using GDB. (Also part of GCC.)
(It's quite easy really, just run the program with GDB and when it crashes, you can print the stack trace. You may have to compile with debugging symbols first, I don't remember.)


But back to the topic...

P.S.: You should check if there's an easy way to do what you intend with the USB port from python. I assume there's some kinda of C bindings or Python library to do that, but I couldn't tell for sure.
Edit: maybe this could work PyUSB

pySerial (http://pyserial.sourceforge.net/) is also worth mentioning, if you are gonna work directly on communication layer.

[Bob2004]

What I meant by "If you're not going to be using it on Windows at all, then yeah, I guess developing directly on Linux would be better." was that, if the application will not need to be used on Windows, just Linux, then he may as well program it in Linux to begin with, to save having to then port it over later. Obviously not really an issue with Java, since that works basically the same in every environment, but pretty much any other language it is a concern. It's easier to build it for your target platform in the first place than it is to code it for something else, then find half of it doesn't work when compiled for Linux and you have to spend ages changing it all.

Well, in the case of Python, you don't need to compile it at all, since it's normaly interpreted directly.
As long as you don't utilize OS specific functions, you can just copy the same Python file to every platform and just run it.

True. Though I imagine dealing with USB and COM ports would be OS-specific, I really have no idea how Python does it.

The rest of that paragraph was a seperate point. Linux Mint isn't designed for programming, so it has fewer development tools. That has nothing to do with IDEs at all - the last time I used Mint, for example, it didn't have any version of the JDK installed, which means you couldn't do any Java development even in just a text editor. And it doesn't come with any of the Mono development tools either, which are needed to compile C# - regardless of any IDEs, if you don't even have a compiler, you can't do much. None of that is particularly hard to install of course, you just use Synaptic and it only takes a few minutes. I was just mentioning it.

I agree that Mint is probabaly not "designed for programming", but as other major Linux distributions I believe it includes out of the box support for C, C++, Perl, Tcl and Python.
Both of those languages you mention (C# & Java) are not good examples in this case, since they both rely on their own runtime environments (what you call "development tools"?), and not the native system libraries.

By development tools I basically meant compilers (since last time I checked the Java and Mono runtimes were included as standard in most distros). Since he's unlikely to use C, C++, Perl, or Tcl, none of those are particularly relevant.

On the IDE point, while a good IDE is definitely not a requirement to be able to program, it's certainly really, really helpful. Easy code management, snippets, templates etc come in handy, as do tools for easily integrating libraries into a project. But mostly, inline debugging! It is so, so, so much easier to debug code when you can step through it line by line, inspect variables at every stage of the process, and easily track down the exact location of any problems.

Yes, and you can also integrate easily with revision control, bug tracking, and all that jazz. But does kitamesume really need all this? Maybe he does, but I'm just saying there is a simpler way.

No, it's more the ease of keeping different classes etc all organised neatly (since in Java, for example, each one needs to be a seperate file). And step-by-step debugging is still very useful - and what he's used to, coming from VB6.

Having to type stuff in a text editor, then manually call the compiler, with the only debug output being the name of the exception, the line number, and a call stack (and any debug output you manually add to your program).

Strangely enough, I find this to be enough information to track down most bugs.
And as for that manual debug output, it can be crucial if you are gonna run that program in a customer's production environment. Hint: They don't run your program in an IDE debugging session there when it crashes.

Sure, you can usually track down most bugs eventually. But it can be a real pain in the arse; it makes life a lot easier when you can immediately see where it went wrong, and inspect variables at will at any point in time without having to quit, edit in a line of code to output their value, then recompile it all, start the program again, and get back to the point where the bug occurs. It's not necessarily more difficult to find bugs without that ability, but it is definitely more of a pain.

And by manual debug output I meant printing the value of a variable to the console every time a loop runs so you can try and see where it's going wrong, etc. Stuff you can't leave in a release version of an application anyway.

When I was programming in Linux, I was using Java, before I switched to Windows (and Netbeans). I was basically just using gedit and javac to develop with, and it worked. Then I installed something totally unrelated (I can't remember exactly what), and it somehow broke my JDK install, which meant I couldn't get anything to compile. Even uninstalling Java, the JDK, and everything related then reinstalling them all again didn't fix it, I spent hours trying to work it out. Hours that would have been better spent getting some actual work done.

Look on the bright side, you probably learned a few things about Java (good & bad) while looking into that problem.

I learnt that the Synaptic package manager is brilliant when it works, but a real pain in the arse when something messes with it and it all goes wrong. I didn't actually spend much time dealing with Java itself at all, because I was too busy trying to get the JDK to install properly. I learnt more about Java after I switched to Netbeans and was able to get more actual programming done.

[rkruger]

True. Though I imagine dealing with USB and COM ports would be OS-specific, I really have no idea how Python does it.

If you check the link I provided above for serial handling, you'll see that all the OS specific stuff is handled in the library itself, so you don't need to care about that in your own program. (And that's typically the case with most Python modules that give you a high-level interface to something.)

No, it's more the ease of keeping different classes etc all organised neatly (since in Java, for example, each one needs to be a seperate file).

It's just as easy to keep your files organized on the filesystem level with directories, you don't really need an IDE to do that for you?
Well, I haven't used Java, maybe it's very picky on where files should be located, hence the need for an IDE abstraction?

And step-by-step debugging is still very useful - and what he's used to, coming from VB6.

You can also do step-by-step debugging with Python when running it in debug mode with PDB.
And if you really need to use a graphical IDE for Python (which includes frontends for that stuff), then you can use IDLE.

Sure, you can usually track down most bugs eventually. But it can be a real pain in the arse; it makes life a lot easier when you can immediately see where it went wrong, and inspect variables at will at any point in time without having to quit, edit in a line of code to output their value, then recompile it all, start the program again, and get back to the point where the bug occurs. It's not necessarily more difficult to find bugs without that ability, but it is definitely more of a pain.

My point was that you cannot always rely on the comforts of an IDE, like the case where the program runs at the customer. (And this seems to be the case for kitamesume, based on what he wrote earlier.)

And by manual debug output I meant printing the value of a variable to the console every time a loop runs so you can try and see where it's going wrong, etc. Stuff you can't leave in a release version of an application anyway.

I was not sure what you meant, but my point here is that a good logging system in your program is really helpful when running it elsewhere.

[Bob2004]

I don't really have any experience at all with Python, so I can't make any comments on that language. I'm basically talking about Java and C#, since those are the two I know; Python might be totally different, for all I know.

Java has to have classes in seperate .java files, and they have to be organised in folders in the same heirarchy as they have in the program. So the class com.bakabt.program. main.something has to be stored in the folder /com/bakabt/program/main/. com.bakabt.program. main.secondary.some thing would have to be in /com/bakabt/program/main/secondary/.

That's not a massive problem, but it's just so much nicer to have a nice tree showing all your classes, organised by package, with libraries and other data files kept seperate and out of the way. It just makes things easier than having to switch between different text editor windows all the time.

Sure, you can usually track down most bugs eventually. But it can be a real pain in the arse; it makes life a lot easier when you can immediately see where it went wrong, and inspect variables at will at any point in time without having to quit, edit in a line of code to output their value, then recompile it all, start the program again, and get back to the point where the bug occurs. It's not necessarily more difficult to find bugs without that ability, but it is definitely more of a pain.

My point was that you cannot always rely on the comforts of an IDE, like the case where the program runs at the customer. (And this seems to be the case for kitamesume, based on what he wrote earlier.)

You can rely on an IDE to develop it with though. I'm not really sure what you mean, since there's absolutely nothing to stop you installing an IDE to develop your program with. Sure, the customer won't be running it in an IDE, but the general idea is usually that you've already written the program by the time they get hold of it. They're not doing any development, so why would they need development tools anyway?

A good logging system is very helpful, sure, when it only logs useful stuff. But when you don't have any way to inspect the contents of a variable other than to add in a line of code printing it to the console, you end up with a lot of useless output, which you have to waste time adding in (then removing again) when trying to debug the program, and which serves no useful purpose once the particular bug you were working on has been fixed. It's an annoying waste of time, compared to just hovering the mouse over the variable and immediately seeing its value.

[Freedom Kira]

I guess Ubuntu just uses regular shell scripting (bash) for internal tasks then? Since it doesn't come with either Python or Perl...

Ubuntu supports bash scripting out of the box, yeah. That's the default terminal, after all.

g++
It's part of the Gnu Compiler Collection, which as you said, is present in almost all Linux distributions.
(And by the way, GCC supports other languages as well, like Fortran, Ada and Objective-C to name some, but I'm not sure if you'll find that on all distributions though.

Nope, no g++. Guess that's not supported natively either. I find that C++ isn't actually all that common, anyway.

Yeah, that can be a pain with C (and C++), but can be solved by using GDB. (Also part of GCC.)
(It's quite easy really, just run the program with GDB and when it crashes, you can print the stack trace. You may have to compile with debugging symbols first, I don't remember.)

The name sounds vaguely familiar... I'll have to keep that in mind. I remember people were using DDD or something along those lines for segfault debugging.

[rkruger]

You can rely on an IDE to develop it with though. I'm not really sure what you mean, since there's absolutely nothing to stop you installing an IDE to develop your program with. Sure, the customer won't be running it in an IDE, but the general idea is usually that you've already written the program by the time they get hold of it.

Unfortunately, bugs do not only appear during the development phase of a program.

They're not doing any development, so why would they need development tools anyway?

Did I say that they (the customer) need development tools? I cannot recall that I did. Maybe we are are talking about two different things here? There's the development host, and then there's the target platform.

While you are free to use an IDE on your development host, you cannot expect that on the target platform, hence the need for logging.

A good logging system is very helpful, sure, when it only logs useful stuff. But when you don't have any way to inspect the contents of a variable other than to add in a line of code printing it to the console, you end up with a lot of useless output, which you have to waste time adding in (then removing again) when trying to debug the program, and which serves no useful purpose once the particular bug you were working on has been fixed. It's an annoying waste of time, compared to just hovering the mouse over the variable and immediately seeing its value.

Of course it doesn't make sense to log "temporary" stuff, but leaving debug printouts (call them trace points if you like) in the program can be a great help later.

It would seem that we come from very different backgrounds here. Judging from your experience with C# and Java, your focus seem to be on desktop applications? As for myself, I work on embedded systems running Linux and other real-time OSes, so maybe you can understand my bias.

The name sounds vaguely familiar... I'll have to keep that in mind. I remember people were using DDD or something along those lines for segfault debugging.

DDD is actually a frontend for GDB, among other things.

[Bob2004]

I think we're miscommunicating a bit here. Good logging is obviously essential; even during development when you have a good debugger, you still need good logging to help identify issues. But in order to try and figure out why a particular bit of code isn't working properly during development - while you're still writing the program - if you don't have any kind of debugger, you need to add more lines of code to inspect variables etc to try and find the issue. This is an unneccesary waste of time (especially since not only do you need to remove them all again later, you have to stop execution, add a line of code, recompile, then run the program again all the way to the point where the bug occurs, every time you want to inspect a particular variable at a particular point in time). That's all I was talking about - nothing to do with proper logging or post-development testing.

And yeah, I've only ever worked on desktop applications. Dabbled very briefly in Android development once, but never really got round to actually making anything.