Programmeertaal translator

[Verwijderd]

Goedendag Tweakers.

Dit zal vast vreselijk noob klinken maar ik ga het een poging wagen.

Ik programmeer zelf al n jaartje in objective-C en sinds kort in swift.
Niet om op te scheppen maar ik zit vol met goede ideeën waarvan ik er een hier ga uitleggen en jullie wil vragen of zoiets al bestaat of dat het überhaupt mogelijk is.

Wanneer je naar Gaming op de PC/Mac kijkt is er technische gezien geen enkele rede waarom je niet zou kunnen gamen op Mac of Linux. De Hardware is namelijk hetzelfde x86_x64 Wat nou als er een programmeertaal translater programma is?

We pakken even een game als voorbeeld neem bijvoorbeeld Battlefield. De enige factor waarom je niet op Linux of Mac kan spelen is DX11.

Dus als je een zelflerende systeem zou ontwikkelen dat C++ bestanden herschrijft naar Objective-C of een andere taal? De programmeur voert de broncode van Battlefield in en je selecteert de taal waar het naar vertaald moet worden. Je klikt Play en het programma herschrijft de gebruikte taal naar de gewenste taal.
Dus je leert het programma bijvoorbeeld 1+1 te schrijven in verschillende talen. En wanneer het programma in de broncode 1+1 herkent die zelfde 1+1 kan herschrijven naar de gekozen taal. En dat het systeem zelf betere of snellere manieren vind om het te vertalen.

Wat denken jullie?? Bestaat zoiets of is het überhaupt mogelijk??

Groetjes Johan

[TommieW]

Als het mogelijk is, is het al uitgevonden.

De kans dat dit mogelijk is acht ik heel erg klein. Door het grote verschil tussen programmeertalen denk ik dat dit niet echt een succes kan worden.

[Verwijderd]

TommieW schreef op maandag 24 november 2014 @ 18:45:
Als het mogelijk is, is het al uitgevonden.

De kans dat dit mogelijk is acht ik heel erg klein. Door het grote verschil tussen programmeertalen denk ik dat dit niet echt een succes kan worden.

Vreselijk antwoord.... Of het nu wel of niet is uitgevonden wilt niet zeggen dat het niet mogelijk is.
De rest van je antwoord is juist wel iets waar ik wat mee kan.

[Kobus Post]

Al zou het kunnen, performance zal enkel minder worden. Wij mensen zijn nou eenmaal slimmer dan die computer

[Gerco]

Het gaat niet zo zeer over de programmeertaal, maar meer de API waar je mee moet praten als je dingen naar een ander OS wilt porten. C/C++ programma's die OpenGL gebruiken zijn prima portable, geen vertaler voor nodig en draaien gewoon op "alle" Operating Systems.

Het grote probleem in het porten van games moet dus iets anders zijn. Dan moet je naar dingen als DirectX gaan kijken. Als een game op DirectX gebouwd is moet je dus de API calls naar DirectX vertalen naar een andere API. Dat is veel meer werk dan "even" een andere programmeertaal gebruiken. Wine heeft een enorme berg werk zitten in een DirectX -> OpenGL API layer, bijvoorbeeld. Op die manier hoef je helemaal de applicatie niet te vertalen, maar herimplementeer je de DirectX API door OpenGL te gebruiken.

Hetzelfde geldt voor een Win32 programma/gui vertalen naar Cocoa (Mac). De programmeertaal heeft er weinig mee te maken. Een Win32 programma in C kun je op een Mac niet draaien, maar je kan prima een Cocoa programma in C compileren en uitvoeren. Het verschil zit hem niet in de programmeertaal, maar in de API naar het OS. Hier heeft Wine wederom een hoop werk in zitten.

De mensen achter Wine zijn al meer dan 15 jaar bezig om Win32 op andere systemen werkend te krijgen en ze zijn er nog steeds niet. Als het makkelijk was waren ze inmiddels wel klaar geweest.

[ Voor 9% gewijzigd door Gerco op 24-11-2014 18:59 ]

[rty]

De programmeertaal boeit toch niet? Gaat om de onderliggende libraries/frameworks die afhankelijk zijn van een OS. Vertalers naar andere programmeertalen zijn er wel, maar ze werken meestal niet erg goed. Je zou kunnen kijken naar LLVM.

[Verwijderd]

Hmmmz oke duidelijk.

Nee ik was van het weekend aan het spelen met Google Translater dus daarom wilde ik eens vragen of zoiets überhaupt bestaat of makkelijk zou zijn.

[alex3305]

Google heeft zo'n tool ontwikkeld die Java code kan omzetten naar Objective C. Zo hebben ze voor het nieuwe Inbox een gedeelde codebase van zo'n 75%.

Zie ook: https://github.com/google/j2objc

[HuHu]

Dat "translaten" noemt men porting: http://en.wikipedia.org/wiki/Porting

Er is trouwens een tool voor het omzetten van DirectX naar OpenGL: https://github.com/ValveSoftware/ToGL

[ Voor 40% gewijzigd door HuHu op 25-11-2014 07:09 ]

[MSalters]

Goed , laten we een stukje moderne C++ code nemen (dit is echte productie code)

C++:

template <typename FwdIter, typename FwdIter2, typename BinaryOp, typename T,
          typename checkTplusT = decltype(std::declval<T&>() += std::declval<T>())>
inline T accumulate_transform(FwdIter begin, FwdIter end, FwdIter2 begin2, BinaryOp op, T initial)
{
    for (; begin != end; ++begin, ++begin2)
    {
        initial += op(*begin, *begin2);
    }
    return initial;
}

Hoe vertaal je dit naar Objective-C ? "1+1" gaat nog wel, maar serieuze code is een ander verhaal.

[Soultaker]

Toch kan dit wel -- er zijn C++-naar-C vertalers, bijvoorbeeld, en Objective-C is effectief een superset van C. Alle Turing-complete talen zijn in principe naar elkaar te vertalen.

Zoals Gerco aangeeft is de taal niet het probleem, maar de libraries (=implementaties van APIs).

[L01]

Ik denk dat het probleem niet echt ligt bij de gebruikte programmeertaal, waarschijnlijk compileert het toch allemaal wel naar een lagere programmeertaal als Assembly ofzo.

Het probleem is meer de communicatie naar de API's van het operating system of andere libraries.

[PrisonerOfPain]

MSalters schreef op dinsdag 25 november 2014 @ 12:21:
Goed , laten we een stukje moderne C++ code nemen (dit is echte productie code)

C++:

template <typename FwdIter, typename FwdIter2, typename BinaryOp, typename T,
          typename checkTplusT = decltype(std::declval<T&>() += std::declval<T>())>
inline T accumulate_transform(FwdIter begin, FwdIter end, FwdIter2 begin2, BinaryOp op, T initial)
{
    for (; begin != end; ++begin, ++begin2)
    {
        initial += op(*begin, *begin2);
    }
    return initial;
}

Hoe vertaal je dit naar Objective-C ? "1+1" gaat nog wel, maar serieuze code is een ander verhaal.

Hoezo zou dit niet te vertalen zijn? De type-restricties worden toch nog gewoon gechecked at compile time (in de C++ frontend), vervolgens is het maar een triviaal loopje.

[johnkeates]

Valve heeft dit dus al ergens op GitHub staan.

https://github.com/ValveSoftware/ToGL

[oxfordpelican]

Ik denk dat het grootste probleem ligt aan het feit dat bijvoorbeeld een game/DirectX een aantal Windows system calls aanroept die gewoonweg niet bestaan in Linux of OSX. Tuurlijk zal Linux een system call hebben die er op lijkt maar hier zal toch een mens naar moeten kijken.

[MSalters]

PrisonerOfPain schreef op dinsdag 25 november 2014 @ 14:00:
[...]
Hoezo zou dit niet te vertalen zijn? De type-restricties worden toch nog gewoon gechecked at compile time (in de C++ frontend), vervolgens is het maar een triviaal loopje.

Elke instantiatie is te vertalen (uiteraard: een C++ compiler doet niets anders) maar de functie zelf is dat niet. Die type restricties bijvoorbeeld dienen voor gestuurde compile-time overload resolution. Veel talen hebben niet eens overload resolution, laat staan de mogelijkheid om dat te sturen.

[Verwijderd]

johnkeates schreef op dinsdag 25 november 2014 @ 14:03:
Valve heeft dit dus al ergens op GitHub staan.

https://github.com/ValveSoftware/ToGL

Ja, en Wine doet ook ongeveer hetzelfde.
Het probleem is dat ze allemaal stoppen bij DX9, en niet volledig zijn.
In theorie kan het, maar in de praktijk ben je jaren bezig om alles goed te implementeren en alle vage bugs eruit te halen.

Een betere oplossing zou zijn om (delen van) videodrivers uitwisselbaar te maken tussen OSen. Het Gallium3D-project houdt zich hier mee bezig, maar hebben helaas weinig steun van fabrikanten: http://en.wikipedia.org/wiki/Gallium3D
Beter zou zijn als OS X/linux/etc gewoon zelf de DirectX-API zouden adopteren, zodat driver-ondersteuning gewoon standaard wordt, net zoals bij OpenGL het geval is (wat intern door nVidia en AMD ook gewoon gedeeld wordt voor meerdere OSen).

[PrisonerOfPain]

MSalters schreef op woensdag 26 november 2014 @ 13:18:
[...]

Elke instantiatie is te vertalen (uiteraard: een C++ compiler doet niets anders) maar de functie zelf is dat niet. Die type restricties bijvoorbeeld dienen voor gestuurde compile-time overload resolution. Veel talen hebben niet eens overload resolution, laat staan de mogelijkheid om dat te sturen.

Volgens mij gebeurt dat ook in C++ in bepaalde situaties bij het omzetten naar native code, al geloof ik dat iig de MS compilers hier sinds VS2010? beter mee om gaan.

Maar goed, meestal gaat het bij een source-to-source compile niet om de leesbaarheid van de uiteindelijke code maar om het feit dat het uberhaupt werkt.

Nu hebben wij (voor Battlefield) geen source-to-source compiles voor onze native code omdat alle platformen waar wij op draaien (iOS inclusief) gewoon support voor C++ en hebben we gewoon een Metal rendering backend. Waar we het wel voor gebruiken is om onze shaders te vertalen, van hlsl naar glsl bijvoorbeeld.

Er zijn wel producten (Unity3D) die wat rare dingen met source-to-source compilation doen om bijvoorbeeld hun runtime in de browser te kunnen draaien maar ik verwacht niet dat wij dat snel zullen doen. Maar ook dan ontkom je niet aan het schrijven van een aantal regels 'native' code in de destination taal.

[Verwijderd]

PrisonerOfPain schreef op woensdag 26 november 2014 @ 15:21:
[...]
Er zijn wel producten (Unity3D) die wat rare dingen met source-to-source compilation doen om bijvoorbeeld hun runtime in de browser te kunnen draaien

Onder Windows worden WebGL shaders sowieso vertaald. Alle populaire WebGL-implementaties (IE11, Chrome/FireFox (ANGLE-project van Google)) draaien namelijk op D3D ipv OpenGL.

Als je een eigen engine ontwikkelt, lijkt het me op zich handiger om een eigen meta-shadertaal te maken, die naar HLSL, GLSL etc vertaald kan worden, dan om 1 van die talen als uitgangspunt te nemen, en te vertalen naar de rest (al kun je natuurlijk altijd wel hints voor de translator in comments opnemen in je shaders... maar of dat echt mooi wordt...).

[RayNbow]

MSalters schreef op dinsdag 25 november 2014 @ 12:21:
Goed , laten we een stukje moderne C++ code nemen (dit is echte productie code)

C++:

template <typename FwdIter, typename FwdIter2, typename BinaryOp, typename T,
          typename checkTplusT = decltype(std::declval<T&>() += std::declval<T>())>
inline T accumulate_transform(FwdIter begin, FwdIter end, FwdIter2 begin2, BinaryOp op, T initial)
{
    for (; begin != end; ++begin, ++begin2)
    {
        initial += op(*begin, *begin2);
    }
    return initial;
}

Ik ben niet echt thuis in C++, maar zou dit een vergelijkbare implementatie zijn in Haskell?

Haskell:

{-# LANGUAGE ViewPatterns #-}
import Data.Monoid
import Data.Foldable
import Data.Function (on)


foldlZipWith
  :: (Foldable f, Foldable g, Monoid m) =>
     (a -> b -> m) -> m -> f a -> g b -> m

foldlZipWith f z (toList -> xs) (toList -> ys) 
 = z <> mconcat (zipWith f xs ys)


ex1 = getSum $ foldlZipWith ((<>) `on` Sum) mempty [1..5] [100,200..]

(De Haskell versie legt wel een restrictie op die niet in de C++ versie bestaat: + moet associatief zijn. Edit: Oh, en het gaat er ook vanuit dat de binaire operator hetzelfde type retourneert als de initiele waarde; dat kan ook generieker...)

[ Voor 5% gewijzigd door RayNbow op 27-11-2014 09:47 ]