LINUX.ORG.RU

Ответ на: комментарий от AndreyKl

Я ещё раз повторяю: то что проверено в типах проверять смысла нет

А я ещё раз повторю: когда ты проверяешь логику тестами, ты проверяешь и типы (неявно), поэтому отдельно (явно) проверять типы смысла нет.

Это область компилятора.

И не нужно усложнять компилятор. И синтаксис.

И если более-менее осмысленная программа на хаскеле скомпилировалась, это часто значит что она работает корректно

Нет, это ничего не значит, кроме того, что она синтаксически правильная. В частности это значит, что в нашу функцию c_to_f всегда передаётся вещественное число. Но это не значит, что данное число - то, которое нужно.

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

А в программе и требуется проверить только ограниченное количество случаев использования в конкретном контексте. Доказывать корректность функции в алгебраическом смысле на практике не требуется. Ну кроме тех случаев, когда программа, как есть, сама является разновидностью алгебраического выражения. Все эти ML-и в таком виде и задумывались, но это отдельная тема.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

А я ещё раз повторю: когда ты проверяешь логику тестами, ты проверяешь и типы (неявно), поэтому отдельно (явно) проверять типы смысла нет.

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

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

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

Ещё раз, количество тестов уменьшается. Если при этом подключить доказательства, то в пределе стемиться к нулю. При этом типы проще и изоморфны коду в любом случае (т.е. их нельзя как тесты написать «неправильно» или «неполно»). Писать типы просто. Например, написать read a :: Int значительно проще чем написать тест который проверит выбросил ли ты исключение или нет если пришёл не инт.

Либо ты не хочешь видеть что я тебе написал, либо я вообще перестал понимать о чём разговор.

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Доказывать корректность функции в алгебраическом смысле на практике не требуется.

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

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 3)
Ответ на: комментарий от AndreyKl

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от den73

Ну вы горазды флудить

Что бы не делать - лишь бы не работать.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Компилятор не может давать таких гарантий. Он может только гарантировать соответствие типа при компиляции, но не то, что список не переполнится в рантайме

хм.

1) ну мы ведь знаем что может. по крайней мере не хуже чем тесты. Но при этом они не в другом файле, а прямо тут же , в коде. Или ты не знаком с вещами вроде Liquid Haskell?

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

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

Но при этом они не в другом файле, а прямо тут же , в коде

Сомнительное достижение. Как-бы обычно с лапшекодом принято бороться.

Или ты не знаком с вещами вроде Liquid Haskell?

И как он поможет, если заполнение списка зависит от внешних рантайм факторов? Например, от внешних данных?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Сомнительное достижение. Как-бы обычно с лапшекодом принято бороться.

почему это стало вдруг лапшекодом? лапшекод - вполне определённое понятие. То что кода становится больше не делает его лапшекодом, отнюдь (слово какое хорошее, «отнюдь» :) )

ну как... пишешь, условно

# LH: n >= 255
if( n < 255) throw error;


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

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

AndreyKl ★★★★★
()
Ответ на: комментарий от ugoday

вы когда говорите «диманически строготипизироавнные», имеете ввиду единственного представителя, лисп, да?

Если да, то обозревал его когда то лет 10 назад, наверное.

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

В исходных текстах? Т.е. курсорчик прыгает, step in, step over, step out, и мышью брекпойнты можно ставить?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

пишешь, условно

ЯННП, только не говори мне, что ты всю дорогу имел в виду проверки типа в рантайме в самой программе. Тесты - это юнит-тесты, а не if( n < 255) throw error;

no-such-file ★★★★★
()
Ответ на: комментарий от AndreyKl

питоновская утиная типизация тоже вполне подойдёт.

обозревал его когда то лет 10 назад, наверное.

Это не считается.

ugoday ★★★★★
()
Ответ на: комментарий от no-such-file

так ты обрати внимание на строку #LH n >= 255! Это ж тест входа , отдельный от кода программы, проверяемый компилятором. А ты говоришь гарантий не даст. Прекрасно даст.

--

Если брать отдельно чистые ф-ции, то ясное дело мы прекрасно всё (ну.. очень многое) можем выразить индуктивными типами. Т.е. там гарантии более «настоящие» что ли.

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

А ты ожидал что хоттабыч тебе прилети, протестирует и бумажку подпишет что ли?

AndreyKl ★★★★★
()
Ответ на: комментарий от ugoday

питоновская утиная типизация тоже вполне подойдёт.

полтора года назад писал микро http-сервис на питоне.

отличий от php больших не нашёл.

AndreyKl ★★★★★
()
Ответ на: комментарий от ugoday

Чтоб ты не спал спокойно, в SBCL нет статической типизации даже сегодня, и 10 лет назад её не было, и в CMU не было, и в Lispworks её тоже нет (во всяком случае, в 6-м). Я её хочу добавить и это является одной из целей в моём манифесте, пулл реквесты слать сюда:

https://github.com/budden/ysbcl

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Я уж не говорю о том, что в SBCL нет Map<T1,T2> и хрен её сделаешь в стандарте CL - эта тривиальщина была во всех C# уж лет 10 назад, наверное.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

И это тоже записано в моём манифесте. Короче, пока мой манифест не реализован, CL является морально устаревшим языком с точки зрения системы типов. И кстати, да, есть такая бага, которая не исправлена в 1.4.2 - если компилятор один раз видит, что x - типа (cons integer), то он незаконно обобщает это на всё будущее. Это страшный баг, который говорит о том, что в SBCL нет и вывода типов. Я его уже поправил в своём форке, но команде SBCL на него наплевать. Пруфлинк:

https://bugs.launchpad.net/sbcl/ bug/1733622

Как ты видишь, undecided и unassigned. Stassats завёл более плохое описание той же баги здесь и объявил мою багу дубликатом. А та, которую завёл он, имеет приоритет Low. В то же время, некоторые баги с приоритетом High скоро отметят 10-летний юбилей. Так что эта бага не будет исправлена никогда.

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от AndreyKl

И если более-менее осмысленная программа на хаскеле скомпилировалась, это часто значит что она работает корректно.

Расскажу свою кулстори. Где-то год назад прочитал learn you a haskell for a greater good джаст фо фан и для закрепления знаний написал программку для решения японских кроссвордов. И вот, несколько месяцев назад девушка не могла решить огромный японский кроссворд, где-то закралась ошибка. Заряжу-ка я его в свою программу, подумал я, и после получаса вбивания цифирок программа была запущена и... убита ООМ киллером. Что за хрень, подумал я, там же нигде не объявляется никакой большой массив или что-то в этом роде. Начал рыться в коде, и, вы не поверите, но это был первый раз когда я не мог въехать в свой собственный код. Ну ладно, спишем это на несколько иную логику хаскель-программ, с которой я не имею дело каждый день. Хорошо, разобрались с кодом, но что же там может жрать память? Погуглив я понял, что хаскелль создает свои ленивые структуры, из-за размеров кроссворда много вариантов и много этих структур. Потом определил в какой части жрется память (там как раз перебиралась масса вариантов), что было не так просто, так как в хаскеле нельзя просто взять и напечатать из функции. Вооружившись костылями для «энергичных вычислений» я поставил их чтобы избавится от ленивых структур, но ... Программа продолжала жрать память и валится и дальше. Потыкав программу еще часик я сдался. Но программа работала корректно, да.

Там было что-то около миллиона вариантов, много, но если бы это был не хаскель, то итерации бы все равно прожевались и я получил бы ответ.

goingUp ★★★★★
()
Ответ на: комментарий от no-such-file

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

Чушь!

* (defun c-to-f (celsius)
    (+ (* 9/5 celsius) 32))

C-TO-F
* (c-to-f 0)

32
* (c-to-f 100)

212
* (c-to-f "-5")

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {AC660F1}>:
  The value
    "-5"
  is not of type
    NUMBER

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL:TWO-ARG-* "-5" 9/5) [tl,external]
0] 0

*

А вот аргумент правильного типа, но вот в его правильности я не уверен :)

* (c-to-f -500)

-868

anonymous
()
Ответ на: комментарий от AndreyKl

так ты обрати внимание на строку #LH n >= 255! Это ж тест входа , отдельный от кода программы, проверяемый компилятором

Каким образом компилятор это проверит, если n известно только в рантайме.

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

Чушь!

Т.е. (c-to-f "-5") это синтаксически некорректное s-выражение? Унылая попытка, бро.

no-such-file ★★★★★
()
Ответ на: комментарий от den73

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

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

Из более интересного в этой области - идрис-мод умеет автопредполагать код (в отличие от автодополнения, он не только банально дописывает подходящие по типу функции, но и пытается сконструировать выражение, иногда удобно), получая подсказки от компилятора. Вот тут , примерно с 25:00 https://www.lektorium.tv/lecture/29853, примерно до 30 минуты.

AndreyKl ★★★★★
()
Ответ на: комментарий от goingUp

за стори спасибо.

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

AndreyKl ★★★★★
()
Ответ на: комментарий от no-such-file

он просто проверяет что инварианты соотвествуют твоим проверкам. После этого везде можно использовать n как число больше илбо равное 255 при доказательстве корректности остальных частей.

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

Вот в тот момент я понял что вообще то это не такое большое дело , просто нафиг не надо никому видно

Действительно, зачем лопата и трактор, если есть палка-копалка. И дураки все те, кто платят деньги за коммерческие IDE, в к-рых этот отладчик как раз есть. Я, правда, скажу, что ЕМНИП gdb в чём-то помощнее, чем студия, но в другом. Мышкости это не отменяет.

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

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

Рынок труда чётко показывает, что к чему. Яндекс-работа: Программист 1С - 3500 вакансий в России, программист Java - 1032, программист Python - 466, программист Clojure - 1, программист Haskell - 1, программист Lisp - 9, но на самом деле 0, т.к. это дополнительные требования.

Видимо, рынок не считает Хаскель таким уж хорошим - Python как минимум в 466 раз лучше.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Да, программист Erlang - 4 вакансии, т.е горячая замена кода востребована. Я уж не говорю про программист SQL - 293 - там тоже есть горячая замена кода.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Видимо, рынок не считает Хаскель таким уж хорошим - Python как минимум в 466 раз лучше.

Кстати, у Python нет горячей замены кода. Наверное, это не слишком востребовано.

tailgunner ★★★★★
()
Ответ на: комментарий от den73

Действительно, зачем лопата и трактор, если есть палка-копалка. И дураки все те, кто платят деньги за коммерческие IDE, в к-рых этот отладчик как раз есть. Я, правда, скажу, что ЕМНИП gdb в чём-то помощнее, чем студия, но в другом. Мышкости это не отменяет.

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

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

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

Аргумент-то не шибко хороший. Горячая замена есть начиная с маш. кодов. Фигач коды да заменяй что хочешь. Что это особо фичей не считалось. Так же есть «горячая замена» у всего что имеет прямой доступ к памяти типа си, только её там надо дописать, но , как и алгебраические типы, она там есть, ага.

Но самое главное - от этого вообще есть толк? вон в яваскрипте есть «горячая замена» - берёшь, прототип мутируешь, вот и заменил что хотел. ТОлько это скорее боль, чем фича. А как у вас в лиспе? Неужели этим кто то пользуется для чего то что расчитано на поддержку?

По рынку труда

1) я не думаю что ты хотел бы работать вместо этих 460 из этих питон программистов, или вместо php программистов. или даже 3470 из 3500 1с программистов.

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

AndreyKl ★★★★★
()
Ответ на: комментарий от den73

Да, программист Erlang - 4 вакансии, т.е горячая замена кода востребована. Я уж не говорю про программист SQL - 293 - там тоже есть горячая замена кода.

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

трудозатраты будут меньше. массово.

А за счет каких фич? Хоть я и не жалею, что прочитал книжку по хаскелю, мне он показался не очень практичным, но я не спец по хаскелю. Честно говоря я бы быстрее переписал бы эту свою программу, допустим, на раст, и получил бы результат, чем заставил бы ее заработать на хаскеле.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

за счет каких фич?

я весь тред распинаюсь))

основная мысль изложена здесь Степпер для SBCL - помогайте (комментарий)

no-such-file и ugoday оппонируют. тейлганнер, по-моему, в целом поддерживает эту мысль.

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

Неужели этим кто то пользуется для чего то что расчитано на поддержку?

Ну вот например, как я сейчас правлю SBCL? Если могу, меняю одну функцию - мгновенный результат. Если не могу, slam.sh + сборка IDE - 2 минуты. Если это не работает - то полная сборка + сборка IDE - 7 минут. В CL все и всегда работают именно так.

я не думаю что ты хотел бы работать вместо этих 460 из этих питон программистов,

Почему же, питон элитен (была где-то статья на хабре), в 3-м мире PHP, а в 1-м - питон. 1С 8 после знакомства с ним оттолкнул из-за динамической типизации (ха-ха) и убедил, что надо делать своё. Мне прежде всего нужна работа, которая приносит деньги для жизни, и лучше больше, чем меньше. По курсу валюты питон лучше. Но может быть, это будет JS.

den73 ★★★★★
() автор топика
Ответ на: комментарий от AndreyKl

угу угу, дело в горячей замене. особенно в случае sql

А ты попробуй выкинтуть ALTER TABLE и ALTER PROCEDURE - мир остановится. Автобус не выйдет на маршрут, самолёт зависнет в воздухе.

den73 ★★★★★
() автор топика
Ответ на: комментарий от AndreyKl

зачем ты делаешь такие далеко идущие выводы без взгляда на (мировую) динамику?

Хаскелю сколько лет? Лет 7 я поглядывал на вакансии по Хаскелю. Всегда 0. Сойдёт за динамику?

den73 ★★★★★
() автор топика
Ответ на: комментарий от ugoday

Ну, бросьте, лисп если и сложнее питона, то не сильно. А чтобы питон не выучить нужно быть очень недалёким человеком.

да, вот тут момент ,я не ответил. я не имел ввиду «выучить синтаксис». я имел ввиду мой пример с приципом лисков, который я приводил в этом треде: положим вы не знаете принцип лисков. пишите на php/python/list, написали программу которая его нарушает. написали тесты (но так как вы принцип не знаете, то тесты не поймали ничего). сдали программу. получили деньги. вы программист, порог вхождения очевидно, преодолён. только через несколько дней увидел проблему из за программой пользоваться невозможно. просит починить. вы лезете, видите, что блин, там концы с концами то не сходятся и придётся много кода теперь переписывать. работа у заказчика стоит, вы пишете дальше.

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

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

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

AndreyKl ★★★★★
()
Ответ на: комментарий от ugoday

В случае BDSM-like системы типов компилятор может проверить только самые детские ошибки, которые всё равно вылезут при достаточном тестовом покрытии.

что то я упустил эти сообщения.

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


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

AndreyKl ★★★★★
()
Ответ на: комментарий от den73

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

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

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

АПД. и да, в 90% перезапуск базы будет связан с парой минут необслуживания кассы. Не критично, не смертельно. все выйдут на марштуры и на рейсы. Но да, неудобно. Но в случае веба например, это делается переключением на другой сервер, горячая замена ненужна. По крайней мере это кажется гораздо большей болью чем переключение серверов.

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от den73

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

AndreyKl ★★★★★
()
Ответ на: комментарий от den73

Ну вот например, как я сейчас правлю SBCL? Если могу, меняю одну функцию - мгновенный результат. Если не могу, slam.sh + сборка IDE - 2 минуты. Если это не работает - то полная сборка + сборка IDE - 7 минут. В CL все и всегда работают именно так.

Т.е. при разработке?

Почти убедительно. Может быть с++-сники поведуться. Но у нас давно репл. И подсказки среды. Результат мгновенный точно так же. А может ещё и мгновеннее))

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

(я не пробовал всерьёз идрис, говорят там проблемы могут быть со скоростью компиляции)

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

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

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

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

Да. Именно так. Может тебя шлют лесом и ты идёшь изучать принцип Лисков. И в следующий раз пишешь уже лучше.

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

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

Очевидно, что ты идеалист-максималист, у которого порог либо преодолён, либо нет. Предлагаю тебе 1.показать свой код 2.выслушать какой твой код говно 3.покинуть эту профессию, т.к. ты профнепрегоден (не смог преодолеть порог)

no-such-file ★★★★★
()
Ответ на: комментарий от AndreyKl

Это я видел. Типы и всё? Но хаскель это не только система типов а еще и ленивые вычисления, о которые я уже обжегся и чистые функции. Вот в rust есть система типов, не такая мощная как в хаскеле, но вполне подойдет для того, что ты писал, почему не он? Есть ocaml, но он не такой стильный модный молодежный как раст :)

goingUp ★★★★★
()
Ответ на: комментарий от AndreyKl

проверит, правильно ли ты написал иф.

Если ты делаешь if (т.е. рантайм ассерт), за что тогда ты боролся и нафиг нужен статический тип? Чтобы программа собралась? Т.е. проверка типа ради проверки типа? А как красиво и радужно всё начиналось.

Я тебе небольшой «секрет» открою, все эти ML-и задумывались как средство доказательства утверждений, заданных соотношениями и алгоритмами программы. Для этого внешние данные не требуются, а результатом проверки является сам факт сборки программы. Это годится только чтобы фибоначчи считать (и да в этом случае всё отлично и даже тесты не нужны), но не для обработки реальных данных. С реальными данными хаскель ничем не лучше php ни в плане «гарантий компилятора», ни, тем более, удобства и быстроты написания алгоритмов обработки.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Если ты делаешь if (т.е. рантайм ассерт), за что тогда ты боролся и нафиг нужен статический тип?

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

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

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

Что то мне подсказывает что на php ты не шибко много писал, как и на яваскрипте. Может быть я ошибаюсь, конечно. Я после яваскрипта, иногда, кажется, на си готов писать, такой он нудный (в смысле того что надо всё помнить и всё тестировать). И php такой же. Хаскель рядом не стоит, правда да, опыта пока не много, только небольшой личный проект.

AndreyKl ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.