W dniu 02.01.2020 o 09:46, slawek pisze:
> Jest wiele mitów:
>
> 1. "Python to język skryptowy" - mit - podział na języki skryptowe
> i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
> dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
> skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
> AWK? A taki Postscript to jest jaki?!

Skoro tak zadajesz pytanie to kompletnie albo nie wiesz co się dzieje w
momencie kompilacji albo udajesz że nie wiesz - stawiam na to drugie :)

https://pl.wikipedia.org/wiki/Kompilator

Już prosta definicja z wiki (która jest uproszczona) pokazuje że zadanie
pytania cytuje: "czym różni się for z javy, C++.." jest to nie właściwe
pytanie. Bo odpowiedz jest bardzo prosta - sposobem wykonania tej
instrukcji - efekt pozostaje taki sam w obu przypadkach ale sposób ich
wykonania jest zupełnie różny. To właśnie dany sposób wykonania
poszczególnych instrukcji sprawia że te instrukcje w danym języku będą
wykonane szybciej inne wolniej... bardziej po chłopsku już się tego nie
da chyba napisać :)

Podział na języki skryptowe i kompilowane jest raczej prosty. Bardziej
skomplikowane jest rozróżnienie języka skryptowego i języka który działa
na maszynie wirtualnej - tj Java .NET które są świetne ale potrzeba do
nich środowiska uruchomieniowego.

>
> 2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
> takie programy jest łatwiej zrobić niż w C++. Choćby w tym sensie
> że biblioteka Qt wymaga w przypadku C++ gimnastyki z
> metakompilatorem, a Python tego nie potrzebuje. Osobną sprawą
> jest kwestia czy każdy program powinien mieć GUI ? - ale
> odpowiedź na to nie zależy od języka.

Okienka to tylko przykład. Jakoś nie widać oprogramowania w Pythonie np
do obrobki Grafiki czy wideo. Znając Pythona wiem że żadne programy
większego kalibru nie powstały i nie powstaną (No chyba ze coś znasz to
podziel się linkiem)

Nie każdy program musi mieć GUI i powiem szczerze czy on jest czy go nie
ma to i tak pozycji Pythona to nie zmienia - nadal pozostaje językiem w
którym większość piszę proste skrypty i strony www.

Ma swoje zalety ale jednak przegrywa z językami kompilowanymi gdy np
zależy nam na pisaniu coś pod konkretną platformę sprzętową

>
> 3. "Python nie kompiluje się" - mit - są kompilatory Pythona.
> Ponadto podział języków na interpretowane (translatory) i
> kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
> techniki.

Napisz jak to JIT działa wtędy będę wiedział czy wiesz o czym piszesz :)

Już wspomniałem że języki skryptowe jest ciężko odróżnić od wykonywanych
na maszynach wirtualnych :)

Pamiętaj o tym pisząc o JIT :)
A DLL dla Pythona są w natywnym.

W natywnym czym?

W Pythonie z tego co wiem można bez problemu użyć DLL napisanej np w C,
ale pisać...? Może jest nigdy w te stronę się nie bawiłem ale stawiam na
to że jeśli jest taka możliwość to czysty Python to nie jest :)

Pozdrawiam

do góry

W dniu 02.01.2020 o 18:16, slawek pisze:
> Roman Tyczka <n...@b...no> Wrote in message:
>> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.
>
> Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
> Pascal.
>
>> Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś
tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi
osobiście potrzebna.
>
> Brak dynamicznych tablic. Brak standardu wiązania z bibliotekami.
> Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
> jak we wbudowanej write. Nieprzenośne przekazywanie funkcji jako
> parametru. Liczne, ale niekompatybilne, dialekty. Brak wyjątków.
> Brak namespaces. Zbyt mocne powiązanie z jednym producentem -
> vendor lock. Do tego np. błędna implementacja delay przez
> Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
> programy po prostu nie działały bo startup code wkładał się z div
> by 0 na kalibracji delay. Trudności z użyciem dla low-level - w
> czym zwkłe C jest gorsze tylko od asemblera. Brak templates. Brak
> makrodefinicji. Brak STL. Brak fork. Brak arytmetyki wskaźników.
> Brak asm jako słowa kluczowego. Brak możliwości współpracy z
> Fortranem. Brak krótkiej ewaluacji. Brak refleksji. Brak
> dekoratorów.
>
>

Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość
rzeczy które tu wymieniłeś sa dostępne.

Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w
tamtym czasie - mało tego odpowiednie ustawienie flag kompilatora
eliminowało ten problem.

Ale ok nie wcinam wam się w wątek - zrobiłem to tylko z powodu błędu na
procesorach

Pozdrawiam

do góry

On Thursday, January 2, 2020 at 9:46:39 AM UTC+1, slawek wrote:
> Jest wiele mitów:
>
> 1. "Python to język skryptowy" - mit - podział na języki skryptowe
> i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
> dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
> skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
> AWK? A taki Postscript to jest jaki?!

Hmmm w sumie tak na szybko z rękawa nie umiem rzucić takiej definicji, aby
nikt się nie przyczepił. Może chodzi o to, że do 'języków skryptowych' nie
warto pisać kompilatora który zamieniałby go na kod maszynowy, bo wymagałoby
to wkompilowania interpretera? Każdy specyficzny element języka skryptowego
wymagałby call do interpretera, albo wstawienia ogromnej ilości kodu inline.

> 2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
> takie programy jest łatwiej zrobić niż w C++.

Nie przepadam za Pyhonem, ani nie mam doświadczenia w pisaniu aplikacji w
Pythonie, ale zgadzam się, że interfejs GUI w językach typu Python robi się
łatwiej, szybciej i w ogóle lepiej się do tego nadają. Po co w C++ się uganiać
za wskaźnikami i martwić czy domyślny konstruktor wywoła się szybciej i
przydzieli pamięć pod listę z danymi do wyświetlenia w GUI... Ale nie
popadajmy w skrajność, dla kogoś kto ma wprawę takie uganianie w C++ jest
nawet przyjemne i też robi się szybko. Podobno główną zaletą Pythona jest
to, że po zaledwie małym kursie można szybko pisać duże aplikacje. W C++
bez solidnego kursu i praktyki programować się zdecydowanie nie da. Czasami tu i
ówdzie można przeczytać, że Python jest dla naukowców. Jeśli chodzi o to, że
naukowiec żyje w swoim świecie, a od czasu do czasu musi szybko napisać
jakiś programik sprawdzający jego teorię w praktyce - to się zgadzam. Po co
naukowiec miałby część swojej intelektualnej twórczości marnować na opanowywanie
ogromnej ilości szczegółów języka takiego jak C++? Natomiast gdy już naukowiec
zwraca się do programisty ze swoim problemem, to bardziej normalne
wydaje się, że programista zaproponuje naukowcowi rozwiązanie uszyte na miarę
problemu i na miarę dostępnego sprzętu właśnie w C++ a nie w jakimś skrypciaku.

> Choćby w tym sensie
> że biblioteka Qt wymaga w przypadku C++ gimnastyki z
> metakompilatorem,

Jeden podpity do drugiego:
- na rynku zrobili taką dziurę, wkłada się tam głowę i samo goli twarz.
- no ale przecież każdy ma inną gębę!
- ale tylko za pierwszym razem ;-)

Więc ta gimnastyka jest tylko za pierwszym razem gdy ktoś nie opanował
metakompilera, kompilera zasobów, itd. Poza tym istnieje IDE o nazwie
QTCreator w którym (dziś, bo kiedyś się wywalało co rusz) można zbudować
naprawdę dużą aplikację i duże GUI nie rozumiejąc jak działa metakompiler a
nawet kompiler c++... w regularnym kodzie produkcyjnym nastawionym na
stosunek funkcjonalności do nakładu pracy nawet nie jest wskazane rozumienie
szczegółów z qmake. Oczywiście gdy ktoś chce wycisnąć maksimum możliwości z
tych narzędzi to musi rozumieć jak one działają, ale taka konieczność
zachodzi tylko w specyficznych aplikacjach.

> a Python tego nie potrzebuje. Osobną sprawą
> jest kwestia czy każdy program powinien mieć GUI ? - ale
> odpowiedź na to nie zależy od języka.

No nie zależy od języka.


> 3. "Python nie kompiluje się" - mit - są kompilatory Pythona.

Słyszałem że jak się podaje typy i pisze w odpowiedni sposób to
można Pythona skompilować do C i potem do kodu maszynowego. Ale
to pisanie w odpowiedni sposób chyba oznacza rezygnację z wygód
jakie niosą kacze interpretowane języki ?

> Ponadto podział języków na interpretowane (translatory) i
> kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
> techniki. A DLL dla Pythona są w natywnym.

Tak, ale nawet (bez sarkazmu) w wydajnej Javie JIT nie może wiele
zrobić gdy jest wirtualny call po nazwie i overloading na podstawie
dynamicznych typów - w przypadku każdego wywołania.


Pozdrawiam

do góry

W dniu czwartek, 2 stycznia 2020 20:30:52 UTC+1 użytkownik J-23 napisał:
> W dniu 02.01.2020 o 09:46, slawek pisze:
> > Jest wiele mitów:
> >
> > 1. "Python to język skryptowy" - mit - podział na języki skryptowe
> > i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
> > dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
> > skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
> > AWK? A taki Postscript to jest jaki?!
>
> Skoro tak zadajesz pytanie to kompletnie albo nie wiesz co się dzieje w
> momencie kompilacji albo udajesz że nie wiesz - stawiam na to drugie :)
>
> https://pl.wikipedia.org/wiki/Kompilator
>
> Już prosta definicja z wiki (która jest uproszczona) pokazuje że zadanie
> pytania cytuje: "czym różni się for z javy, C++.." jest to nie właściwe
> pytanie. Bo odpowiedz jest bardzo prosta - sposobem wykonania tej
> instrukcji - efekt pozostaje taki sam w obu przypadkach ale sposób ich
> wykonania jest zupełnie różny. To właśnie dany sposób wykonania
> poszczególnych instrukcji sprawia że te instrukcje w danym języku będą
> wykonane szybciej inne wolniej... bardziej po chłopsku już się tego nie
> da chyba napisać :)

Bo i rozumowanie jest raczej "chłopskie".

> Podział na języki skryptowe i kompilowane jest raczej prosty. Bardziej
> skomplikowane jest rozróżnienie języka skryptowego i języka który działa
> na maszynie wirtualnej - tj Java .NET które są świetne ale potrzeba do
> nich środowiska uruchomieniowego.

A do których języków nie potrzeba środowiska uruchomieniowego?

"Podział" na "języki skryptowe i kompilowane" z logicznego punktu widzenia nie jest
podziałem dychotomicznym.
Kiedyś mówiło się o "językach kompilowanych i interpretowanych".
Ale to, czy dany język jest "kompilowany czy interpretowany", nie jest kwestia samego
języka, tylko narzędzi. (Np. istnieją interpretery języka C)

Określenie "język skryptowy" nie ma związku z tym, jaka jest technika implementacji.
Z definicji jest to "język służący do pisania skryptów"
(albo - bardziej pedantycznie: język, o którym myśli się jako o języku, w którym
pisze się skrypty).
I znów, to, czy język służy, czy nie służy do pisania skryptów, nie jest cechą samego
języka, tylko tego, w jaki sposób ktoś postanowi go użyć.

Prototypowe języki skryptowe to języki powłoki (np. bash albo DOSowe batche albo
skrypty w PowerShellu).

Są one "skryptowe", bo pełnią funkcję "end-user programmingu" - tzn. ich autorzy nie
muszą rozumieć szczegółów implementacji systemów, a wystarczy, że znają zasady
korzystania z tych systemów.

W dalszej kolejności mamy języki takie jak Perl czy AWK, które są uznawane za
skryptowe, bo są podobne do skryptowych.
Ponieważ zakres zastosowań Pythona pokrywa się z zakresem zastosowan Perla, a
niekiedy i języków powłoki, czasem i o nim mówi się, że jest "skryptowy".

Znam ludzi, którzy woleliby do tych samych celów użyć Haskella (który jest "mocno
kompilowany").

Swego rodzaju "opozycją" do języków skryptowych są języki systemowe - czyli takie,
które służą do pisania dużych, skomplikowanych systemów (czy raczej: o których się
myśli, że do tego służą).

Ale to nie jest twardy podział. Języki takie jak PHP czy JavaScript można w tym duchu
nazwać "webowymi", bo się ich używa do opracowywania stron (choć nic nie stoi na
przeszkodzie, by pisać w nich skrypty).

No, a PostScript jest oczywiście stosowy.

do góry

W dniu 03.01.2020 o 00:20, slawek pisze:
> J-23 <B...@p...fm> Wrote in message:
>> Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość rzeczy
które tu wymieniłeś sa dostępne.Błąd związany z Pentium o którym piszesz nie był
domeną tylko Pascala w tamtym czasie.
>
> Tak, większość z tych rzeczy była dostępna w C++ w XX wieku. W
> Pascalu/Delphi nie. Jeżeli coś pomyliłem, to napisz konkretnie
Właśnie o to chodzi że większość tych rzeczy które wymieniłeś byly
jeszcze w latach 90 tych
> co. Może Pascal ma obsługę wyjątków? Nie ma?
Nie ma obsługi wyjątków od kiedy :P?? Bo są od dawna nawet wersji nie ma
co przytaczać :P ale try...except...finally było na bank w latach 90
tych juz :)
No właśnie. A może
> nie jest prawdą że co dialekt Pascala to w inny sposób
> przekazywało się funkcję/procedurę jako parametr (mały myk - były
> wersje, bodajże Turbo Pascal, gdzie to w ogóle było niemożliwe)?

Dialekt Pascala się zmieniał i zmienia nadal ale inne języki i ich
dialekty też się zmieniają - proste (także marny zarzut że język się
rozwija)

> A może jest już STL dla Pascala?
Są :) nie są tak rozwinięte jak w C++ ale są :)

To może można redefiniować
> operatory w Pascalu?!
Tego brak
>
> Mylisz też, misiaczku, tzw. Pentium Bug z błedem delay. Ten
> pierwszy był błędem samego CPU - Intel Pentium we wczesnej wersji
zgadza się i wystarczyła wstawka asembler owa lub pogrzebanie z
przełącznikami kompilatora by to naprawić. Nawet pamiętam do dziś że
zrobiłem sobie narzędzie gdzie w lini komend podawałem ścieżkę programu
i w ten sposób odpalałem program i tego problemu nie było
> - instrukcja fdiv mogła, w pewnych okolicznościach przyrody,
> "dawać mniej dokładne wyniki" - np. zamiast 4.0 wychodziło
> 5.0.
>
> Ten drugi to błąd w kodzie startup Turbo Pascala - program na
> dzień dobry robił pustą pętlę z n iteracjami mierząc ile to czasu
> t zajmuje, potem dzielił n/t po to aby skalibrować działanie
> funkcji delay. Dowcip w tym że przy szybkich procesorach, takich
> jak Pentium, wychodziło t = 0.0 z oczywistym efektem. Co
> powodowało że nieoczekiwanie wszystkie programy (exe) zrobione w
> Turbo Pascalu przestawały dawać się uruchamiać. Oczywiście,
> powstał patch - nadpisujący kod startowy w exe-kach. Tyle że były
> to czasy gdy nie było aktualizacji Windows trzy razy na godzinę.

O tym samym mówimy :) ja napisałem to raz i miałem z głowy. Właśnie w
taki sposób jak opisałem powyżej

Dodam nawet że miło wspominam ten czas bo z tego w tamtym czasie miałem
spory grosz :)
>
>
>
> ----Android NewsGroup Reader----
> http://usenet.sinaapp.com/
>

do góry

On Friday, January 3, 2020 at 1:18:08 AM UTC+1, slawek wrote:
> "M.M." <...@...c> Wrote in message:
> > Podobno główną zaletą Pythona jestto, że po zaledwie małym kursie można szybko
pisać duże aplikacje. W C++bez solidnego kursu i praktyki programować się
zdecydowanie nie da. Czasami tu iówdzie można przeczytać, że Python...
>
>
> 1. IMO Python jest niezbyt dobry dla programów mających ponad
> 100000 LOC (nie licząc bibliotek i cudzych modułów).

Często czytałem że większe programy pisane w językach z dynamicznym
typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem
tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?
Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod
warunkiem że nie przekracza 5tys linii, w tym do 100tys, a w jeszcze
innym do milionów?

> Idealnie
> program w Pythonie to jakieś 2000 do 5000 LOC robiące to do czego
> w C++ potrzeba byłoby jakiegoś giganta na pół miliona linii kodu.

Czy na pewno nadal rozmawiamy o języku programowania czy już o
bibliotekach? Pół miliona to 100 razy więcej niż 5tys. W C++
też pisze się efektywnie, ale trzeba mieć odpowiednie biblioteki.

> Oczywiście całkiem konkretne rzeczy da się zrobić w np. 50
> linijkach lub mniej. Przykładowo: zassać dane z bazy, zrobić
> obliczenia i narysować publish-ready wykresy.

W C++ też to można zrobić w 50 linijkach, kwestia bibliotek.


> 2. W C++ da się programować na poziomie C. Tak m.i. programują
> mikrokontrolery elektronicy - udając że nie ma OOP, STL, new i
> nawet const.

Osobiście programowałem w C++ na mikrokontrolery. Dzięki szablonom
miałem prawie od kopa 3 wersje swojej biblioteki, wielkość kodu w
zależności od wersji biblioteki różniła się wielokrotnie, mogłem
wybrać najmniejszy kod. W C bym musiał nieźle się nagimnastykować żeby
uzyskać taki efekt.


> 3. Siłą Pythona jest abstrakcja - patrz niżej:
> def commute(a, b): return a*b - b*a
>
> Dowcip w tym ze definicja commute jest zupełnie ogólna - mogą tam
> być zwkłe int, mogą być macierze, mogą być operatory różniczkowe.

Niby w C++ też, ale zapis jest z lekka rozwlekły:
template< class T >
void compute(T &a, T &b) { return a*b - b*a; }


> W C++ też dałoby się to /jakoś/ zrobić. Tyle że w Pythonie taki
> poziom abstrakcji jest czymś zupełnie normalnym.

Hmmmm to prawda.


> 4. Python ma parę PASKUDNYCH wad.

Ja nie wiem.

Pozdrawiam

do góry

On Thu, 2 Jan 2020 18:16:45 +0100 (GMT+01:00), slawek wrote:

>> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.
>
> Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
> Pascal.
>
>>Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś
tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi
osobiście potrzebna.

Jak pisałem poprzednio, gdy mówimy o dzisiejszym Object Pascalu to:

> Brak dynamicznych tablic.

są oczywiście i to od dawna

> Brak standardu wiązania z bibliotekami.

nie wiem na czym standard miałby polegać, ale biblioteki z innych języków
da się używać, a także linkować pliki .obj

> Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
> jak we wbudowanej write.

To prawda, choć jeśli dopuścić zapis wywołania z tablicą:

DoJob([1, 'text', 6.5]);
DoJob(['text', 15]);

to się da.

> Nieprzenośne przekazywanie funkcji jako
> parametru.

Typy funkcyjne/proceduralne są od bardzo dawna, od dekady są też metody
anonimowe, więc można ich wszystkich używać jako parametrów

> Liczne, ale niekompatybilne, dialekty.

To prawda.

> Brak wyjątków.

Są od dekad.

> Brak namespaces.

Tak, tego brakuje

> Zbyt mocne powiązanie z jednym producentem - vendor lock.

To nie jest argument przeciw językowi.

> Do tego np. błędna implementacja delay przez
> Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
> programy po prostu nie działały bo startup code wkładał się z div
> by 0 na kalibracji delay.

Problem sprzed ponad 20 lat - nieistniejący.

> Trudności z użyciem dla low-level - w czym zwkłe C jest gorsze tylko od asemblera.

Czyli konkretnie co?

> Brak templates. Brak makrodefinicji.

Są za to generyki.

> Brak STL.

Jest Spring:
https://spring4d.4delphi.com/docs/master/Html/index.
htm?Spring.Base.htm

> Brak fork.

Fakt

> Brak arytmetyki wskaźników.

Od ponad dekady jest

https://helloacm.com/pointer-arithmetic-in-delphi/

> Brak asm jako słowa kluczowego.

Od dekad:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Asse
mbly_Expressions

> Brak możliwości współpracy z Fortranem.

To jest jakiś uniwersalny wymóg dla języków?

> Brak krótkiej ewaluacji.

Od dekad:

http://docs.embarcadero.com/products/rad_studio/delp
hiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsb
ooleanshortcircuitevaluation_xml.html

> Brak refleksji.

http://robstechcorner.blogspot.com/2009/09/delphi-20
10-rtti-basics.html

> Brak dekoratorów.

Jeśli masz na myśli to co w Javie nazywa się annotations, to są attributes:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Attr
ibutes_and_RTTI

--
pozdrawiam
Roman Tyczka

do góry

W dniu piątek, 3 stycznia 2020 00:35:32 UTC+1 użytkownik slawek napisał:

>
> Dodam, że nigdzie nie znalazłem skutecznej definicji kryterium co
> jest "językiem skryptowym". Tzn. takiej, że mając język X można
> zastosować je do jednoznacznego rozstrzygnięcia czy język jest
> skryptowy czy nie jest.
>
> Czyli "skryptowy" to słowo nie niosące żadnego konkretnego
> znaczenia, rodzaj "yyyeee" czy "hmmm".

Nie. "Skryptowy" to pojęcie oparte na prototypie i podobieństwie względem prototypu.
Nie ulega najmniejszej wątpliwości, że języki powłoki systemu to języki skryptowe.

O ile jednak ma sens mówienie, że dany język w swoich typowych zastosowaniach jest
skryptowy (czyli np. "jeżeli chcesz pisać programy, które w jakiś sposób naśladują
twoje interakcje z komputerem, rozsądnie wybrać taki a taki język"), o tyle raczej
nie ma sensu mówienie o językach "nie-skryptowych". (W C możesz zrobić wszystko to,
co w bashu. Tyle że opeartory w rodzaju <, > czy >> są dużo prostsze w użyciu, niż
interfejsy fopen, fread i fwrite)

Ale to coś więcej, niż "yyyeee" czy "hmmm".

do góry

W dniu piątek, 3 stycznia 2020 18:12:41 UTC+1 użytkownik slawek napisał:
> > Nie ulega najmniejszej wątpliwości, że języki powłoki systemu to języki
skryptowe.
>
> No to popatrz - VBA nie jest skryptowy. A VBS jest.

I w czym problem?

> C jest skryptowy, bo jest csh, czyli C-shell.

Wiesz w ogóle o czym mówisz?

Zobaczmy.

$ csh

% int x = 5;
int: Command not found

% int f(void) { return 5; }
Badly placed ()'s.

No rzeczywiście.

> A Javascript nie jest skryptowy, bo to nie język powłoki systemu.

No nie jest. I co teraz?

> > W C możesz zrobić wszystko to, co w bashu. Tyle że opeartory w rodzaju <, > czy
>> są dużo prostsze w użyciu, niż interfejsy fopen, fread i fwrite.
>
>
> No cóż, nie bardzo kumam o co ci chodzi - zwłaszcza że bash jest
> napisany w C - więc nie da się zrobić w bash tego co niemożliwe w
> C. Owszem, w C można zrobić to czego nie da się zrobić w bash.
> Np. napisać procedurę obsługi przerwania.

Faktycznie nie bardzo kumasz o co mi chodzi.
Może przeczytaj jeszcze kilka razy to, co napisałem.
(Albo poczekaj aż będziesz miał zdaną maturę)

do góry

W dniu piątek, 3 stycznia 2020 19:17:58 UTC+1 użytkownik slawek napisał:

> > Faktycznie nie bardzo kumasz o co mi chodzi.Może przeczytaj jeszcze kilka razy
to, co napisałem.(Albo poczekaj aż będziesz miał zdaną maturę)
>
> To przeczytaj co piszą w Wikipedii:
>
> "
> Język skryptowy (ang. script language) - język
> programowania obsługujący skrypty[1]. Często służący do
> kontrolowania określonej aplikacji.
>
> Skrypty - programy napisane w językach skryptowych, "
>
>
> Nawet jeżeli nie masz matury to powinieneś wychwycić że taka
> definicja skryptowości kupy się nie trzyma.

Chyba przeoczyłeś: "przeznaczone do wykonywania w specjalnych środowiskach
uruchomieniowych automatyzujących wykonywanie zadań, które alternatywnie mogą być
wykonywane jedno po drugim przez użytkownika".
Może jednak lepiej zaczekaj do tej matury.

> I nie spinaj się tak bardzo, bo od tego tylko hemoroidy ci urosną.

Masz w tej kwestii jakieś doświadczenia, którymi chciałbyś się tutaj podzielić?

do góry