Komentowana treść: Nowy framework do tworzenia aplikacji
23.02.2019 12:09
[#121]
Re: Nowy framework do tworzenia aplikacji
@mccnex, post #106
Obojętnie w jakim kierunku framework miałby pójść dalej, podstawy są wspólne. Nawet gry wykorzystają podstawowe kontrolki GUI chociażby do ustawień, inne typu np. obsługa plików również się przydadzą. A gdyby myśleć o jakimś narzędziu IDE do tego to tym bardziej. Więc na początek tak czy inaczej należy zrobić rzeczy podstawowe.
Mi osobiście podoba się taki pomysł. Coś w czym można wyklikać/zakodować grę 2d to byłaby fajna aplikacja więc czemu nie.
Po zrobieniu podstawowej funkcjonalność, przyjdzie czas na decyzję co dalej. Na tą chwilę chcę się zająć komponentem do edycji tekstu WYSIWYG.
Mi osobiście podoba się taki pomysł. Coś w czym można wyklikać/zakodować grę 2d to byłaby fajna aplikacja więc czemu nie.
Po zrobieniu podstawowej funkcjonalność, przyjdzie czas na decyzję co dalej. Na tą chwilę chcę się zająć komponentem do edycji tekstu WYSIWYG.
23.02.2019 12:29
[#122]
Re: Nowy framework do tworzenia aplikacji
@*y, post #109
Nie zagłębiałem się w API AmigaOS4.x i MorphOS, ale na przykład problem MUI/Reaction nie występuje ponieważ kontrolki API2 nie bazują na nich, więc jedna rzecz z głowy. Z innymi rzeczami może być podobnie, w ostateczności pewne funkcje mogą nic nie robić pod AmigaOS3.1, albo zwracać domyślne wartości. Wtedy program może zachowywać się trochę inaczej, ale nadal poprawnie. Przykładowo powiedzmy, że jest na jakimś amisystemie api do odczytu prędkości wentylatora na procesorze, gdy na innym nie jej ma, to funkcja, która podaje tę wartość zwróci powiedzmy zero, inna możliwość to sprawdzić czy taka funkcja jest dostępna odpytując metadane danej klasy, ale to już trochę więcej zachodu ze strony programisty. Tak więc możliwości są.
23.02.2019 14:20
[#124]
Re: Nowy framework do tworzenia aplikacji
@smith, post #123
Tamat jak widać wywołał dość spore poruszenie na forum... a w przypadku "rozwoju softu pod AOS" to już jest sukces 
Panowie - ostatnio mamy prawdziwy wysyp fajnego HW do naszych Amig. I zapewne bardzo się z tego cieszymy. Dlaczego więc nie próbować "rozruszać" SW ? Dobrowolna kwota miesięcznej wpłaty powiedzmy tych 20 zł tylko przez użytkowników (czy ich cześć) PPA dała by kwotę powiedzmy 10000 zł. Wiem że szału to nie robi z punktu oczekiwań autora ale jeśli umożliwiało by ambitnemu programiście któremu chce się coś robić poświęcenie powiedzmy 3-4 godzin dziennie przy projekcie to myślę że w sensownym okresie czasu (rok ? dwa ?) może powstać coś świeżego i sympatycznego.
No chyba ze lepiej jest przeznaczyć te 20zł na "kolejny hit w Backbone"
Panowie - ostatnio mamy prawdziwy wysyp fajnego HW do naszych Amig. I zapewne bardzo się z tego cieszymy. Dlaczego więc nie próbować "rozruszać" SW ? Dobrowolna kwota miesięcznej wpłaty powiedzmy tych 20 zł tylko przez użytkowników (czy ich cześć) PPA dała by kwotę powiedzmy 10000 zł. Wiem że szału to nie robi z punktu oczekiwań autora ale jeśli umożliwiało by ambitnemu programiście któremu chce się coś robić poświęcenie powiedzmy 3-4 godzin dziennie przy projekcie to myślę że w sensownym okresie czasu (rok ? dwa ?) może powstać coś świeżego i sympatycznego.
No chyba ze lepiej jest przeznaczyć te 20zł na "kolejny hit w Backbone"
23.02.2019 14:30
[#125]
Re: Nowy framework do tworzenia aplikacji
No dobra, popatrzyłem na dokumentację, itd. Skopiowałeś Foundation framework i zrobiłeś własny wariant języka ObjectiveC. Fajnie, ale to nic nowego. Wprowadziłeś chociaż założenie, że stringi są zawsze w Unicode?
23.02.2019 14:42
[#126]
Re: Nowy framework do tworzenia aplikacji
@pisklak, post #124
No właśnie tak! Wolę jednorazowo zapłacić 20PLN za kolejne "cudo" w Backbone niż zapłacić miesięczny abonament za framework obiektowy zbyt ciężki do uciągnięcia dla Amigi klasycznej. Autor crapa z Backbone być może stworzy kolejną, lepszą gierkę dla Amigi. Autor tego framework'a próbuje stworzyć przyjazne, proste, w miarę na czasie środowisko programistyczne. To z wykładnika eliminuje Amigę klasyczną bo ona nie posiada niezbędnych zasobów do uciągnięcia tego wszystkiego. Jeśli inicjatywa wypali zobaczysz w kolejnej inkarnacji tego środowiska elementy, które będą do użycia na UAE i NG a klasyk się nimi udławi. Będzie jak z Arosem 68k. To nie dla mnie.
23.02.2019 15:09
[#127]
Re: Nowy framework do tworzenia aplikacji
@Jacek Piszczek, post #125
Kontenery, string i inne tego typu komponenty są standardem w frameworkach więc nie mówiłbym tutaj o kopiowaniu. C nie ma przestrzeni nazw i przeciążonych funkcji więc nazwy muszą być odpowiednio dobrane, a pewne rzeczy mają swoje standardowe określenia więc po co je zmieniać. Co do ObjectiveC to tak samo można powiedzieć, że BOOPSI, zwłaszcza opakowane makrami, to też jego wersja. Po prostu binarne dynamiczne obiekty, jakoś je trzeba stworzyć. Moje makra nie kłują w oczy, kod wygląda jak w C, a nie jak w ObjectiveC, który jest brzydalem jakby na to nie patrzeć, więc myślę że całkiem fajnie to wyszło.
Co do stringów to wszędzie gdzie jest potrzebny parametr tego typu jest używany AFString*, makro AFS też go tworzy ze zwykłego C stringa, jest to właśnie po to, żeby gdy będzie na to czas przejść bezboleśnie na Unicode.
Co do stringów to wszędzie gdzie jest potrzebny parametr tego typu jest używany AFString*, makro AFS też go tworzy ze zwykłego C stringa, jest to właśnie po to, żeby gdy będzie na to czas przejść bezboleśnie na Unicode.
23.02.2019 15:17
[#128]
Re: Nowy framework do tworzenia aplikacji
@*y, post #126
Przyjmujesz założenia bez podstaw do nich. Mogę Cię zapewnić, że jak dotąd włożyłem całkiem sporo wysiłku aby chodziło to dobrze nawet na wolnych Amigach (a jeszcze trochę się da zrobić) np. wywołania metod wirtualnych są szybsze niż w BOOPSI (czyli MUI, Reaction). Sama budowa kontrolek GUI jest taka aby na wolnych komputerach można było zrobić je jak najlżejsze. Oczywiście animacje będą pewnie już gorzej wyglądać, ale one nie są niezbędne do działania aplikacji. Jeżeli jest np. wyświetlany pasek postępu to obojętnie czy przesuwa się płynnie czy skokowo to aplikacja, która go wyświetla nadal robi to co ma robić. Więc tak, mam A500 też na względzie i na pewno ona też na tym skorzysta.
23.02.2019 15:44
[#129]
Re: Nowy framework do tworzenia aplikacji
@smith, post #128
Pojedyncze kontrolki systemu nie zarżną. Zbuduj jednak z nich poważny program i odpal na maszynie dla AmigaOS3.x (A1200 + FAST). Mówisz, że da radę? Jeżeli ruszy taki amigowy Libre Office Writer, to chylę czoła. Jeśli jednak planujesz swój framework dla "pchełek" to jest on stanowczo za drogi.
23.02.2019 16:22
[#130]
Re: Nowy framework do tworzenia aplikacji
@*y, post #129
A1200 z FASTem ma taką wydajność jaką ma i tego się nie przeskoczy, pozostaje kwestia jak się tą wydajność wykorzysta. API2 schodzi jak najniżej się da, czyli trochę intuition, a reszta graphics, po to aby przechodzić przez jak najmniej warstw więc jak najmniej dociążać komputer samą sobą. Dlatego pociągnie nie tylko pchełki. Popatrz na to jeszcze z innej strony. Ktoś pisze program, ma na niego określoną ilość czasu, musi wykonać w nim moduły A, B i C. W ramach tego czasu jest w stanie je w jakimś stopniu zoptymalizować i przetestować. A teraz sytuacja się zmienia. Używa frameworku, który dostarcza mu A i B. Na optymalizację i testowanie A i B zostało przeznaczone dużo więcej czasu niż on mógł na to przeznaczyć. Jaki mamy wtedy efekt? A i B z frameworku są szybsze od jego A i B, a on ma więcej czasu na C. Mało tego, jeśli ktoś kiedyś jeszcze coś poprawi/przyspieszy w A i B to od razu wpływa to pozytywnie na prędkość/jakość działania całego programu. Więc chyba jednak warto użyć frameworku.
23.02.2019 17:42
[#131]
Re: Nowy framework do tworzenia aplikacji
@smith, post #130
Nie jestem zawodowym programistą więc może jestem w temacie "trochę do tyłu". Jednak z doświadczenia, także programistycznego wiem, że jak coś jest poskładane z uniwersalnych klocków to jest po prostu wolniejsze i większe od kodu robionego pod konkretną maszynę. Duży program poskładany z puzzli nie zmieści się w pamięci klasyka i wydajnościowo go udusi. Chyba, że stworzysz komponent overlay'a, który będzie przerzucał z dysku do pamięci i odwrotnie nieużywane kawałki kodu (moduły). Wtedy kwestia pamięci się rozwiąże, pojawi się natomiast kwestia wydajności.
23.02.2019 18:37
[#132]
Re: Nowy framework do tworzenia aplikacji
@*y, post #131
API2 schodzi jak najniżej się da, czyli trochę intuition, a reszta graphics, po to aby przechodzić przez jak najmniej warstw więc jak najmniej dociążać komputer samą sobą. Dlatego pociągnie nie tylko pchełki.
Czyli tymi "puzzlami" będą funkcje z bibliotek systemowych. To chyba ok?
Ostatnia aktualizacja: 23.02.2019 18:41:17 przez ede
23.02.2019 18:38
[#133]
Re: Nowy framework do tworzenia aplikacji
@*y, post #131
To wszystko zależy jakie i jak się ich użyje, no i w którym punkcie na osi czasu rozwoju projektu się jest. Co do wielkości można się zgodzić, przeważnie komponenty robią więcej niż potrzebujemy ponieważ są z założenia uniwersalne, pojawia się jednak jedno ale. Gdy z biegiem czasu chcemy dorobić do naszej aplikacji kolejne funkcjonalności, może się zdarzyć że zamiast zrobić to jak należy dodamy kilka ifów, bo akurat nie mamy czasu, albo nam się nie chce. Za jakiś czas kilka następnych itd. W efekcie może nasz kod zacząć zajmować więcej miejsca niż ten z gotowego komponentu.
Jeśli chodzi o prędkość to zależy ile pracy, w który kod było włożone i sprawa jest jeszcze mniej jednoznaczna.
Ale nawet jeżeli program używający frameworku byłby większy i trochę wolniejszy niż napisany w całości od początku, to musisz uwzględnić przyczyny dla których się używa gotowych rozwiązań. Dzięki nim można napisać program dużo szybciej. Czasem tydzień zamiast pół roku. To może być powód dla którego w ogóle ktoś zdecyduje się coś stworzyć. Myślę więc, że lepiej mieć jakiś program, nawet jeśli okazałby się trochę większy i trochę wolniejszy, niż nie mieć go wcale.
Jeśli chodzi o prędkość to zależy ile pracy, w który kod było włożone i sprawa jest jeszcze mniej jednoznaczna.
Ale nawet jeżeli program używający frameworku byłby większy i trochę wolniejszy niż napisany w całości od początku, to musisz uwzględnić przyczyny dla których się używa gotowych rozwiązań. Dzięki nim można napisać program dużo szybciej. Czasem tydzień zamiast pół roku. To może być powód dla którego w ogóle ktoś zdecyduje się coś stworzyć. Myślę więc, że lepiej mieć jakiś program, nawet jeśli okazałby się trochę większy i trochę wolniejszy, niż nie mieć go wcale.
23.02.2019 18:44
[#134]
Re: Nowy framework do tworzenia aplikacji
@*y, post #131
Powiedzmy sobie szczerze.... takie MUI to na "gołej" A500 czy A1200 też się "za bardzo nie mieści". Ale już na 030 z odrobiną fastu jest całkiem znośnie. Podejrzewam że w tym przypadku może być podobna wydajność. Uważam że taki framework może na słabszych konfiguracjach mieć po prostu wszystkie fajerwerki powyłączane, a na lepszych można "zaszaleć" .
PS. Przyznam szczerze że ostatnio zainspirowany tą dyskusją trochę (bardzo nawet - ot odpaliłem na UAE i poklikałem w demka, oraz troszkę dokumentacji poczytałem) Feelina. Pierwsze wrażenie całkiem pozytywne. Pozytywne wrażenie robią też początki API2.
PS. Przyznam szczerze że ostatnio zainspirowany tą dyskusją trochę (bardzo nawet - ot odpaliłem na UAE i poklikałem w demka, oraz troszkę dokumentacji poczytałem) Feelina. Pierwsze wrażenie całkiem pozytywne. Pozytywne wrażenie robią też początki API2.
23.02.2019 22:34
[#135]
Re: Nowy framework do tworzenia aplikacji
@*y, post #131
Jednak z doświadczenia, także programistycznego wiem, że jak coś jest poskładane z uniwersalnych klocków to jest po prostu wolniejsze i większe od kodu robionego pod konkretną maszynę.
"kod" to assembler, więc to inna bajka. Pisząc program w C czy to dla klasyka czy NG, można odkrywać koło na nowo, albo używać gotowych rozwiązań, i chyba właśnie o to chodzi żeby używać np. gotowe Datatypes.
A propo Backbone - to jest game maker napisany w Amosie, api2 w C, więc dla mnie wybór w co zainwestować jest oczywisty, a czas pokaże :)
24.02.2019 00:08
[#136]
Re: Nowy framework do tworzenia aplikacji
@*y, post #131
Jednak z doświadczenia, także programistycznego wiem, że jak coś jest poskładane z uniwersalnych klocków to jest po prostu wolniejsze i większe od kodu robionego pod konkretną maszynę.
Tak, to szczera prawda. Widać to doskonale na przykładzie bibliotek graphics i intuition. Intuition udostępnia wysokopoziomowe funkcje rysujące (np. rysowanie ramek, obrazków bądź tekstu), które są łatwiejsze w obsłudze, ale jednak wydajnościowo ustępują funkcjom niskopoziomowym z biblioteki graphics. Trzeba zatem stosować narzędzia adekwatne do wymagań i stawianego celu.
W przypadku BOOPSI to od autora klasy zależy z jakiego rozwiązania skorzysta. Ma on do dyspozycji strukturę RastPort i może robić dowolne operacje na niej rysujące, czy to będą funkcje intuition, graphics lub jakieś własne, np. do animacji.
Można to uogólnić w ten sposób, że uniwersalne, wysokopoziomowe rozwiązania będą zawsze mniej wydajne niż niskopoziomowe, specjalistyczne. Jednak atutem jest szybsze osiągnięcie celu. Trzeba dobrze rozważyć poszczególne opcje.
W przypadku opisywanego frameworka nie sądzę jednak by dało się pogodzić takie wymagania jak Amiga 500 + OS2.0 oraz AmigaOne X5000 + OS4.1. Amiga 500 z chipsetem OCS wymaga zupełnie innego podejścia do rysowania i animacji. OCS jest wysoce wydajny, jak korzysta się z niego w odpowiedni sposób, tzn. rysuje się w synchronizacji z wiązką obrazu. Copper i Blitter zostały przeznaczone do wysokich rozdzielczości i prędkości, ale nie obsługuje się ich tak samo jak RTG. Pomylenie tych dwóch technologii stało się przyczyną niesłusznych zarzutów pod adresem rozwiązań graficznych stosowanych w Amigach.
Wielokrotnie już wskazywałem, że dużo oprogramowania może działać wydajnie bez potrzeby kart PowerPC G5, wydajnych kart graficznych itp., które są sercem maszyn pod systemy NG. Ja sam korzystam z wielu takich programów na mojej Amidze 1200. Ciężkie oprogramowanie, szczególnie porty stały się kulą u nogi Amig klasycznych i spowodowały migrację osób w stronę rozwiązań NG. Nie pisałbym o tym, gdyby dotyczyło to tylko tego. Ten problem nie ustąpił w żadnym momencie, a użytkownicy NG są wciąż zmuszeni do zamiany sprzętu na nowy, kosztujący nierzadko niebagatelne pieniądze.
Rozumiem, jak ktoś może sobie na to pozwolić. Ale ja, ze względów głównie finansowych nie mogę, dlatego staram się rozwijać oprogramowanie dla Amigi 1200, bo to jest Amiga która przeszła próbę czasu i nadal należy do najatrakcyjniejszych Amig zarówno ze względu na cenę, jak i możliwości jakie oferuje.
Nie wiem jak koledzy, ale ja ubolewam że użytkownicy NG nierzadko są zmuszeni do korzystania z niekompletnego lub wadliwego oprogramowania. Sam odczułem to na własnej skórze korzystając z komputera Sam440ep. Nawet taki sztandarowy program, jak PageStream ma już swoje lata i nie ma wersji natywnej dla PowerPC.
Nie podoba mi się też to, że użytkownicy NG upatrują wybawienie w postaci przejścia na inną platformę i technologię zapominając o samym systemie Amiga OS i jego walorach. Kto wie, może mają rację - i rzeczywiście takie przejście poprawi dla nich sytuację m.in. na polu oprogramowania. Ja jednak odbieram to jako kolejną ucieczkę z tonącego okrętu i ucieczkę od problemów. Ileż okrętów jeszcze musi zatonąć?
Mam nadzieję, że to nowe API uaktywni programistów, ale czy aby na pewno spełni swoją rolę jeśli chodzi o przyśpieszenie procesu powstawania nowych programów? Pewnie czas pokaże. Zapewne wszystko zależy od tego na ile użytkownikom NG naprawdę zależy na rozwoju i istnieniu platformy Amiga NG. Bo z moich obserwacji wynika, że jest to kilka procent ogółu użytkowników NG.
Ja, jak wielokrotnie podkreślałem, podchodzę do tego w taki sposób: po prostu lubię Amigę, Amiga OS, czasy i rozwiązania Commodore oraz Escom, polskie czasopisma, gry i inne rzeczy. Tak jak większość klasykowców. Nie zależy mi na rozwoju NG, bo, oprócz kilku uaktualnień Amiga OS4.1 oraz MorphOSa to nie widzę by tam się coś rozwijało. Za to Amiga klasyczna jest po prostu jak zawsze na topie.
Tak dużo rzeczy jest jeszcze do odkrycia w Amidze, która ma bogatą historię i duży dorobek. A jeśli ktoś uważa to za archeologię zaś sam korzysta już z nowoczesnych rozwiązań - powinien pomyśleć, czy rzeczywiście wspiera tym Amigę - chociaż taką, jaką lubi i jak ją rozumie.Bo przejście na system BSD, zaakceptowanie innych rozwiązań to według mnie byłaby porażka Amiga OS. No, ale użytkownicy NG mogą mieć swoje zdanie w tej sprawie. Uzewnętrznia to jednak słabość tych mocnych, wydawałoby się, rozwiązań NG i poniekąd pokazuje to, że w wielu moich opiniach o obecnej sytuacji tkwi ziarno prawdy.
24.02.2019 16:01
[#138]
Re: Nowy framework do tworzenia aplikacji
@R-Tea, post #137
Ale czemu bijesz do mnie? Chyba przytoczyłem "kilka" argumentów, które powinny otrzeźwić szarego klasykowca. Mnie rozwój NG nie interesuje zupełnie, więc to chyba normalne, że wspierał tego framework'a nie mam ochoty. Z mojej strony więc nie można liczyć na żadną pomoc. Już chyba jaśniej nie można...
24.02.2019 23:24
[#142]
Re: Nowy framework do tworzenia aplikacji
@Hexmage960, post #136
Tak, to szczera prawda. Widać to doskonale na przykładzie bibliotek graphics i intuition. Intuition udostępnia wysokopoziomowe funkcje rysujące (np. rysowanie ramek, obrazków bądź tekstu), które są łatwiejsze w obsłudze, ale jednak wydajnościowo ustępują funkcjom niskopoziomowym z biblioteki graphics. Trzeba zatem stosować narzędzia adekwatne do wymagań i stawianego celu.
Jak pisałem to wszystko zależy. Głównie od tego ile pracy zostało włożone w jeden i drugi kod. To że coś jest pisane konkretnie pod jakiś program w ogóle nie ma wpływu. Najważniejsza jest złożoność algorytmu, na drugim miejscu jego implementacja. Co do wielkości podobnie. Można napisać coś tak rozwlekłego, że ogólny komponent, robiący więcej będzie mniejszy. Więc nie ma co generalizować. A porównywanie Intuition i Graphics, to trochę porównywanie jabłek i pomarańcz, bo one robią różne rzeczy, a prostokąt narysowany na bitmapie to jeszcze nie guzik w oknie.
Można to uogólnić w ten sposób, że uniwersalne, wysokopoziomowe rozwiązania będą zawsze mniej wydajne niż niskopoziomowe, specjalistyczne. Jednak atutem jest szybsze osiągnięcie celu. Trzeba dobrze rozważyć poszczególne opcje.
Uniwersalne/specjalizowane i wysokopoziomowe/niskopoziomowe to dwie różne klasyfikacje.
W przypadku opisywanego frameworka nie sądzę jednak by dało się pogodzić takie wymagania jak Amiga 500 + OS2.0 oraz AmigaOne X5000 + OS4.1. Amiga 500 z chipsetem OCS wymaga zupełnie innego podejścia do rysowania i animacji. OCS jest wysoce wydajny, jak korzysta się z niego w odpowiedni sposób, tzn. rysuje się w synchronizacji z wiązką obrazu. Copper i Blitter zostały przeznaczone do wysokich rozdzielczości i prędkości, ale nie obsługuje się ich tak samo jak RTG. Pomylenie tych dwóch technologii stało się przyczyną niesłusznych zarzutów pod adresem rozwiązań graficznych stosowanych w Amigach.
A czy funkcje rysujące w API2 muszą być takie same w wersji dla AmigaOS3.x i dla innych systemów? Nie muszą
Jak pisałem to wszystko zależy. Głównie od tego ile pracy zostało włożone w jeden i drugi kod. To że coś jest pisane konkretnie pod jakiś program w ogóle nie ma wpływu. Najważniejsza jest złożoność algorytmu, na drugim miejscu jego implementacja. Co do wielkości podobnie. Można napisać coś tak rozwlekłego, że ogólny komponent, robiący więcej będzie mniejszy. Więc nie ma co generalizować. A porównywanie Intuition i Graphics, to trochę porównywanie jabłek i pomarańcz, bo one robią różne rzeczy, a prostokąt narysowany na bitmapie to jeszcze nie guzik w oknie.
Można to uogólnić w ten sposób, że uniwersalne, wysokopoziomowe rozwiązania będą zawsze mniej wydajne niż niskopoziomowe, specjalistyczne. Jednak atutem jest szybsze osiągnięcie celu. Trzeba dobrze rozważyć poszczególne opcje.
Uniwersalne/specjalizowane i wysokopoziomowe/niskopoziomowe to dwie różne klasyfikacje.
W przypadku opisywanego frameworka nie sądzę jednak by dało się pogodzić takie wymagania jak Amiga 500 + OS2.0 oraz AmigaOne X5000 + OS4.1. Amiga 500 z chipsetem OCS wymaga zupełnie innego podejścia do rysowania i animacji. OCS jest wysoce wydajny, jak korzysta się z niego w odpowiedni sposób, tzn. rysuje się w synchronizacji z wiązką obrazu. Copper i Blitter zostały przeznaczone do wysokich rozdzielczości i prędkości, ale nie obsługuje się ich tak samo jak RTG. Pomylenie tych dwóch technologii stało się przyczyną niesłusznych zarzutów pod adresem rozwiązań graficznych stosowanych w Amigach.
A czy funkcje rysujące w API2 muszą być takie same w wersji dla AmigaOS3.x i dla innych systemów? Nie muszą
24.02.2019 23:41
[#143]
Re: Nowy framework do tworzenia aplikacji
@*y, post #138
Napiszę to jeszcze raz, Ty nie wierzysz, ale żeby inni widzieli. API2 jest pisane także z myślą o klasyku od samego początku i zrobię wszystko co się da aby chodziło na nim jak najlepiej. Celem jest aby każda platforma skorzystała. Jeśli byś zadał sobie trud i uruchomił dema to zobaczyłbyś, że są skompilowane na mc68k i AmigaOS3.1. Celem API2 jest ułatwianie programowania bez wnoszenia dodatkowego narzutu, ma szanse chodzić lepiej niż MUI i Reaction. Więc jeżeli program ze względu na funkcje, które realizuje będzie działać na klasyku, to napisany przy użyciu API2 będzie to robił nie wolniej niż napisany bez jego użycia, a do tego da się go napisać szybciej.
25.02.2019 00:04
[#144]
Re: Nowy framework do tworzenia aplikacji
Najlepiej pozwolić wielu programistom rozwijać ten projekt jako open source.
Wtedy rozwój pójdzie szybciej i bez oczekiwanych składek da radę.
Wtedy rozwój pójdzie szybciej i bez oczekiwanych składek da radę.
25.02.2019 12:35
[#147]
Re: Nowy framework do tworzenia aplikacji
Wesprę, a jak będą efekty będę wspierał dalej.
Próbuję coś pisać pod klasyka i niestety często budzi to frustrację właśnie z powodu nowoczesnych przyzwyczajeń. Mój program rodzi się powoli i z mniejszymi lub większymi problemami :) I nie jest to zarzut dla klasyka, tak się po prostu pisało 20 lat temu, i taki AmigaOS został zaprojektowany 30 lat temu.
Ale człowiek wychowany na C# czy Javie nawet mimo szczerych chęci będzie miał problem, bo to jest jednak zupełnie inne programowanie. I ciekawe ilu dzisiejszych programistów zraża się próbując coś napisać pod AmigaOS, i sobie odpuszcza bo im szkoda czasu na obchodzenie problemu np braku jakiejś normalnej kolekcji. O kodowaniu w asemblerze nie wspominam, bo na to to już trzeba poświęcić się na full time.
Ale gdyby pojawiło się jakieś spójne API zawierające pasujące do siebie elementy backend/frontend, to kto wie czy to faktycznie nie pomogłoby na marazm software'owy, i być może większa liczba programistów przebrnęłaby do szczęśliwego końca polegającego na wypuszczeniu w świat nowego softu.
Próbuję coś pisać pod klasyka i niestety często budzi to frustrację właśnie z powodu nowoczesnych przyzwyczajeń. Mój program rodzi się powoli i z mniejszymi lub większymi problemami :) I nie jest to zarzut dla klasyka, tak się po prostu pisało 20 lat temu, i taki AmigaOS został zaprojektowany 30 lat temu.
Ale człowiek wychowany na C# czy Javie nawet mimo szczerych chęci będzie miał problem, bo to jest jednak zupełnie inne programowanie. I ciekawe ilu dzisiejszych programistów zraża się próbując coś napisać pod AmigaOS, i sobie odpuszcza bo im szkoda czasu na obchodzenie problemu np braku jakiejś normalnej kolekcji. O kodowaniu w asemblerze nie wspominam, bo na to to już trzeba poświęcić się na full time.
Ale gdyby pojawiło się jakieś spójne API zawierające pasujące do siebie elementy backend/frontend, to kto wie czy to faktycznie nie pomogłoby na marazm software'owy, i być może większa liczba programistów przebrnęłaby do szczęśliwego końca polegającego na wypuszczeniu w świat nowego softu.
