Показаны сообщения с ярлыком philosophy. Показать все сообщения
Показаны сообщения с ярлыком philosophy. Показать все сообщения

понедельник, 24 ноября 2014 г.

Удивительные факты о наследовании

Говорят, с тех пор, как в Rust и Go убрали наследование, всех сторонников объектно-ориентированной парадигмы ждёт ад и погибель. Даже вроде бы адекватные блоггеры пишут об этом и советуют забыть про ООП. Код, который приводится в качестве примера, настолько прекрасен, что я не могу его не привести:

trait Animal {
  def word: String
  def talk() { println(this.word) }
}
class Cat extends Animal { def word = "Meow!" }

class Dog extends Animal { def word = "Woof!" }

class JustACat { def meow = "Meow!" }

class HappyCat extends JustACat with Animal {
  def word = meow + " :)"
}

class SadCat extends JustACat with Animal {
  def word = meow + " :("
}
val dog = new Dog()
dog.talk

"Вот по большому счету и все, что нужно знать об АТД и классах типов" сообщает нам автор. "Забудьте об ООП! Используйте АТД и тайпклассы!".

Не имею ничего против trait-ов и языка Scala, но такой пример реализации ООП порадует разве что борцов за права домашних животных. Абсолютно непонятно, какое отношение к реальным программам имеют все эти котики и собачки и как собрать из этих грузок и перегрузок что-то работающее. Вспоминать Майерса или Буча тут не стоит - куда уместней общеизвестная песенка:

Я жму на велике любимом,
Он зовется "Украина"
Но седло от унитаза,
А педаль от пианино.
Все потырили друзья,
В двух местах сломали раму,
Ну и пусть себе смеются,
Металлисты-наркоманы!

Раз уж пошла такая путаница, надо разобраться, какое бывает ООП. Обычно под ним понимают что-то в духе C++/C#/Java - модификаторы public/private/protected, виртуальные функции, наследование, и проч., проч., проч.

Но есть языки наподобие Python, Ruby или PHP - где приватных полей нет вообще, а приватность функций зависит от доброй воли пользователя библиотеки, а типы можно сравнивать через duck typing. При этом наследование в них очень разное: в PHP оно аналогично Java (можно наследовать только от одного класса), Python разрешает множественное наследование, а в Ruby разрешает новомодные подмешивания (впрочем, большинство пользователей про них не в курсе).

Есть, наконец, JavaScript, где наследование через прототип настолько загадочно, что некоторые даже пишут свои обёртки, чтобы заменить его на что-то более привычное. И многие из этих обёрток реализуют и множественное тоже.

Ну и на закуску - есть известные реализации псевдо-ООП на C (вроде тех, что встроены в GTK и WinAPI), есть языки-надстройки вроде Lua, и громадную, ещё с начала 1990-х историю ORM для записи унаследованных объектов в реляционные базы данных.

Как легко заметить, главное в ООП - наследование, а наличие приватных полей и виртуальных функций - дело десятая. Куча народу пишет на JavaScript и не в курсе про его систему наследования, или на Python, а наследуют "как привыкли", с интерфейсами и основным классом.

О чём и было сказано уже в другом блоге, где дискуссия продолжалась: Ситуация усугубляется еще и тем, что из широкоизвестных ОО языков чисто ОО языками являются всего два -- Java и Eiffel.

четверг, 24 июля 2014 г.

В борьбе за достоверность

Итак, фальсификации.

Поддельные фото, видео, документы, высказывания, события, люди.

В последнее время (камеры дешёвые, видеоредакторы быстрые и общедоступные) их больше с каждым днём.

В итоге с журналистами происходят скандалы, официальные лица говорят странные вещи и все обвиняют друг друга, что дурят честной народ.

И пока кто-то воюет, а кто-то требует воюющих прекратить, эксперты всех мастей ищут способ докопаться до достоверных данных. Конечно, если пригласят в ток-шоу, то можно любую чушь нести, - но если большая корпорация наняла за большие деньги? или кто-то из государственных мужей требует прокомментировать? Не скажешь же ты, что "танки на фотографии есть, а есть ли там фотошоп - не знаю, я им не пользуюсь".

Первый вариант я нашёл на постнауке. Там выложена интересная глава из книги на тему (вставлю, если найду). Сводится к тому, что единственной защитой является 100% идентификация времени-места съёмки и человека, который её вёл. То есть если Вася из Ростова-на-Дону снял на мобильник летающую тарелку, то в свойствах видео это должно быть написано, а сам Вася, если попросят, должен предъявить паспорт, мобильник, самого себя и место, где он снимал (а также, желательно, летающую тарелку).

Конечно, это хороший способ доказать, что видео настоящее (про тарелку не говорим). К сожалению (как мы знаем из новостей), это не подходит для кадров от которых действительно что-то зависит. Если ты - местный житель и заснял военное преступление, то подписываться под ним ты точно не будешь. Хотя бы потому, что следующее военное преступление могут устроить с тобой.

Другой вариант - сдаться и решить, что они все друг друга всё равно дурят. Люди древности успешно выживали без международных новостей и это не мешало им охотиться на мамонтов.

Если новости на тебя не влияют никак, то это работает. Но в этом и есть недостаток. Отказаться от ненужных новостей могут те, кому они не нужны.

А если это твоя работа? Если у заказчика в той стране контракты, заводы, газеты и пароходы? Конечно, эксперт может уйти в управдомы, но проблема от этого никуда не уйдёт.

Третий вариант предлагает Николай Караев - со временем возникнут что-то наподобие орденов или корпораций высококлассных экспертов и журналистов, которые заведомо сначала думают, а потом говорят.

Это поможет исправить проблему... но не ту, ради которой всё затевалось. Дело в том, что новость нужна быстро. Министр должен сделать заявление, президент принести соболезнования, новость уйти в эфир, не дожидаясь, пока комиссия или суд закончит свою работу. Даже признанный эксперт не всегда может быстро разобраться в проблеме, а консультативные комиссии заседают годами (и полное заключение может попросту лечь в архив - как в случае с Чхонаном).

Вот у нас есть фото, видео или аудиозапись. Мы пригласили в студию... да хотя бы даже бывшего разведчика (на CNN бывает). И спрашиваем, что он о ней думает. А он отвечает честно: дескать, я не знаю, тут смотреть в лаборатории надо, нет ли монтажа. Да и вообще в наше время такого не было.

Конечно, это ни разу не экспертиза. Мало ли чего не было двадцать лет назад? Во времена Рейгана и Linux-а не было - а при Буше-старшем появился. И не в США, а где-то в Финляндии. Может, и это "такое" появилось только в последнее время и не успело дойти до США.

Видимо, когда окончательно прижмёт, будут придуманы какие-то социал-инженерные решения для работы с подделками.

Или человечество просто забьёт.

воскресенье, 1 декабря 2013 г.

Братья наши соломенные

Если у X есть недостатки, это не всегда значит, что X - плохо. Например, у легендарных Соломенных Енотов львиная (даже не енотная!) доля песен написаны 7-стопным ямбом и поэтому кажутся одной и той же песней.

Но это не значит, что Соломенные Еноты - плохая группа. Они хорошие. Особенно поздние.

вторник, 20 августа 2013 г.

Ads and Reality of Functional Programming

There’re a lot of rumors about functional programming now. For example, a lot of people say (mostly on forums) that only really smart guys can learn a functional language and in the short time a Java/C#/C++ programmer will look like a pure C programmer in our age.

Why will functional languages win? Because “they are languages of future” and “I like them”. One more thing: a Haskell program looks really difficult. How can you beat such a difficult thing?

But I don’t think so. Functional languages are very active now, they give great influence to Object Oriented ones, Ruby, Python, PHP, Java, C#, even C++ are implementing lambdas and mapping. But “being futuristic and unusual” and “look difficult” aren’t features. It isn’t even the truth.

Firstly, functional languages are much older then Object Oriented ones. LISP was released in 1958, and became popular in Algol time. They had really plenty of time to beat Fortran or Pascal, but they didn’t. Even today there’re plenty of languages with functional influence, there’re plenty of languages where functional style is possible, but the pure functional family is very little: LISP relatives (they are surviving in Closure, Emacs and SICP, but even SICP course is studied  today with examples on Python), Haskell (more studied then used), Erlang (needed only if you work for Sony Ericsson) and ML languages (OCaml/F# and Scala). All of them look unusual. if you were teached programming on Pascal/C++/Java/Python and are very usual for stufent who studied SICP. LISP was used even in Soviet Union (there’re some translations of handbooks made in 1988-1990).

Even Google uses C++/Python/Java, not Scheme or Haskell.

Secondly, if you need really unusual and different things, try quantum mechanics. The simpler code is, the cheaper will be support. If you aren’t sure, do you need the easy supported code, ask your vendor.

But what’s the thing that make functional languages useful? Let’s look to very ancient (1984, last edition at 1990) paper by a guru:


  1. Glueing Functions Together – you can glue functions and objects they generate as easy as you glue modules of your application.
  2. Glueing Programs Together – any program on a functional language is a function and can be used this way easily
  3. Lazy evaluation makes functional language a good choice to write AI (this was even in Soviet-time books on computer science from 1990!). Because of it, you can avoid storing in memory all of the wrong variants during position analysis.

Have you met this pros in any of functional languages polemics? Or they aren’t important anymore?

If you didn’t, there aren’t any gurus in this thread. There’re just people who show you rare things that are fashionable only because they are rare. Such a people will never make functional languages popular: when something can be used my everyone, it isn’t cool and fashionable anymore.

Studying and using the ideas from functional programming is the business of “simple” programmers on C++-like languages. Because we are only ones who can find place for all of pretty lambdas, closures and monads.

вторник, 12 июня 2012 г.

UnitTest: Что такое UnitTest?


Unit в UnitTest - это unit of work. То есть a use case, вызванный public method-ом и закончившийся result-ом. А result-ом может быть:
  1. Возвращаемое значение или Exception.
  2. Заметные изменения в системе. Заметные - значит, система после них работает по-другому. Например, добавление пользователя - это заметное изменение, потому что теперь под ним можно заходить.
  3. Вызов внешней системы, которую мы не можем контролировать во время теста. Например, файловая система, сеть, user threads, или любая другая зависимость, которую мы не можем контролировать и которая выполняется медленно.
Для 3-его типа нужно использовать mock-объекты. Для 1-2 - порвать все зависимости и проверять возвращаемое значение или состояние системы.

Вроде бы просто. Тем не менее, я понял, что отчего-то был уверен, что UnitTest-у и случая 1 достаточно. Хотя уже созданы обёртки для эмуляции файловой системы. Или вот эксперименты над Python

Blog: Оптимальный формат

Оптимальный формат программистского блога очень хорошо формулирует английское слово papers. Т.е., наброски по какому-то вопросу, выложенные в сеть, чтобы не потерялись.

Нечто наподобие научных заявок на статьи. За некоторые из научных papers даже дают миллион - например, за известный paper Григория Перельмана.

пятница, 8 июня 2012 г.

Phylosophy: ElseIf vs Switch, Python vs XSLT

There're ELSEIF operator in Python, and there aren't any SWITCH.

There're SWITCH operator in XSLT (aka <xsl:choose>), and there aren't any ELSEIF. There aren't any ELSE in it even.

вторник, 22 мая 2012 г.

Books: Паттерны, сэр!

Кто-то издаёт толстенные тома, в которых переводит стандартные паттерны из известной книжки на C#, Java, Python...

А кто-то новые печёт!

пятница, 18 мая 2012 г.

Philosophy: Паттерны - 2

Wolfgang Pree из Зальцбурга тоже исследовал паттерны и написал про них книжку. В отличии от писаний "банды четырёх", в Рунете про неё почти никто не слышал.

Даже перевода нет.

Зато есть конспект на английском.

пятница, 4 мая 2012 г.

Life: Музыка паттернов проектирования

В "Русских Ночах" Одоевского очень много разговоров о музыке. В те времена рассуждали примерно так: у животных нет понятия о красоте, хотя есть понятие о логической связности мира (т.е., разум). Но человеку красота доступна. Не в этом ли его тайна? И ещё - из всех искусств музыка выглядит наиболее "бесполезной" и ни на что в материальном мире не похожей, в отличии от архитектуры, скульптуры, литературы и живописи. Не в ней ли тайна прекрасного?

Может быть, именно способность воспринимать прекрасное сделала человека человеком? Прекрасное чувствует и европеец, и древний грек, и древний египтянин. Даже дикарь с далёких островов Полинезии замирает, очарованный величественным водопадом, а вернувшись в хижину, он делает их дерева нарядные украшения. Напротив, филистёр этого лишён - и потому ближе к животному, чем к человеку.

Неспроста так популярно в ту эпоху система Шеллинга, а главным героем романтической прозы очень часто становится музыкант. Про музыку пишут так проникновенно, что и не снилось современному искусствоведу. Даже меркантильный человек наших дней заинтересуется классикой после "Себастиана Баха" и "Последнего концерта Бетховена". Искусство классической музыки сложно, красиво и, самое гласное, её много. Стройное здание классической музыки похоже на дворец - а кто из людей не хотел бы хоть недельку пожить во дворце?

Будет здорово, если хотя бы один программист отнесётся к своей работе ка персонажи эры романтизма относились к музыке. Сел за клавиатуру - и начал творить симфонию или кантанту, изобретая, переделывая и что-то отбрасывая. Конечно, есть ещё и заказчик... но у музыки барокко, Баха и Бетховена тоже были заказчики.

Кто знает - может, ремесло программиста станет тогда более возвышенным. А их код - более гармоничным.

Ведь программирование - это тоже искусство. Это выражается, например, в том, что программисты обычно сами не могут объяснить, как они делают то, что делают. Как у композиторов или у исполнителей - у величайших есть своя манера. Для кого-то и Perl недостаточно гибок, а для кого-то - например, для Линуса Торвальдса - и C++ есть излишество, эксплуатирующее достоинства чистого C.