Но ссылки — это зло. Попробуйте опровергнуть очевидное.

При необходимости, времени и настроении — запросто. Если оно действительно неверно. Но требуется разобрать «по полкам».

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

Вы объединяете в какое-то непонятное «Вы» целую кучу разнородных факторов. Личность это не один триггер с однозначной реакцией, это самоуправляемая сложная компонента. Вот от этого и надо оценивать, что такое воля.

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

Язык без типов высших порядков и вычислений времени компиляции реализовать проще всего.

Вам говорят про контроль, а Вы про реализацию языка, которая по своему определению тут не предполагает такого контроля.

Что-то мне кажется, что в данном случае у Вас проблемы с языком — конкретно, с восприятием данного сообщения.

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

А для кого нужно облегчение автоматического контроля корректности программ, как не для людей? ;)

Воля — это то, что внушают, чтобы повысить ЧСВ. Волевой человек, это ж так круто, не лошок какой )))

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

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

Ти перебільшуєш вплив *nix на життя тих часів. Можна сказати, що PHP у деякій мірі сприяв переходу на *nix, тому що у якості сервера можна було використати стареньку четвірку, яка значилася у металобрухту.

Саме в цей час я був адміном інтернет-провайдера і усе бачив своїма очима. Перебільшувати нема чого з дуже простої причини: реально крім Unix нічого не було видно. Windows був в щезаюче малий кількості, провайдери не хотіли зв’язуватися з ним. Ще інше було тільки у того, хто мав натхнення та купу дурних грошей.

Типовий хостинг (>99%) того часу вже підпадав під термін LAMP, але з тим, що 50% «L» було FreeBSD, і 100% «P» було Perl; а мали варіанти не мали і цього і задовольнялись SSI. Але CGI на Perl були _окремими_ істотами, в яких ще треба було адекватно 1) закерувати запроси на них, 2) написати генерацію html і, що типовий веб-розробник завжди забував, http-заголовки. Модуль CGI це спростив, але несуттєво.

І тут серед цього з’являється крива, глючна, дивна тулза «Personal Home Page» (це вже потім його перейменували) з кривим модулем до апача (і тільки), але який дозволяє _плавно_ переходити від статичного HTML або легкого SSI до повноцінної динамічної генерації на сервері. Тільки треба включити шмат кода до сторінки. Хочеш банер? Включи генератор банера на вибір (це вже дало більше половини(!) причин включення mod_php до серверної бази), два рядки без зміни іншої частини сторінки. Хочеш список новин? Теж добавити два рядки. І так далі. А головне, що все пройшло за анекдотом «мадам, что во что должно быть встроено?» — код всеред HTML, а не навпаки, як за традиційними підходами, був прийнятний для тої ж частини IT-людства, що вважає Excel за краще.

І поки розробники різних там FastCGI оптимізували швидкість для високонавантажених серверів, PHP захопило весь нижній шар. Все прошло за Єськовським описом конкуренції в рослинному миру — не треба конкурювати на вже обороняємих теренах, треба захоплювати майже покинуті та новостворені.

К 2000 головна частина цього процесу завершилася — з появою цілих форумів на PHP. Він вже сформував власний ринок.

І саме тоді треба було замість навалювання дурних фіч зайнятися нормалізацією усеї логіки роботи цього чуда. Але...

то були приблизно однакові інструменти для створення сайтів.

Не були! Саме за причин, що я описав вище. Якщо Ви згадуєте, наприклад, mod_perl, він довго не міг вбудовуватись в сторінки (і не знаю, чи зроблено це зараз в штатних версіях).

Але почати працювати на PHP з нуля було набагато легше.

І я вказав, чому це було так.

ASP також Turing повна.

Хтось заперечував?

Але типова ознака продуктів Microsoft, як на мене, була у тому, що відчуття простоти використання. Так, зробити можливо все, але перед цим треба була дуже багато прочитати книжок, мануалів, ...

Мабуть, тут пропущене слово «не було» (перед «відчуття»).

Сейчас по моему мнению все время навязывается общественным мнением (или навязывают общественное мнение), что надо всего желать, что без желания ничего не бывает, что желание == целеустремленность и т.д. и т.п. Ложь.

Как раз чистая правда. А проблема, видимо, в том, что Вы не провели даже такое элементарное разделение, как активная и пассивная воля. Случай «миллионов толстых людей» в том, что в лучшем случае пассивная выдаётся за активную.

Даже не знаю, то такое инстраграм. Не видел еще ни разу

Тогда бегите от него подальше — соблазн будет слишком велик.

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

Первый. Потому что ему доступно множество способов, а второй найдёт способ скомпенсировать затраты энергии жратвой в три горла.

На желаниях далеко не заедешь

Но начнёшь первый шаг. А на активном движении по принципу «шаг вперёд, две назад» можно запросто уйти в неверном направлении.

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

Вы, наверно, каждую еду выкладываете в инстаграм :)

Потому что у вас нет выбора. Настоящее одновариантно.

У меня есть выбор — я сделал себе такое настоящее, в котором мне не нужно копаться в говнокоде :)

Возможно, это временно. Но пока что работало. И есть хорошая вероятность, что это продлится долго.

Настоящий, качественный код и взрывается красиво. Ради таких моментов стоит тратить жизнь на работе:)

Сама идея того, что я писал: чтобы было интересно жить, надо делать интересным здесь и сейчас, наслаждаться процессом, а не мечтать о результатах.

Вот пока Вы будете это противопоставлять, так и будете по уши в... например, в TDD ;(

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

Причем, основное мое утверждение: именно стремление к результатам, желание результатов и делает унылым и однообразным настоящее. Оно не объективно неинтересное. Т.е. когда для вас результат становится важнее процесса.

Ваш путь — это создание приятных процессов в никуда. Абсолютный представитель такого пути — резиновая женщина. Всё хорошо, только вот детей не даёт. А ведь программный продукт — это ваш ребёнок, хоть и не биологический. Вам не хочется, чтобы он получился живучим и красивым?

На той час був .ASP.

Не на Unix.

то приблизно після години роботи у мене виникло враження, що я можу написати на PHP майже будь-який сайт з нуля.

Це враження від будь-якої Turing-повної мови:)

В мене був знайомий, що всі сайти с досить складними CGI писав на Bash, нічого іншого не визнавав.

Инструмент не может быть плохим или хорошим, он может быть не к месту или не правильно используемым.

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

Аналогии из статьи в этом смысле очень хороши: молоток с двумя раздвоенными концами это инструмент, удобный для крайне узкого класса задач, хоть и пригодный — ценой заметно бо́льших усилий для работы — для почти всех. Вот это «почти» и спасает то, что при других условиях давно бы вымерло. Хороший инструмент — оптимизирован массовым опытом по десяткам параметров.

У меня был аналогичный опыт сравнения при переходе Perl -> Python. Perl отлично держит нишу одностраничных скриптов, тут он даже опережает Python. Но когда мы выходим на уровень «10K строк кода плюс 5 библиотек», проблемы нарастают настолько, что цена продирания через них становится психологически задалбывающей. Переход вылечил практически все проблемы старого кода только за счёт читаемости и более чёткой проверки корректности действий, хотя и дал свои проблемы (отсутствие фиксации набора локальных имён переменных — шаг назад).

ClojureScript, CoffeeScript, Dart and etc.etc. — там до фига чего есть.

И они работают в Opera и IE?

Все еще не вижу потребности в итерациях с точки зрения проекта.

Пишут, что >90% проектов зачинаются тогда, когда детальные требования ещё совершенно не понятны никому, есть только рамочные ТУ (технические условия). По своему опыту я согласен с этой цифрой.

При правильном фидбэке снизу регулярные обсуждения типа «а мы вот такую проблему недоглядели» на этапе прототипирования и раннего написания — обычны и, более того, чрезвычайно полезны, потому что помогают вовремя переключиться на правильную стезю, а не писать уже заведомо ненужный код.

Это был абстрактный пример

То есть ни о чём. Ясно, спасибо.

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

Ещё один подтасовочный приём. На самом деле я испытываю, да, обоснованную неприязнь на основании личного опыта общения с этим языком и средствами, написанными на нём. Если это «личная неприязнь», то у Вас точно так же «личное пристрастие».

PHP интерпритатор, и у него есть свои настройки — это нормально.

Так как всё-таки поведёт себя функция при попытке выполнить неразрешённое поведение? Или это зависит от ещё одной серии настроек?

И почему эти настройки настолько сложны и запутанны?

Альтернатив на сегодня более чем нужно. Да, они почти все компилируется в JS, за некоторым исключением.

Которого, считаем, нет, если мы хотим реальной переносимости.

Но тем не менее если вам нужна та же статическая типизация то TypeScript вам в помощь.

К статичности типизации проблемы не сводятся.

JS с некоторых пор прекрасно живёт на сервер-сайде.

Где он не имеет никакого преимущества, кроме обобщения некоторого кода со страницами.

А вот для внутри браузера альтернативы нет.

А вообще по теме: если бы PHP был так плох как его малюют, то он бы не получил такого широкого распространения, в том числе в крупнейших проектах.

Причина распространения у него банальна: он занял нишу, которой ещё не было и которая была очень актуальна — живой код вставками в HTML.

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

То есть у обоих существование не за счёт собственного качества, а за счёт уже наработанной базы.

Есть реальность. Есть задача ее можно решить за 1*n часов на Java и за 0.6*n часов на РНР. Оба инструмента дадут приемлемый результат. Стоимость часов примерно одинакова ибо нам нужно более менее нормальное решение (о да, открою секрет, программисты на РНР получают не меньше чем на Java).
Соотвественно вопрос какой инструмент использовать? Думаю ответ очевиден.

Очевидно — использовать Python, потому что стоимость будет от 0.3*n до 0.4*n. Польза, кроме скорости разработки — надёжность за счёт отсутствия неявных конверсий и диверсий, и свобода движения в случае необходимости ускорить решение — PyPy, Cython, Jython и так далее.

Или Erlang — от 0.6*n до 0.8*n, зато мы получаем кучу других полезных фишек у выходного результата, если они нужны (написание демона или иного типа долговременного сервера).

Вот это действительно реальность. А обе предложенных Вами альтернативы в общем случае неудобны, но вторая (PHP) ещё и кошмарна, а если она вообще упомянута, то условия для предпочтения Java не соблюдены и за ней тоже нет смысла гоняться.

И то — я не все альтернативы рассмотрел, ограничившись только самыми популярными.

И отсюда мы можем плавно перейти к следующему пункту:

(int) — это внутренний хак.

Так что же лучше, хак от платформы или хак внешний...

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

Каждый пример в той статье, по сути узость мышления автора.

Расскажите, пожалуйста, каким образом жалоба на чрезмерно большое количество фактов, влияющих на открытие URL через fopen(), и отсутствие внятных данных, как же будет выглядеть отказ в выполнении, показывает «узость мышления» автора. Или это Вы вспомнили «ширшее надо быть, ширшее» из москворусских классиков?

Если вы берете технологию ибо она круче/лучше но не эффективней, то пожалуй вы еще не доросли до таких решений.

Это уже второй приём подтасовочной полемики в одном не сильно большом сообщении (называется Imago). Зачем Вы так?

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

Верю — альтернативы-то нет, другого стандартного языка для браузеров пока, увы, не ввели. После этого нет проблем рассказывать про «превосходно решает задачи», при отсутствии реального выбора.

Як тільки ці PHP-шники наплодили стільки сайтів у інтернеті, коли весь час витрачається на пошук помилок?

Так, що помилки на цих сайтах нікого не хвилюють.

Це був unsafe C/C++. Драйвер AMD Catalyst.

О! В C/C++ такого простору для помилок вже немає, і легше тримати дісципліну.