Sikeres lett a "LiveCode (Open Source)" Kickstarter kampánya

Programozás

1987-ben az Apple kiadta a HyperCard nevű eszközt, amellyel akár végfelhasználók programozói tudás nélkül is tudtak programokat készíteni. A HyperCard klónt, a LiveCode-ot készítő RunRev Ltd szerint a HyperCard minden idők legegyszerűbb és legmodulárisabb végfelhasználói programozói környezete volt, amelyhez foghatót sem előtte, sem azóta nem készítettek.

A Runedev szerint a LiveCode a HyperCard következő generációs verziója, amellyel gyakorlatilag bárki, bármilyen alkalmazást készíthet egyszerűen Windowsra, Linuxra, OS X-re, mobil platformokra, desktopra, szerverre - legyen akár programozó vagy sem. A RunRev egy Kickstarter kampányt indított annak érdekében, hogy kiadhassák a LiveCode nyílt forrású verzióját:

A Kickstarter kampányban 350 ezer fontot kértek. A kampány sikeresen zárult és majdnem félmillió fontnyi összeg jött össze. A projekt által felvázolt útiterv szerint márciusban kiadják a forráskód "Community Edition" változatát, a végleges kiadás pedig 2013 őszén érkezhet.

A projekt FAQ-ja szerint a LiveCode Open Source-szal játékokat, mobil alkalmazásokat, desktop- és szerveralkalmazásokat, segédprogramokat, adatfeldolgozó eszközöket, adatbázis frontendeket stb. lehet készíteni. Forráskód szinten az Open Source verzió azonos lesz a kereskedelmi verzióval, csak licencben térnek majd el.

Az Open Source verzió licencéül GPLv3-at választották.

Részletek a projekt Kickstarter oldalán.

( sz332 v | 2013. 03. 04., h – 19:19 )

Te jó ég, már előre látom, milyen szép gányolásokat lehet ebben elkövetni..

( STP | 2013. 03. 04., h – 19:50 )

"A projekt FAQ-ja szerint a LiveCode Open Source-szal játékokat, mobil alkalmazásokat, desktop- és szerveralkalmazásokat, segédprogramokat, adatfeldolgozó eszközöket, adatbázis frontendeket stb. lehet készíteni."
És az orrodat nem tiszticcsa?

( prion | 2013. 03. 04., h – 22:12 )

szuper :) a programozásnak olyan skillnek kéne lennie mint az olvasásnak. kicsit mindenki értsen hozzá, de persze ebből nem következik, hogy bárki bár milyen összetettségű szöveggel kell, hogy boldoguljon.

( Nyosigomboc v | 2013. 03. 04., h – 22:14 )

Ez mar az N+1. hasonlo project. A vege mindig ugyanaz, hogy a logikat le kell programozni. Egy uj programozasi nyelvet 2-3 nap alatt meg lehet tanulni annyira, hogy tudd valamennyire hasznalni (nyilvan nyelvfuggo, scripteket egyszerubb). A programozas logikajat tart sokaig elsajatitani, azt, hogy egy algoritmusnak milyen lepesei vannak, es mit hogy erdemes osszerakni. Ehhez viszont gondolkodasra van szukseg, amit a nyelvi elemzo nem tud kivaltani.

Ami az elonye, hogy a plusz reteg miatt eleg sok platformra tud kozvetlenul appot kesziteni. De ebben kozel sem egyedulallo.

--
akkor most free tibet vagy delete tibet a jó?? - falu

" Egy uj programozasi nyelvet 2-3 nap alatt meg lehet tanulni annyira, hogy tudd valamennyire hasznalni (nyilvan nyelvfuggo, scripteket egyszerubb)."

Az nem művészet, hogy ha egyik imperatív[+OOP] nyelvről egy másik imperatív[+OOP] nyelvre kell átváltani. Azért ha valakinek azt mondják, hogy akkor holnaptól prologozol, akkor lehet köhögni fog érte.

"Ehhez viszont gondolkodasra van szukseg"

És itt jön be az, hogy a legtöbb ember képtelen algoritmizálni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( hans1985 | 2013. 03. 04., h – 22:51 )

Ez most mi? Szerintem halott ötlet! Ebben össze lehet rakni egy elágazásos szekvencia programot mondjuk, valami kvízt vagy hasonlót, de komoly programot írni a Gyuszi bácsi nem fog rajta az unokájával közösen egy délutáni tea mellett.
Ez baromság. Aki programozni akar, komolyan és nem csak hülyéskedni az úgysem ebben fog. Az átlag ember nem szeret programozni, és nem is fog megszeretni ez által sem. Van egy réteg akinek ez a szakmája, vagy hobbija, de ez olyan csekély réteg ami az emberek kis hányadát teszi ki, nekik erre nincs szükségük.
Kis Pistike a szomszéd sráccal esetleg ír két sor kódot aminek eredménye képpen egy labada kattintásra zöldből pirosra vált, aztán le is törlik az appot, azzal az indokkal, hogy ez uncsi és szar.

Nem értem kinek akarják ezt adni, vagy kikre számítanak, vagy mi fog ebben készülni, de hogy értelmes program nem az biztos!

________________________________
blog: http://horvathjanos.wordpress.com

Értem, akkor is ez van a szerveroldalon, még ha egy kisebbségnek ez nem is tetszik, valamiért mégis ezt preferálják.
Ez olyan mintha valaki leminősítené mondjuk pl. a fa ablakokat mert neki nem tetszik, miközben az épületek többségén az van. Ha olyan rossz lenne valami akkor nem használnák a tömegek, pláne úgy hogy emögött semmi marketing nincs, ez nem egy Coca Cola vagy egy Windows.

Amúgy meg a számok magukért beszélnek, nem kell velem egyetérteni, akkor is ez van:

PHP 78.7%
ASP.NET 20.1%
Java 4.1%
ColdFusion 1.1%
Perl 0.8%
Ruby 0.5%
Python 0.2%
________________________________
blog: http://horvathjanos.wordpress.com

Lazán kapcsolódik, éppen aktuális szopás:

Adott egy gyorsan összetúrt PHP script, amivel valamit ellenőrizni kívántam. Túloldalt egy MSSQL figyelt. Először ment a csodálkozás, hogy miért nem kapok vissza egy rekordot sem, ha a query MSSQL Management Studioba bemásolva megy. Na miért? Mert a fogyaték PHP nem egy egységes belső stringreprezentációt használ, hanem össze-vissza karakterkódolásban. Ezzel pl. C#-ban (hacsak valaki nem tol ki kifejezetten magával) 0, azaz 0 probléma lenne. De gyanítom Java-ban is megoldott ez.

De azért jó az a PHP, mert sokan használják!

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azon az oldalon kb. évek óta nincs semmi, szimplán a muportal.hu-ra vitt. Ismerősnél, ahol volt hostolva volt egy kisebb gebasz (Linuxra nincs vírus című szlogen mutatkozott ismét megbukni), úgy néz ki nem nagyon figyelt, hogy mit rakott vissza.

Gratulálok, hogy ebből ilyen messzemenő következtetéseket vontál le.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azt azért remélem észrevetted, hogy most ezzel (és a fenti) hozzászólásaiddal azt az álláspontot képviseled, miszerint nem baj, hogy egy programnyelv (és a szorosan hozzátartozó rutinkönyvtárak) által használt belső adattárolási mód nem egységes. Magyarul: önmagával nem képes konzisztens lenni.
Erről már korábban vitáztunk (eredmény nélkül), pont az ilyenek miatt nem tartom mérvadónak a véleményedet ebben az ügyben.
Másrészt az "csak ezt ismerem - ez a jó" mentalitás sokszor nagyon jellemző a PHP kóderekre. Érdemes mást is megnézni.

Én nem mondtam, hogy csak ezt ismerem és azt sem, hogy csak ez a jó. Ti mondjátok folyamatosan, hogy csak ez a rossz, erről van szó.
Én is szívesebben írnám a szerver oldali kódomat Ruby-ba, de nem tehetem, és nem is arra van igény/lehetőség. Pedig a Ruby-t pl. jobbnak tartom a PHP-nél webre.

________________________________
blog: http://horvathjanos.wordpress.com

Mesélj. DB-t nem módosíthatok PHP-s része meg bugos, iniset-tel történő módosítás nem működik, workaroundhegyek vannak csak rá. Vagy használok COM-on OLEDB-t. Bár biztos az is véletlen, hogy legtöbben még is maradtak az iconv()-nál MSSQL esetén.

Szóval taníts mester!

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ne kötekedj, ne hisztizz, oldd meg, mert más is megoldja, meg lehet. Ne kifogásokat keress. Ha meg annyira nagy szopás neked ez az egész, akkor miért használod, miért ugrottál bele úgy, hogy nem néztél utána mire kell, mit fogsz használni stb... ahogy mondtam, legkönnyebb a nyelvet szidni, az nehezebb, hogy megoldjunk egy problémát, és ha nem megy akkor minden szar és minden hibás csak mi magunk nem. Értelek én... semmi gond.

________________________________
blog: http://horvathjanos.wordpress.com

Ja értem, szóval halvány lila fingod nincs arról, hogy a PHP és az MSSQL hogy működik együtt csak okoskodsz jólnevelt PHP fanboy módjára.

Igen, képzeld megnéztem, hogy milyen megoldások vannak és képzeld meg is oldottam a problémát. De attól még a megoldás okádék. Ez egy olyan felesleges probléma, ami más programnyelvben nem fordul elő. Ha téged nem zavar az, hogy ilyen workaround hegyekkel kell teletűzdelni, akkor üsse kő. Engem viszont zavar, hogy érdemi feladatok megoldása helyett ezekkel megy el az idő.

Kifogások? Nem, ezek szimpla megoldatlan problémák a PHP körül.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Használtam együtt a kettőt igaz nem mostanában, hanem kb. 2 éve. Volt egy kész MSSQL adatbázis amit egy régebbi más nyelven írt cucc töltögetett éveken át, erre kellett új PHP alapú appot építeni. Igaz, hogy csak alap SQL műveletek voltak, insert, update, delete stb. de nem találkoztam ilyen óriási problémákkal mint amiket itt próbálsz bemagyarázni, pedig az már két éve volt, és azóta nyilván változtak a dolgok, feltételezem, hogy nem fejlődött visszafelé a nyelv. :)

Ahogy mondtam, szimplán hisztizel. :)

________________________________
blog: http://horvathjanos.wordpress.com

Akkor miért van tele az internet ezzel a problémakörrel? :)

Egy esetben nincs szopás, ha mindenhol ugyanazt használod. Namost, ez jelen esetben nem áll fenn. Érdekes módon C#-ban valahogy tudja a csatoló, hogy mivel dolgozik a .NET és nem nekem kell ezzel külön túrázni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Ha mindenhol minden utf-8-ban van akkor semmi probléma sincsen sehol! "

És ha nem megvalósítható, akkor mi van? :)

" ilyen esetben nem csak PHP+MSSQL-el lesz probléma..."

Akkor magyarázd meg, hogy miért _csak_ és kizárólag ezzel van szopás és miért nem jelent problémát pl. C#-ban? :)

Körbe kellene kicsit nézelődni a nagyvilágban, mi van a PHP+JS hányadék-tengeren túl.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mesélj mester, te mit tennél, ha van egy ügyviteli rendszer, MSSQL-lel, nem te fejleszted és igencsak morcosan néznének rád, ha kitalálnád, hogy te most módosítasz a DB-ben? (Mindezt azért, mert a rühes PHP nem képes megugrani azt a szintet, amit minden más.)

És továbbra is választ várok arra, hogy miért _csak_ php-ben van ezzel szívás?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Tudtad előre mit vállalsz nem? Akkor meg? Ha annyira MS centrikusan kell dolgozni, és annyira jónak tartod a megoldásaikat, akkor miért nem választottál MS által szolgáltatott nyelvet szerver oldalra? Senki nem kötelezett/kötelezhetett, hogy saját magadat szívasd meg! Én meg arra várok választ, hogy miért szidod az eszközt, amit te magad választottál a feladathoz?
Ha nem akartál baltával fát vágni mert neked az nem elég jó, akkor miért nem fogtál láncfűrészt már az elején?

________________________________
blog: http://horvathjanos.wordpress.com

De volt, egy ideig el is tűrtem a hülyeségeit, volt mikor sikerült átbeszélni/lebeszélni dolgokról, de volt mikor nem és ebből volt a több. Nem értett semmihez csak beleszólt abba is amiről fogalma nem volt, simán erőszakosan ragaszkodott ahhoz amit nem is ismer. Ez ment egy ideig, aztán másik munkahely után néztem, mert nem vagyok olyan hülye, hogy erre pazaroljam az időmet meg idegileg kikészüljek miatta. :)
________________________________
blog: http://horvathjanos.wordpress.com

Erre is van megoldás, nem hiszem, hogy te vagy az első és egyetlen aki ilyen felépítésű rendszerben dolgozik. Ha nem találsz rá megoldást, az sem a nyelv hibája.
Tőlem meg ne várj megoldást a problémára, nem az én feladatom, hogy elvégezzem helyetted, keress megoldást és oldd meg!

________________________________
blog: http://horvathjanos.wordpress.com

Ember, elolvastad egyáltalán, hogy mit írtam?

A probléma megoldható, kézi munkával, workaroundokkal. (Meg már vagy 2x írtam, hogy megoldottam).

A problémám azzal van, hogy ezzel miért nekem kell szívnom és miért nem képesek a kedves PHP devek megoldani ezt, mikor mindenhol máshol megoldott probléma.

De ugyanilyen az, hogy a CRC32 viselkedése miért platformfüggő? Vagy, hogy a debug_print_backtrace() miért csak és kizárólag közvetlen a standard outputot használja - ezzel lehetetlenné téve, hogy mondjuk az ob_*() függvényekkel használjam? (Megoldás: Exception példányosítása + getTraceAsString(). Broaf.).

Hozhatnék ilyen példákat tömegével, amelyekre van megoldás, csak szükségtelen, felesleges workaround. És kezdem úgy érezni, hogy az igazán nagy probléma nem is ott van, hogy ezek benne vannak a nyelvben, hanem, hogy egyesek úgy gondolják, hogy ez így jól van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

(És ezzel egyúttal erre is válaszolnék.)

Attól még lehet rossz, hogy az a legnépszerűbb. Lehet, hogy nem a minősége miatt népszerű, hanem mert hamarabb/olcsóbban találsz PHP tárhelyet, mint mondjuk ASP.NET-est.

Érdekes, hogy ha mondjuk nagyobb a költségvetés (mondjuk nagyvállalat honlapja/webshopja/akármi), ott egész más az arány.

Sőt, még fejlesztek is PHP-ben, na ezt add össze!

Azóta már számtalanszor bebizonyosodott, hogy hiba volt PHP-ben elkezdeni, nem véletlen, hogy minden háttérfolyamatot cserélünk ki és PHP már lassan csak egy "buta" frontend lesz minden előtt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hiba volt, de nem a PHP hibája, hanem a te tervezési hibád!
Ha elkezdek faházat építeni akkor előre tudom, hogy e célra fejlesztett CNC-t kell használnom eszközként, mert ha normál faipari gépekkel csinálom, akkor ugyan megleszek a munkával, de mivel univerzális eszközöket használtam és nem célszerszámot, ezért a munka is több overhead-el jár, több szopással, több kiegészítőmunkálatokkal, több javítással, és ilyen olyan gépbeállítási időpazarlásokkal. A munka végén én is belátnám, hogy ugyan nagyon jók azok a gépek arra amire valók, de nem a legalkalmasabbak egy kiemelkedően óriási munka, egy húszmilliós gerendaház legyártására. Ez nem a gépparkom hibája lesz hanem az enyém!

________________________________
blog: http://horvathjanos.wordpress.com

Ja értem, szóval akkor "csak egy webshop" (ha jól emlékszem pont te jellemezted így) létrehozására alkalmatlan a PHP. :)

De a teljesség kedvéért: nem azt mondtam, hogy teljesen használhatatlan, hanem azt, hogy egy csomó szopás más nyelvben szimplán nem fordul elő.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Web az marad most már PHP, túl sok munka van benne, hogy azt kidobjuk a kukába. A mögöttes cronok viszont kíméletlenül lecseréljük. Valószínűleg mono lesz mert van egy másik belsős Windowsos fejlesztés, amiből át lehet emelni nem kevés részt. Java volt a másik versenyző.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( atlasz | 2013. 03. 05., k – 00:16 )

Szerintem a legtobb ember (akit erdekel a problema) meg tudja tanulni szovegbol is megerteni a kodot es az esetek nagy reszeben elvan az ilyen szines grafikus megjelenites nelkul is.
Talan inkabb egyszeruen es jol hasznalhato komponensekre volna szukseguk az embereknek, amikbol gyorsan osszedrotozhatjak azt, amire szukseguk van. Pl. GUI eseten ez a Swing ellentetje volna. Nagy es komplex komponensek, amiket egy egyszeru feluleten felkonfigural az ember az elvart feladatra es osszekapcsolja oket. Hasonloan ahoz, ahogy egy shell kodban teszi az ember a kulonbozo programokkal.

GUI elemek és drótozás: ezt a webes világban jelenleg is mindenki megcsinálja magának, egy idő után mindenki rendelkezik pár js-css-html sablonnal, amiket ügyesen berángat ha kellenek. Más irányokról nem tudok nyilatkozni, de ha máshol ez nincs meg, akkor tényleg kéne. El se bírom képzelni, hogy egy app készítésekor tényleg azzal szórakozzak, hogy na, mi hol jelenik meg. Egy jó framework-el, vagy akár csak sablonokkal gyakorlatilag csak a végén rendezek át pár dolgot, és szinte folyamatában is tesztelhető a kód.

Amire ezt is kiválóan lehet majd alkalmazni: tanulás és prototipizálás (akár kis szinten is).

Amire szintén lehet alkalmazni: "kéne ide egy gomb, ami azt csinálja az asztalon, hogy ..." (widget fejlesztés hobbi szinten, vagy akár kisvállalkozásoknak).

Amitől nem félek: optimizálatlan programokkal van teli most is a piac, nem pont ezek a programok fogják majd megborítani ezt se.

Nekem speciel a mobilokra való fejlesztési résznél felcsillant a szemem egy pillanatra, nem titkolom, prototipizálásra használtam már a Google ilyen jellegű szoftverét (inventor vagy i...valami), arra, hogy két gomb legyen a GUI-n, és az küldjön valami jelet egy szervernek, nagyon is elég volt egy ilyen megoldás.

Az az igazság, hogy legtöbbeknek segíthet a belépési küszöböt lentebbre rakni, és segíthet kitalálni, hogy az adott programra tényleg szükség van-e.

( uid_18079 | 2013. 03. 05., k – 10:46 )

Ilyen már van androidra. Androidos appokat lehet létrehozni. Még logikát is.

( Gergely | 2013. 03. 05., k – 13:51 )

Szerintem ez egy kurva jo termek lesz. Nagyon sok mas teruletrol jovo embert ismerek akinek problema a programozas viszont a szakteruletebol adodoan szuksege lenne ra, pl biologus. Nekik egy ilyen nagy segitseg lenne, mondjuk nem feltetlenul fogja oket erdekelni, hogy megy-e minden eszkozon elso korben az biztos. A prototipus gyartasrol nem is beszelve, ahol gyorsan, olcson tudsz egy termeket eloallitani es lemerni, hogy egyaltalan erdemes foglalkozni vele vagy sem.

Mai vilagunkban elegge specializalodtunk minden tudomanyteruleten es szerintem itt az ideje hogy az interdiszciplinaritas uj teret hoditson. Ez folyik le ha jobban szemugyre veszitek a big data buzzword korul is.

Trollok szuklatokoruek meg hat mindig is lesznek... :)
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.