Я не претендую на объективность и не претендую на истинность, а высказываю лишь свое субъективное мнение, с которым вы можете быть согласны, а можете быть не согласны. Я не хочу никого переубеждать, лишь хочу обратить внимание на то, что, на мой взгляд, существуют более простые решения для подобного рода задач.
Чем вообще могут отличаться два разных языка программирования: набором предоставляемых функций, господствующей парадигмой и синтаксисом. Правильно?
Набор функций PHP и Python различен в пользу второго, но в данном примере нас это не сильно волнует, т.к. оба набора достаточны для реализации. Будем считать, что применительно к данной задаче, функционал языка эквивалентен (хотя опять же, в общем случае, это далеко не так).
Что касается синтаксиса, то по моему личному мнению синтаксис Python более чист – нет замусоривающих взгляд конструкций и излишней пунктуации. Вообще здесь, конечно, вы правы – надо рассматривать случай, когда оба куска написаны хорошо. Я буду рад, если вы представите хорошо написанный вариант указанного кода и мы сравним полученное.
Что касается семантики и господствующей парадигмы – в PHP это, в основном, структурное программирование. Да, классы там есть, а в 5.3 и старше – они сделаны на достаточно высоком уровне чтобы ими можно было комфортно и беспроблемно пользоваться. Но стандартная библиотека по-прежнему структурно-ориентирована. Массивы, строки – все это простые типы данных, а не объектов. Для манипуляций с ними нужны внешние, относительно объекта, функции, принимающие ссылку на данные в качестве своего аргумента.
Например strpos(ссылка_на_строку, ссылка_на_подстроку) vs строка.find(подстрока) – казалось бы «какая разница»? ИМХО разница есть и она значительна. Разница в том, что, например, функции по работе со строками предоставляют множество модулей – ядро, mbstring, iconv. С массивами точно так же существует 4 различных сортировки, которые реализованы независимо друг от друга и обладают своими плюсами и минусами. Каждый раз чтобы произвести какую-то операцию, нам нужно осуществить подбор нужной функции, и вспомнить ее особенности. А особенности могут быть весьма нетривиальны: в одном модуле функции принимают данные в первом параметре, в другом – в последнем. Где-то тип возвращаемых данных зависит от передаваемых в функцию флагов. Т.е. в стандартной библиотеке творится достаточно приличный разброд.
Та же функция pack – чтобы найти ее в мануале – нужно достаточно потрудиться, и, видимо, автор ее не нашел потому, что он увидел функцию hexdec и ему в голову не пришло, что аналогичная hexdec-у функция может быть реализована через pack. Да, те, кто по-опытней вспомнят аналогичную фичу C++ и найдут ее там, но вопрос в том, сколько времени они потратят на прототипирование при этом?
ИМХО в Python данная проблема решена лучше, т.к. там, в отличие от PHP, существуют очень четкие Code Conventions, которые обязаны соблюдаться всеми разработчиками. Без их соблюдения код не принимают, даже если он чист, отлажен и идеально быстр. Благодаря этому достигается полное единообразие всей стандартной библиотеки и большого количества сторонних модулей, которые придерживаются этого правила, что существенно сокращает время на обучение новым модулям и разработку.
Фактически это дает возможность программисту не думать о модулях, а думать об алгоритме. А не этого ли мы ждем от хорошего ЯП, господа? :-)
По сравнению с исходным PHP файлом, пример на Python:
1) 11 строчек вместо 25 — почти в 2.5 раза лаконичней
2) Нет никаких «забытых разработчиками функций» — в PHP же такая ситуация очень типична и встречается постоянно, если вы отходите в сторону от прямого назначения языка — т.е. от Web-фич.
3) Визуально код чище благодаря отсутствию громадного количества служебных символов, служебной пунктуации и прочего мусора, который облегчает жизнь транслятору, но зумусоривает мозг программисту.
Не возможно, а скорей всего был сильней. Но суть моего замечания даже не в абсолютной скорости, а в том, что ветра такой скорости — делю абсолютно обычное и дуют часто. Суть в том, что не было никакой аномальной скорости, аномальной порывистости или чего-то еще аномального, чего здесь не было бы раньше.
А про обычные, штатные ветра, проектировщики были обязаны знать и учитывать их, какими бы сильными или слабыми они ни были. Впрочем, справедливости ради, надо отметить, что тот факт, что такой ветер дует часто, а колебания стали такими только сейчас, может так же говорить и о физическом нарушении конструкции.
Не было там 16 м/с. Я в это время по улице гулял рядом и меня вовсе не сдувало с ног. Да, надо заметить что ветер был. Но он был не слишком сильный, и очень даже обычный для нашей местности.
В городе не упало у деревьев ни одной ветки, все провода в норме, ничего не поломалось. Хотя как минимум пару раз в год дуют ветра, от которых деревья еще как ломаются. Проектировщики не могли этого не знать и не учитывать.
Так что ответственно заявляю никакого аномально сильного ветра в тот день в Волгограде не было. И очень неприятно, что явную ошибку кого-то пытаются спихнуть на мифическую плохую погоду.
Дул абсолютно обычный для нашей местности ветер и подкапывал дождик, местами — сильный дождик.
1) Теща почему-то всегда считает, что она, не имея прав, лучше всех знает как управлять автомобилем.
2) Никто из нас не является политологом, зато все считают, что разбираются в политике достаточно, чтобы обсуждать обустройство государства.
Вот и с остальным будет так же:) Бич 21 века не в том, что мы мало знаем — мы знаем очень много. Бич в том, что мы считаем, что мы знаем вообще все и разбираемся во всем.
Отнюдь. Я даже говорю не лично про вас, а вообще про весьма ограниченную способность человека к саморефлексии.
Мы часто видим зомбо-действия в поступках своих друзей, как, например любовь к предмету, основанная лишь на его цене, а не на реальных характеристиках. Либо когда человек защищает навязанную телевизором/интернетом точку зрения так, как будто это его личные мысли.
Но часто ли мы задумываемся о своих действиях? Поймите, те, кого вы считаете зомби, точно так же смотрят на вас и считают вас зомби. И, поверьте, у них есть на то причины. Потому что в той или иной степени все мы зомби, и я тоже.
Но и мощности там нужны в тысячи и десятки тысяч выше чем для простой работы стартера. В обзорах «теслы» писали что аккумулятор весит толи 200, толи 300 килограмм.
Вопрос кроме того в другом — у аккумулятора со временем значительно ухудшается ресурс. Вы бы стали после покупки автомобиля менять свой гарантированно новый аккумулятор на кота в мешке, которого подсунут на заправке?
Стоят-то они (особенно литий-основанные) ого-го сколько…
Скорее всего внедрением в видео специальной метки, по которой можно вычислить скачавшего и последующего судебного разбирательства на сумму с множеством нулей.
Еще очень надо иконки сервисов, где размещен проект. Объясняю — как правило, у фрилансера нету «прокачанных» аккаунтов на всех биржах сразу.
Например, у меня есть много отзывов на фриланс.ру, а на остальных по 2-3 отзыва. В таком случае на фриланс.ру я могу бороться за большие заказы, а на остальных без отзывов это будет достаточно бесполезное времяпровождение, поэтому туда можно и не соваться, либо соваться только если нет других вариантов.
В общем — больше информации, хорошей и разной. У разных людей разные методы, поэтому больше информации даст вам больше поклонников.
Думаю, что вы сосредоточили свое внимание не на том месте.
Во-первых адекватный заказчик при выборе из Васи и Пети будет сравнимать их портфолио и отзывы, а не то, что Вася отписался на 2 минуты 32 секунды раньше, чем Петя. Более того, отклик в первые же секунды зачастую говорит о том, что исполнитель даже не удосужился ознакомиться с деталями заказа перед тем, как делать предложение. Поэтому 5 минут — далеко не критичны.
Во-вторых я, как фрилансер, все равно не смогу пол-дня сидеть и мониторить чаще чем раз в 5 минут. Ибо есть и другие заказы, которые надо делать, а не медитировать на поток заказов.
Вместо этого, добавьте лучше отображение цены и категории заказа, чтобы автоматически отсеивать слишком дешевые/дорогие заказы, а так же заказы из той области знаний, которыми заведомо не обладаешь.
По-моему за статьей вы не увидели смысла — «никогда не считай, что твоя стадия — последняя».
И это относится не только к программированию. Ваш «смысл жизни» — тоже не последняя стадия, и отражает лишь ваш жизненный этап, а не является универсальной общечеловеческой истиной.
Как можно оценивать модель саму по себе? Модель нужна для того, чтобы решать задачи.
Если задача — сделать клевую презентацию Петербурга — то это полный отстой. Ибо нет текстур, выглядит отвратительно, а точности измерений для презентаций никому нафиг не нужны.
Если же задача — смоделировать высоты зданий и коммуникации — то модель великолепна (если верить заявлениям о ее точности). Ибо для решения этой задачинет абсолютно никакого смысла тратить в 5 раз больше работы (а значит и денег) на текстуры, которые абсолютно не важны ни для определения высот зданий, ни для коммуникаций. Зато, например, в отличие от презентационной модели, здесь будет играть решающую роль точность измерений.
Чем вообще могут отличаться два разных языка программирования: набором предоставляемых функций, господствующей парадигмой и синтаксисом. Правильно?
Набор функций PHP и Python различен в пользу второго, но в данном примере нас это не сильно волнует, т.к. оба набора достаточны для реализации. Будем считать, что применительно к данной задаче, функционал языка эквивалентен (хотя опять же, в общем случае, это далеко не так).
Что касается синтаксиса, то по моему личному мнению синтаксис Python более чист – нет замусоривающих взгляд конструкций и излишней пунктуации. Вообще здесь, конечно, вы правы – надо рассматривать случай, когда оба куска написаны хорошо. Я буду рад, если вы представите хорошо написанный вариант указанного кода и мы сравним полученное.
Что касается семантики и господствующей парадигмы – в PHP это, в основном, структурное программирование. Да, классы там есть, а в 5.3 и старше – они сделаны на достаточно высоком уровне чтобы ими можно было комфортно и беспроблемно пользоваться. Но стандартная библиотека по-прежнему структурно-ориентирована. Массивы, строки – все это простые типы данных, а не объектов. Для манипуляций с ними нужны внешние, относительно объекта, функции, принимающие ссылку на данные в качестве своего аргумента.
Например strpos(ссылка_на_строку, ссылка_на_подстроку) vs строка.find(подстрока) – казалось бы «какая разница»? ИМХО разница есть и она значительна. Разница в том, что, например, функции по работе со строками предоставляют множество модулей – ядро, mbstring, iconv. С массивами точно так же существует 4 различных сортировки, которые реализованы независимо друг от друга и обладают своими плюсами и минусами. Каждый раз чтобы произвести какую-то операцию, нам нужно осуществить подбор нужной функции, и вспомнить ее особенности. А особенности могут быть весьма нетривиальны: в одном модуле функции принимают данные в первом параметре, в другом – в последнем. Где-то тип возвращаемых данных зависит от передаваемых в функцию флагов. Т.е. в стандартной библиотеке творится достаточно приличный разброд.
Та же функция pack – чтобы найти ее в мануале – нужно достаточно потрудиться, и, видимо, автор ее не нашел потому, что он увидел функцию hexdec и ему в голову не пришло, что аналогичная hexdec-у функция может быть реализована через pack. Да, те, кто по-опытней вспомнят аналогичную фичу C++ и найдут ее там, но вопрос в том, сколько времени они потратят на прототипирование при этом?
ИМХО в Python данная проблема решена лучше, т.к. там, в отличие от PHP, существуют очень четкие Code Conventions, которые обязаны соблюдаться всеми разработчиками. Без их соблюдения код не принимают, даже если он чист, отлажен и идеально быстр. Благодаря этому достигается полное единообразие всей стандартной библиотеки и большого количества сторонних модулей, которые придерживаются этого правила, что существенно сокращает время на обучение новым модулям и разработку.
Фактически это дает возможность программисту не думать о модулях, а думать об алгоритме. А не этого ли мы ждем от хорошего ЯП, господа? :-)
По сравнению с исходным PHP файлом, пример на Python:
1) 11 строчек вместо 25 — почти в 2.5 раза лаконичней
2) Нет никаких «забытых разработчиками функций» — в PHP же такая ситуация очень типична и встречается постоянно, если вы отходите в сторону от прямого назначения языка — т.е. от Web-фич.
3) Визуально код чище благодаря отсутствию громадного количества служебных символов, служебной пунктуации и прочего мусора, который облегчает жизнь транслятору, но зумусоривает мозг программисту.
А про обычные, штатные ветра, проектировщики были обязаны знать и учитывать их, какими бы сильными или слабыми они ни были. Впрочем, справедливости ради, надо отметить, что тот факт, что такой ветер дует часто, а колебания стали такими только сейчас, может так же говорить и о физическом нарушении конструкции.
В городе не упало у деревьев ни одной ветки, все провода в норме, ничего не поломалось. Хотя как минимум пару раз в год дуют ветра, от которых деревья еще как ломаются. Проектировщики не могли этого не знать и не учитывать.
Так что ответственно заявляю никакого аномально сильного ветра в тот день в Волгограде не было. И очень неприятно, что явную ошибку кого-то пытаются спихнуть на мифическую плохую погоду.
Дул абсолютно обычный для нашей местности ветер и подкапывал дождик, местами — сильный дождик.
2) Никто из нас не является политологом, зато все считают, что разбираются в политике достаточно, чтобы обсуждать обустройство государства.
Вот и с остальным будет так же:) Бич 21 века не в том, что мы мало знаем — мы знаем очень много. Бич в том, что мы считаем, что мы знаем вообще все и разбираемся во всем.
Мы часто видим зомбо-действия в поступках своих друзей, как, например любовь к предмету, основанная лишь на его цене, а не на реальных характеристиках. Либо когда человек защищает навязанную телевизором/интернетом точку зрения так, как будто это его личные мысли.
Но часто ли мы задумываемся о своих действиях? Поймите, те, кого вы считаете зомби, точно так же смотрят на вас и считают вас зомби. И, поверьте, у них есть на то причины. Потому что в той или иной степени все мы зомби, и я тоже.
Так какое же мы тогда имеем право кого-то судить?
В таком случае останется только Apple, а это уже далеко не так страшно.
Вопрос кроме того в другом — у аккумулятора со временем значительно ухудшается ресурс. Вы бы стали после покупки автомобиля менять свой гарантированно новый аккумулятор на кота в мешке, которого подсунут на заправке?
Стоят-то они (особенно литий-основанные) ого-го сколько…
Как минимум это потребует оборудование заправок тяжелой подъемной техникой и работниками для ее эксплуатации. Что неминуемо породит кучу проблем.
Еще очень надо иконки сервисов, где размещен проект. Объясняю — как правило, у фрилансера нету «прокачанных» аккаунтов на всех биржах сразу.
Например, у меня есть много отзывов на фриланс.ру, а на остальных по 2-3 отзыва. В таком случае на фриланс.ру я могу бороться за большие заказы, а на остальных без отзывов это будет достаточно бесполезное времяпровождение, поэтому туда можно и не соваться, либо соваться только если нет других вариантов.
В общем — больше информации, хорошей и разной. У разных людей разные методы, поэтому больше информации даст вам больше поклонников.
Во-первых адекватный заказчик при выборе из Васи и Пети будет сравнимать их портфолио и отзывы, а не то, что Вася отписался на 2 минуты 32 секунды раньше, чем Петя. Более того, отклик в первые же секунды зачастую говорит о том, что исполнитель даже не удосужился ознакомиться с деталями заказа перед тем, как делать предложение. Поэтому 5 минут — далеко не критичны.
Во-вторых я, как фрилансер, все равно не смогу пол-дня сидеть и мониторить чаще чем раз в 5 минут. Ибо есть и другие заказы, которые надо делать, а не медитировать на поток заказов.
Вместо этого, добавьте лучше отображение цены и категории заказа, чтобы автоматически отсеивать слишком дешевые/дорогие заказы, а так же заказы из той области знаний, которыми заведомо не обладаешь.
И это относится не только к программированию. Ваш «смысл жизни» — тоже не последняя стадия, и отражает лишь ваш жизненный этап, а не является универсальной общечеловеческой истиной.
Если задача — сделать клевую презентацию Петербурга — то это полный отстой. Ибо нет текстур, выглядит отвратительно, а точности измерений для презентаций никому нафиг не нужны.
Если же задача — смоделировать высоты зданий и коммуникации — то модель великолепна (если верить заявлениям о ее точности). Ибо для решения этой задачинет абсолютно никакого смысла тратить в 5 раз больше работы (а значит и денег) на текстуры, которые абсолютно не важны ни для определения высот зданий, ни для коммуникаций. Зато, например, в отличие от презентационной модели, здесь будет играть решающую роль точность измерений.
Обязательсва вам что-то продавать они тоже не давали.