"Sylwester Łazar" <i...@a...pl> wrote in message
news:lhs2p0$n77$1@mx1.internetia.pl...
> Nawigacja w samochodzie - bez ładowania zacznie migać
> na czerwono już po godzinie jazdy.
> Ma ktoś taką, co po naładowaniu działa przez tydzień?
> I to są fakty, a reszta to banialuki.

Fakty są takie, że nawigacja napisana w całości w asemblerze
po pierwsze nie pracowałaby na tej samej baterii 24*7 razy
dłużej a po drugie kosztowałaby tyle że mało kto byłby nią
zainteresowany...

Już to widzę jak taki Garmin czy innny TomTom co dziś
zleca pisanie softu w Indiach programistom C++ każe
pisać ten sam kod w asemblerze aby mniej prądu pobierał...
Ech... poza tym - w takich urządzeniach najwięcej prądu bierze
wyświetlacz i jego podświetlenie - procesor idzie w uśpienie
dosyć często i nie jest głównym konsumentem prądu z baterii.

do góry

W dniu 2014-04-06 18:14, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 14:39, AlexY pisze:
> [..]
>>> Nie, nie tylko, ASM, pascal, basic. Tych potrzebowałem to się nauczyłem,
>>> zrobiłem podejście do C i C++ ale chyba już za stary jestem bo mi się
>>> odechciało, może to kwestia braku odpowiedniej literatury napisanej w
>>> sposób dla mnie zrozumiały.
>>
>> No to chyba młodszy jesteś ode mnie bo ja uczyłem się Algolu i Fortranu.
>> DO nauki c wystarczył mi Kernighan Ritchie oraz kieszonkowy leksykon c z
>> serii O'Reilly.
>
> Nie będę się licytował, angielski mam słaby, nie programuję zawodowo i
> nawet bym nie chciał bo to wypala mózg :)

Nic nie pisałem, że Kernighana czytałem w oryginale. Jest polski
przekład. Jest sporo podręczników do c, tłumaczonych z angielskiego lub
napisanych przez polskich autorów.


> [..]
>>> Nikt nigdy nie wmówi mi że asm jest łatwy,
>>
>> Nie piszę, że łatwy tylko, że większe ma się szanse na to, że program
>> będzie wystarczająco mały i wystarczająco szybki aby zmieścić się w
>> osmiobitowcu i maksymalnie wykorzystać jego słabą wydajność. Czyli
>> ciężką pracą kodera, bohatersko zwalcza się problemy wynikające ze
>> słabej architektury.
>
> Źle do tego podchodzisz, rozpoczynając projekt sprawdzasz który sprzęt
> spełni wymagania i na nim dłubiesz, dłubanie na siłę w zbyt słabym
> sprzęcie jest skazane na porażkę.

Ja tak właśnie nie podchodzę. Ale wydaje mi się że ci co się trzymają
asemblera niestety są przez to często zmuszeni do pracy z prockami w
których ledwo się mieszczą.

>>> jego podstawowa zaleta to
>>> wiedza co w danym momencie się dzieje z każdym bitem, całkowita kontrola
>>> sprzętu,
>>
>> Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.
>
> Ogarniasz go na bieżąco podczas pisania, do tej pory nie miałem z tym
> problemu.

Zazwyczaj operując w ramach jednej rodziny. Przejście na coś całkiem
innego boli. Sam przechodziłem z 51 na AVR i szybko stwierdziłem, ze
wgryzanie się w pisanie w asm wymaga ode mnie dużo wysiłku. Po jednym
małym projekcie wolałem się nauczyć c i kilka projektów zrobiłem w
AVR-gcc. Przejście z c na AVR do c na ARM było już znacznie łatwiejsze.
Podejrzewam, że ci co upierają się przy asm, z oporami sięgają po
bardziej złożone architektury twierdząc, że to co mają w zupełności im
wystarcza.

>>> zawsze, wszystkie procedury bez skrępowania mogę okroić z
>>> funkcji których nie użyję, nie wiem czy tak samo można grzebać w
>>> bibliotekach C. np obsługa LCD HD44780 wyciąć obsługę 8bitowej
>>> transmisji i odczyt stanu wyświetlacza.
>>
>> Możesz to zrobić. Jeśli biblioteka ma dużo kodu, a wykorzystujesz tylko
>> małą część to możesz wyciąć te funkcje, wkleić wprost do swojego kodu
>> albo zapisać jako inną bibliotekę. Tu ograniczeniem może być licencja.
>> Często się korzysta z dorobku innych zawartego w domenie publicznej.
>> Dołączenie czyjegoś kodu np. na GPL wprost do twojego kodu powodowałoby
>> wymóg opublikowania twojego kodu. Często jest jednak tak, że licencja
>> zezwala na używanie zamkniętego kodu twojego własnego programu, a
>> publikować trzeba jedynie zmiany w środowisku jak funkcje biblioteczne
>> czy sterowniki. Wtedy lepiej zmianę jakiejś biblioteki zapisać jako nową
>> bibliotekę i ewentualnie opublikować w razie potrzeby.
>
> Licencja... no właśnie...

Twój wybór. Możesz korzystać z pracy społeczności na zdefiniowanych
przez nią warunkach albo pisać wszystko sam. Naprawdę każdy musi sam
wymyślać stos TCP, albo obsługę HD44780?


>>> Nikogo nie zamierzam przekonać do swoich racji wiem że rynek wymusił
>>> pisanie szybko bo na chlebek nie zarobisz, ale czy to jest rzeczywiście
>>> dobre?
>>
>> Czy pisanie w c pod linuksa czy systemy BSD jest twoim zdaniem
>> niewłaściwe, bo nie panuje się nad efektem kompilacji? Superkomputery,
>> routery, duża część serwerów internetowych, systemy dowodzenia i
>> prowadzenia ognia. Lepiej i bezpieczniej byłoby gdyby to wszystko pisać
>> w asemblerze?
>
> Tu jest sedno sprawy, uC to ściśle określony sprzęt, system operacyjny
> ma działać na całej rodzinie sprzętu, ponadto poziom komplikacji jednak
> przewyższa atmelkowe miganie diodką, na uC program napiszesz, produkt
> sprzedasz i możesz o nim zapomnieć,

Tylko po co w takim razie argumentacja, że pisanie w c jest
niebezpieczne z powodu błędów kompilatora czy ogólnie mówiąc szybkie
tanie i kiepskie? Skoro kod skompilowany z c jest poprawny i stabilny w
routerach czy w serwerach to czemu miałby być niepoprawny w przypadku
atmelkowego migania LEDem?

> systemy operacyjne co rusz się
> aktualizuje, co w przypadku asm jest szczególnie ciężkie. To wymusza
> użycie języka wysokiego poziomu, moje "ale" jest co do jego wyboru.

Jakoś nie robią tego na Basicu. Widocznie c jest do tego lepszy.


--
pozdrawiam
MD

do góry

W dniu 2014-04-06 19:18, Mario pisze:

> W ramach licencji możesz kompilować i programować do 256 kB kodu
> wynikowego. Na poczatek warto bo te małe LPC ( 8xx, 11xx i 13xx) mają
> tylko SWD nie mają pełnego JTAGA. LPCXPresso niestety nie jest
> kompatybilne z OpenOCD ( chętnie stosowane środowisko do programowania i
> debugowania - dające się zintegrować z toolchainem gcc + Eclipse)

Miałem na myśli programowanie procka (zapis do pamięci flash) przez
JTAG a nie programowanie w ogóle :)

--
pozdrawiam
MD

do góry

>
> Nie pracuję z zastosowaniami bateryjnymi ale tu znalazłem takiego
> co w stanie uśpienia przy działającym RTC bierze tylko 0,9uA:
>
http://www.st.com/web/en/resource/technical/document
/datasheet/CD00277537.pdf
>
> To tylko jeden przykład - ARMów różnych jest od groma i trochę,
> każdy szanujący się producent ma coś z tym rdzeniem na pokładzie.
>
> ARM to dziś praktycznie standard energicznie zastępujący dawne
> standardy (8051). Nawet firmy które wciąż żyją z rdzeni 8051 na
> ARMa się przesiadają dosyć intensywnie. Tu taki przyklad:
> http://www.silabs.com/products/mcu/lowpower/pages/32
-bit-microcontroller-
technology.aspx
> Sami używaliśmy ich klonów 8051, teraz zachęcają nas do przesiadki na ARM.

Pewnie ARM jest lepszy od innych, może nawet najleszy.

Ale mnie to nie bardzo rusza; mi jest potrzebne coś co łyknie skompilowany
kod w jęz C i będzie działało, może być 8,16 czy też 32 bitów; co mnie to
interesuje, niech kompilator się tym martwi.
Na chwilę obecną wystarcza mi coś co ma 2XUART, SPI, 64kB ROM i kilka KB.
Prawdę mówiąc jeśli dzisiaj byłby popularny HD64180 (rozbudowany klon Z-80)
to bym go użył.

Kiedyś się zabierałem za ARM ale nie było takiego prostego programatora jak
do PIC czy też AVR (16zł na allegro) żeby można coś popróbować i szybko
zaprojektować PCB do finalnego wyrobu.

jp

do góry

Użytkownik Pszemol napisał:
> "AlexY" <a...@i...pl> wrote in message
[..]
>> 1. Chcę wiedzieć co program robi a nie analizować i poprawiać błędy
>> kompilatora, zwłaszcza że co kompilator to inaczej program złożony.
>
> Jakie błędy kompilatora chcesz poprawiać?? To jakieś mity.

Odpisałem w poście do Mario

>> 2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
>> wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
>> przejrzysty, nie można było go rozbudować?
>
> Zostaw na chwilę C++, bo to trochę inna bajka, rzeczywiście, ale C,
> stare dobre C, to właściwie asembler jest. To nie jest język wysokiego
> poziomu. Jest właśnie bardzo krytykowany za "bliskość sprzętu".

Tak też mi to przedstawiono, kłopot w tym że mam problem z akceptacją
rzeczy nielogicznych, z tego powodu np liczby urojone w technikum zdałem
ale nigdy ich nie zrozumiem, oraz nigdy nie będę politykiem.

> Poza specyficznymi przypadkami pisanie dziś w asemblerze to jakieś
> hobby tylko, hardcore zupełnie niepraktyczny.
>
> C/C++ to nie jest "sieczka" do wyrywania kasy - miliony programistów
> go rozumie i używa na codzień. I wcale nie są geniuszami, więc może

Bo muszą

> nie dołuj się i po prostu poczytaj trochę podstaw od C a przekonasz się
> że trochę wprawy i poradzisz sobie. Dużo Ci to pracy zaoszczędzi.

Poleć jakąś książkę/kurs dla starego assemblerowca, do tej pory nikt nie
dał mi wędki która idealnie leży mi w rękach :)

[..]
> Nie bardzo więc widzę gdzie Ty widzisz trudność że w AVR zrobisz
> płytkę samemu a do ARMa musisz mieć jakiegoś gotowca...

Może to jakieś zabobony, ARM to dla mnie procesory wydajności średniej
klasy PC, wysokie zegary, masa nóżek a najlepiej BGA, zwyczajnie nie na
moje potrzeby, być może faktycznie cenowo to jest na poziomie 89C2051
ale to tak jakbym do pracy dojeżdżał limuzyną z szoferem i obstawą 6
ochroniarzy.

>> 4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
>> zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora. Załamka
>> polega na tym że w imię przyśpieszenia programowania poświęca się
>> jakość ale to niestety normalne w obecnych czasach, program napisany
>> ze 3 razy szybciej wychodzi 2 razy większy i 5 razy wolniejszy, a do
>> tego mimo że napisany prawidłowo zawiera błędy kompilatora, znane i
>> nieznane.
>
> Te Twoje mityczne "błędy kompilatora" to chyba błędy programisty
> piszącego nieumiejętnie w C... Na codzień piszę programy w C i C++
> i z błędami kompilatorów nie mam do czynienia wcale.

Błędy mogą objawiać się np przycięciem się programu w jakiejś pętli z
której sam wyjdzie, tyle że zdecydowanie za dużo czasu mu to zajmie,
takich rzeczy nie wyłapiesz jeśli nie robisz analizy asm.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

> > Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
co
> > stworzył, a to w sumie tak jakbyś od razu w asm pisał.
Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
Obok masz przykład.
Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
mikrokontrolera,
na który w życiu nie napisałem nawet linijki.
A ja nie jestem nadczłowiekiem.

> Są dwie możliwości błędów kompilatora: błąd ujawnia się w postaci
> błędnie działającego kodu wynikowego (takie wyłapiesz) lub nie
> ujawnia się w postaci błędnie działającego kodu wynikowego...
> Tych drugich nie ma potrzeby wyłapywać ani się nimi przejmować.
Tak samo jak dziurą w bucie. Przecież jakoś kuśtykasz.

> Obawiam się, że sztucznie demonizujesz coś, czego nie znasz..
> Uważaj, bo strach przed nieznanym ma wielkie oczy ! :-)
To prawda.
Faktem jest, że niemal jedyna w Twoich postach, ale ważna.
Nie ma się co bać C.
Nie musisz nic czytać, ani po polsku, ani po angielsku.
Nauką jest Twój kompilator. Często darmowy lub w promocji czasowej po
zalogowaniu.
Przykłady w liczbie 3+ masz w katalogu EXAMPLES.
Otwierasz projekt, kompilujesz i otwierasz plik *.lst
Tam masz pięknie rozrysowane:
instrukcja w C
i 10-20 linijek kodu w czystym ASM, który znasz i rozumiesz.
Jak widzisz, że za dużo, to zostaw sobie:
void main() {
ALMAKOTA =1;
}
i popatrz na Lambadę ;-)

Jak zaczniesz czytać książki, to może się okazać, że dowiesz się
jakie są "dobre zwyczaje".
Dobre zwyczaje są dobre, jeśli są dobre.
Cały kod w C jest i tak zamieniany na kod maszynowy,
gdzie BASICowy rozkaz GOTO jest najważniejszy.

> i na innych użytkownikach drogi. Owszem, jadąc rowerem (asembler)
> pojedziesz najkrótszą drogą do celu, krótszą niż autobusem (C/C++)
> ale niekoniecznie najszybszą... A wypadki zdarzają się i busom i rowerom.
Albo odwrotnie.
Lecąc F16 (ASM) będziesz szybciej niż drezyną (C) u celu.
Na dwoje babka wróżyła.
Jeśli operujesz z rozdzielczością 20 ns, to rób sobie w C i szukaj procków,
co spełnią Twoje
założenia i tańczą Lambadę (R)Alex od wtorku do niedzieli.

S.

do góry

W dniu 2014-04-06 18:55, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 14:28, AlexY pisze:
> [..]
>>> 2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
>>> wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
>>> przejrzysty, nie można było go rozbudować?
>>
>> Uważasz, że żeby nauczyć się c to trzeba się odpłatnie szkolić u
>> specjalistów? No to może w tym jest twój problem. Ja po nastu latach
> [..]
>
> Wszystkiego idzie się samemu nauczyć, ja na razie jakoś nie mam
> motywacji, a jest ona mi niezbędna po pierwszych podejściach do C

Tak jak pisałem dla mnie wystarczającą motywacją było przejście z asm na
51 do asm na AVR.
>
>>> 4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
>>> zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora.
>>
>> Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od
>> błędów własnych?
>
> Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
> co stworzył, a to w sumie tak jakbyś od razu w asm pisał.


No ale na błędy kompilacji narzekają chyba tylko ci co nie kompilują.
Chyba to jest dla nich odpowiednik takich niedostępnych winogron które
zapewne i tak są kwaśne.

>>> Załamka
>>> polega na tym że w imię przyśpieszenia programowania poświęca się jakość
>>> ale to niestety normalne w obecnych czasach, program napisany ze 3 razy
>>> szybciej wychodzi 2 razy większy i 5 razy wolniejszy,
>>
>> I wrzuca się go na 10 razy szybki procek. W efekcie czas realizacji
>> zadania jest mniejszy, koszt zarazem też niższe, a wydajność procka wraz
>> z oprogramowania wyższa.
>
> Właśnie, i ten procek zamiast zrobić co trzeba to tańczy lambadę nagraną
> przez kompilator, dlatego musi być 10x szybszy.

Dostajesz kod np 1.6 wolniejszy niż byś go napisał sam w asm a
uruchamiasz go na 10 razy szybszym procku. Nie opłaca się? W dodatku
czas przesiadki programisty na ten 10 razy szybszy procek jest też
wielokrotnie szybszy w przypadku c niż asm.

>>> a do tego mimo że
>>> napisany prawidłowo zawiera błędy kompilatora, znane i nieznane.
>>
>> Z błędami kompilatora jest tak jak z błędami w architekturze procka. Są
>> znane i nieznane. Jak masz pecha to możesz na nie trafić.
>> Jak siedzisz w temacie i korzystasz z wiedzy zawartej w dużej
>> społeczności masz duże szanse dowiedzieć się o tych błędach i ich
>> unikać. A największe społeczności są teraz zgromadzone wokół ARMów i gcc.
>
> Co do błędów kompilatorów nie podam konkretów bo ich nie mam, co jakiś
> czas gdzieś trafie na jakieś info że coś źle z kompilatora wychodzi ale
> nie kolekcjonuje tego, mam zakodowane że przy kompilatorach mój program
> z moimi błędami jest nakładany na cudzy program (kompilacja) z cudzymi
> błędami, tak jak piszesz trzeba być na bieżąco z danym kompilatorem aby
> znać i omijać jego bolączki. Przy ASMie trzeba być na bieżąco jedynie z
> erratą procka.

Tylko, że z błędami spowodowanymi przez siebie programista walczy co
chwila, a błąd kompilatora masz szansę spotkać raz na dziesięć lat. No
chyba, że używasz ne opartych na gcc, komercyjnych kompilatorów dla
niezbyt popularnych architektur.

> Przypomniało mi się coś:
> http://bash.org.pl/4845689/
> <Lukasz> w C++ o błędach mówi nam kompilator
> <Lukasz> w PHP klient

No ale to jest o błędach programisty :)



--
pozdrawiam
MD

do góry

> Dostajesz kod np 1.6 wolniejszy niż byś go napisał sam w asm a
> uruchamiasz go na 10 razy szybszym procku. Nie opłaca się? W dodatku
Możesz podać jakieś obliczenia?
Nie możesz, bo musisz napisać w ASM i w C,
a potem porównać, a Ty tego nie robisz.
1,6x wolniejszy kod w C vs, ASM dla TEGO samego procka, to kłamstwo,
które próbujesz przeforsować.
Nie uda Ci się.
Z moich obliczeń częściej wynika dokładnie co napisałeś, ale bez kropki,
czyli 16x.
I dlatego musisz wybrać coś 10x szybszego.
Dopóki nie udowodnisz - nie masz prawa pokazywać mnożników.
Możesz podać jedynie link do RZETELNYCH analiz.
S.

do góry

W dniu 2014-04-06 18:59, Sylwester Łazar pisze:
>>>> jego podstawowa zaleta to
>>>> wiedza co w danym momencie się dzieje z każdym bitem, całkowita
> kontrola
>>>> sprzętu,
>>>
>>> Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.
>>
>> Ogarniasz go na bieżąco podczas pisania, do tej pory nie miałem z tym
>> problemu.
> I tak to wygląda.
> Ceny 32-bitowców są na poziomie 3$.
> Wszystkie inne 8 i 16 bitowe, które mają jakąś sensowną pamięć, kosztują już
> 2x więcej.
> Wygląda na to, że nie ma popytu na 32-bitowe uC.

Ceny pamięci DDR2 SA znacznie wyższe niż pamięci DDR3. Według twojej
logiki nie ma popytu na pamięci DDR3 i dlatego producenci muszą zjeżdżać
z ceny.

> Pytanie dlaczego?
> Ja je lubię, ale większość ludzi zobaczy kartę katalogową i ucieka na
> drzewo.
> Gdyby taki 32-bitowiec miał tylko jeden prosty UART,
> 2 przerwania, 1 timer i kartę katalogową 50 stron, to ludzie by się nie
> bali.

Przecież są takie. Nawet w DIP. LPC810 za 4,47 zł. Aha, dlatego takie
tanie bo nikt ich nie chce. Dziwne, przecież mają jeden UART i 8 nóżek :(

> A tak, same zalety wymienione na początku, zamiast zachęcać,
> to odstraszają wydumanymi nazwami.
> Przyszły użytkownik zadaje sobie pytanie: Po co właściwie to jest?
>
> A tak jak powiedział Alex, nie przejmować się, że ma tyle bloków
> dodatkowych.
> Jak będę jakiś potrzebował, to sobie poszukam rejestru konfiguracyjnego o
> nazwie:
> bardzo_fajny_blok_CON i ustawię sobię w nim bit bardzo_fajny_blok_ON.
> Do tego czasu udajemy, że się nie znamy :-)

No i tak to mniej więcej działa. Z poprawką na to, że często nie musisz
ustawiać bitu. Wystarczy, ze użyjesz bibliotekę wykorzystującą
sterowniki CMSIS. Przy inicjalizacji (np portu UART czy SPI) podajesz
który to numer portu, jaka prędkość bodowa i na którym pinie jest Tx a
na którym Rx.
A poza tym sarkazm zupełnie niepotrzebny. Nie mów, że nie nie pisałeś
programu w którym stosowałeś tylko jeden ADC czy PWM a procek miał ich
do dyspozycji 10 czy 4.


--
pozdrawiam
MD

do góry

Użytkownik Mario napisał:
> W dniu 2014-04-06 18:14, AlexY pisze:
[..]
>> Źle do tego podchodzisz, rozpoczynając projekt sprawdzasz który sprzęt
>> spełni wymagania i na nim dłubiesz, dłubanie na siłę w zbyt słabym
>> sprzęcie jest skazane na porażkę.
>
> Ja tak właśnie nie podchodzę. Ale wydaje mi się że ci co się trzymają
> asemblera niestety są przez to często zmuszeni do pracy z prockami w
> których ledwo się mieszczą.

To nie tak że ledwo się mieszczę, po prostu czasem trzeba zrezygnować z
jakiejś extrasowej funkcji bo nie wejdzie, założona funkcjonalność musi
się zmieścić albo procek za mały.

[..]
> Podejrzewam, że ci co upierają się przy asm, z oporami sięgają po
> bardziej złożone architektury twierdząc, że to co mają w zupełności im
> wystarcza.

A może faktycznie im wystarcza?

[..]
>> Tu jest sedno sprawy, uC to ściśle określony sprzęt, system operacyjny
>> ma działać na całej rodzinie sprzętu, ponadto poziom komplikacji jednak
>> przewyższa atmelkowe miganie diodką, na uC program napiszesz, produkt
>> sprzedasz i możesz o nim zapomnieć,
>
> Tylko po co w takim razie argumentacja, że pisanie w c jest
> niebezpieczne z powodu błędów kompilatora czy ogólnie mówiąc szybkie
> tanie i kiepskie? Skoro kod skompilowany z c jest poprawny i stabilny w
> routerach czy w serwerach to czemu miałby być niepoprawny w przypadku
> atmelkowego migania LEDem?

Nie wiem w czym windows jest pisany ale daleko mu do bycia stabilnym.
Linuxa ciężko ale też da się wywalić.

>> systemy operacyjne co rusz się
>> aktualizuje, co w przypadku asm jest szczególnie ciężkie. To wymusza
>> użycie języka wysokiego poziomu, moje "ale" jest co do jego wyboru.
>
> Jakoś nie robią tego na Basicu. Widocznie c jest do tego lepszy.

Nie znam powodów innych niż ten co podałem (kasa).
Co stało na przeszkodzie zaadoptowania basic'a?
A już wiem... kasa... nie byłoby jej za kursy, książki, poradniki i
trzeba by było zabulić za licencje/prawa autorskie do basic'a.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry