On Sat, 03 Oct 2015 11:45:49 +0200, Marek <f...@f...com> wrote:
> niżej).Bałaganiarska składnia dopuszcza case > insensitive co
pozwala
> na tworzenie mało czytelnego kodu.

Czytelność kodu źródłowego zależy od programisty. Widziałem programy
w Asemblerze napisane strukturalne i czytelnie. A zapewniam cię, że
Basic nie jest jedynym językiem case insensitive.

do góry

>
> 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.
[--ciach-]
Niestety Marku masz rację, sam kiedyś próbowałem w tym pisać
ale każdy trochę bardziej skomplikowany program to walka z baskomem,
gdzie help swoje a kompilator swoje. Więc po tych doświadczeniach także
uważam że baskom to nieporozumienie.

--
Pozdr

Janusz_K

do góry

On Sat, 03 Oct 2015 13:43:26 +0200, slawek <f...@f...com> wrote:
> Czytelność kodu źródłowego zależy od programisty. Widziałem
programy
> w Asemblerze napisane strukturalne i czytelnie. A zapewniam cię, że
> Basic nie jest jedynym językiem case insensitive.

Otóż to, każdy język dopuszczający case ins. jest bałaganiarski z
natury, szczególnie dla winusera, który jest do tego przyzwyczajony
np. FS. Jeden czy drugi pedant tego nie zmieni.

--
Marek

do góry

użytkownik k...@g...com napisał:
> Wiekszosc osob pada na wskaznikach i z tego
> powodu zostaja programistami Javy,
>


Większość przykładów softu na stronach producentów IC
jest w C zdaje się.



> zarabiajac 2x tyle co na programowaniu
> niskopoziomowym:D


A nie lepiej udzielać pożyczek, abo zostać prezesem
jakiej spółki?

do góry

Pan Marek napisał:

>> A zapewniam cię, że Basic nie jest jedynym językiem case insensitive.
>
> Otóż to, każdy język dopuszczający case ins. jest bałaganiarski z
> natury, szczególnie dla winusera, który jest do tego przyzwyczajony
> np. FS. Jeden czy drugi pedant tego nie zmieni.

Dziwi mnie ta opinia. Z czasów programowania w pascalu pamiętam ile
dobrego dla porządku w kodzie wynikało z niewrażliwości na wielkie
litery. Choćby stosując pary BEGIN-END, Begin-End, begin-end dawało
się lepiej przedstawić strukturę programu. Bardzo cenne w czasach,
kiedy nie było edytorów kolorujących kod i sprawdzających składnię.

Jasne, że są języki, w których szczególnie łatwo nabałaganić, ale
nigdy bym nie wpadł na to, że "case ins." ktoś może uznać za główny
element sprzyjający.

--
Jarek

do góry

On Sat, 03 Oct 2015 11:45:49 +0200, Marek <f...@f...com> wrote:
> mityczne b=---*a++, którym straszy sie przyszłych

To że tak można nie oznacza że trzeba. Można puszczać bąki, ale
przecież nie robi się tego publicznie.

Pierwszy błąd: dlaczego a, dlaczego b? Czy b jest też wskaźnikiem?
Nic nie mówiące nazwy, sugerujące że a, b, c to tego samego typu...
Ale jaki sens ma zmiana znaku wskaźnika?!

Lepiej value = ---*ptr++;

Kolejny błąd: unikanie nawiasów.

value = -(--(*ptr++));

Nadal paskudnie, ale trochę lepiej.

do góry

W dniu 2015-10-02 o 09:27, Marek pisze:

Polecam środowisko Eclipse.

Blog Mirka zawiera tyle wiedzy że kolega szybko i bezproblemowo
poradzi sobie z instalacją.
http://www.mirekk36.blogspot.com/

http://mirekk36.blogspot.com/2011/11/dlaczego-eclips
e-zamiast-avr-studio.html

http://mirekk36.blogspot.com/2011/05/wybor-jezyka-pr
ogramowania.html




Kanał na Youtube:
https://www.youtube.com/user/mirekk36

Pozdr. PK.

do góry

On Sat, 3 Oct 2015 14:46:12 +0200, Jarosław
Sokołowski<j...@l...waw.pl> wrote:
> Jasne, że są języki, w których szczególnie łatwo nabałaganić, ale
> nigdy bym nie wpadł na to, że "case ins." ktoś może uznać za główny
> element sprzyjający.

Ja bym nawet przymknął na to oko i się tego nie czerpał, gdyby nie ta
reszta mankamentów.

--
Marek

do góry

Pan Marek napisał:

>> Jasne, że są języki, w których szczególnie łatwo nabałaganić, ale
>> nigdy bym nie wpadł na to, że "case ins." ktoś może uznać za główny
>> element sprzyjający.
>
> Ja bym nawet przymknął na to oko i się tego nie czerpał, gdyby nie
> ta reszta mankamentów.

"Nie czepiał się"?! Przecież tu się nawet nie na czego czepiać, ani na
co przymykać oka -- bo to "case ins." w kontekscie porządku w kodzie nie
jest mankamentem, a wręcz przeciwnie. O innych wadach różnych języków
można długo, ale są to rzeczy dość powszechnei znane. A w każdym razie
nie tak zaskakujące, jak opinia o dowolności stosowania wielkich liter,
która prowadzi do bałaganu w programie.

Fortran jest językiem zaprojektowanym w czasach, gdy komputery posługiwały
się alfabetem sześciobitowym, w którym były tylko wielkie litery. Więc
nawet trudno go wprost zaliczyć do "case ins." -- po prostu ten problem
tam nie istnieje. Ma on za to osobliwe podejście do spacji -- tego znaku
nie ma w jego alfabecie, jest on całkowicie ignorowany przez kompilator,
spacje można umieszczać w dowolnych miejscach. Nawet we wnętrzu nazw
zmiennych i słów kluczowych. Ta oszczędnośc jest poważnym mankamentem,
jego najbardziej znaną implikacja jest całkowita zmiana sensu instrukcji
gdy przecinek zostanie omyłkowo zamieniony na kopkę. Zapis "DO 10 I=1,32"
oznacza pętlę wykonywaną 32 razy z inkrementacja zmiennej "i". Natomiast
"DO 10 I=1.32" jest równoważnie stworzeniu zmiennej rzeczywistej "do10i"
i przypisaniu do niej wartości "1,32". O tym wszyscy wiedza i się pilnują.
Ale z drugiej strony wiedzą też, że można w tym języku tworzyć czytelne
wielowyrazowe nazwy dla zmiennych i funkcji -- "TABLICA STANOW WEJSCIA"
to w tym języku całkiem dobra nazwa. Po prostu mając "space ins." da się
napisać bardziej czytelny kod (choć nabałaganić też można).

--
Jarek

do góry

W dniu 03.10.2015 o 07:39, slawek pisze:
> Przy 100 linijkach Basic daje radę. Przy 2000 linijkach jakby mniej.
> Przy 10000 zaczynają być problemy z C. C++ teoretycznie nadaje się do
> rzeczy mających parę milionów linijek.
>
> Jeżeli chcesz pomrugać LED to Basic jest ok. Jeżeli napisać mały system
> operacyjny na Atmegę, to C jest ok. Jeżeli piszesz np. program AI mający
> kierować samochodem, to C++ jest jedną z opcji.

Cholera, czyli mylą się wszyscy deweloperzy linuxa pisząc kernel w
czystym C?

--
Pozdrawiam
Jakub Rakus

do góry