Discussion Forums > Technology

Programming Questions | Repositories

<< < (6/7) > >>

Freedom Kira:

--- Quote from: rkruger on March 20, 2012, 11:18:15 PM ---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.

--- End quote ---

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.


--- Quote from: rkruger on March 20, 2012, 11:18:15 PM ---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.

--- End quote ---

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.


--- Quote from: rkruger on March 20, 2012, 11:18:15 PM ---Strangely enough, I find this to be enough information to track down most bugs.

--- End quote ---

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:

--- Quote from: Freedom Kira on March 21, 2012, 03:32:10 PM ---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.

--- End quote ---
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...


--- Quote from: Freedom Kira on March 21, 2012, 03:32:10 PM ---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.

--- End quote ---
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.


--- Quote from: Freedom Kira on March 21, 2012, 03:32:10 PM ---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.

--- End quote ---
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...

--- Quote from: asermax on March 20, 2012, 07:33:20 PM ---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

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

Bob2004:

--- Quote from: rkruger on March 20, 2012, 11:18:15 PM ---
--- Quote from: Bob2004 on March 20, 2012, 08:39:08 PM ---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.

--- End quote ---
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.
--- End quote ---

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


--- Quote ---
--- Quote from: Bob2004 on March 20, 2012, 08:39:08 PM ---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.

--- End quote ---
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.
--- End quote ---

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.


--- Quote ---
--- Quote from: Bob2004 on March 20, 2012, 08:39:08 PM ---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.

--- End quote ---
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.
--- End quote ---

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.


--- Quote ---
--- Quote from: Bob2004 on March 20, 2012, 08:39:08 PM ---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).

--- End quote ---
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.
--- End quote ---

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.


--- Quote ---
--- Quote from: Bob2004 on March 20, 2012, 08:39:08 PM ---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.

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

--- End quote ---

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:

--- Quote from: Bob2004 on March 21, 2012, 04:52:08 PM ---True. Though I imagine dealing with USB and COM ports would be OS-specific, I really have no idea how Python does it.

--- End quote ---
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.)


--- Quote from: Bob2004 on March 21, 2012, 04:52:08 PM ---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).

--- End quote ---
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?


--- Quote from: Bob2004 on March 21, 2012, 04:52:08 PM ---And step-by-step debugging is still very useful - and what he's used to, coming from VB6.

--- End quote ---
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.


--- Quote from: Bob2004 on March 21, 2012, 04:52:08 PM ---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.

--- End quote ---
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.)


--- Quote from: Bob2004 on March 21, 2012, 04:52:08 PM ---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.

--- End quote ---
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.


--- Quote from: rkruger on March 21, 2012, 05:33:41 PM ---
--- Quote from: Bob2004 on March 21, 2012, 04:52:08 PM ---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.

--- End quote ---
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.)

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page