Hej,
Jakie jest praktyczne zastosowanie słabego typowania w językach i czemu jest tak bardzo popularne? Czy ma jakąkolwiek przewagę nad silnym typowanie poza tym że nam te typy znikają z oczu i kod jest krótszy?
Przychodząc do PHP z Javy, ta cecha języka bardzo utrudnia mi życie z powodu słabej czytelność kodu. Co Wy o tym sądzicie, jakie typowanie wolicie?
Szybkość pisania kodu.
Nie mylmy słabego typowania z dynamicznym.
słabe kontra silne
dynamiczne kontra statyczne
są teoretycznie 4 możliwości (słabe dynamiczne, silne dynamiczne, słabe statyczne, silne statyczne).
Czy ma jakąkolwiek przewagę nad silnym typowanie poza tym że nam te typy znikają z oczu i kod jest krótszy?
Python ma silne typowanie, a typy też znikają z oczu i kod jest krótszy. Brak potrzeby pisania w kodzie typów to raczej kwestia albo dynamicznego typowania (typy ustalają się dynamicznie, w trakcie uruchomienia programu, tak jak jest to w Pythonie), albo dobrej inferencji statycznej (jeśli kompilator sam na poziomie kompilacji może wykryć co jest jakiego typu, w Swift chyba tak jest, chociaż mało programowałem w tym).
Matthi napisał(a):
Jakie jest praktyczne zastosowanie słabego typowania w językach i czemu jest tak bardzo popularne? Czy ma jakąkolwiek przewagę nad silnym typowanie poza tym że nam te typy znikają z oczu i kod jest krótszy?
Niektórym jest "łatwiej", gdy nie muszą tych typów pisać... ale jest masa języków, które są statycznie typowane, i też nie wymagają pisania typów.
No i jest Jest też JavaScript, którego trzeba używać, bo po prostu nie ma innego wyjścia.
Przychodząc do PHP z Javy, ta cecha języka bardzo utrudnia mi życie z powodu słabej czytelność kodu. Co Wy o tym sądzicie, jakie typowanie wolicie?
To raczej temat na flame. ;)
mr_jaro napisał(a):
Szybkość pisania kodu.
I wprowadzania błędów.
@LukeJL, możesz podać przykład języka ze słabym statycznym typowaniem?
Powiedziałbym, że Visual Basic ze swoim variantem jest najbliższy idei słabego statycznego typowania, ale tak w ogóle to wydaje mi się to oksymoronem — jak coś jest słabo typowane, to (a przynajmniej ja to tak rozumiem) typ zmiennej nie jest dobrze określony na każdym etapie, a jak coś jest statycznie typowane, to typy zmiennych są rozumiane przez kompilator. Czyli musielibyśmy mieć typy, które kompilator rozumie, ale nie są rozumiane…
Szybkość pisania kodu.
Może nie tyle szybkość pisania kodu, co brak jawnego pisania typów w kodzie pozwala na elastyczność w przypadku zmiany zdania - chociaż bardziej mam na myśli typowanie na poziomie całych obiektów, np. duck typing (obiekty nie mają jawnie zdefiniowanych interfejsów/typów, ale każdy obiekt można uznać za obiekt dowolnej "klasy" - wystarczy, że będzie miał w sobie odpowiednie metody/właściwości, których potrzebujemy), albo możliwość dodania/usuwania właściwości i metod z obiektów na żywca.
Nie zawsze są to ładne praktyki, ale jednak przydatne. Nie wiem jak coś napisać, w JS dodaję po prostu właściwości do istniejącego obiektu (czasem nawet w trakcie działania programu, przy debugowaniu) i patrzę co się stanie. Przyśpiesza to prototypowanie rozwiązań..
Natomiast w językach, w których obiekty są zawsze ustalonego "typu", tak się nie da, bo tam wszystko trzeba zadeklarować, czy klasa implementuje dany interfejs, jakiego rodzaju obiekty przyjmują metody, co zwracają itp. Więcej roboty przy sytuacji, kiedy się kod silnie modyfikuje.
@LukeJL, możesz podać przykład języka ze słabym statycznym typowaniem?
Sam się zastanawiam, właśnie dlatego napisałem, że teoretycznie takie istnieją (chociaż podobno C jest takie, ale nie będę się spierał).
brak jawnego pisania typów w kodzie pozwala na elastyczność w przypadku zmiany zdania - chociaż bardziej mam na myśli typowanie na poziomie całych obiektów, np. duck typing (obiekty nie mają jawnie zdefiniowanych interfejsów/typów, ale każdy obiekt można uznać za obiekt dowolnej "klasy" - wystarczy, że będzie miał w sobie odpowiednie metody/właściwości, których potrzebujemy), albo możliwość dodania/usuwania właściwości i metod z obiektów na żywca.
Jak masz odpowiedi system typów to możesz mieć i to i to - wszystko otypowane i jednocześnie elastyczne, w przypadku JS zarówno TS jak i Flow mają typy strukturalne, czyli taki automatyczny duck-typing, przykład we Flow:
// @flow
type FooBar = {
foo: string,
bar: string
}
class Example {
foo: string
bar: string
baz: string
constructor(foo: string, bar: string, baz: string) {
this.foo = foo
this.bar = bar
this.baz = baz
}
}
class AnotherExmple {}
function doSomething (obj: FooBar) {
return JSON.stringify(obj, null, '\t')
}
const result1 = doSomething({ foo: 'elo', bar: 'yo' }) // ok
const result2 = doSomething({ foo: 'elo', bar: 'yo', baz: 'hello' }) // ok
const result3 = doSomething(new Example('elo', 'yo', 'hello')) // ok
const result4 = doSomething({ foo: 'elo' }) // typechecker error
const result5 = doSomething(new AnotherExmple()) // typechecker error
console.log(
result1,
result2,
result3
)
w TS będzie delikatnie inaczej (trzeba jawnie zezwolić na dodatkowe pola, dodając indekser, cała reszta identyczna):
type FooBar = {
foo: string,
bar: string,
[key: string]: any
}
Wydaje mi się, że hejtujesz statyczne typowanie bo nie znasz wszyskich zalet i opcji jakie masz.
Eh, te typowania to jakiś debilizm, przecież każdy wie, że na najniższym poziomie procesor się nad tym nie zastanawia, a tylko wykonuje kod.
Tylko kompilator generuje problem, który sam musi rozwiązać.
Ale ja tam wolę automaty, raz piszesz i od razu obiekt, który jest tym czym chciałeś.
LukeJL napisał(a):
Natomiast w językach, w których obiekty są zawsze ustalonego "typu", tak się nie da, bo tam wszystko trzeba zadeklarować, czy klasa implementuje dany interfejs, jakiego rodzaju obiekty przyjmują metody, co zwracają itp. Więcej roboty przy sytuacji, kiedy się kod silnie modyfikuje.
Co zmusza do myślenia najpierw. Zgadzam się, że przy prototypowaniu fajnie móc sobie rozszerzyć dowolny obiekt o dowolną akcję w dowolnym momencie... Ale jeszcze fajniej jeśli uruchomiony program jest poprawny pod względem typów, no i też łatwiej debugować obiekt zdefiniowany w jednoznaczny sposób niż w przypadku gdy jego definicja jest rozsiana w wiele miejsc, w których ktoś sobie coś akurat dodał.
@LukeJL, możesz podać przykład języka ze słabym statycznym typowaniem?
Sam się zastanawiam, właśnie dlatego napisałem, że teoretycznie takie istnieją (chociaż podobno C jest takie, ale nie będę się spierał).
Ten argument w stosunku do C (i C++) pada chyba z uwagi na łatwość konwersji między typami wynikającą także z możliwości bezpośredniego jeżdżenia po pamięci... Nie nazwałbym jednak tego słabym typowaniem, skoro takich konwersji nie zrobimy przypadkiem, a przede wszystkim każda deklarowana zmienna musi mieć swój typ.
Typowanie statyczne docenia się przy refactoringu najbardziej.
(To takie doświadczenie szczególnie widoczne w TypeScript gdzie typy można opuścić - zgadnijcie gdzie się zwykle wali coś po przeróbkach).
Natomiast konieczność pisania typów przy każdej zmiennej nie dość, że jest mecząca to wcale nie podnosi IMO czytelności... nawet zaciemnia.
Co gorsza w takiej Javie często aby nie psuć czytelności upraszcza się typy i nie używa całej siły generyków (po to żeby potem nie pisać typu na 5 linijek).
@LukeJL, możesz podać przykład języka ze słabym statycznym typowaniem?
W C# masz wszystko naraz w razie potrzeby ;-)
Masz:
string / int / double -> jawne / silne typowanie
var -> słabe typowanie (w momencie kompilacji zamienia się w jeden z typów konkretnych)
dynamic -> niejawne dynamiczne -> typy same mogą się zmienić np. z int-a na stringa lub odwrotnie
object -> silnie niejawne typowanie -> zmiana typów musi być wykonywana jawnie