Wszystko jest wyrażeniem

Question

Zauważyłem, że wiele języków, takich jak Ruby i CofeeScript (również transcompiler), obsługuje wszystko, co jest wyrażeniem.

Teraz sprawia, że ​​język jest nieco prosty do zrozumienia i zdecydowanie wydaje się być czysty na powierzchni, ale szukałem może niektórych publikacji naukowych na temat pozytywów i negatywów tych dwóch podejść.

Byłoby korzystne, gdyby publikacje miały wyraźne przykłady, które porównywały korzyści wynikające z tego, że wszystko było wyrazem, a raczej nie.

Przykłady w języku CoffeeScript kontra Javascript byłyby dobre, ale niewymagane.

Koncept jest zdecydowanie fajny, ale wciąż nie jestem pewien, jak bardzo rewolucyjny jest ten pomysł (oczywiście coś rewolucyjnego jest w pewnym sensie opinią).

Dzięki!

Answer 1

Nie ma w tym nic rewolucyjnego. Podejście expression-oriented jest techniką functional programming.

Kod zorientowany na wyrażenie jest prostszy i mniej zagracony niż kod zorientowany na instrukcje, z powodu mniejszej liczby assignments i żadnych wyraźnych instrukcji return. Brak rozróżnienia między wyrażeniami i poleceniami umożliwia spójność koncepcyjną (zobacz: Referential transparency) i bottom-up.

Niektóre współczesne języki przyjęły koncepcje programowania funkcjonalnego (np. C#, Python, Ruby).

Niektóre naukowe spojrzenie na korzyści płynące z praktyki funkcjonalnych:

• Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs - John Backus

Ciekawe artykuły:

• Why Functional Programming is Important in a Mixed Environment
• Is C# becoming a functional language?

chodzi o komentarz na temat problemów z wydajnością, ewentualne koszty stałe związane z wyborem paradygmatu jest prawdopodobnie znikomy.Nawet w C większość stwierdzeń evaluate as an expression - jednak porównanie między językiem kompilowanym (C) a językiem interpretowanym (CoffeeScript) jest raczej bezużyteczne.

Na uwadze teoretycznej, imperative language reprezentuje przepływ sterowania bardziej w sposób zorientowany na maszynę, co może pozwolić na łatwiejszą optymalizację ręczną niż język funkcjonalny.

Skuteczność języka i jego znaczenie zależą w dużym stopniu od użycia. Odnośnie JavaScript i jakiejkolwiek transformacji kodu na górze, ta dyskusja dotycząca wydajności jest zupełnie nieistotna. Wzrost produktywności przeważa nad każdym trafieniem wydajności.

Answer 2

Przez „wszystko jest wyrazem” Zakładam, że to co jest opisane w http://jashkenas.github.com/coffee-script/

To trochę brzmi jak co pytasz o to języki funkcjonalne. Rozważmy na przykład Lispa, który zrobił coś podobnego w latach pięćdziesiątych. To ostatecznie wychodzi z rachunku Lambda, w którym kod i dane są naprawdę tym samym, i możesz przekazać kod tak, jakby był danymi (ponieważ tak jest).

Nie znam żadnych artykułów naukowych omawiających to konkretnie, ale teraz masz przynajmniej kilka słów kluczowych do wyszukania.