silnie typowany jezyk interpretowany

Question

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?

Comments

Np. Typescript (to silne typowanie trochę oszukane, ale jest i nie przypiszesz intowi stringa, no chyba że zmienisz typ na odpowiedni)

---

typescript nie jest interpretowany.

---

Może być interpretowany np. Przez ts-node

---

Ciekawe czy istnieją statycznie i jednocześnie słabo typowane języki programowania

---

@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 :( 

---

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.

---

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 :)

---

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

---

@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.

---

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.

Answer 1

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?

Comments

fakt, troche malo precyzyjne pytanie.

ale wow jaka analiza. dzieki za takn obszerna odpowiedz. :)

---

@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". 

---

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.

---

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.

---

@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.

Answer 2

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

Comments

o ile kojaze to Java i C# sa kompilowane.

jakbym znalazl w google to bym nie pisal na forum.

---

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

---

Przecież Java korzysta z JVM a kod C# jest wykonywany przez .NET