Programming Language Paradigms

Transcript

1. Парадигми в езиците за програмиране Стефан Кънев http://skanev.com/ @skanev OpenFest 3 ноември 2012 София
2. Стефан
3. twitter: @skanev github: skanev blog: http://skanev.com/
4. ⽃⽄ Ruby, Ruby, Ruby ̆̇㽈
5. Ruby & Python
6. Всеки път
7. “Разчупен лед”
8. Днес нямам време за това!
13. Aspect-Oriented Programming Object-Oriented Programming Functional Programming Imperative Programming Structured Programming Logical Programming Language-Oriented Programming
14. ще гледаме нещата отгоре-отгоре
15. размисли на които ме навеждат
16. Wikipedia дефинира “програмна парадигма” като фундаментален стил за програмиране (или “парадигмален стил за програмиране”)
17. семантика организация възможности runtime
18. семантика кое какво значи
19. организация как и на какво разделяме програмата
20. възможности какво е разрешено и какво е забранено
21. runtime код, работещ заедно с програмата ни
22. няколко неща за парадигмите
23. Един език може да е едновременно функционален и обектно-ориентиран
24. Няма нито “чисто обектно-ориентирани” езици, нито “чисто функционални” езици.
25. Парадигмите нямат еднозначна дефиниция. Няма конкретно свойство, което да прави езика функционален или нефункционален.
26. No silver-bullet-oriented programming
27. Aspect-Oriented Programming
28. AspectJ
30. [ˈzɛrɒks,]
31. Искаме да преведем пари от една сметка в друга...
32. void transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) throws Exception { Transaction = new Transaction(); try { transaction.begin(); logger.info("Transferring money..."); if (!checkUserPermission(user)) { logger.info("User has no permission."); throw new UnauthorizedUserException(); } if (fromAcc.getBalance() < amount) { logger.info("Insufficient funds, sorry."); throw new InsufficientFundsException(); } fromAcc.withdraw(amount); toAcc.deposit(amount); transaction.commit(); logger.info("Successful transaction."); } catch(Exception e) { transaction.rollback(); throw e; } }
33. void transfer(Account fromAcc, Account toAcc, int amount) throws Exception { if (fromAcc.getBalance() < amount) { logger.info("Insufficient funds, sorry."); throw new InsufficientFundsException(); } fromAcc.withdraw(amount); toAcc.deposit(amount); }
34. Трансфер Заем Погасяване Logging Transactions Authorization Cross-cutting concerns
35. aspect TransactionLogging { before(): target(Account) && call(void withdraw(int)) { Logger.getLogger().info("Transferring money..."); } } COMEFROM
36. Разделя кода на малки, независими и тестваеми парчета.
37. @transactions @logging @authenticate def transfer(sender, receiver, amount): if sender.balance() < amount: raise "Insufficient funds" sender.withdraw(amount) receiver.deposit(amount) Подобно, но не AOP
38. Object-Oriented Programming
39. ...или грешните неща, на които ни учиха в училище.
40. Данни + Функци = Обекти
41. Alan Kay
42. Разделяме програмата на малки, независими компоненти, които си общуват с изпращане на съобщения.
43. Алан Кей твърди, че обмяната на съобщения между обектите е по- важна от самите обекти. http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
44. Добрия обектно-ориентиран дизайн има много на брой, малки на размер, прости класове. Същината му е в комуникацията между тях.
45. Основната ценност е улесняване на поддръжката и разширяемостта на системата.
46. много прост пример
47. collection = MusicCollection.new extract_songs(input).each do |song| collection.songs << song end Лош обектно-ориентиран код
48. collection = MusicCollection.new extract_songs(input).each do |song| collection.add_song(song) end Добър обектно-ориентиран код
49. още по-прост пример
50. public static float area(Circle circle) { return PI * circle.radius * circle.radius; } Лош обектно-ориентиран код
51. class Circle { public float area() { return PI * radius * radius; } } Добър обектно-ориентиран код
52. Наследяване
53. Наследяването се използва по-рядко, отколкото учебниците ни карат да си мислим.
54. Причина №1 наследяването да е неразбрано
55. ⸮
56. Основната теза на книгата е “предпочитайте композиция пред наследяване”. За нещастие, остава неразбрана.
57. Наследяването има две предназначения в повечето езици за програмиране.
58. Преизползване на код Моделиране на релация IS (подтип) OK Бърз път към ада
59. Liskov Substitution Principle
60. Liskov Substitution Principle
61. Клас Child може да наследява клас Parent, само ако на всички места, на които програмата приема Parent може да подадем Child. class Child extends Parent
62. Functional Programming
63. Три неща функции от по-висок ред намаляване/премахване на странични ефекти мощна типова система
64. Haskell, Erlang, LISP, OCaml, F#
65. map & filter (функции от по-висок ред)
66. emails = [] for user in users if user.active? emails << user.email end end notify(emails)
67. emails = users.select { |u| u.active? }.map { |u| u.email } notify(emails)
68. Въпросът е: кое от двете е по-ясно?
69. Често когато покажа това на някого, той ще каже, че първия вариант е по-ясен. Но за мен втория вариант е по-ясен. Защо?
70. Експеримент: кое от следващите две изречения е по-ясно?
71. ϧϏΛ࢖ͬͯخ͍͠։ൃऀʹͳΔɻ ϧϏΛ࢖ͬͯخ͍͠ιϑτ΢ΣΞΛ࡞ΔਓʹͳΔɻ
72. map и filter са част от “азбуката”
73. В момента за мен map и filter са по- четими. Първия път като ги видях не бе така.
74. accidental vs. essential complexity
75. странични ефекти (още състояние/state)
76. Писането без странични ефекти е като здравословния начин на живот – всеки го подценява докато не го пробва.
77. Липсата на странични ефекти прави кода декларативен. Така той е по-лесно четим.
78. Наличието на странични ефекти превръща кода в императивен. Това го прави по- трудно разбираем.
79. 83% от всички бъгове са породени от код със странични ефекти Lorenzo van Matterhorn учен
80. Конкурентност
81. Липсата на странични ефекти сериозно опростява паралелизацията на приложението.
82. типова система
83. Типовата система ни гарантира по време на компилация, че цял клас от грешки няма как да възникнат.
84. Типовата система на един функционален език е далеч по-развита от тази на (например) Java.
85. Type Inference
86. Типовата система е feature на езика, подобно на наследяване. Може да я карате да върши работа вместо вас.
87. The Expression Problem
88. Нека разгледаме система, в която имаме типове (кръг, квадрат) и операции (обиколка, лице).
89. class Circle def initialize(center, radius) @center, @radius = center, radius end def area Math::PI * @radius * @radius end end class Square def initialize(top_left, side) @top_left, @side = top_left, side end def area @side * @side end end ООП
90. ФП Circle = Struct.new(:center, :radius) Square = Struct.new(:top_left, :side) module Geometry extend self def area(shape) case shape when Circle then Math::PI * shape.radius * shape.radius when Square then shape.side * shape.side end end end
91. Ще разгледаме какво се случва когато искаме да добавим нов тип или нова операция.
92. class Circle def initialize(center, radius) ... def area ... def circumference 2 * Math::PI * @radius end end class Square def initialize(top_left, side) ... def area ... def circumference 4 * @side end end Операция в ООП ☢
93. module Geometry def area(shape) case shape when Circle then Math::PI * shape.radius * shape.radius when Square then shape.side * shape.side end end def circumference(shape) case shape when Circle then 2 * Math::PI * shape.radius when Square then 4 * shape.side end end end Операция във ФП ✔
94. class Rectangle def initialize(top_left, width, height) @top_left, @width, @height = top_left, width, height end def area @width * @height def circumference 2 * @width + 2 * @height end end Тип в ООП ✔
95. module Geometry def area(shape) case shape when Circle then Math::PI * shape.radius * shape.radius when Square then shape.side * shape.side when Rectangle then shape.width * shape.height end end def circumference(shape) case shape when Circle then 2 * Math::PI * shape.radius when Square then 4 * shape.side when Rectangle then 2 * shape.width + 2 * shape.height end end end Тип във ФП ☢
96. ООП ФП Тип Операция Лесно Трудно Трудно Лесно The Expression Problem
97. Обърнете внимание, че функционалния подход ще изглежда грешно в Java.
98. извод
99. всеки език ни поставя рамки
100. Рамките създават структура, която е позната на повечето програмисти в дадената среда.
101. Рамките могат да бъдат и нож с две остриета. Какво става ако пишем на Java и ни трябва често да добавяме нови операции?
105. Труден въпрос: кога да стоим в рамките на един език и кога да излезем от тях?
106. Imperative Programming
107. фон Нойман езици
108. Давате ясни и точни инструкции на компютъра какво да направи.
109. emails = [] for user in users if user.active? emails << user.email end end notify(emails)
110. Кога императивното програмиране е подходящо?
111. Скорост
112. Някои алгоритми са естествено императивни. В този стил са много по-ясни.
113. Structured Programming
114. Едсгар Дийкстра
115. Едсгар Дейкстра е известен със спорната си фамилия и с това, че е открил блог поста.
116. Структурирано програмиране a.k.a. бунта на Дайкстра срещу GOTO
117. Не просто goto в C, а всякакви jump-ове (Assembler, BASIC)
118. Структурираното програмиране предлага набор от езикови абстракции, които да заменят GOTO
119. Структурирано Неструктурирано for, while goto функции goto блокове goto
120. class Structured extends Imperative * not sure about LSP
121. Böhm-Jacopini theorem
122. Всеки алгоритъм може да се изрази само с три вида конструкции.
123. sequence selection iteration
124. Няма да вземам отношение за GOTO, но...
125. ...Кнут твърди, че определен код е по-четим с GOTO...
126. ...Д[аеи]йсктра показва как употребите на GOTO могат да се премахнат...
127. ...има теорема твърдяща, че може да напишете всичко без GOTO...
128. ...не съм писал на език с GOTO отдавна.
129. Но пък от време на време пиша на език с COMEFROM!
130. Logical Programming
131. Не давате на компютъра решение, а проблем. Той намира решението вместо вас.
132. Подходящо за бързи/мързеливи сметки
133. Има ред специални приложения
134. Изисква особен runtime
136. 1. The Brit lives in a red house. 2. The Swede keeps dogs as pets. 3. The Dane drinks tea. 4. The green house is next to, and on the left of the white house. 5. The owner of the green house drinks coffee. 6. The person who smokes Pall Mall rears birds. 7. The owner of the yellow house smokes Dunhill. 8. The man living in the centre house drinks milk. 9. The Norwegian lives in the first house. 10. The man who smokes Blends lives next to the one who keeps cats. 11. The man who keeps horses lives next to the man who smokes Dunhill. 12. The man who smokes Blue Master drinks beer. 13. The German smokes Prince. 14. The Norwegian lives next to the blue house. 15. The man who smokes Blends has a neighbor who drinks water. Who has the fish? Einstein’s Riddle
137. BEWARE! HERE BE DRAGONS!
138. solution(People) :- People = [_, _, _, _, _], same(brit, red, People), same(swede, dogs, People), same(dane, tea, People), left_of(green, white, People), same(green, coffee, People), same(birds, pall_mall, People), same(yellow, dunhill, People), center_house(milk, People), first_house(norwegian, People), neighbors(blends, cats, People), neighbors(horses, dunhill, People), same(beer, blue_master, People), same(german, prince, People), neighbors(norwegian, blue, People), neighbors(blends, water, People), maplist(person, People), flatten(People, Items), is_set(Items).
139. has(Thing, Person) :- nationality(Thing), Person = [Thing, _, _, _, _]. has(Thing, Person) :- color(Thing), Person = [_, Thing, _, _, _]. has(Thing, Person) :- pet(Thing), Person = [_, _, Thing, _, _]. has(Thing, Person) :- beverage(Thing), Person = [_, _, _, Thing, _]. has(Thing, Person) :- cigars(Thing), Person = [_, _, _, _, Thing]. same(A, B, People) :- has(A, Person), has(B, Person), member(Person, People). first_house(A, People) :- has(A, Person), People = [Person, _, _, _, _]. center_house(A, People) :- has(A, Person), People = [_, _, Person, _, _]. left_of(A, B, People) :- has(A, PersonA), has(B, PersonB), nextto(PersonA, PersonB, People). neighbors(A, B, People) :- left_of(A, B, People); left_of(B, A, People).
140. has_fish(Nationality) :- solution(Solution), member([Nationality, _, fish, _, _], Solution).
141. ?-
142. ?- has_fish(Answer).
143. ?- has_fish(Answer). Answer = german.
144. Language-Oriented Programming
145. Развиваме собствени езици, които описват проблема по-добре.
146. Embedded DSL
147. Огъваме езика да ни даде по-добро API
148. class Comment < ActiveRecord::Base validates_presence_of :body belongs_to :user belongs_to :revision attr_protected :user_id, :solution_id delegate :solution, to: :revision delegate :task, :task_name, to: :solution def editable_by?(user) self.user == user or user.try(:admin?) end def user_name user.name end end
149. Macros
150. Разширяваме синтаксиса
151. (define-syntax unless (syntax-rules () ((_ condition body) (if (not condition) body (void)))))
152. (unless (belly-full?) (begin (eat) (drink)))
153. DSL
154. Правим какъвто си искаме език (заедно с парсер и интерпретатор)
155. Scenario: Purchasing goods with coupons Given a product "MacBook Air" that costs 2000$ And a discount coupon "CUCUMBER" for 10% When I add "MacBook Air" to my bag And I apply the coupon "CUCUMBER" Then I should have to pay 1800$ Cucumber
156. In Closing
157. аспектно-ориентирано AspectJ in Action
158. обектно-ориентирано SmallTalk Best Practice Patterns Implementation Patterns Design Patterns Refactoring Refactoring to Patterns MIT 6.170 записки
159. c2.com
160. функционално програмирнане Haskell (която и да е книга, сериозно) Structure and Interpretation of Computer Programs A Little Java, A Few Patterns
161. две наблюдения един възглед
162. Езика ни дава рамки, които структурират програмата ни. Това я прави по-разбираема за всички останали.
163. Рамките понякога ни водят към лоши решения и трябва да знаем кога да излизаме от тях.
164. Разбирането на теоритична материя прави кода ни по-добър.
165. Благодаря ви!