Amiga coder wanted for contract work

I’m looking to hire an AmigaOS 4 coder this year for some contract work. The job is porting the open source programming language Swift to AmigaOS. This is an open source project so the pay is not massive. Still it’s paid work for Amiga programming work which I think is rare in this community I believe. Please ping me if interested and be prepared to show past work examples please.

Are you sure you want to do Swift? Even if the language is portable, there is apparently a Linux version, it's not going to be super useful without the whole Mac/iOS set of APIs.

MorphOS for example does have an Objective C environment but it doesn't have an implementation of Cocoa and the various 'kits' needed to make Swift do cool things like games and whizzy animated UIs.

It's still hugely ambitious, given we never even got a complete Java, but it's ever so slightly more realistic to do something like porting the Android runtime which could then potentially allow AOSP to run and thus Android apps and games as long as they don't assume and need ARM native code.

does swift use LLVM as compiler? We don't have any LLVM compiler on AmigaOS4

@DiscreetFX

Noticed few tools to convert “Swift” into C# or Javascript, I a have also read about converter to C++, but can’t find it, Swift is just different way to write classes, I’m sure there bit more too then that, but its maybe not the most useful thing. On the contrary I see people struggling because now they have additional language to learn.

@LiveForIt

Amiga API is of course not object oriented, even BOOPSI is accessed from regular C even if it has OO architecture - but there are attempts to wrap it, like APP/OO libraries. The question is are those any good?

@NinjaCyborg

The thing is that C++ programs can use C libs, but C++ libs can’t be used by C programs.
Anyway if you compile a amiga .library with C++, then AmigaOS does not find the symbols, ramlib does not support it.

As for the argument about structs & functions vs class & methods, is just a organizational & structural thing, sure things looks cleaner with classes, as you see where things belongs. As you are forced into a strict naming scheme.

Any way you can clean up C with few macros,

#define OON(sname,fname) sname ## _ ## fname(sname)

#define OOA(sname,fname,…) sname ## _ ## fname(sname, __VA_ARGS__)

carType *car;

color = OON(car,getColor);

OOA(car,setColor,0xFFFF0000);

I suggest organize things into .c files where one “object” is one .c file, so you have the functions for car in one place, car.c and data in car.h, if split things up keep source code clean, its not so hard to keep organized.

Anyway function points inside structs work more or less like virtual methods, only difference is that you must pass in struct pointer into as argument of the function pointer.

Another thing that is useful is

#ifdef __cplusplus
#endif

So you can include methods for struct if header is included into a C++ program, the normal methods does not take up any space in struct. Anyway, you need function outside of struct, for normal C programs, so it does not really solve it. in the end is code style thing. The extra work to support the C++ style become boilerplate code.

@discreetfx

Am very sympathetic to your objective of finding developers and excited you're willing to fund some project, but i'm not sure starting with porting Swift is a realistic goal, what is the end you are trying to achieve for which you think Swift is the means?

I assume you are not the original discreteFX guy behind imagefx etc?

@LiveForIt

Quote:

A library is just a library, many libraries writte in C++ have C interfaces too.

Quote:

That's not really the problem, you can easily make C stub functions to wrap a C++ library into an amiga.library in the same way as you do for a static library. ramiib does not use symbols to find libraries, nor is there any symbol searching done to find function offsets.

The problem is more creating a amiga style .library from C++ classes that can then be used from C++ . Because C++ uses 'mangled' function names to handle calls with varying numbers of arguments with varying argument types there is no easy one vector per function interface, This is where shared objects come into play.

@NinjaCyborg

Quote:

No, but neither is posix

@broadblues

Don't think I said it was

@NinjaCyborg

Perhaps I should have expended my point a little more, the baseline of most if not all systems are not object orientated, that has no bearing on whether you can do object orientated programming on it.

I know that, why do you feel the need to tell me?