>> Описывать численные алгоритмы на Хаскеле удобно, например.
а потом сумеете легко предсказать сложно получившегося алгоритма по времени и памяти?
численные алгоритмы они многие о матрицах и их элементах… и всех Фортран до сих пор, наверное, на этом деле побеждает по количеству строчек написанного кода. Товарищи вот в Sisal тужатся создать панацею, но все никак не могут допилить, чтобы производительность нормальная была (= пытаются научить компилятор просекать, где можно иммутабельность выкидывать и без копировать изменять массивы прямо на месте). Иными словами, писать императивные по своей сути алгоритмы на ленивых чистых языках — это плевать против ветра и ждать, что умный компилятор защитит вас своим зонтиком. Компиляторы конечно становятся умней (вон Parallel Haskell двигается к светлому будущему, кажется), но это не избавляет вас от задачи расставлять ему везде подказки (а вот здесь мы хотим форсировать thunk. а вот здесь мы будем использовать грязный мутабельный массивчик). Так зачем же эта головная боль?
мне кажется в этом тексте «readability» это именно «readability», но интервью с Фитцпатриком цитируется все равно неверно. Дословно Брэд сказал
To check in you need three conditions met: You need someone to review it and say it looks good. You need to be certified in the language – basically, you’ve proven you know the style of this language – called “readability.” And then you also need the approval from somebody in the owner’s file in that directory. So in the case that you already are an owner of that directory and you have readability in that language, you just need someone to say, “Yeah, it looks good.”
А в тексте поста стало почему-то вместо «трех условий» — «два требования».
Кстати само интервью доступно в чуть ли не полностью в Google Books:
«Here’s an early preview of how we designed, built, and implemented these speed tests. Stay tuned for the full results; we’ll post them here tomorrow.»
Ситуация когда субъект воспринимает рисунок из стрелочек и прямоугольничков, как дарованное с небес откровение о мироустройстве. И пользуясь напильником и топором пытается впихнуть любую ситуацию в рамки одной или нескольких таких картинок, забывая об особенностях предметной области и уже существующей кодовой базы. Плодит тонны вспомогательных классов (слався Адаптер!) и прочего гудрона. Речь бессвязная («бла-бла-бла стратегия бла-бла-бла итератор бла-бла-бла фабрика»).
Вы вот так под одну гребенку всех олимпиадников и выпускников мехмата замели… Словно на мехмате преподы только и делают, что учат «Не пользуйтесь дети Гибернейтом! Будут вам гвозди в руки вбивать, все равно не пользуйтесь!»
Лично мне кажется, что этот код прекрасная иллюстрация того, что олимпиадное программирование и промышленное сильное отличаются. Написать такой код в живой программе не уважать себя, коллег и пользователей.
Важную роль в программировании играет рассмотрение разных «неправильных» случаев ввода и корректная их обработка. Вы же на это просто забиваете, потому что олипиадные входные данные всегда отформатированы корректно.
>> Проблема из пальца не высосана, я об этом внятно написал в посте.
Проблема неизвестных размеров из пальца не высосана, согласен и возникает достаточно часто. Но я говорил нечто другое: иллюстрирующий её пример высосан из пальца, я все-таки считаю что в данном конкретном случае передавать указатель на буфер (размер которого как я уже говорил не превосходит 10 байт) было бы более красиво и правильно.
А то! И ядро QNX даже читал… И даже первую страницу книги Льва Николаевича Толстого «Война и Мир».
Только все это не имеет отношение к делу.
Во-первых, код библиотек как бы он не был написан является исключительно проблемой авторов. Если у меня есть претензии к стилю — я их не вам буду высказывать. Кстати, в ядре Линукс нормально так пишут. Многие места вообще до блеска вылизаны за все это время…
Во-вторых, если кто-то пишет плохой код это не значит, что вы должны писать плохой код и выкладывать его на всеобщее обозрение не пересмотрев и не вылизав. У вас сроки не горят и заказчик не буйствует…
В-третьих, кто вам сказал, что меня «учили»? Мои культура написания на Си проистекает как раз из практики, различных корпоративных стандартов, чтения чужого кода и чувства прекрасного, которое должно быть у каждого программиста.
а потом сумеете легко предсказать сложно получившегося алгоритма по времени и памяти?
численные алгоритмы они многие о матрицах и их элементах… и всех Фортран до сих пор, наверное, на этом деле побеждает по количеству строчек написанного кода. Товарищи вот в Sisal тужатся создать панацею, но все никак не могут допилить, чтобы производительность нормальная была (= пытаются научить компилятор просекать, где можно иммутабельность выкидывать и без копировать изменять массивы прямо на месте). Иными словами, писать императивные по своей сути алгоритмы на ленивых чистых языках — это плевать против ветра и ждать, что умный компилятор защитит вас своим зонтиком. Компиляторы конечно становятся умней (вон Parallel Haskell двигается к светлому будущему, кажется), но это не избавляет вас от задачи расставлять ему везде подказки (а вот здесь мы хотим форсировать thunk. а вот здесь мы будем использовать грязный мутабельный массивчик). Так зачем же эта головная боль?
для простейшего случая «обойти деревцо в глубину выплевывая код» разве что.
Confessions of a Used Programming Language Salesman, The International Conference on Functional Programming 2006
статья очень интересная (и без матана ;-) ), рекомендую
неделю назад еще не было этого выпуска: он в пятницу вышел =)
Для автоматической проверки стиля (там где это возможно) используются разного рода lint-еры, например, google-styleguide.googlecode.com/svn/trunk/cpplint/
Для организации ревью используется тулы типа Rietvield (http://code.google.com/p/rietveld/, используется на codereview.chromium.org/) и Mondrian (techtalk: www.youtube.com/watch?v=sMql3Di4Kgc).
а разные url схемы это всего лишь разные способы доступа к существующему git-репозиторию.
А в тексте поста стало почему-то вместо «трех условий» — «два требования».
Кстати само интервью доступно в чуть ли не полностью в Google Books:
books.google.dk/books?id=nneBa6-mWfgC&lpg=PP1&ots=gDysIdRW0v&dq=Brad%20Fitzpatrick%20coders%20at%20work&hl=en&pg=PA49#v=onepage&q&f=false
chrome.blogspot.com/2010/05/pedal-to-chrome-metal-our-fastest-beta.html
Ситуация когда субъект воспринимает рисунок из стрелочек и прямоугольничков, как дарованное с небес откровение о мироустройстве. И пользуясь напильником и топором пытается впихнуть любую ситуацию в рамки одной или нескольких таких картинок, забывая об особенностях предметной области и уже существующей кодовой базы. Плодит тонны вспомогательных классов (слався Адаптер!) и прочего гудрона. Речь бессвязная («бла-бла-бла стратегия бла-бла-бла итератор бла-бла-бла фабрика»).
переполнение ничего не портит, потому что числа ограниченной разрядности по сложению образуют циклическую группу.
Важную роль в программировании играет рассмотрение разных «неправильных» случаев ввода и корректная их обработка. Вы же на это просто забиваете, потому что олипиадные входные данные всегда отформатированы корректно.
Проблема неизвестных размеров из пальца не высосана, согласен и возникает достаточно часто. Но я говорил нечто другое: иллюстрирующий её пример высосан из пальца, я все-таки считаю что в данном конкретном случае передавать указатель на буфер (размер которого как я уже говорил не превосходит 10 байт) было бы более красиво и правильно.
А то! И ядро QNX даже читал… И даже первую страницу книги Льва Николаевича Толстого «Война и Мир».
Только все это не имеет отношение к делу.
Во-первых, код библиотек как бы он не был написан является исключительно проблемой авторов. Если у меня есть претензии к стилю — я их не вам буду высказывать. Кстати, в ядре Линукс нормально так пишут. Многие места вообще до блеска вылизаны за все это время…
Во-вторых, если кто-то пишет плохой код это не значит, что вы должны писать плохой код и выкладывать его на всеобщее обозрение не пересмотрев и не вылизав. У вас сроки не горят и заказчик не буйствует…
В-третьих, кто вам сказал, что меня «учили»? Мои культура написания на Си проистекает как раз из практики, различных корпоративных стандартов, чтения чужого кода и чувства прекрасного, которое должно быть у каждого программиста.