Eliksir: uzasadnienie pozwalające na ponowne powiązanie zmiennych

Question

Jakie są przesłanki pozwalające na ponowne wiązanie zmiennych w eliksiru, gdy Erlang na to nie pozwala?

Answer 1

Ponieważ jest to prostsze.

Spójrz na this question zamieszczonych na liście dyskusyjnej Erlang w roku 2009. Konkretnie ten fragment:

---

Lubię dopasowanie wzorca w większości przypadków, ale uważam, że piszę tyle kod, w którym potrzebuję aktualizować przyrostowo strukturę danych, i utrzymywanie tego kodu jest uciążliwe, gdy mam kod taki jak:

X = foo(), 
X1 = bar(X), 
X2 = xyzzy(X1), 
blah(X2). 

a później chcą go zmienić na:

X = foo(), 
X1 = whee(X), 
X2 = bar(X1), 
X3 = xyzzy(X2), 
blah(X3). 

redakcji - to jest odpowiedź na to pytanie.

To bardzo często przechodzi przez IRC. Jest to wynikiem złej praktyki nazywania zmiennych i nie ma potrzeby wprowadzania ponownego wiązania w celu "naprawienia" tego; po prostu przestań używać pojedynczych liter i liczników jako nazw zmiennych.

Jeśli na przykład, że został napisany

FooStateX = foo(), 
PostBarX  = bar(FooStateX), 
OnceXyzziedX = xyzzy(PostBarX), 
blah(OnceXyzziedX). 

---

Kod wykazać, że nie jest wcale tak rzadkie w Erlang (uwaga uwaga „To przechodzi przez IRC dużo”). Zdolność eliksirów do ponownego wiązania nazw oszczędza nam konieczności generowania nowych nazw dla rzeczy przez cały czas. To wszystko. Warto pamiętać, że oryginalni twórcy Erlanga nie próbowali budować funkcjonalnego języka. Byli po prostu pragmatycznymi programistami, którzy mieli problem do rozwiązania. Podejście Elixir to prosty pragmatyzm.

Answer 2

Oto uzasadnienie prosto z pierwszej ręki:

http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-variables/

Answer 3

języki najbardziej funkcjonalnych nie pozwalają na ponowne związanie zmiennych w tym samym zakresie. Tak więc eliksir pozwalający na to zdecydowanie nadaje mu niefunkcjonalny, imperatywny charakter. Problemem Erlanga jest raczej brak zakresu lub dokładniej, że istnieje tylko jeden zakres w całej klauzuli funkcji. Mieliśmy poważne dyskusje, czy wprowadzić zakres, ale ostatecznie zdecydowaliśmy się go odrzucić, ponieważ był on wstecz niezgodny z istniejącym systemem. A programiści nienawidzą niespójnych zmian wstecz.

Sposób Erlang ma jedną poważną zaletę: jeśli źle zrobisz, generalnie pojawia się błąd, więc możesz popełnić błąd.Porównywano po prostu dziwne zachowanie, gdy zmienna nie ma wartości, której oczekuje się, aby była trudniejsza do wykrycia i poprawienia.

Osobiście uważam, że problem nowych nazw zmiennych, na przykład przy użyciu schematu numerycznego, jest znacznie przesadzony. W porównaniu do czasu, jaki zajmuje mi opracowanie WHAT Mam zamiar zrobić zmianę nazw zmiennych jest trywialne. A po chwili widać to bez zastanowienia. Szczerze.

EDIT:

Również podczas łączenia danych za pośrednictwem sekwencji funkcji faktyczne znaczenie danych zmienia się więc ponowne użycie tej samej nazwy zmiennej może być bardzo mylące. Może to w końcu oznaczać ogólne "dane, które przechodzą z jednej funkcji do drugiej".