Это относится только к особенностям языка и компилятора, не к сторонним библиотекам. Лично мне нюансы сторонних API почему-то запоминаются, а вот особенности языка просто откладываются и вспоминаются только либо возникновении соответствующих симптомов, либо при непосредственном программировании.
Про 3. Длинные цепочки and очень быстро становятся плохочитабельными. Подход с несколькими if-return в начале, из личного опыта, намного удобнее и понятнее.
При переходе к другой парадигме нужно менять мышление. Иного способа быстро и надежно использовать новый инструмент просто не существует.
Пример из жизни: насколько быстро человек освоит IDE, если до этого он писал программки в блокноте и собирал из командной строки? Естественно, в первое время ему это будет казаться магией, и захочется продолжать работать с командной строкой, потому что «понятно, как оно работает». Просто сила привычки и недоверие ко всему новому.
Представляю.
Но тут еще дело уважения к языку.
Ведь каждый язык программирования — это свой синтаксис и своя семантика, а отсюда следуют своя терминология, свои «правильные» подходы, своя культура и т.д.
И оно отнюдь не только для того, чтобы выделиться.
Во-первых, единство стандарта позволяет всем писать более-менее одинаково (с точки зрения форматирования и использования конструкций языка для каких-либо простых задач типа сортировки).
Во-вторых, этот единый стиль не взялся с потолка, а длительное время шлифовался профессионалами, специализирующимися на данном языке программирования. Следовательно, большинство вопросов «против», которые вы можете придумать, исходя из того, «как оно сделано в таком-то моем любимом языке программирования», окажутся либо уже давно решенными, либо противоречащими культуре языка (хотя, может быть, работать оно будет корректно).
Можно привести множество примеров, но как Java-программист замечу: в Java до сих пор нет замыканий )
Пролог — это не функциональный язык. OCaml ближе к LISP'у.
Пролог работает по правилам вывода, т.е. из известных выводит неизвестные, перебирая доступные правила (факты).
Здесь же выполнение идет от аргументов функции к ее результату, фактически линейное с callback'ами.
Допустим, вы написали функцию, назовём её repeated, которая берёт исходную строку s, число n и возвращает новую строку, состоящую из троекратно повторённой строки s.
Если такое происходит, нужно либо добавлять ссылки наверх, либо по-умолчанию свертывать блоки, добавляя рядом значок «Развернуть» (картинка или надпись).
А в более общем случае представь, что ты клиент.
Заходишь на главную страницу.
У тебя есть пара конкретных вопросов.
Как много кликов и прокруток придется сделать, чтобы на них ответить?
Насколько сложно при этом будет обнаружить глазами нужные ссылки?
Ориентировочные показатели такие:
— Более двух кликов = заказчик не найдет.
— Прокрутка вверх-вниз недопустима, необходимо добавлять ссылки «наверх».
— Если одного взгляда на область сайта недостаточно для того, чтобы понять назначение этой области — что-то нужно менять.
Если я правильно понимаю условие (найти путь с наименьшим числом ходов), то решать следует так:
0) Текущая точка = стартовая точка.
1) Если расстояние до конечной точки <= 4, переходим к шагу 5.
2) Выпустим 8 лучей из текущей точки, чтобы все возможные ходы коня приходился на различные части плоскости (разделенными нашими лучами).
3) Проанализируем, в какой из частей плоскости находится конечная точка.
4) Делаем ход в соответствующем направлении, переходим к шагу 1.
5) Рисуем квадрат — и поиском в ширину находим кратчайший путь.
Варианты доработки:
— Лучше вместо кучи картинок отображать одну, а вверху сделать навигацию. Дополнительно можно реализовать как слайд-шоу. Получим и преимущество большой картинки, и возможность просмотра всех доступных.
— Текст внизу переместить в FAQ, сделать для него ссылку вверху правой колонки, ссылки на разделы А-Д добавить как подпункты, сократить названия ссылок. Например, так: смогу ли я вам помочь, мои достижения, что вы получите, расчет стоимости.
— В самой FAQ перед описаниями поместить ссылки на все разделы, после каждого раздела — ссылка для прокрутки к началу.
Я бы сказал так: при работе с Firebug бывает удобно прописать стиль элемента, который автоматически заносится в style.
Поскольку это нужно только для того, чтобы подобрать нужные стили, и время жизни таких страниц — до обновления страницы, то данных подход вполне себя оправдывает.
Если же прописывать style в файлах — это уже темная сторона, тут безоговорочно.
В моем случае было так: у компании кончились средства на проект, а дополнительных инвестиций не нашли. Текущие договоры не покрыли ЗП сотрудникам, в итоге через несколько месяцев оттуда ушли почти все толковые программисты. Текущее состояние этой компании мне неизвестно, но, судя по всему, ничем хорошим они не кончили.
Так что без адекватного материального резерва или инвестиций браться за большие проекты — самоубийство.
Внимательности не хватает :-)
Зато если спросят проблему, то знающий решит мгновенно, а незнающий — вряд ли решит сразу.
Пример из жизни: насколько быстро человек освоит IDE, если до этого он писал программки в блокноте и собирал из командной строки? Естественно, в первое время ему это будет казаться магией, и захочется продолжать работать с командной строкой, потому что «понятно, как оно работает». Просто сила привычки и недоверие ко всему новому.
Но тут еще дело уважения к языку.
Ведь каждый язык программирования — это свой синтаксис и своя семантика, а отсюда следуют своя терминология, свои «правильные» подходы, своя культура и т.д.
И оно отнюдь не только для того, чтобы выделиться.
Во-первых, единство стандарта позволяет всем писать более-менее одинаково (с точки зрения форматирования и использования конструкций языка для каких-либо простых задач типа сортировки).
Во-вторых, этот единый стиль не взялся с потолка, а длительное время шлифовался профессионалами, специализирующимися на данном языке программирования. Следовательно, большинство вопросов «против», которые вы можете придумать, исходя из того, «как оно сделано в таком-то моем любимом языке программирования», окажутся либо уже давно решенными, либо противоречащими культуре языка (хотя, может быть, работать оно будет корректно).
Можно привести множество примеров, но как Java-программист замечу: в Java до сих пор нет замыканий )
Пролог работает по правилам вывода, т.е. из известных выводит неизвестные, перебирая доступные правила (факты).
Здесь же выполнение идет от аргументов функции к ее результату, фактически линейное с callback'ами.
Не троекратно, а n-кратно.
Если такое происходит, нужно либо добавлять ссылки наверх, либо по-умолчанию свертывать блоки, добавляя рядом значок «Развернуть» (картинка или надпись).
Заходишь на главную страницу.
У тебя есть пара конкретных вопросов.
Как много кликов и прокруток придется сделать, чтобы на них ответить?
Насколько сложно при этом будет обнаружить глазами нужные ссылки?
Ориентировочные показатели такие:
— Более двух кликов = заказчик не найдет.
— Прокрутка вверх-вниз недопустима, необходимо добавлять ссылки «наверх».
— Если одного взгляда на область сайта недостаточно для того, чтобы понять назначение этой области — что-то нужно менять.
0) Текущая точка = стартовая точка.
1) Если расстояние до конечной точки <= 4, переходим к шагу 5.
2) Выпустим 8 лучей из текущей точки, чтобы все возможные ходы коня приходился на различные части плоскости (разделенными нашими лучами).
3) Проанализируем, в какой из частей плоскости находится конечная точка.
4) Делаем ход в соответствующем направлении, переходим к шагу 1.
5) Рисуем квадрат — и поиском в ширину находим кратчайший путь.
— Лучше вместо кучи картинок отображать одну, а вверху сделать навигацию. Дополнительно можно реализовать как слайд-шоу. Получим и преимущество большой картинки, и возможность просмотра всех доступных.
— Текст внизу переместить в FAQ, сделать для него ссылку вверху правой колонки, ссылки на разделы А-Д добавить как подпункты, сократить названия ссылок. Например, так: смогу ли я вам помочь, мои достижения, что вы получите, расчет стоимости.
— В самой FAQ перед описаниями поместить ссылки на все разделы, после каждого раздела — ссылка для прокрутки к началу.
Особенно когда с используемым программным framework'ом нельзя сделать некоторых вещей, которые сделаны в верстке.
Поскольку это нужно только для того, чтобы подобрать нужные стили, и время жизни таких страниц — до обновления страницы, то данных подход вполне себя оправдывает.
Если же прописывать style в файлах — это уже темная сторона, тут безоговорочно.
на -> не.
В моем случае было так: у компании кончились средства на проект, а дополнительных инвестиций не нашли. Текущие договоры не покрыли ЗП сотрудникам, в итоге через несколько месяцев оттуда ушли почти все толковые программисты. Текущее состояние этой компании мне неизвестно, но, судя по всему, ничем хорошим они не кончили.
Так что без адекватного материального резерва или инвестиций браться за большие проекты — самоубийство.