Saturday, May 25, 2013

I be compiling

I don't want to start over again in all respects. So what language should I write Linux programs in?

I know it should be C, but I find coding in that language to be a pain. It's not the core language itself but all the stupid libraries. I decided to try Euphoria again because it has a translator to C and I've enjoyed coding in Euphoria before. I installed it in the wrong place, but I'm not going to fix that right now. One mistake in any of the config files and I'll have a holy mess. Uninstalling is not something Linux does well at this point. I tried translating a sample application but could not open the C output for reasons I have yet to figure out. So then I used the -gcc switch and that seemed to work producing an executable without producing C source. After copying the output to /usr/bin the program ran perfectly.

Technically, I don't ever need to see the C source as long as I can get from Euphoria source to executable code, but it would nag at me if I didn't figure that out.

I have to find an editor I like but that's a small issue.

The next big thing is creating a linkable library that gives me a windows program. I don't really want to reinvent the wheel but I also don't want installation issues. I'd like to just hand off an executable and say run it.

This is why desktop Linux never really gets off the ground. Developers, mostly kids to this old man, never seem to understand that regular people just want things to work and don't care to fuss with details. A statically linked executable that you just have to drop into the right folder would seem to fit the bill. The advantages of dynamically linked software are only advantages if they don't make things more difficult for the user.

I'll have to think about this.

Update: Now some griping. From the OpenEuphoria site...
Euphoria v4.0 is a very large jump in functionality from the previous stable release, 3.1.1.
No it isn't. That's what they said back when they started that project. Even then it was clear they didn't and still don't understand functionality or software elegance. Adding the kitchen sink is not the same as adding functionality. They didn't add any. Everything they can do in 4, I could still do in 3 and it would be more maintainable because of it's lower complexity.

Functionality would be to add windows in addition to the command line interface. They did not do that. So I'm going to have to figure out how to do that by my little old worn out self. How many computer scientists does it take after years of work to change a lightbulb? /gripe over.

I would also like to see some SQL database connectivity, but at least 3 had the ability to use an integral data store.

Update: Apparently there is a way for SQL.

They went open source on September 19, 2006.  So for seven years (with 21 people working on it, many from the beginning) they didn't add windows functionality and still have a very primitive graphics capability (that would not play nice in a windowed environment.) That has to be fixed and not with something I have to pay for or hope my users already have installed. To be fair windows had that functionality in DLLs that were part of the OS and I don't think Linux does (because of a different philosophy.)

Update: Now I'm getting somewhere... Euphoria can call routines in a shared library (.so) I just have to find the right library. A C call demo was included. I tested it and it works.

re: holy mess. It turns out it was no big deal. I reorganized my home folder adding a bin folder which is automatically added to $PATH by .profile. Compile continues to work as expected.

Update: I found what I need.

I've been compiling a few samples and things look encouraging however there are problems. For about a decade I worked with Visual Basic from version 4 to 6 and anything that would run in the interpreter I could compile. Not so in this case. Things that run fine in the interpreter produce code with out of scope link errors which I'm sure I can run down in time. Also, the translation from Euphoria source to C source is very slow taking multiple passes. Also, error trapping isn't what it should be for a product to be handed out to others. That can be dealt with by very careful coding but not entirely. I don't like that.

I would not consider it a professional solution. However, all my life I've not gone forward because my standards for something I would hand off to others has been much higher than the crap others were willing to sell to me. The perfect really is the enemy of the good. I see it even now with software for Linux, some good, some not, some you have no way of knowing because it just doesn't work.

The development environment is not up to what I've been used to during my last decade of employment, but I can make it work. I can produce something the users will not have trouble with. That's what matters.

Update: Hmmm... another little wrinkle. If I want just a single executable file how do I include resources? In VB they have controls you add artwork to that you index. I could include a folder with resources but that allows others to screw things up. Then when the program doesn't work, they blame the programmer, not the person that screwed with the folder. BTW, they should blame the programmer if stuff is left in unsafe places. Also, compiling everything each time makes no sense. I've got to make a library to link to so only my new code gets compiled.

No comments: