Степпер для SBCL - помогайте

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

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

в целом ты не учитываешь пару аспектов:

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

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

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

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

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

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

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

Я тут слегка наброшу.
YouTube
Очень рекомендую посмотреть первую половину доклада. Там Николай толковые вещи говорит про фп, типы и динамические языки.

42 минуты смотреть? вы издеваетесь, сударь. может тезисно изложите?

АПД. а, половину. всё равно многовато, тезисное изложение было бы толковее. но на досуге гляну если найду время. сегодня много потратил на болтовню, как no-such-file сказал, лишь бы не работать...

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

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

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

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

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

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

Конечно, ты ошибаешься.

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

не дёргаешься, не дёргаешься. всё равно ломается всё. с типами проще. в той же яве и в том же си++.

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

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

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

Очень рекомендую посмотреть первую половину доклада.

Что-то первые 10 минут - сплошные невнятные понты. Это точно стоит смотреть?

очень умнО

Очень умнО - это отвечать выборочно, только на то, что удобно.

вопрос этот численный, а не качественный

Ах уже численный? А это

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

кто-то другой писал, не ты?

можно ведь просто взять лучше чем то что сейчас

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

по моим впечатлениям, разработка это постоянные изменения. и тесты это тот ещё геморой. Типы гораздо проще при изменениях

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

предлагаю за сим закончить разговор

Согласен.

Очень умнО - это отвечать выборочно, только на то, что удобно.

стараюсь не пропускать аргументов. повтори, вкратце.

Ах уже численный? А это

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

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

ну вот что мне на это ответчать? ладно, не буду пропускать: микроскоп совершеннее молотка не в деле забивания гвоздей. а хаскель лучше php в деле написания ПО.

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

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

Что-то первые 10 минут - сплошные невнятные понты.

спасибо, погляжу с 10 минуты.

стараюсь не пропускать аргументов. повтори, вкратце

Мы вроде бы закончили? Я во всяком случае, сказал всё что хотел.

да, спасибо за вопрос..

вообще есть ещё один аргумент у меня за хаскель и иже с ним: математические абстракции.

Если брать историю, то видно что уровнь абстракций рос - маш коды - ассемблер - подпрограммы - процедуры/функции - объекты.

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

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

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

Я, кстати, встречал однажды диссертацию (автореферат) в которой рассматривалось (по памяти) применение теоретико-категорных абстракций в с++. Вот только на практике я такого кода не видел.

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

По моему это тоже очень важный аспект. А там кто его знает.

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

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

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

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

Было бы интересно сравнить хаскель vs closure, может быть 5 сотен «одинаковых» библиотек (т.е. библиотек которые друг другу соотвествуют,т..е ну напримре работа с json и т.п) , но два аспекта:
- количество строк кода (с удалениями и добавлениями и без удалений)
- количество багов в багтрекере (закрытых и открытых)
- количество пользователей

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

Очень рекомендую посмотреть первую половину доклада.

Что-то первые 10 минут - сплошные невнятные понты. Это точно стоит смотреть?

И как только ты повёлся на предложение посмотреть видео от евангелиста на ютьюбе(?)

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

И как только ты повёлся на предложение посмотреть видео от евангелиста на ютьюбе(?)

А что такого? На ютубе есть интересные видео.

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

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

https://ru.wikipedia.org/wiki/Erlang#Горячая_замена_кода http://club.cnews.ru/blogs/entry/import_goryachaya_zamena_koda_b7f8 https://habrahabr.ru/post/81783/

Есть ли у тебя пруфлинки на твою? Если термин «горячая замена кода» плохим, то какой тогда хороший?

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

Нет, если бы, допустим, программы были написаны на Хаскеле, где нельзя добавить поле в классе уже работающей программы, то такой перезапуск был бы связан с многочасовой выгрузкой многих Гб данных из старой структуры и загрузкой в новую. Впрочем, и в SQL alter table обычно запускают не без проблем, но перерывы в работе при этом минимальны.

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

Я деньги зарабатываю не на гитхабе, а на рынке труда, и ты тоже.

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

Не слишком, но всё же SQL востребован на сегодня в 300 раз больше, чем Хаскель. При том, что вакансия по Хаскелю спорадическая, обычно их 0, а тут вдруг 1, так что коэффициент гораздо больше.

По моему это тоже очень важный аспект.

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

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

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

Вероятно моё понимание термина неверно. Почему то да, самомодифицирующийся.

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

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

Во первых, я должен сказать что понимаю, что сегодня sql и «горячая замена» связаны неразрывно.

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

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

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

Мне кажется тебе нужно согласиться, что требования к кандидатам sql никак не связаны с «запросом рынка на горячую замену кода». Я не знаю насколько актуально требование горячей замены в целом, но надеятся на то что лисп будет кому то нужен просто потому что в каждой sql базе данные (и код) меняются на лету мне кажетя весьма наивным. Если, конечно, ты не собрался заменить лиспом сами базы данных.

Я деньги зарабатываю не на гитхабе, а на рынке труда, и ты тоже.

На мировом, как и ты. И гитхаб есть некое, может и несколько искаженное, но отражение мировых тенденций, по факту.

На мировом, как и ты

Тогда нужно смотреть мировой аналог rabota.yandex.ru, а не гитхаб, где выложены _открытые_ репозитории, к-рые не пропорционально отражают закрытые.

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

У рынка есть запрос на минимальный простой. SQL даёт это из коробки, CL даёт, Хаскель - нет. При этом бизнес напрямую видит минимальный простой при обновлении БД, а внутри ИТ можно увидеть и пользу минимального простоя в ходе разработки. Горячая замена, как и твоя статическая типизация - это инструмент минимизации потерь контекста при разработки. Ни много, ни мало - приложение можно разрабатывать без остановки самого приложения. Так что не понял, с чем я должен согласиться. Полезность SQL и его востребованность во многом связаны именно с горячей заменой, которую он предоставляет. То, что это мало кто осознаёт - это уже другой вопрос. И то, что это недооценено для обычных ЯП - это третий вопрос.

Тогда нужно смотреть мировой аналог rabota.yandex.ru, а не гитхаб, где выложены _открытые_ репозитории, к-рые не пропорционально отражают закрытые.

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

У рынка есть запрос на минимальный простой. SQL даёт это из коробки, CL даёт, Хаскель - нет.

Запрос на минимальный простой который просит рынок вряд ли может быть удовлетворён средствами лиспа, это важно вообще-то (ну только если ты не начнёшь утверждать что может, «только надо в него базу sql встроить»).

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

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

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

Да, тут я спорол горячку. Зациклился на массивах из за примера с компил-тайм длиной. А тесты не писал уже довольно давно. Или вообще сишный код у меня всплыл, 10 летней давности, не уверен. Но это не так важно...

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

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

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

На хаскеле существуют интересные решения, вроде такого https://hackage.haskell.org/package/justified-containers-0.1.2.0/docs/Data-Ma... .

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

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

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

А проблема обращения к пустому массиву, как и нулл-поинтер существуют, как ни крути. А в таких языках их нет, что вообще то замечательное свойство.

В лиспе типы есть, другое дело, что на данный момент кривоватые. Но тут не слишком интересно сравнивать ноль лиспа и случайный 1 (а реально - ноль) Хаскеля на рынке труда. Для твоего раззомбирования важнее сравнить этот 0 с сотнями и тысячами для других языков. Это значит, что Хаскель промышленностью не востребован. Была бы востребованность - были бы вакансии в заметном количестве. Давай посмотрим на мир. Что ты предлагаешь в качестве мирового аналога yandex.ru? jobs на stackoverflow?

Ну, одна - это ты грубишь. вот например , на вскидку https://www.facebook.com/careers/jobs/a0I1200000LTJsQEAX/ .

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

В целом давай jobs на стековерфлоу поглядим, отчего нет.

АПД. Только я не знаю что там глядеть, что то зашёл - там какие то вопросы.. там поиск есть?

Может ты и прав... будешь когда-нибудь потом.

может быть...

Там есть спец. сайт jobs, но похоже,что ни по common lisp, ни по haskell там работы нет, и поэтому он предлагает что-то левое. А значит, нельзя его использовать.

Даже русская мафия в POI говорила не с таким акцентом

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

Нет, это просто недоделокализованная русская версия. Вообще-то оно вот так выглядит

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

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

Проблема в том, что если Вам пришлось запустить отладчик на своей программе, значит Вы не понимаете, как эта программа работает. К слову, Линус Торвальдс именно поэтому против отладчиков.

А Common Lisp предоставляет встроенный в REPL отладчик на стероидах. Там, где на C++ или Racket я сначала постараюсь продумать, как данные должны обрабатываться программой, какие граничные условия должны быть, какие алгоритмы использовать и какие части программы должны изменяться в будущем, на Common Lisp мне проще набросать прототип, а потом на работающем прототипе смотреть на ошибки и пытаться понять, какие случаи я упустил.

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

А вот то что типов нет, на мой взгляд - критично.

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

Если брать конкретно Хаскелл (и Си++), то сила его не в типах как таковых, а в полиморфизме на типах. Возможность писать

f :: Int -> Int -> Int
f x y = x + y

f :: Kilometers -> Kilometers -> Kilometers
f x y = x + y

И даже иметь разные pi::Double и pi::Float — это удобно. И часто позволяет писать меньше кода. Но в реальных программах всё равно приходится ставить проверки на диапазоны и невозможные значения.

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

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

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

К слову, Линус Торвальдс именно поэтому против отладчиков.

Линус сказал эту глупость 18 лет назад, когда его dayjob была какая-то фигня в Transmeta. С тех пор в Linux появилось много навороченных средств отладки и мониторинга (отадчиков - то ли 2, то ли 3).

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

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

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

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

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

С тех пор в Linux появилось много навороченных средств отладки и мониторинга

AFAIK, Линус к ним отношения не имеет. Так-то и на MS Visual Studio уже ядро линукса отлаживать можно (http://sysprogs.com/VisualKernel/tutorials/kgdb/)

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

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

Рекомендую к прочтению https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/

Daniel Lemire is a computer science professor

there are cases where a debugger is the right tool

Ясно, спасибо.

С тех пор в Linux появилось много навороченных средств отладки и мониторинга

AFAIK, Линус к ним отношения не имеет

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

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

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

there are cases where a debugger is the right tool

Ты дочитывай "... mostly on simple or quick-and-dirty projects, or in contexts where my brain is overwhelmed because I do not fully master the language or the code". То есть отладчик нужен только если пишешь индусский быдлокод или если сам не понимаешь, что пишешь, так как не знаешь языка (и получается ещё хуже, чем быдлокод, тот хоть работает).

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

Гм... Его там особо не спрашивали. Точнее спросили, он сказал, что против, остальные пришли к выводу, что им отладчик всё равно хотелось бы. «You seem to miss the implications of GPL. There's nothing Linus can do to prevent you from distributing your debugger, both as a patch and as a part of the kernel, as long as you don't break GPL.» (с).

Ты дочитывай

Я дочитал.

Точнее спросили, он сказал, что против, остальные пришли к выводу, что им отладчик всё равно хотелось бы. «You seem to miss the implications of GPL. There's nothing Linus can do to prevent you from distributing your debugger, both as a patch and as a part of the kernel, as long as you don't break GPL.» (с).

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

Так, в общем, помогать мне никто не собирается, спасибо, я вас понял.

Ты думаешь, здесь хоть кто-то разбирается в потрохах SBCL настолько, чтобы понять как работал старый степпер и что именно ты поменял?

Этот план я изложил товарищу из группы SBCL, может они сделают сами.

Там больше шансов.

P.S. Если честно, даже я не понял, что было не так, что именно сделано, что именно ещё надо сделать. Видео с описанием «как это работает в моей IDE» — это, по-моему, худший вариант описания. На страничке ysbcl чуть лучше, но опять же нет измеримой цели. «I implemented a stepper that steps in each form. SBCL's stepper only steps on some function cals. But source for numbers is not shown correctly, steps are too frequent,». Так требуется шаг на каждой форме или не на каждой?

никто и не может включить его в официальное ядро в обход Линуса. И Линус его таки включил. А потом еще один.

Принимал патчи в ядро Эндрю Мортон. Линус как в 2000 году высказал своё фи, так больше к этой теме не возвращался.

P.S. Поиск по LKML ужасный...

Там больше шансов.

Шансы сделать 100%, если на это потратить время. Думаю, месяца хватит.

Если честно, даже я не понял, что было не так, что именно сделано, что именно ещё надо сделать.

Это было написано для тех, кто пробовал степпер из SBCL. Хотя я согласен, что фраза корявая. Смысл в том, что у SBCL шаги слишком редкие, а у меня - слишком частые, но когда мой степпер останавливается на атомах, исходник показывается криво. Но я уже не буду ничего менять. В мире тоже никому это не нужно. Честно сказать, везде, где я пытался полагаться на SBCL, он меня подвёл. Сплошной пентагоновский распил и откат, показуха, а не программа. За 15 лет можно столько наговнять, что потом и за 100 не исправишь. Пора его, наверное, закопать уже.

Попробую ещё CCL может быть. Правда, в отличие от SBCL, где есть чёткая процедура сборки, в CCL с этим как-то мутно, судя по описанию. Но у CCL таких жутких проблем с качеством нет.

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

знаешь, мы с тобой этого уже касались, емнип: мой воркфлоу как то так устроен, что изменения - просто какая то неотъемлемая часть жизни моей. Кажется, ты мне тогда сказал что это из за отсутствия планирования как такового. Я не знаю что на это ответить до сих пор, может быть ты прав.

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

Ну на php ясно что происходит (если нет тестов): f5 -> error-> fix -> f5 -> error -> fix -> f5 -> ура -> submit -> error -> fix -> submit -> ура -> (если вспомнил без сабмита про третье место) fix -> fix -> submit 2 -> (всё равно) error -> fix -> fix -> ура

через неделю: submit3 -> error -> чёрт, когда же я это сломал то? ах неделю назад, так что тут было...

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

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

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

А всё ленивость, вместо того,..

придёт идрис и нас спасёт :)

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

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

Изменилось представление модели. Штука в том что эта (изменённая) модель используется не только на данной странице, но и ещё в двух-трёх местах.

Расширение модели (добавление полей) вообще не должно ничего ломать. Переименование поля отслеживается либо умным IDE, либо grep -R по исходникам, но это требуется гораздо реже.

Работу за деньги на пхп ведь никто не отменял (для тех кто хаскель неосилил вовремя)...

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

Принимал патчи в ядро Эндрю Мортон

Мортон мог принять их только в -mm. Патчи в ядро Линуса принимает Линус и он один.

Ладно, не буду спорить. У меня информация только из LKML.