On Fri, 2 Oct 2015 23:52:29 +0200, "Grzegorz Niemirowski"
<g...@p...onet.pl> wrote:
> Lepszy bo możliwości więcej, w tym możliwości strzelenia sobie w
stopę. Żeby
> nie było: też przeszedłem z Bascoma na C, ale nie uważam że należy
potępiać
> Bascoma.

Nie miałem zamiaru komentować w tym wątku Bascoma (bo de facto nie o
niego było pytanie) ale mnie niestety sprowokowałeś. Bascom to
policzek dla Basica bo podobno jemu ma być podobny. Nazywa się
"kompilatorem" a de facto jest czymś w rodzaju konsolidatora
bibliotecznych (gotowych) asmeblerowych instrukcji i makr użytych w
kodzie. Język, który kpi sobie z programisty (o tym
niżej).Bałaganiarska składnia dopuszcza case insensitive co pozwala
na tworzenie mało czytelnego kodu. Osoba, którą znam co poświęciła mu
zbyt dużo czasu szybko doszła do ściany w rozwoju i koniec. Język
kompletnie nie rozwija, ogranicza wyobraźnię do kontekstu "jednego
programu" przez co trudno ogarnąć takiemu programiście
wielozadaniowość nawet opartą na prostej maszynie stanów. Brak
możliwości pisania własnych bibliotek (uwaga, można ale w asemblerze,
kpina nr 1), brak możliwości porozdzielania projektu na skompilowane
obiekty aby za każdym razem nie "kompilować" całości. Brak
jakiejkolwiek optymizacji, kod jest składany z gotowych klocków, więc
jego rozmiar rośnie dość szybko. Niezgodność dokumentacji producenta
w opisie instrukcji, znalazłem takie, które nie chcą działać mimo, że
zostały użyte wg przykładów. Brak sensownej i logicznej konsekwencji
w instrukcjach/makrach. Tam nie da się nic przewidzieć (co do
poprawnej składni). Raz argumenty instruckji są bez nawiasów a raz w
nawiasach, np. skladnia instrukcji rysowania linii na LCD graf
wyglada tak:

line(x1,y1)-(x2,y2)
a zapalenia pixla:
pset x,y,z

logiczne, prawda? Raczej kpina nr 2.

Niektóre funkcjonalności nie działają jak powinny, ostatnio kolega
męczył się przez tydzień z fontami na LCD graficznym. Użycie
instrukcji wyboru fontu do pisania powodowało niedziałający w ogóle
kod (niestartujący w ogóle mcu). Sprawa była o tyle dziwna, że
posiłkował sie przykladami kodu z artykułów, ktorych autorzy
twierdzili, że im działa. Po kilku dniach szukania przyczyn poddał
się i przepisał jota w jote kod z przykladu, o dziwo kod zadział. Co
się okazalo? Że kod działa jeśli instrukcje grafiki są w procedurach
a nie w pętli głównej (sic!). Czemu? Nie wiadomo. Faktycznie we
wszystkich przykładach użyto podobnej konstrukcji z procedurami, ale
nikt się nie zająknął, że tak być musi bo nie zadziała. Jest to
piękny przyklad, jak próba inwencji w inną koncepcję konstrukcji kodu
(bez procedur) sprowadza na ziemię, bo tak się nie da, bo coś nie
działa. Tylko traci się czas, kpina z programisty nr 3.
Najlepsze zostawiam na deser. Ktoś może powiedzieć, że te powyższe
zarzuty są przesadzone, bo język ma być prosty dla prostych
rozwiązań, dla nie-programistów a bardziej elwktroników więc nikomu
niepotrzebne dołączanie skompilowanych obiektów czy rozdzielanie kodu
na wiele plików. Składnia jest jaka jest, po to jest help aby z niego
korzystać. I nawet jestem w stanie mu przyznać rację. Ale jak się
dowiedziałem, że wyrażenia arytmetyczne są ograniczone do dwóch
operandów (sic) i jednego operatora to mi już wszystko odpadło. Tak,
w Bascomie nie da się napisać prostego wyrażenia x=3*y+23*z, o
bardziej skomplikowanym nie wspominając. Programista musi rozłożyć
wyrażenie na kilka prostych wyrażeń jednooperatorowych wprowadzając
najczęściej dotatkowe zmienne pomocnicze. Kolejna kpina, nawet nie
liczę która.

Co można powiedzieć dobrego o Bascomie? No lista instrukcji obsługi
peryferiów robi wrażenie, trzeba przyznać ogrom pracy jaką włożono w
rozwój. I na tym koniec bo zaraz za tym idzie zadziwienie z tej
liczby doklejanych do tego jezyka instrukcji-potworków aby obsłużyć
kolejną taką czy inną kolejną funkcjonalność. Przy niektórych
mityczne b=---*a++, którym straszy sie przyszłych adeptów C to pikuś.
A miał to być język prosty, do prostych zastosowań.

--
Marek