Книшки итд.

[yigal_s]

"Приобрел для ознакомления"

Art of Multiprocessor Programming. Herlihy etc. - Revised Edition (!!!)
Actors in Scala. Haller etc.
An introduction to Parallel Programming. Pacheco.
Structured Parallel Programming. McCool etc.
SOA in practice. Josuttis

То есть, книжками по мультитреду (который на хорошем уровне нахер никому не нужен) я уже укомплектован очень неслабо, читай - не хочу.

Кстати, вдруг появилось
- третье издание "Advanced programming in the UNIX environment", а также
- четвёртое (так и хочется сказать заключительное) издание Страуструпа. The С++ Programming Language.

Вообще, программирование сейчас ИМХО переживает взрывообразное развитие, связанное с

а) некоторой уже закритичной скоростью появления новых или входом в рынок старых но малоизвестных технологий (а не просто buzzwords), языков и подходов, новых платформ
б) переводом программиста в статус многознающего, но полутупого фабрично-конвеерного рабочего (все эти agile, scrums, TDD).

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

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

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

Comments

[mikkim08.livejournal.com]

Не уверен в актуальности "Actors in Scala", Haller'а. Политика партии сейчас вроде в том, чтобы заменить оригинальные скальные акторы на Акку до полного слияния.

Насколько я понял, в Скале 2.10 теперь часть Акки перетащили в Скалу (а в Акке соответствуюшие APIs задепрекейтили), так что в результате надо пользоваться и теми, и другими, что не очень красиво выглядит.

[yigal_s]

вот с акторами у меня никак времени не хватает толком разобраться (мало времени и ЖУТКО имхо зашумленная тема), а об Akka я не слыхал. Спасибо за наводку.

Кстати, можете что-то посоветовать почитать об акторах вменяемого и мозгорасширяющего?

(книга, кстати, довольно старая, но только сейчас появилась ее полная версия для ознакомления ))))

[mikkim08.livejournal.com]

К сожалению не смогу помочь. Я тоже в акторах не очень, и читаю в основном все в интернетах, потому что книжки устаревают как-то быстро.

[yigal_s]

ну вот с акторами, казалось бы, Эрланг и Ada должны были всё закрыть уже много лет назад. Но нет же, идёт какое-то непонятное копошение, смысл которого при отсутствии практического опыта и времени даже на теоретическую подготовку - мне несколько не до конца ясен.

[mikkim08.livejournal.com]

Я про Аду с Эрлангом совсем ничего не знаю. Я только Скалу/Акку пытаюсь понять.

[ursego.livejournal.com]

так и хочется сказать заключительное

:-))))))

[ursego.livejournal.com]

Страус всё ещё не труп...

[yigal_s]

Я, конечно, ему желаю долгих лет (ибо верю, что всё плохое сделал он не со зла и не от подлости), но многие брендовые книги, тот же "Advanced programming in the UNIX environment", спокойно себе выходят в новых изданях после смерти авторов.

Вот что я не желаю долгих лет С++ -- это да.

[ursego.livejournal.com]

Вот что я не желаю долгих лет С++ -- это да.

Вообще непонятно как этот мамонт до сих пор не вымер. Но когда помрёт - благодарное человечество установит на его могиле два креста.

[yigal_s]

молон лабе -- "приди и возьми"

убийцы С++ так и не появилось, хотя потеснили его изрядно

[beldmit.livejournal.com]

C++ за 20 лет моих взглядов в ту сторону мутировал не до потери сходства, но близко к тому...

[mikkim08.livejournal.com]

переводом программиста в статус многознающего, но полутупого фабрично-конвеерного рабочего

Тут есть некоторое противоречие :) Но ситуация действительно требует в определенном смысле копать вширь, а не вглубь. Так например лучше изучить какой-нибудь новый язык, чем продолжать изучать тонкости С++ (если Вы, конечно, не его компилятор пишете).

То же самое, наверное, и с мультитредингом. Лучше сделать новую фичу, чем вылизывать инфраструктуру с мультредингом. И даже если из-за непонимания мультрединга будет сбой, невелика беда. Аппликацию перезапустят, добавят еще один сервер в горячем резерве и т.д. А фича она народу нужнее.

Опять же не везде, наверное. Возможно, в embedded есть ниши, где это не так, но в прикладном программировании в целом вдаваться в тонкости, наверное, не надо.

[yigal_s]

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

Сбой мультитреда бывает разный - могут и данные критичные записаться неправильно, например. Но в принципе, учитывая, что мы не марсоход запускаем, а ненайденные ошибки можно списать на ленность отдела тестирования ))) и опять же учитывая ваше совершенно справедливое замечание, что креш сервера нам нынче не помеха, то я согласен, в принципе. Фичи, а дальше хоть трава не расти. Хотя персонально у меня душа лежит совсем к другому.

[mikkim08.livejournal.com]

Хотя персонально у меня душа лежит совсем к другому.

Да, но мне кажется, интересно понять, откуда берется эта тенденция, и каковы альтернативы.

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

[yigal_s]

да в общем, любую операционку или драйвера писать - нужна абсолютная бескомпромиссная надежность, ИМХО.

А так... у меня жена на Windows 8 недавно pdf редактировала чем-то там вроде встроенного редактора. Поля заполняла. Я еще удивился - а что это такая за программ? Взял её потом и закрыл, потянув, как это принято в современном Windows 8 окошко вниз. Когда снова открыли - вместо заполненных полей - мусор. И ничего - "пипл хавает".

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

[mikkim08.livejournal.com]

процветающее (в силу непонятных до конца причин) место, где лично твои таланты и интересы будут эффективны и востребованы

Интересно, что это такое может быть.

[yigal_s]

любая успешно работающая фирма, по идее, где есть определенные вакансии, ниши или направления, которые нужно/можно заполнить.

[mikkim08.livejournal.com]

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

Ок. Выходит, значит, что эти качества ценятся выше чем ум сейчас.

[yigal_s]

я даже больше скажу - порой неумение видеть дальше собственного носа помогает осваивать новые технологии - ибо свято веришь что тебя ведут куда надо и не отвлекаешься на "ненужные" вопросы.

И да, в широчайшем пласте программистской деятельности это может цениться выше, и быть эффективнее, чем ум.

[mikkim08.livejournal.com]

Ну да. Если какой-нибудь хипстер поднял за день сайт на RoR, пока его коллеги ковырялись с более старыми технологиями, то он, конечно, эффективнее.

А, если со временем обнаружились, всякие проблемы с security, scalability и т.д., то это уже не его проблема (и даже не его менеджера) и неэффективным он от этого быть не перестает.

[yigal_s]

ну так вот же о чем весь этот agile и tdd -- ты должен писать то что нужно сегодня и не думать ни о чем больше. Какой нафиг scalability? Как понадобится - так и напишем.

[yatur.livejournal.com]

У меня есть два возражение.

1. Agile не означает полного отсутствия архитектуры и стратегического видения. Смысл agile в том, чтобы не уходить на полгода в программистский "запой", а держать цели под контролем.

2. К сожалению, рынок зачастую диктует условия, которые противны нашему инженерно-программистскому духу. Скажем, ты можешь за месяц сделать веб-сайт, который потянет 10 пользователей, решительно наплевав на scalability или за три месяца сделать веб-сайт, который потянет 100,000 пользователей. С инженерной точки зрения второй вариант однозначно предпочтительней. С рыночной же, второй вариант может оказаться вообще не жизненным - инвесторы не согласятся ждать 3 месяца и у тебя просто не будет денег, чтобы написать свой замечательный scalable веб-сайт.

[yigal_s]

держать цели под контролем - никому не запрещается.

давайте возмьём tdd - он требует писать РОВНО то, что позволяет тесту пройти успешно и ни грамом больше. Хочешь фичу - пиши на неё тест, а потом РОВНО тот код, который этот тест заставит работать. Отклонимся в более пространный код - значит код уже не будет полностью протестирован. Ибо понятно, что тестируем мы те фичи, что нужны сегодня, а ЗАКЛАДКИ будущей архитектуры протестировать невозможно хотя б потому, что это закладки, а не готовые фичи-функциональности, которые, скажем, "сработают", через пол-года, когда проект достаточно обрастет "мясом".

Теперь понятно, что в таком формате заложить что-то на будущее возможностей особых нет.

По второму возражению - у меня нет возражений против рынка. Но кто сказал, что все проекты надо писать в режиме "завтра потоп"?

[yatur.livejournal.com]

> давайте возмьём tdd - он требует писать РОВНО то, что позволяет тесту пройти успешно

Я не очень люблю TDD. Он хорош только в режиме, когда все абсолютно ясно. Скажем, когда мы пишем что-то чисто алгоритмическое. Если же мы пишем код, который "дергает" чужие модули с заранее до конца неизвестным поведением, TDD либо невозможен, либо сильно замедляет процесс. В такой ситуации я обычно пишу тесты после основного кода, или даже не пишу вообще.

Что же касается ЗАКЛАДОК будущей архитектуры, которые "сработают" через полгода - я к ним отношусь довольно скептически. Зачастую они только усложняют проект, а ситуация, ради которой их писали, так никогда и не возникает. Т.е., конечно, надо стараться писать модульно и все такое, но закладками лучше не увлекаться, ИМХО.

> Но кто сказал, что все проекты надо писать в режиме "завтра потоп"?

Ну зачем же потоп. Каждый случай индивидуален.

[yigal_s]

* Я не очень люблю TDD. Он хорош только в режиме, когда все абсолютно ясно.

Именно что. Об чем, кстати, и был исходный спич -- профессия вырождается в чистое производство (или загоняется в рамки такового).

* Скажем, когда мы пишем что-то чисто алгоритмическое.

Хехе. Я б хотел посмотреть на алгоритмиста, разрабатывающего алгоритм в режиме TDD.

* TDD либо невозможен, либо сильно замедляет процесс

Апологет TDD вам немедленно объяснит, что вся проблема в том, что вы не умеете делать правильный TDD. Правильный TDD снижает нагрузку на программиста, улучшает качество кода, вообще универсально полезен. А иначе - это вы просто неправильно его делаете.

Кстати, теперь об Agile -- разве TDD - это не одна из его ключевых технологий???

* закладками лучше не увлекаться, ИМХО

У каждого свой опыт как положительных, так и отрицательных результатов тех или иных действий. Человек может заранее знать что в его системе должно быть, когда она заработает - это следствие тех же бизнес требований. И понятно, что заработает система сильно раньше, чем все бизнес требования будут исполнены.

[yatur.livejournal.com]

> Апологет TDD вам немедленно объяснит

Ну, с верующими вообще лучше в дискуссии об их вере не вступать.

> Кстати, теперь об Agile -- разве TDD - это не одна из его ключевых технологий???

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

> Человек может заранее знать что в его системе должно быть

Может. Но из эопыта - чаще это всякая умозрительная лабуда в стиле "а вдруг у нас в машине будет два руля".

[yigal_s]

Я не настолько знаю agile и все эти новомодные шутчки, которые в последнее время вдруг проросли мейнстримом, чтобы тут спорить что является ключевой технологией, а что нет. Мне как-то казалось, что TDD для многих в области agile - методология самоочевидная и безальтернативная. Но я не буду настаивать.


* "а вдруг у нас в машине будет два руля".

я видел обратные крайности - машины без рулей. ибо оно и так катило от парковки до калитки, а что дальше шоссе начинается - разработчиков не напрягало.

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

[yatur.livejournal.com]

Agile - это что-то вроде английского языка. Вроде бы и модно, и многие говорят по-английски, но одни пишут check, а другие cheque, и ямаец шотландца понимает с трудом.

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

[cema.livejournal.com]

Про Скалу стоит спросить у ivan_gandhi.

[yigal_s]

Увы, я у него в бойкоте из-за оскорбления Святых Пусь и прочего тоталитаризма.

[yatur.livejournal.com]

> программирование сейчас ИМХО переживает взрывообразное развитие

Есть быстрое развитие, но взрывообразным я бы его не назвал.

Нулевой взрыв был вызван появлением собственно, компьютеров, первый - появлением языков высокого уровня (Лисп, Фортран), второй - появлением юниксообразных OS, третий - появлением PC, четвертый - появлением Интернета.

ИМХО, главное событие последних нескольких лет - это появление мобильных платформ (телефоны, планшеты) и окончание зимней спячки в мире браузеров, где присновечный IE6 был, наконец-то, существенно потеснён более современными собратьями. Но по сравнению с появлением Интернета это так, небольшой хлопок. ИМХО, конечно.

> а) некоторой уже закритичной скоростью появления новых технологий

ИМХО, дело не столько в скорости появления новых технологий, сколько в скорости отмирания старых. Это вызывает нездоровый, многолетний разрыв между тем, что реально имеет место в коммерческом программировании и тем, что толкают производители софта. Я об этом писал еще в 2009-м году: http://www.ikriv.com/blog/?p=158

ИМХО, нынешнее состояние рынка чем-то напоминает конец 70-х, когда каждый уважающий себя программист писал свой язык. Сегодня каждый уважающий себя программист пишет HTML templating engine и какую-нибудь приблуду для программирования мобильнков :)

> б) переводом программиста в статус многознающего, но полутупого фабрично-конвеерного рабочего

С конца 70-х до примерно середины 90-х народ искал Правильную Методологию, которая позволит либо
а) писать программы без ошибок, либо, еще лучше
б) вообще избавиться от программистов и рисовать программы квадратиками и стрелочеками на экране.

Так что, все могло закончиться горазо хуже. К счастью, ничего подобного достигнуто не было, вот мы и имеем scrum и agile. Ну и аутсоурсинг, конечно :) Если от программистов не получается избавиться, их можно хотя бы отправить в Индию. Agile это, кстати, не так уж плохо, если его правильно готовить. Другое дело, что многие только делают вид, что они занимаются agile, а на деле у них как был waterfall, так и остался.

Я, кстати, наблюдаю специализацию. 40 лет назад хороший программист был универсалом. Сегодня же одни люди пишут embedded, другие - веб-сайты, третьи - игрушки. Перейти из одной области в другую становится все сложнее и сложнее.

Но другой стороны, проблема глубина vs. ширина остается. Гавань - это какие-нибудь драйвера или embedded системы. Эти вещи куда более стабильны, чем "передний край". Но там скучно. Поймать волну можно с "новой Джавой" - но пока ее нет, пока индустрия находится в состоянии веселого бардака. Но так уж ли это плохо? ИМХО, куда лучше, чем вечный IE6 и Visual Basic :)