• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

silnie typowany jezyk interpretowany

Object Storage Arubacloud
0 głosów
543 wizyt
pytanie zadane 7 lipca 2022 w Inne języki przez icytower Bywalec (2,110 p.)
Zaczalem sie ostatnio zastanawiac nad praktycznymi różnicami pomiedzy kezykami interpretowanymi i kompilowanymi.

roznic jest mnostwo ale te rozwazania doprowadzily mnie do mysli, ze nie slyszalem w sumie o zadnym jezyku interpretowanym z silnym typowaniem.

kojarzycie taki?
komentarz 7 lipca 2022 przez jankustosz1 Nałogowiec (35,880 p.)
Np. Typescript (to silne typowanie trochę oszukane, ale jest i nie przypiszesz intowi stringa, no chyba że zmienisz typ na odpowiedni)
komentarz 7 lipca 2022 przez icytower Bywalec (2,110 p.)
typescript nie jest interpretowany.
komentarz 7 lipca 2022 przez jankustosz1 Nałogowiec (35,880 p.)
Może być interpretowany np. Przez ts-node
komentarz 7 lipca 2022 przez doskanoness Obywatel (1,240 p.)
Ciekawe czy istnieją statycznie i jednocześnie słabo typowane języki programowania
komentarz 7 lipca 2022 przez Wiciorny Ekspert (269,590 p.)
edycja 7 lipca 2022 przez Wiciorny

@jankustosz1, ale to jest cecha polegająca na rozwiązaniu a nie na przynależności do jężyka.
Teoretycznie każdy język może być kompilowany i interpretowany, dlatego rozróżnienie to polega na najczęściej stosowanych rozwiązaniach, a nie zależy od cech samego języka

Ts jest skryptowy, a to umożliwia mu bycie kompilowanym do JS- który jest interpretowany przez przeglądarki 

Analogicznie mądra odpowiedz, jak poprzednio podawany przykład wzorca projektowego, ktory nie byl nawet poprawnie zaimplementowany :( 

komentarz 7 lipca 2022 przez jankustosz1 Nałogowiec (35,880 p.)
Zobacz sobie tamtą odpowiedź. Prawidłowo streściłem na czym polega wzorzec dekoratora. Jak uważasz, że źle to napisz to pod tamtym tematem. Wcześniej napisałeś bzdurę, że nie powinniśmy dziedziczyć i jednocześnie przyjmować obiektu tego samego typu jako argument konstruktora. Na tym właśnie opiera się ten wzorzec projektowy.
komentarz 7 lipca 2022 przez Wiciorny Ekspert (269,590 p.)
No nie :) bo łamiesz zasadę którą nawet powinien zachować dekorator : liskov substitution principle i fakt interfejsów, które zwalniają Cię z niepoprawnego dziedziczenia :)

nie każdy wraper możesz nazwać dekoratorem, tak samo nie kazdy dekorator tzw. klasa opakowująca, chcesz to CI podam link do mojej pracy naukowej na ten temat i temat wzorców obiektowego programowania np. w javie jest na google scholar :)
komentarz 7 lipca 2022 przez Wiciorny Ekspert (269,590 p.)
tak samo jak samo napisanie czegośco 1:1 wygląda jak wzorzec singleton, nie będzie tym wzorcem jeśli obiekt na którym ten wzorzec jest wykorzystany jest niepoprawny .

Np. singleton, może być wykorzystany jako obiekt pojedynczego połąćzenia w bazie relacyjnej, ale już nie jako pojedyncza klasa encji- bo wtedy skorzystasz z proxy-singletona.

JA NIETWIERDZE, że nie wiesz czym jest wzorzec, jestem przekonany że dobrze wiesz, ale podałeś zły przykład, ergo nieprzemyślany, lub przekopiowany w istocie z bledem
komentarz 7 lipca 2022 przez jankustosz1 Nałogowiec (35,880 p.)

@Wiciorny, 

Mówisz, że łamę zasadę L z SOLID i zamiana klasy bazowej na klasę potomną sprawi, że coś przestanie działać. Ale rzecz w tym, że klasa bazowa jest abstrakcyjna lub jest interfejsem, więc ta zasada nie ma tutaj zbytnio sensu.

Oczywiście, że nie każdy tego typu wrapper jest dekoratorem. Identycznie wręcz wygląda wzorzec proxy, ale różni się zastosowaniem. Adapter też jest całkiem podobny.

komentarz 7 lipca 2022 przez jankustosz1 Nałogowiec (35,880 p.)
Dodam że tydzień temu pisałem egzamin z Projektowania Obiektowego Oprogramowania, czyli tak naprawdę z wzorców projektowych. Ciekawi mnie ten temat i dostałem z tego egzaminu 5, więc coś wiem.

2 odpowiedzi

+4 głosów
odpowiedź 7 lipca 2022 przez edutomek Dyskutant (8,380 p.)
Dziwne pytanie zadajesz. Albo ja tego pytania nie rozumiem.

Zaczynasz od różnic pomiędzy językami interpretowanymi, a kompilowanymi - a kończysz na typowaniu silniejszym i słabszym. Tymczasem jedno z drugim nie ma niczego wspólnego. To dwie zupełnie niezależne kategorie. (Trochę tak, jakby się zastanawiać, czy trawa jest bardziej zielona, czy bardziej mokra od stojącego w pobliżu drzewa.)

O ile sprawa z typowaniem statycznym i dynamicznym jest prosta i w zasadzie zero-jedynkowa: albo mamy typowanie statyczne, albo dynamiczne, o tyle typowanie słabe (słabsze?) i silne (silniejsze?) już tak nie wygląda. (Pomijając już fakt, że te dwie kategorie typowania są często mylone.) Wszystko zależy od tego, jakie ograniczenia są nakładane na operacje, które można wykonać z danymi różnych typów. A te ograniczenia są różne, no i może ich być więcej, lub mniej.

Weźmy taki JavaScript: da się tam dodać napis do liczby (otrzymamy napis). To "ciągnie" JS w kierunku słabego typowania. Ale już poza tym przypadkiem, to w JS mamy w zasadzie same obiekty (tam wszystko jest obiektem!). No to o jakim typowaniu mowa? Jak obiekt, to obiekt. Do funkcji przekazujemy obiekt, zwracamy obiekt, do zmiennej przypiszemy obiekt... A że jeden obiekt to napis, drugi to tablica, a trzeci akurat to Object, to kogo obchodzi? Może poza programistą, który musi nad tym bałaganem jakoś zapanować.

W TypeScript jest już nieco lepiej, bo można dokładniej określić typy. Pytanie tylko, co z tego, skoro mamy takie Any. (A nawiązując do odpowiedzi jankustosz1, nieco czepialsko napiszę: TypeScript nie jest interpretowany, tylko transpilowany do JS - więc czy w ogóle pasuje do kategorii języków interpretowanych, rzekomo silniej typowanych? Ale to tylko pokazuje, że pytanie jest nieprecyzjnie zadane.)

W takim C (wiem, wiem, kompilowany) jest już nieco lepiej: napisu (czyli: tablicy znaków) do liczby nie dodamy. (Zresztą jakiego typu miałby być wynik?) Ale już spokojnie przekażemy do funkcji int-a, czy double, niezależnie od tego, jakiego typu (liczbowego) funkcja potrzebuje - typ zostanie domyślnie skonwertowany przez kompilator (co z mojego punktu widzenia zakrawa niemalże na zbrodnię). Ponadto jest możliwa jawna konwersja danej praktycznie dowolnego typu na dowolny inny - bo kto nam zabroni potraktować bajty z pamięci komputera jako typ, o którym sobie akurat pomyślimy? Bajty to bajty.

Porównajmy to teraz do takiego OCamla (wiem, wiem, kompilowany), w którym nie dodamy nawet liczby całkowitej do zmiennoprzecinkowej, bez jawnej konwersji. To jest dopiero silne typowanie! Z tym, że nie ma to nic wspólnego z tym, że OCaml jest kompilowany.

A jeśli chodzi o języki interpretowane (???), to do JS można skompilować taki PureScript, który ma (1) znacznie lepszy system typów (TS niech się schowa), (2) jest typowany silnie - z typami nie ma tam żartów. Tylko że PS można też skompilować do np. C (albo C++, nie pamiętam już) i wtedy zrobi się z niego język kompilowany. (???)

Kiedyś (lata temu) używałem też ReasonML (obecnie to się chyba nazywa po prostu Reason), który jest mniej-więcej odpowiednikiem OCamla, transpilowanym do JS. Ale znowu - ReasonML nie jest bezpośrednio interpretowany (jak TS, czy PS), więc czy w ogóle zaliczyć go do kategorii, o której mowa w pytaniu?
komentarz 7 lipca 2022 przez icytower Bywalec (2,110 p.)
fakt, troche malo precyzyjne pytanie.

ale wow jaka analiza. dzieki za takn obszerna odpowiedz. :)
2
komentarz 7 lipca 2022 przez Comandeer Guru (600,730 p.)

@edutomek, 

Ale już poza tym przypadkiem, to w JS mamy w zasadzie same obiekty (tam wszystko jest obiektem!).

To akurat nie jest prawda. W JS-ie istnieją typy proste, które zachowują się jak obiekty w niektórych sytuacjach z powodu mechanizmu "opakowywania"

komentarz 7 lipca 2022 przez edutomek Dyskutant (8,380 p.)

Może uściślając:

TAK, w JS mamy typy prymitywne.
Nawet można ich użyć, jak się człowiek bardzo uprze:

1.toString(); // tu będzie błąd - typ prymitywny nie ma metod
(1).toString(); // tu będzie ok - mamy już wrapping
var a = 1; // tu też nastąpi wrapping
a.toString(); // więc tu też ok

Czyli: formalnie mamy typy prymitywne, ale w praktyce i tak mamy do czynienia z obiektami. Bo kto normalny będzie wywoływał metodę na liczbie (zapisanej jako literał w kodzie)?

Odnośnie unwrapping, wspomnianego w tekście, to też nie do końca uda nam się wyłuskać typ prymitywny:

var a = 1;
a.valueOf().toString(); // będzie ok

(Nie mam pewności, czy to jest unwrapping - autor pokazywał to na napisach, ja użyłem liczb.)

Cytując autora tekstu:

In day-to-day programming, I pretend that wrapper objects don’t exist. They are used under the hood but rarely useful elsewhere.

To co mi po takich prymitywnych wartościach, skoro praktycznie nie da się z nich zrobić użytku? (Dosadniej: co mnie obchodzą szczegóły implementacyjne silnika JS?)

Żeby była jasność: nie mam zamiaru się spierać, że te typy nie istnieją w JS. Owszem, istnieją. Tyle, że są używane głównie "wewnętrznie", przez JS. Programista praktycznie nie ma z nimi do czynienia. Stąd moje stwierdzenie (wiem, kontrowersyjne, a co ;-)), że w JS wszystko jest obiektem.

1
komentarz 7 lipca 2022 przez Comandeer Guru (600,730 p.)

Cytując autora tekstu:

Ale ten cytat mówi dokładnie coś odwrotnego, niż Twój komentarz. To właśnie te opakowujące obiekty są szczegółem implementacyjnym, a nie typy proste!

Z typami prostymi ma się do czynienia non stop w JS-ie i ma to swoje konkretne implikacje, np. typy proste są niemutowalne w przeciwieństwie do obiektów. Cały system porównywania wartości prymitywnych jest inny (bo są porównywane przez wartość, nie jak obiekty przez tożsamość):

true === true; // true
new Boolean( true ) === new Boolean( true ); // false

Pomijam już fakt, że np. undefined nie posiada wrappera, a jest typem prostym.

komentarz 8 lipca 2022 przez Oscar Nałogowiec (29,290 p.)

@edutomek, 

W takim C (wiem, wiem, kompilowany) jest już nieco lepiej: napisu (czyli: tablicy znaków) do liczby nie dodamy. (Zresztą jakiego typu miałby być wynik?)

 

Przecież w C spokojnie dodaje się int i wskaźnik (a napis jako tablica jest konwertowalny domyślnie do wskaźnika).

"pasja informatyki" + 2 daje "sja informatyki" i w dodatku podobno jest to przemienne.

smiley

–2 głosów
odpowiedź 7 lipca 2022 przez doskanoness Obywatel (1,240 p.)
edycja 7 lipca 2022 przez doskanoness
Silnie i dynamicznie typowany język interpretowany - np. Python
Słabo i dynamicznie typowany język interpretowany - masz JavaScript, PHP5
Silnie, statycznie typowany język interpretowany - Java, C# itd

I tak dalej

Serio Google nie boli
komentarz 8 lipca 2022 przez icytower Bywalec (2,110 p.)
o ile kojaze to Java i C# sa kompilowane.

jakbym znalazl w google to bym nie pisal na forum.
komentarz 8 lipca 2022 przez Whiskey_Taster Pasjonat (15,610 p.)

@doskanoness, Google nie boli, ale szukać i czytać też trzeba potrafić. Java nie korzysta z interpretera. 

komentarz 8 lipca 2022 przez doskanoness Obywatel (1,240 p.)
Przecież Java korzysta z JVM a kod C# jest wykonywany przez .NET

Podobne pytania

+3 głosów
1 odpowiedź 233 wizyt
pytanie zadane 7 lutego 2023 w SQL, bazy danych przez zbiku25 Bywalec (2,940 p.)
0 głosów
2 odpowiedzi 2,672 wizyt
pytanie zadane 27 września 2020 w C# przez Masterkk121 Początkujący (280 p.)
0 głosów
1 odpowiedź 234 wizyt
pytanie zadane 18 sierpnia 2020 w Java przez amtrax Dyskutant (9,630 p.)

92,539 zapytań

141,381 odpowiedzi

319,469 komentarzy

61,926 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Kolejna edycja największej imprezy hakerskiej w Polsce, czyli Mega Sekurak Hacking Party odbędzie się już 20 maja 2024r. Z tej okazji mamy dla Was kod: pasjamshp - jeżeli wpiszecie go w koszyku, to wówczas otrzymacie 40% zniżki na bilet w wersji standard!

Więcej informacji na temat imprezy znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...