Ужас какой-то. Я даже на 1С сначала проектирую изменения (при этом согласую с заказчиком, что будут изменены формы такие-то так-то, функции такие-то так-то), а уже потом пишу.

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

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

В php ведь уже есть возможность указывать типы. Почему не пользуешься?

пользуюсь, оно не ловит конструкции вроде ->{$varname} к примеру. И не ловит изменения в ассоциативном массиве. Плохо работает с __get __set. Многословно нужно дублировать все объявления, специально для ide. Если изменил код, надо не забыть измененить объявление типа. В хаскеле это автоматом не скомпилится, а тут надо вспоминать. И оно не всегда удачно их читает. И потом яваскрипт, который всё это обрабатывает, тоже ничего особо не ловит. Всё руками.

Вообще надо idea ещё раз попробовать. С год назад я ею пользовался , но толку особо не увидел, может быть я зря её забросил, не знаю.

Оффтоп: Слушай, по твоей речи YouTube делает авто-субтитры на порядок качественнее, нежели если говорит англичанин. Русский след на ютубе :D

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

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

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

А если начинать писать без полной структуры, то будет как в анекдоте:

Чукчи купили банку pаствоpимого кофе. Один читает, втоpой делает.
Пеpвый - "Положить ложку кофе"
Втоpой - "Угу"
Пеpвый - "Добавить две ложки сахара"
Втоpой - "Угу"
Пеpвый - "залить кипятком"
Втоpой выплевывая - "Вот же садисты однако !"
Пеpвый - "Да однако - там еще пеpемешать написано !"

Так или иначе, но твои утверждения смотрятся странно в контекте типизиация vs нетипизация: мне кажется прямо таки неоспоримым что проверка типов - большой плюс. Странно грепать и «писать явным образом экспорт» в php. Такого типа документация имеет тенденцию быстро становиться неактуальной, в отличие от экспорта модулей в том же хаскеле, к примеру, которую хочешь -не хочешь, а компилятор проверит при каждой сборке.

Очевидно лучше иметь автоматизированное решение всех этих проблем, чем костыльное.

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

Правда, я думаю, именно поэтому ява/сишарп у php/перлов/питонов и прочих лиспов и выигрывает так просто и непринуждённо в тех местах где нужно чтобы это хоть как то работало. А не как во многих php проектах - заказчик зашёл на главную, работает - ну и ок. Дальше лень, забросил да забыл. Ясно что разработать больше - денег бы не хватило. А так вроде и «инвестировал» и программисты довольны и вообще радуга на небе. То что в это надо ещё тучу бабла ввалить чтобы оно действтилеьно работало - всем пофиг потому что пользователей всё равно тут никогда не будет.

И да, я не пишу модуль сразу «вот уже готово». Сначала некоторую, правда рабочую структуру, потом другой модуль. Так по кругу.

Насчёт «начал писать без полной структуры» - мне смешно, спасибо. Или же у меня такая странная выборка заказчиков, из которых наверное больше 90% не в курсе какая там будет структура. Ну , может у тебя другая ситуация.

Ладно, может я что то не так делаю, всегда можно чему то научится.. попробую ещё раз идею.

Всё равно твои утверждения смотрятся странно в контекте типизиация vs нетипизация: мне кажется прямо таки неоспоримым что проверка типов - большой плюс. Странно грепать и «писать явным образом экспорт» в php. Такого типа документация имеет тенденцию быстро становиться неактуальной, в отличие от экспорта модулей в том же хаскеле, к примеру, которую хочешь -не хочешь, а компилятор проверит при каждой сборке.

Контекст всё тот же.

На PHP я пишу

// phone : "+" и 10 цифр
function showPhone(phone)
{
  assert(preg_match("+\d{10}", phone);
  ...
}

На Haskell

-- phone : "+" и 10 цифр
showPhone :: String -> IO ()
showPhone phone = do
  guard $ RegExp.Match "+\d{10}" phone
  ...

Затем выясняется, что телефон может быть числом На PHP

// phone : "+" и 10 цифр или 10-значное число 
function showPhone(phone)
{
  assert(is_string(phone) && preg_match("+\d{10}", phone
        || is_integer(phone) && phone >= 1000000000 && phone <=9999999999);
  ...
}

На Haskell

-- phone : "+" и 10 цифр
data Phone = PhoneInt Int | PhoneString String

checkPhone :: Phone -> Bool
checkPhone (PhoneInt x) = x >= 1000000000 && x <= 9999999999
checkPhone (PhoneString x) = RegExp.Match "+\d{10}" x

showPhone :: Phone -> IO ()
showPhone phone = do
  guard $ checkPhone phone
  ...

Так как на комментарий компилятор не ругается, он почти наверняка останется неизменным. Более того, если на PHP или лиспе для меня тип — «возможные значения переменной», то есть assert я пишу всегда, если значение параметра не может быть любым, то в Haskell я с большой долей вероятности буду думать в терминах языка. То есть программа сведётся к

-- phone : "+" и 10 цифр
showPhone :: String -> IO ()
showPhone phone = do
  ...

и

-- phone : "+" и 10 цифр
data Phone = PhoneInt Int | PhoneString String

showPhone :: Phone -> IO ()
showPhone phone = do
  ...

А это уже верный путь к проблемам в будущем (как только попадёт ошибочная строка не соответствующая шаблону). Система типов расслабляет.

Правда, я думаю, именно поэтому ява/сишарп у php/перлов/питонов и прочих лиспов и выигрывает так просто и непринуждённо в тех местах где нужно чтобы это хоть как то работало

Гм. C и даже C++ также уверенно php и перлу проиграл. Хотя система типов у C++ гораздо лучше, чем у Java.

Причина в другом. К яве и сишарпу прилагается талмуд в котором на каждый алгоритм дан единственно верный способ его описания. Поэтому если для большинства языков производительность программистов отличается почти в сотню раз, то для явы и сишарпа всего в два-три раза. А если тебе надо определить, сколько программистов набрать на проект, то это очень важно. То есть если проект могут написать 30-60 программистов на ява, то его смогут написать 3-300 программистов на C++ или лиспе.

Ха, развеселил :)

хороший комментарий, спасибо. Пример интересный, актуальный.

Вообще мне кажется что проблему я понимаю в чём то сходно с тобой.

Но ты утверждаешь что использование более совершенного инструмента «расслабляет» (В последнем комментарии это в рафинированом виде прямо). Т..е у тебя есть агрументы против использования лучшего инструмента.

Мне кажется это похоже на увлечённость.

Вообще я считаю себя человеком увлекающимся. Причём довольно сильно. Но зная эту черту за собой, я стараюсь знакомиться с доступной мне аргументацией, когда начинаю знакомиться с предметом. Стараюсь подходить с рационалистических позиций, выбирать сторону истины (не всегда удаётся избежать «рационализации», правда). К чему я.. ну если так не делать, то можно увлечься чем угодно и легко оказаться на стороне , гм,не очень хороших людей, делающих не очень хорошие поступки прикрываясь благими идеями. Или даже увлечься лиспом :)

Насчёт «начал писать без полной структуры» - мне смешно, спасибо. Или же у меня такая странная выборка заказчиков, из которых наверное больше 90% не в курсе какая там будет структура. Ну , может у тебя другая ситуация.

Так в курсе должен быть не заказчик, а разработчик. Заказчик должен быть в курсе, чего он хочет (если речь про сайт, то согласовать дизайн, навигацию, список страниц и функции на каждой странице).

И да, я не пишу модуль сразу «вот уже готово». Сначала некоторую, правда рабочую структуру, потом другой модуль. Так по кругу.

Структуры данных и список функций должен быть до разработки. Условно, согласовал дизайн ЛОРа, и пишешь себе (на бумажку, в текстовый файл или ещё куда): главная (авторизация, список новостей) -> (пользователь, новость), список форум (выбор форума из списка) -> форум, форум (просмотр тем, добавление темы) -> тема, ... И так для всех страниц сайта. Потом по каждому полученному объекту прописываешь поля, просматривая все страницы, где с этим объектом что-то делают. И только потом начинаешь собственно писать код.

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

1) Хотя система типов у C++ гораздо лучше, чем у Java.

лучше с твой т.з. я имею ввиду т.з. более эффективно в плане: min(цена $ научить программиста + поправить потом баги, [список всех языков])

Вряд ли можно показать что система типов с++ в этом смысле лучше. Даже я , программировавший на нём около года всего, помню всех этих виртуальрных функций, друзей, мув семантик, контсрукторы копирования, при этом перепутать это всё не стоит вообще ничего. Система типов тебя никак не защищает от своей собственной «мощи».

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

То есть если проект могут написать 30-60 программистов на ява, то его смогут написать 3-300 программистов на C++ или лиспе

и 3-300 на php. Однако, php выигрывает у с++ и лиспа. Потому что порог вхождения ниже, многократно.

Поэтому он соревнуется с явой, правда в нишах где результат зачастую не так важен. я думаю в этом секрет, процентов на 60% - очень дешёвые программисты (вследствие низкого порога вхождения) помноженные на «да нам только посмотреть и выкинуть» - вот это тот рынок на котором пхп был есть и будет вне конкуренции, пока новые технические решения (типа сайт билдеров) не станут действтилеьно совершенными.

Но ты утверждаешь что использование более совершенного инструмента «расслабляет» (В последнем комментарии это в рафинированом виде прямо). Т..е у тебя есть агрументы против использования лучшего инструмента.

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

Можно писать на Haskell, но надо осознавать, что типы в нём очень ограничены. Тогда при необходимости не забудешь поставить guard на входящее выражение и вернёшь Maybe или Either, если при корректных входных данных потенциально возможны неверные выходные.

Например то, что в Text.Regex.Posix операция =~ может бросать исключение, с моей точки зрения нонсенс.

Заказчик должен быть в курсе, чего он хочет (если речь про сайт, то согласовать дизайн, навигацию, список страниц и функции на каждой странице).

о, наконец-то ты понял. да, я об этом - они не в курсе вообще то. делаем что имеем, как видим (ясное дело всё согласовано до мелочей!). А потом меняем. И это похоже и есть жизнь. В том смысле что быть в курсе просто нельзя, объективно, до того как ты увидел и пощупал результат. Я это понимаю на самом деле. Вот шкаф почти можно спланировать заранее. А сайт (более-менее свежий) - нет. Шаблонный да, легко. Но что то чего нет ещё точно в таком виде - нет, не удаётся.

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

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

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

То есть согласен, что явы побеждает пхп не благодаря типам? Кстати, NodeJS на серверах очень активно теснит яву. А 1С (бестиповый) в РФ вытеснил многочисленные программы на Delphi.

Для крупных проектов вообще язык зачастую маловажен (пример КОБОЛа и 1С особо ярок). Главное, чтобы были нормальная стандартная библиотека и руководство по стилю.

То есть согласен, что явы побеждает пхп не благодаря типам?

нет. не уверен почему ты сделал такой вывод.

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

А 1С (бестиповый) в РФ вытеснил многочисленные программы на Delphi.

автоматическое управление памятью же?

Для крупных проектов вообще язык зачастую маловажен (пример КОБОЛа и 1С особо ярок). Главное, чтобы были нормальная стандартная библиотека и руководство по стилю.

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

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

Теперь понял. У нас разные заказчики. В бухгалтерии заказчик всегда точно знает чего хочет (и даже когда не точно, его можно наводящими вопросами заставить определиться). А сайты я делал только небольшие (в десяток пунктов меню) и что на какой странице должно быть у заказчика выпытывал заранее. Дизайн потом еще три месяца ровняли (цвет, три пиксела влево, рамки скруглить, ...), но серверную часть и JS уже не трогали.

Блин, всё равно не могу представить, как заказчик может не знать заранее, какие функции должен выполнять его сайт. Даже если таких сайтов никогда не было. У меня единственный раз такое было, когда замдиректора у заказчика рассказывал, что должно быть, а потом оказалось, что четверть необходимой информации он просто не знал (так как работать с продуктом совсем другой сотрудник должен).

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

1С успешно заменил. Проекты на нём огромнейшие (73647 процедур и 24388 функций в 1С:Зарплата). И очень многое, что раньше писали на яве, теперь на питоне. Клиент-банк https://ibank2.ru/ был на яве, теперь на JavaScript.

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

1С успешно заменил. Проекты на нём огромнейшие (73647 процедур и 24388 функций в 1С:Зарплата)

Почему «заменил» - 1С:Зарплата когда-то была на Яве?

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

Кстати, в таких условиях считается, что скриптовые языки (php, питон, лисп) на порядок эффективней. Потому что в примере с телефоном и его изменением типа, в скриптовом языке понадобилось только изменить проверку, а в типизированном всюду заменить phone на phoneAsString(phone) и добавить ветку для обработки второго варианта телефона.

В С++ для этого Александреску придумал стратегии. Но с ними синтаксис становится ужасный: template <class CharType, class Traits = char_traits<CharType>, class Allocator = allocator<CharType>> class basic_string;

Блин, всё равно не могу представить, как заказчик может не знать заранее, какие функции должен выполнять его сайт.

Ну, если тебе любопытно, был у меня такой случай (правда скорее выдающийся чем обычный):
Приходит мужик, делат сайт. Он в общем подумал что ему надо и в некотором смысле знает и спланировал что то. Приходит с эксель таблицей, там поля ввода и формулы, штук 150 кажется было, где-то варантов 6 (на сколько помню) по которым часть этих полей появляется/исчезает или считается по альтернативным формулам. Это то что его пользователь должен вводить (условно 6 типов пользователей, такой у него бизнес). Я говорю - дизайн? Говорит: мне попроще, только чтоб работало. Делаем набросок, шаблонный дизайн. программируем. готово. Он говорит, да, всё так. вот только теперь он видит это в деталях и понимает что это не очень то то что он хотел бы иметь в результате. Угу, переделываем. Переделали. Он понял что вообще то ему нужны другие поля и формулы... а там только на то чтобы с этим экселем сверится, часы уходят.. ну и он понимает, что дизайн ему вообще то нужен крутой. Находим дизайнера. Дизайнер, по моему профи был, дизайнит. Учитывает поля (новые) . Даёт нам (это месяц прошел с момента как нашли дизайнера, два с начала проекта, емнип). Дизайн заказчику нравится. Поля новые есть, формулы в экселе есть (ясное дело не без ошибок), делаем. Сделали. Формулы опять поменялись.. правда в этот раз не радикально. Но зато стало ясно что вообще то надо подинамичнее делать: надо чтобы поля при вводе (в смсле onchange) считались/менялись, а не по нажатию сабмит..

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

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

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

как то так..

Почему «заменил» - 1С:Зарплата когда-то была на Яве?

Конкуренты на Java есть. https://www.cuba-platform.com/ например.

SAP R/3 тоже потихоньку вытесняется. У него ABAP — типизированный, со сборщиком мусора.

Он понял что вообще то ему нужны другие поля и формулы...

Это реально ужас. Хотя Common Lisp примерно под такое техзадание и разрабатывался. С дополнительным требованием, что программу останавливать нельзя.

1С успешно заменил. Проекты на нём огромнейшие (73647 процедур и 24388 функций в 1С:Зарплата).

интересно.

Я бы попробовал объяснить дешевизной 1с-ников по сравнению с явистами (ведь 1с-ники только в РФ работают, а явисты могут уйти на зарубежный рынок, вместо того чтобы скидывать цену). И это может быть, гм, «пробой». Т..е не факт что это зацепиться: написать было дешевле, а обслуживание/сопровождение дороже выйдет, например. Может занять десяток лет, пока рынок заметно отшатнётся от этого явления. Но конечно это может или противоречить моим рассуждениям, или показывать что производительность труда не растёт в достаточной степени чтобы окупить подготовку программиста на яве если сравнивать с 1с. Может быть в россии оптимум будет не на яве а на 1с ввиду низкой стоимости рабочей силы.

а в типизированном всюду заменить phone на phoneAsString(phone) и добавить ветку для обработки второго варианта телефона.

ветку пришлось добавить и в php. собственно, тут ветка vs ветка , ничего vs написать инстанс show или заменить на asstring. Оба варианта не такие страшные, потому что компилятор предупредит и всё будет сделано. Ситуация, когда изменения есть, а отследить их нетривиально - более неприятна: цена рантайм ошибки несравнимо выше чем компил тайм. Что до стратегий, надеюсь (кажется, не безосновательно), что функциональные языки ведут себя сильно лучше во первых из за композиции, во вторых, типизированные, потому что типы выразительней.

Всё таки типы и конструкции в хаскеле гораздо, гм, по моим впечатлениям, менее «хрупкие», чем в с++, к примеру. Необычное поведение (ленивость, эксепшины не вовремя, как ты заметил) - это безусловно проблема. Но, всё таки, это скорее «остатки» от проблемы, если сравнивать с с++ или тем более с динамическими языками: там ведь этого поведения ничего другого и нет, по большому счёту.

Но твои аргументы и аргументы евангилиста кложи с ютуба мне кажутся интересными (в смысле, расстраиваете вы меня оба:) ).

Ответом на кложу мне кажется можте быть что это просто язык который «почти может» (как и лисп, имхо). Это такое функциональное программирование «для бедных»: решение которое работает «в основном». Т.е. решает 70% задач, за 30% затрат. Правда, ещё 30% оно решит только если потратить 200%, по сравнению там где обычное потратит 100% (условно). Но пока находишься в 70%, ты в шоколаде. Такое себе php но сделаное с головой.

Наверное, если бы я задумался о замене php лет 5 назад и понимал бы ситуацию как сейчас, я бы променял php на кложу (не на лисп, из за jvm и библиотек). А потом бы присматривался к хаскелю.

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

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

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

See also: Python.

Как говорил один умный лиспер: «На обычных языках программы проектируются как дом, а на лиспе они выращиваются как дерево».

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

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

Так может, надо вместо signed int указать в сигнатуре unsigned int?)

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

В случае Haskell'а это тоже встречается. Причём сообщение типа «ошибка чтения из файла» в функции, которая работает со строками в списке весьма неожиданна. А всё ленивость, вместо того, чтобы ругнуться и упасть, он ошибку в список сохраняет вместо строки. И если список не обрабатывать, то ошибки даже как бы и нет.

Явственно пахнуло джаваскриптом.

И это обычное состояние программиста. Любого.

Рекомендую к прочтению https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/ (англ.) и/или https://habrahabr.ru/post/339038/ (рус.).

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

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

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

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

Вообще хаскеляторы, смотрю, то пхп зарабатывают, то 1С.

Пример у тебя реальный. Это monk, наверное, привык иметь дело, как минимум, с людьми с ВО. Те, действительно, должны иметь какие-то навыки для ясного оформления ТЗ по определению, в универе муштруются подходящие умения и навыки.

Ну что, господа, короли хеллоуворлдов, знатоки программирования

Если можно вкратце, к какому консенсусу вы пришли касательно будущего лиспа? Когда уже на лиспе можно будет писать как на 1C?

Почему «заменил» - 1С:Зарплата когда-то была на Яве?

Конкуренты на Java есть

Ну то есть ничего он не заменил.

SAP R/3 тоже потихоньку вытесняется

Эллочка понемного побеждает Вандербильтдиху.

monk, наверное, привык иметь дело, как минимум, с людьми с ВО. Те, действительно, должны иметь какие-то навыки для ясного оформления ТЗ

Скорее с бухгалтерами. Это очень формализованная область.

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

Так может, надо вместо signed int указать в сигнатуре unsigned int?)

В моём языке, например, это запрещено (don't) ES.106, ES.102, I.6 (hint: в unsigned разломана семантика числа).
И почему это интересно температура в °C не может быть отрицательной?

Так может, надо вместо signed int указать в сигнатуре unsigned int?)

Дробные градусы бывают

И почему это интересно температура в °C не может быть отрицательной?

Упс. Затупил. Имел в виду, неотрицательная абсолютная температура. То есть для c-to-f аргумент должен быть не меньше -273,16.

Я так и подумал :) Потом я подумал отчего температура в K не может быть отрицательной и понял что забыл физику. Кажется какой-то матаппарат её потеряет нынешний смысл, типа отрицательной температуры под корнем где-то окажется, и только лишь. Как бы то ни было, unisgned типы (в C++) подходят только для битовой арифметики.

То есть для c-to-f аргумент должен быть не меньше -273,16.

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

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

До очень недавнего времени лисп был только за деньги и даже за деньги программы на нём были очень медленными. А дальше проблема инфраструктуры. Если в C#, Java и 1С вложились корпорации, то при попытке написать что-нибудь на лиспе сразу начинается: графический интерфейс постоянно в состоянии «на 80% работает», SQL-клиент не умеет ни курсоры ни параметризованные запросы и т.д. На 90% библиотек нет документации, она сводится к одному примеру использования и посыланию в исходники.

Любая попытка сделать целостную инфраструктуру приводит к тому, что это уже не совсем лисп (на http://dwim.hu пытались).

То есть он конкурентоспособен с языками времён ANSI CL, но с современными не хватает базовой инфраструктуры.

Формула перевода (как я её вижу на википедии) имеет один и тот же смысл на всём множестве действительных чисел.

А потом спутники падают... Там тоже не поставили проверку на допустимую исходную ориентацию разгонного блока «Фрегат». Ведь формулы имеют смысл на всём множестве действительных чисел.

P.S. Тогда можно в c-to-f принимать любое значение вообще. Если входящее значение не числовое, то возвращать (c-to-f 0).

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

Я именно поэтому сейчас пишу на Racket, а не на Common Lisp. Фактически, вред отладчика осознал только когда начал писать на Racket. В Racket фактически нет отладчика: есть контракты, есть тесты и есть документация, причём не принято публиковать библиотеку без контрактов, тестов и документации. Благодаря этому костылей на порядок меньше.

P.S. Тогда можно в c-to-f принимать любое значение вообще. Если входящее значение не числовое, то возвращать (c-to-f 0).

Более того -- именно так оно и должно быть сделано (template<typename T> T c2f(T);). И не надо приписывать мне спутники, которые я не ронял.

Если можно вкратце, к какому консенсусу вы пришли касательно будущего лиспа? Когда уже на лиспе можно будет писать как на 1C?

Как только какое-нибудь ЗАО «Лисп» вбухает в библиотеки лиспа столько денег, сколько 1С вбухало в свою платформу.

P.S. Скобки не проблема. Вот это тоже Common Lisp:

defun fibfast (n)
  if {n < 2}       ; Indentation, infix {...}
    n              ; Single expr = no new list
    fibup n 2 1 0  ; Simple function calls

defun fibup (max count n1 n2)
  if {max = count}
    {n1 + n2}
    fibup max {count + 1} {n1 + n2} n1

именно так оно и должно быть сделано

Нет. Если это преобразование из градусов Цельсия, то значение градусов Цельсия должно быть действительным числом не менее -273,16.

А «именно так» будет преобразование согласно формуле 32+1,8*x произвольного объекта, для которого определена операции умножения на рациональное число и для результата умножения определено сложение с целым числом.

Всё верно, типы отдельно (могут энфорсить свой диапазон в конструкторе, если захотят), алгоритмы отдельно. И алгоритму c2f при этом по барабану на _кельвины_ и матаппарат физического приложения, которое их использует.

Если это преобразование из градусов Цельсия, то значение градусов Цельсия должно быть действительным числом не менее -273,16.

Если уж на то пошло, то тип «градусы Цельсия» должен быть числом не менее -273.16.

Ошибка восприятия: прочитал про проверку на положительность и с чего-то решил, что температура не должна быть отрицательной :(

Сейчас (или когда-нибудь) Денис доделает своего Франкенштейна с Альфа Центавра, и точно заживём. Как-раз опустят «железный занавес» и все заграничные хаскели запретят.

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

Я именно поэтому сейчас пишу на Racket, а не на Common Lisp. Фактически, вред отладчика осознал только когда начал писать на Racket. В Racket фактически нет отладчика: есть контракты, есть тесты и есть документация, причём не принято публиковать библиотеку без контрактов, тестов и документации. Благодаря этому костылей на порядок меньше.

Можно ли это считать признанием лиспера, что одна из фич лиспа провоцирует порочный подход к разработке?

Скобки не проблема.

Пишет другие скобки...

Если это преобразование из градусов Цельсия, то значение градусов Цельсия должно быть действительным числом не менее -273,16.

Если уж на то пошло, то тип «градусы Цельсия» должен быть числом не менее -273.16.

Если уж на то пошло, то значения типа «градусы Цельсия» должны быть числами не менее -273.16.