24 berichten aan het bekijken - 1 tot 24 (van in totaal 24)
  • Q:
    Bijdrager
    TypeWriter

    Runrev livecode

    Heeft iemand ervaring met Livecode van Runrev Ltd?
    Het ziet er allemaal prachtig uit en het is een interessante mogelijkheid: programmeren met het gemak van HyperCard maar een echte App als resultaat. Geen objectiveC dus.

    Maar werken die Apps dan snel?
    Heeft iemand een paar voorbeelden van Apps die met Runrev ontwikkeld zijn?
    HE

    Sleutelbeheerder
    Night

    Zonder er een blik op geworpen te hebben denk ik wel redelijk in de buurt te komen met de vergelijking tussen iWeb-pagina’s en een “normaal” opgemaakte webpagina. Om het gemak van HyperCard te bereiken zal er ongezien veel onnodige broncode meegeprogrammeerd worden. Een optimale snelheid zul je dus nooit bereiken. Uiteraard ligt het aan het soort programma’s dat je ermee wil maken, of het gemak opweegt tegen de nadelen…

    Kijk anders ook eens naar de links in de onderste post:
    http://forums.whirlpool.net.au/archive/1647633

    Bijdrager
    TerryVog

    Ik kan me de reactie van Night voorstellen, maar ik ken deze ontwikkel-omgeving heel goed en ik kan het echt aanbevelen.

    Je moet je indenken dat je bij elke programmeertaal gebruik maakt van de bibliotheken die meegeleverd. En die zijn snel, want die zijn goed getest. Ga je je eigen bibliotheken schrijven, dan hangt het resultaat sterk af van jouw eigen genialiteit. Een enkeling zal daar zo goed in zijn dat ‘ie daardoor snellere software kan schrijven. Maar de meeste programmeurs doen er verstandig aan de standaard bibliotheek-functies te gebruiken.

    Wat ik bedoel: als je toch standaard bibliotheken aan gaat roepen, maakt het voor de computer geen noemenswaardig verschil of je die nou aanroept met ObjectiveC of met Livecode. Voor de computer niet, maar voor jou wel! Jij wilt een begrijpelijke taal. Eentje die je gewoon kunt begrijpen als je het terugleest. Want je zult het moeten teruglezen als je de bugs wilt ontdekken. De keuze is dan tussen:

    if ( x > 9 )
    {
    NSLog (@”x is greater than 9!”);
    }
    else
    {
    NSLog (@”x is less than 9!”);
    }

    Of:

    if x > 9 then
    put “x is greater than 9!”
    else
    put “x is less than 9!”
    end if

    Al die haakjes, accolades en punt-komma’s typen sneller, maar maken het uiteindelijk onleesbaar. Bij langere scripts moet je dan ook aantekeningen gaan bijhouden wat zo’n } eigenlijk afsluit, want dat kan een if-structuur zijn, maar ook een repeat-loop of iets anders. Bij Livecode zie je het onmiddellijk: end if.

    Ik heb geen commerciële programma’s geschreven ermee, maar dat zou er absoluut mee kunnen. Wel heb ik bij diverse projecten Livecode scripts gebruikt. In veel gevallen had ik bijvoorbeeld een deadline van een week, maar was ik al binnen een dag klaar.

    Zoals Night al zei: het hangt af van het soort programma dat je wilt maken. Dat bepaalt of het met Livecode kan of niet. Maar je moet wel erg ambitieus zijn als je tegen de beperkingen van Livecode op loopt.

    Bijdrager
    Verwijder

    Er worden nu een paar dingen beweerd waar ik het niet mee eens ben:

    de bibliotheken die meegeleverd. En die zijn snel, want die zijn goed getest.

    Van testen wordt een bibliotheek niet sneller.

    als je toch standaard bibliotheken aan gaat roepen, maakt het voor de computer geen noemenswaardig verschil of je die nou aanroept met ObjectiveC of met Livecode

    Ik neem aan dat Livecode werkt met een interpreter of engine. Er zit dan a.h.w. een extra laag tussen jouw code en de computer en dat kost tijd. Of je dat merkt hangt af van de snelheid van de interpreter/engine en van wat het programma doet. Als je het merkt dan is dat vooral bij ingewikkelde berekeningen en bij het verwerken van grote hoeveelheden data.

    NSLog of Put is bij debuggen meestal niet nodig als je een symbolic debugger tot je beschikking hebt. Dat neemt natuurlijk niet weg dat je sources terug moet kunnen lezen.

    Al die haakjes, accolades en punt-komma’s typen sneller, maar maken het uiteindelijk onleesbaar.

    Of je accolades en puntkomma’s vervelend vind is meer een kwestie van smaak en wennen. Ik vind het bij lange statements van meerdere regels wel prettig dat tussen de statements een puntkomma staat. Welke accolades bij elkaar horen kan je zien aan het inspringen en het helpt als je de sources netjes formatteert. Ik vind “x = 1;” prettiger typen en lezen dan “set x to 1”. Objective-C heeft gelabelde parameters wat de leesbaarheid aanzienlijk verhoogt.

    Maar je moet wel erg ambitieus zijn als je tegen de beperkingen van Livecode op loopt.

    Ook hier hangt het er van af wat het programma moet doen en “erg ambitieus” is relatief. Als je tegen de beperkingen van Livecode aanloopt kan je zelf een external maken maar dan zit je in C++ te programmeren.

    De voordelen van Livecode lijken me: cross platform en makkelijker voor niet-nerds. De nadelen: de prijs en minder geschikt voor grotere ingewikkelde programma’s.

    Bijdrager
    TerryVog

    Hoi Willemien,

    Ik merk dat je niet alles interpreteert zoals ik het bedoeld heb. Bij de eerste quote bedoelde ik met ‘getest’ natuurlijk ‘beproefd’ of ‘geoptimaliseerd’, tegenover ‘zelf geschreven’, ‘buggy’.

    Het klopt dat Livecode met een engine werkt, dus ongetwijfeld heb je gelijk dat dat trager moet zijn. Maar deze engine is heel snel. Het draaide al soepel in de HyperCard-dagen op hardware die we nu belachelijk traag vinden. En sindsdien is het voortdurend geoptimaliseerd voor nieuwe hardware.

    Ik vind het bewonderenswaardig dat je kunt wennen aan al die puntkomma’s en andere tekens. Maar mij lukt het niet. Je noemt een uitstekend voorbeeld: x = 1 is een toewijzing; je stopt de waarde 1 in de variabele genaamd x. Op zich is dat heel goed leesbaar en begrijpelijk. Maar… dat lijkt als 2 druppels water op x == 1, wat dan weer gebruikt wordt om te kijken of x dezelfde waarde heeft als 1. Ik vind dat behoorlijk verwarrend. Mensen staren zich daar blind op en hebben niet snel door dat ze een is-tekentje vergeten zijn. Staat er gewoon wat meer Engels omheen, dan is het voor iedereen duidelijk:

    put 1 into x — toewijzing
    if x = 1 then — vergelijking

    Ik denk overigens dat we het erover eens zijn dat ‘erg ambitieus’ nogal relatief is. Het is uitbreidbaar met externals, maar het kan ook shell-scripts of AppleScripts starten. Maar voor sommige projecten is het niet ideaal. Je hebt het over grote ingewikkelde programma’s. Het is ook minder geschikt als het een heel specialistische taak moet uitvoeren.

    Bijdrager
    Verwijder

    Helemaal mee eens.
    Ik was al gewend aan “x = 1” toen ik “put 1 into x” of “set x to 1” voor het eerst tegenkwam en vind het omslachtig en wazig.
    Blijkbaar wil ik te veel want ik loop zelfs tegen de grenzen van Cocoa aan.

    Bijdrager
    TypeWriter

    Ik ben bezig met de 30-dagen demo van RunRev en ik ben eigenlijk van plan om het vooral voor de iPad en evt. iPhone te gebruiken.

    Wat betreft de inzetbaarheid: ik geloof persoonlijk dat je met LiveCode beter geen snelle action-game kunt programmeren; misschien is het daar gewoon niet efficient genoeg voor, maar dat kan ik niet helemaal beoordelen. Maar voor de meeste ‘informatieve toepassingen’, zeg maar van het type ‘ov9292’of ‘trein’ heeft het zo te zien meer dan genoeg in huis.

    Of zie ik het verkeerd? In het verleden heb ik vrij veel met HyperCard gedaan en het komt me allemaal heel bekend voor.

    Wel vraag ik me nog af wat de raakvlakken tussen RunRev/LiveCode en XCode zijn. Ik neem aan dat je een RunRev app kan prototypen in de iPhone/iPad Simulator, maar dat verder de hele omgeving op zich staat. Dus je gebruikt geen interface builder, geen Cocoa Framework enzovoorts.

    Bijdrager
    TerryVog

    Voor wie het wil weten: je kunt deze zomer 7 weken lang de Summer Academy volgen; een serie webinars waarvoor je je min of meer gratis kunt inschrijven. In de cursus leer je een iOS of Android app schrijven.

    Het loopt van 9 mei tot 27 juni. Je koopt een licentie voor 79 euro, maar die betaal je alleen als je je niet uitschrijft voor 27 juni.

    Wat betreft de inzetbaarheid: ik geloof persoonlijk dat je met LiveCode beter geen snelle action-game kunt programmeren; misschien is het daar gewoon niet efficient genoeg voor, maar dat kan ik niet helemaal beoordelen. Maar voor de meeste ‘informatieve toepassingen’, zeg maar van het type ‘ov9292’of ‘trein’ heeft het zo te zien meer dan genoeg in huis.

    Tsja, als je met ‘snelle action-game’ World of Warcraft bedoelt, vergeet het dan maar. Bedoel je Angry Birds? Dat moet geen probleem opleveren. Echt de engine is supersnel. Sneller dan AppleScript, JavaScript, PHP en al die andere talen die met een engine werken.

    Dan nog een overzicht dat boekdelen spreekt. Stel, je hebt een komma-gescheiden lijst, en die wil je sorteren op basis van de derde ‘kolom’, in omgekeerde alfabetische volgorde…

    In Livecode zeg je dan:
    sort lines of tekstVariabele descending by item 3 of each

    In de afbeelding staan 3 andere talen; ik was niet bereid om dat allemaal over te typen en ik was bang dat ik ergens een puntkomma of accolade verkeerd zou typen. That says it all, doesn’t it?

    Maar deze thread heeft de focus vooral op de vraag of het uiteindelijke resultaat een snel werkende app is. Dus ik zal me daarbij proberen aan te sluiten. Denk je nou werkelijk dat 22 regels programma-code in Java sneller wordt uitgevoerd dan die ene regel in LiveCode?

    Bijdrager
    Verwijder

    Denk je nou werkelijk dat 22 regels programma-code in Java sneller wordt uitgevoerd dan die ene regel in LiveCode?

    Nee, maar ik denk wel dat 22 regels Objective-C/C sneller worden uitgevoerd dan 22 regels in LiveCode. Waarschijnlijk wil je na het sorteren van de komma-gescheiden lijst er ook nog iets mee gaan doen. Er is ook vast wel een voorbeeld te verzinnen waar iets met Cocoa in één regel kan en in LiveCode 22 regels nodig zijn of niet kan.
    Ik denk dat het verschil in snelheid tussen Objective-C/Cocoa en LiveCode veel kleiner is dan het verschil in leercurve, mogelijkheden en gemak.
    Ik vraag me hetzelfde af als TypeWriter:

    Wel vraag ik me nog af wat de raakvlakken tussen RunRev/LiveCode en XCode zijn. Ik neem aan dat je een RunRev app kan prototypen in de iPhone/iPad Simulator, maar dat verder de hele omgeving op zich staat. Dus je gebruikt geen interface builder, geen Cocoa Framework enzovoorts.

    En hoe uitgebreid is LiveCode, het ziet er uit als moderne en geavanceerde HyperCard, maar kan je in LiveCode alle user interface elementen gebruiken die er in Cocoa zijn? Hoe zit het met dingen als lokalisatie, Quartz, Spotlight, Sync Services, Keychain, koppeling met Adresboek enz.? Ondersteunt LiveCode dit? of heeft het ook zoiets?

    Bijdrager
    TerryVog

    Er is ook vast wel een voorbeeld te verzinnen waar iets met Cocoa in één regel kan en in LiveCode 22 regels nodig zijn of niet kan.

    Zeker weten. Helemaal mee eens. En ik had de vraag van TypeWriter niet beantwoord omdat de suggestie gewoon al helemaal klopt. Je hebt XCode nodig om de iPhone/iPad Simulator te kunnen gebruiken. Verder moet je je bij Apple aanmelden als iOS developer om de app op je iDevice en in de App store te kunnen zetten. Dat kost $99 per jaar. Dat erop zetten loopt ook via XCode; voor de rest gaat het allemaal buiten XCode om.

    De user interface elementen regelt LiveCode zelf onder de motorkap. Bij mijn weten is er niets wat wel in Cocoa zit, maar niet in LiveCode. Het gebruikt de interface elements van het OS waar het op draait. Dus als je nu een Mac-programma maakt, en de radio buttons van Lion krijgen een ander uiterlijk, dan gaat jouw programma daar automatisch in mee. Maak je er een Windows-standalone van, dan komen daar radio-buttons die er normaal uit zien op dat OS. Dat geldt ook voor Linux, iOS en Android.

    Je code kan zonder of met minimale aanpassing op vrijwel elk OS draaien. Met iets meer aanpassing kunnen diezelfde scripts ook op een webserver als CGI draaien, of als alternatief voor PHP.

    Hoe zit het met dingen als lokalisatie, Quartz, Spotlight, Sync Services, Keychain, koppeling met Adresboek enz.?

    Dat ligt ingewikkeld. Jij denkt natuurlijk heel sterk vanuit XCode. Dus dan is LiveCode onbekend en raar. Je zult tevergeefs naar dergelijke API’s. Maar dat betekent niet dat het er niet in zit. Sommige dingen in je opsomming zijn nogal specifiek van Apple. Omdat LiveCode ook op al die andere OSsen draait, gebruikt het niet al die Apple-specifieke benamingen. Maar tijdens het uitvoeren, gebruikt het zo veel mogelijk de API’s van het OS waar het op draait.

    Bepaalde functionaliteit zit er niet in, maar daar is vaak wel een alternatief of een workaround voor. Bijvoorbeeld via AppleScript, een shell of een external. In de 10 jaar dat ik ermee werk, heb ik maar zelden behoefte gehad aan zo’n oplossing. Nadeel van deze workarounds is dat ze platform-specifiek zijn. Dus vaak is het beter om er gewoon een feature request van te maken. Niet zelden komt het dan in een volgende versie.

    Nog even voor TypeWriter: mocht je nog oude Hypercard-stacks hebben, dan kan LiveCode die openen. Dat is natuurlijk beperkt nuttig; graphics van toen kunnen echt niet meer in dit decennium. Maar als je er gegevens uit nodig hebt, is het een oplossing. En de meeste scripts zullen gewoon werken.

    Bijdrager
    TypeWriter

    Hoi allen,

    in elk geval alvast bedankt voor de uitgebreide reacties.
    Ik schrijf me in elk geval in voor die Summer Course. Dan heb ik denk ik sowieso een goede start / opfriscursus en kan ik denk ik wel beoordelen of het aan alle eisen voldoet.

    Nog dit:

    Je code kan zonder of met minimale aanpassing op vrijwel elk OS draaien. Met iets meer aanpassing kunnen diezelfde scripts ook op een webserver als CGI draaien, of als alternatief voor PHP.

    Als alternatief voor PHP is natuurlijk extra interessant. PHP heeft als voordeel dat er verschrikkelijk veel open source code voor beschikbaar is, maar weer als nadeel dat het toch een behoorlijk ‘declaratieve’ taal is. En qua code niet echt heel toegankelijk, vind ik.

    Helemaal leuk zou het zijn als je Livecode kunt gebruiken om een webinterface voor FileMaker Pro in elkaar te sleutelen. Maar misschien draaf ik nu een beetje door.

    HE

    Bijdrager
    TerryVog

    Helemaal leuk zou het zijn als je Livecode kunt gebruiken om een webinterface voor FileMaker Pro in elkaar te sleutelen. Maar misschien draaf ik nu een beetje door.

    Valt wel mee. Sowieso zit ondersteuning van MySQL, SQLite en nog wat andere database-structuren er standaard in. Gaat het echt om FM pro, dan zou je eens moeten kijken naar FMPro Migrator. De maker ervan, David Simpson, weet heel veel van integratie van FileMaker en LiveCode. Hij heeft ook iets met conversie van PHP naar LiveCode, maar dat is nogal experimenteel.

    Bijdrager
    beugelaar

    Wellicht een beetje late reactie maar ik kan LiveCode zeer aanbevelen, De IDE lijkt eenvoudig maar hierachter gaat een compleet nieuwe wereld open. Bedenk dat de hele LiveCode IDE geschreven is in LiveCode! Je kunt de meest geavanceerde controls maken op basis van je eigen .png ontwerp (sliders, treeviews etc.) De taal is in het begin vreemd, zeker als je een tradionele programmerachtergrond hebt zoals VB, C#, Java, PHP etc. Heb je echter het principe door (ik denk pas na 6 maanden) dan kun je echt alles bouwen en sterker: het is razend snel. De apps draaien in dezefde look en feel op een Window, Mac of Linux besturingssyteem. Je hebt hebt SQL Yoga (kost 199 euro) waarmee je iedere database als een object kunt benaderen. dus geen tijdrovende SQL statements meer. CRUD/newerk afhandeling: geen probleem. Integriteit gegevens database bewaken: geen probleem.
    De grootste kracht: iOS, Android. Je hoeft niet je app iedere keer opnieuw te builden (geldt ook voor de desktop en web plugin) maar ziet direct je wijzigingen op de emulator! Voordeel: gigantische tijdwinst.
    Spelletjes ontwikkelen: gebruik Franklin 3D engine. No limits.
    Conclusie: echte aanrader. Ik heb onlangs voor 799 euro de gehele LiveCode product line kunnen aankopen inclusief een yearly subscription zodat alle updates voor een jaar gratis te downloaden zijn evenals alle previews.
    Een echte aanrader als je anders gaat denken!

    Bijdrager
    bitsflew
    TerryVog op 28 april 2011

    sort lines of tekstVariabele descending by item 3 of each

    In de afbeelding staan 3 andere talen; ik was niet bereid om dat allemaal over te typen en ik was bang dat ik ergens een puntkomma of accolade verkeerd zou typen. That says it all, doesn\’t it?

    Voor de volledigheid is hier de Objective-C versie:

    <br />
    NSArray* textItems = [[[theText componentsSeparatedByString: @"\n"] sortedArrayUsingComparator: ^(id obj1, id obj2) {<br />
     	NSArray* line1 = [obj1 componentsSeparatedByString: @","];<br />
     	NSArray* line2 = [obj2 componentsSeparatedByString: @","];<br />
     	return [[line1 objectAtIndex: 2] compare: [line2 objectAtIndex: 2]];<br />
    }] componentsJoinedByString: @"\n"];<br />
     

    Wat leesbaarder: http://pastebin.com/StjJ5NqV

    Bijdrager
    TypeWriter

    De grootste kracht: iOS, Android. Je hoeft niet je app iedere keer opnieuw te builden (geldt ook voor de desktop en web plugin) maar ziet direct je wijzigingen op de emulator! Voordeel: gigantische tijdwinst.

    Ben ik het wel mee eens, dat is booming business, alleen zou LiveCode voor de afhandeling van de multi-touch events wel een facelift kunnen gebruiken: nu moet je de mouseH en mouseV oppikken en kijken of en zo ja hoeveel en in welke richting de gebruiker zijn vinger heeft verplaatst. Terwijl er gewoon een SwipeLeft event oid zou moeten zijn.

    Zoiets:

    on SwipeLeft
    doe dit
    doe dat
    end SwipeLeft

    on Touch [with] [two][three] [fingers]
    end Touch
    enz.

    Maar dat zien ze bij RunRev ook wel en het zal ongetwijfeld in de volgende release komen.

    HE

    Inactief
    Anoniem
    bitsflew op 04 oktober 2011

    </p>
    <p>NSArray* textItems = [[[theText componentsSeparatedByString: @"\\n"] sortedArrayUsingComparator: ^(id obj1, id obj2) {</p>
    <p> 	NSArray* line1 = [obj1 componentsSeparatedByString: @","];</p>
    <p> 	NSArray* line2 = [obj2 componentsSeparatedByString: @","];</p>
    <p> 	return [[line1 objectAtIndex: 2] compare: [line2 objectAtIndex: 2]];</p>
    <p>}] componentsJoinedByString: @"\\n"];</p>
    <p>

    Wat doet dat ^ symbool daar?

    Edit: en hoe die html tags er opeens inkomen weet ik ook niet:confused:

    Bijdrager
    Verwijder

    ^ is onderdeel van de syntax van blocks.
    Ik ben niet weg van de syntax, Objective-C is elegant maar blocks niet, naar mijn mening. Ik heb blocks nog niet onder de knie, misschien ga ik het nog mooi vinden.

    Die </p><p> is onderdeel van de Code-opmaak hier en er wordt regelmatig over geklaagd maar dat helpt blijkbaar niet.

    Bijdrager
    bitsflew
    Willemien op 07 oktober 2011

    ^ is onderdeel van de syntax van blocks.

    Ik ben niet weg van de syntax, Objective-C is elegant maar blocks niet, naar mijn mening. Ik heb blocks nog niet onder de knie, misschien ga ik het nog mooi vinden.

    De block syntax is een uitbreiding op C, en kan gebruikt worden in C, C++, Objective C en Objective C++.

    Inactief
    Anoniem
    Willemien op 07 oktober 2011

    ^ is onderdeel van de syntax van blocks.

    Ik ben niet weg van de syntax, Objective-C is elegant maar blocks niet, naar mijn mening. Ik heb blocks nog niet onder de knie, misschien ga ik het nog mooi vinden.

    Aha, ik had inderdaad wel eens wat gehoord over blocks maar me er nog niet op gestort. Ik ben nu eindelijk eerst een inhaalslag aan het doen om CoreData en Bindings te leren.

    Bijdrager
    Gustav

    Na het lezen van bovenstaande posts en na een paar dagen met de ‘probeerversie’ van LiveCode bezig te zijn ben ik zeer enthousiast over het programmeren hiermee.
    Wat ik niet geheel begrijp (of kan achterhalen) is dat er niet een massa mensen hiermee werkt.
    Zou dit komen omdat het weer een nieuwe taal is, of dat je er uiteindelijk toch minder mee kan?

    Ik ben al enige tijd bezig geweest om XCode te doorgronden, maar ik vind het lastig. Lang geleden heb ik met C++ gewerkt, maar ik merk dat het me nu veel moeite kost om het coderen weer op te pakken.
    De syntax die in LiveCode gebruikt wordt trekt me meer aan.
    Tevens de mogelijkheid om multiplatform app’s te maken vanuit dezelfde architectuur van de programma regels.

    Naast de redenen om LiveCode te gebruiken, ben ik toch ook op zoek naar redenen om ‘er niet aan te beginnen’. En dus redenen om toch door te bijten in XCode. Ik wil voorkomen dat ik uiteindelijk toch weer op XCode over moet stappen (omdat bijvoorbeeld LiveCode teveel beperkingen heeft/krijgt).
    Ik zie niet veel mogelijkheden om in de komende tijd beide talen simultaan te leren (naast de andere bezigheden in de week…)

    LiveCode bestaat nu al ongeveer 10 jaar, maar heeft niet een groot marktaandeel weten te veroveren.
    Als het zoveel voordelen biedt, waarom dan niet een enorme grote gebruikersgroep?

    Bijdrager
    TerryVog

    LiveCode bestaat nu al ongeveer 10 jaar, maar heeft niet een groot marktaandeel weten te veroveren.
    Als het zoveel voordelen biedt, waarom dan niet een enorme grote gebruikersgroep?

    Daar heb je zeker een punt, Gustav.

    Ik denk dat het belangrijkste nadeel best ingewikkeld zit. LiveCode richt zich op een soort tussengroep. Ik bedoel dit: Je hebt een groep die opgeleid is in de complexere talen. Die mensen hebben sterke bedenkingen bij LiveCode omdat het zo simpel is. Die mensen worden heel zenuwachtig als ze ineens heel veel principes die in de hun bekende talen belangrijk zijn, mogen vergeten hier.
    Dan heb je de ‘gemiddelde’ computeraar; mensen die geen behoefte hebben aan eigen software omdat ze daar nog nooit over na hebben gedacht. Zij gebruiken misschien een tiental programma’s, en hebben geen visie voor wat daaraan toe te voegen valt.
    En dan heb je dus die tussengroep die ik net bedoelde. Zij hebben geen tijd om een C-variant te leren, of ze verwachten dat dat te moeilijk is. Ze hebben misschien ideeën over wat zij handige software zouden vinden, of ze lopen tegen de beperkingen aan van bestaande programma’s. Voor deze groep is LiveCode ideaal.

    Waarom slaat het dan niet aan bij deze groep? De relatieve onbekendheid is een belangrijke drempel. De kosten ook. Als je niet zeker weet of programmeren iets voor jou is, en je mag kiezen tussen gratis XCode of een betaalde LiveCode, dan probeer je eerst de gratis programmeer-omgeving. Daar schrik je je het leplazarus van de complexiteit, en je besluit om niet opnieuw een poging te wagen om überhaupt te programmeren.

    Ik vind het jammer dat LiveCode niet bekender is. Maar ik voor mezelf zit er niet mee. Het aantal gebruikers is enkele tienduizenden, dus voldoende voor een gezonde bedrijfsvoering. En verder doe ik er mijn voordeel mee dat ik ermee kan werken. Het heeft me al bij aardig wat repetitieve taken geholpen.

    Natuurlijk kan ik niet beslissen wat het beste is voor jou. En verschillende talen simultaan leren is niet handig. Maar ik merk dat ObjC makkelijker voor mij is omdat ik LiveCode ken. Omdat jij ervaring hebt met C++ is het misschien anders voor jou.

    Overigens: dat het ‘weer een nieuwe taal’ is, kun je niet echt zeggen. De taal is grotendeels gebaseerd op HyperTalk, door Apple ontwikkeld in 1987.

    Bijdrager
    Verwijder

    Je hebt een groep die opgeleid is in de complexere talen. Die mensen hebben sterke bedenkingen bij LiveCode omdat het zo simpel is. Die mensen worden heel zenuwachtig als ze ineens heel veel principes die in de hun bekende talen belangrijk zijn, mogen vergeten hier.

    Ik behoor tot deze groep en als ik met iets als LiveCode aan de gang ga dan wordt ik niet zenuwachtig maar voelt het net alsof ik normaal met gewone Lego speel en nu met de grote blokken van Duplo mag spelen. Het is even leuk zolang het nieuw is maar ik wil al snel mijn gewone Lego terug.

    Bijdrager
    Gustav

    In hoeverre het mogelijk dat Apple Apps die ontwikkeld zijn in LiveCode niet zo makkelijk in de AppStore toelaat?
    Voorrang voor XCode?

    Bijdrager
    TerryVog

    Maakt werkelijk niet uit voor de App Store. Clarify van Blue Mango Learning is een tijdje geleden zelfs bekroond als beste App in zijn categorie in de Mac App Store, terwijl deze bij mijn weten in LiveCode gemaakt is. Ook in de iOS App Store zijn diverse voorbeelden te vinden.

    Voor de toelating in de App Stores kijken ze vooral naar of het doet wat het beweert te zullen doen en of het stabiel is.

24 berichten aan het bekijken - 1 tot 24 (van in totaal 24)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.