LINUX.ORG.RU

Анализ пользователей Common Lisp и Racket

 , ,


11

7

Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист. Поэтому из языка намеренно исключены сложные для понимания конструкции (пользователь не обязательно квалифицированный программист), поэтому в языке мощнейший отладчик, позволяющий без остановки программы переопределять функции и вообще делать что угодно. Но из-за этого документация по большей части библиотек Common Lisp существует только в виде docstring и комментариев в коде (некоторые вообще считают, что код сам себе документация). Из-за этого обработка ошибок почти всегда оставляется на отладчик (главное сделать рестарт «перезапустить с последней итерации», а там пользователь сам разберётся). Из-за этого в программе проверяется только happy path (пользователь ведь «тоже программист»).

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

И поэтому в Racket нет CLOS (есть как минимум две реализации, но не используются) - провоцирует заплаточное программирование (monkey patching), поэтому отладчик намеренно ограничен (если ты отлаживаешь программу, значит ты не знаешь как она должна работать!), поэтому нет разработки в образе (image based) - она провоцирует разработку через отладку (а значит непонимание программы и проверку только happy path).

Таким образом, Racket и Common Lisp несмотря на внешнее сходство являются очень разными языками. И я рекомендую писать на Racket, если только конечными пользователями программы не являются исключительно программисты на Common Lisp.

Взято с http://racket-lang.blog.ru/#post214726099

Хотелось бы знать, что по этому поводу думают пользователи ЛОРа. А также, мне кажется, что для Java и C++ будет где-то такая же разница.

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

Проблема в том что хаскель не форсирует эти нормы.

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

Так можно и про Си сказать, что тот не форсирует применение типов указателей — можно везде ставить void* и компилятор схавает. Или про Си++, что тот не форсирует RAII на уровне языка.

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

Ну ок, поговорили ;) спасибо за разговор.

Зато на примере проанализировали пользователей:

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

den73 — пользователь Common Lisp: главное динамическая реализация, разработка без перезапуска и производительность работы программиста (видимо, в написанных функциях в час). Язык должен позволять разрабатывать программу в образе.

qnikst — пользователь Haskell/ML: главное система типов. Правильно написанные типы — половина программы. Если типы описаны верно, то это позволяет почти гарантировать корректность программы. Язык должен позволять удобно описывать типы и проверять их корректность.

-----

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

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

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

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

Ну в достаточно expressive системе типов моё мнение будет совпадать со мнением анонима

Не будет. Всё равно ты будешь измерять в «возможностях системы типов», а аноним, если система типов будет не хуже, чем в Typed Racket найдёт, что в Haskell нет контрактов, Template Haskell не умеет syntax/loс, и тесты в Haskell нельзя описывать в файле маосго модуля как в Racket (module+ test ...).

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

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

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

Вообще в хацкеле сначала пишутся типы, а потом код.

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

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

Ты не понял? Еще раз - без топ-левел определений (а хаскель всячески стимулирует НЕ ПИСАТЬ топлевел определения) практически любая ошибка типов будет ошибкой обсуждаемого вида.

Ошибка типизации тут - ошибка в логике в другом месте.

Ошибка типизации - не тут. Ее тайпчекер нашел тут. А он найти ее мог где угодно. До тебя пример с закраской графа не дошел?

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

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

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

Так можно и про Си сказать, что тот не форсирует применение типов указателей — можно везде ставить void* и компилятор схавает. Или про Си++, что тот не форсирует RAII на уровне языка.

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

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

Особенно когда много фвп, поинтрфриблядство и трехэтажные типы.

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

anonymous
()

«Хотелось бы знать, что по этому поводу думают пользователи ЛОРа»

Пользователей обоих языков я бы расстреливал на месте.

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

Пользователей обоих языков я бы расстреливал на месте.

Они тебя чем-то обидели? Детская травма?

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

«Они тебя чем-то обидели? Детская травма?»

Если я раздавил таракана тапком, это означает, что тараканы меня чем-то обидели в детстве, господин Фрейд?

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

Неприязнь к тараканам имеет вполне очевидные причины. А беспричинная неприязнь - это паранойя.

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

«Неприязнь к тараканам имеет вполне очевидные причины. А беспричинная неприязнь - это паранойя.»

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

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

Пользователей обоих языков я бы расстреливал на месте.

Если для тебя неочевидны причины нелюбви к задротам, то для меня очевидны.

Т.е для тебя «пользователи обоих языков» - задроты? Обоснуй.

кривых велосипедов

Опять же, голословное высказывание. Надо бы пояснить, почему Racket и CL - кривые велосипеды. И что для тебя не кривой велосипед?

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

Чем больше кривых велосипедов, тем хуже.

Оценка кривости велосипеда без рассмотрения сферы его применения? Чтоб ты всю жизнь катался по скалам на трековом велосипеде!

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

«Т.е для тебя «пользователи обоих языков» - задроты? Обоснуй.»

Практическое применение этих языков отсутствует. Стоимость поддержки слишком велика.

«И что для тебя не кривой велосипед?»

Например, Perl.

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

Практическое применение этих языков отсутствует. Стоимость поддержки слишком велика.

Во-первых опять голословно - где статистика? Во вторых не аргумент.

Например, Perl.

Может лучше COBOL?

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

«Может лучше COBOL?»

Тогда уж язык АДА.

«Во-первых опять голословно - где статистика?»

Может быть, в Гугле?

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

«Во-первых опять голословно - где статистика? Во вторых не аргумент.»

Racket https://www.openhub.net/languages/racket 118 проектов, 269 задротов

Lisp https://www.openhub.net/languages/lisp 1878 проектов, 2774 задротов

Perl https://www.openhub.net/languages/perl 32560 проектов, 55976 программеров.

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

Тогда уж язык АДА.

Ты считаешь пользователей языка АДА задротами? Тогда уж за одно и пользователей Эрланга и Фортрана, что уж.

Может быть, в Гугле?

В гугле есть статистика? Пруфы в студию!

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

Fortran https://www.openhub.net/languages/fortranfree 1225 проектов, 3262 задротов

Erlang https://www.openhub.net/languages/erlang 2245 проектов, 3402 задротов

Tcl https://www.openhub.net/languages/tcl 2306 проектов, 4745 задротов

Golang https://www.openhub.net/languages/golang 1902 проектов, 4827 задротов

VHDL https://www.openhub.net/languages/vhdl 402 проектов, 706 задротищей

Verilog ??? 0 проектов, 0 стыдно сказать кого

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

Такие же мертвые языки, как Racket или Lisp. Только у Fortran было время популярности во времена, когда компы были убоги и доступны только на работе.

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

Такие же мертвые языки, как Racket или Lisp.

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

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

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

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

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

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

Не уверен есть ли более кривой велосипед в этой вселенной, чем Perl. Разве что флюс пожалуй, но тот хоть с турбонаддувом, а пердл - это самокат с девятью колёсами разного размера.

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

«Во-первых опять голословно - где статистика? Во вторых не аргумент.»

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

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

Практическое применение этих языков отсутствует. Стоимость поддержки слишком велика.

На твоем локалхосте? Ну может быть. Верю.

Например, Perl.

фубля

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

«Да чтоб тебе так зарабатывать, сколько средний пользователь верилога зарабатывает.»

Не вижу достоинств для работодателя платить втридорога программисту на языке, на котором в стране от силы 2-3 «специалиста». Размер зарплаты - это минус, а не плюс, для экономики. У Чубайса зарплата в миллионах, и что?

Чисто для справки, сколько зарабатывает пользователь Verilog у тебя в стране?

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

«Зачем ты врешь?»

Ну назови практическое применение языков, на котором пишет 3.5 задрота. Кроме распила бюджета?

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

«На твоем локалхосте? Ну может быть. Верю.»

В целом в мире. Рвется пукан, боишься осознать ненужность своих знаний?

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

«Да чтоб тебе так зарабатывать, сколько средний пользователь верилога зарабатывает.»

http://puschino.hh.ru/search/vacancy?area=1&text=verilog&specializati...

Что-то я не вижу, чтобы кодер на Verilog зарабатывал больше кодера на Перле. 40-120 тыс. - недостаточно для сакрального знания.

http://puschino.hh.ru/search/vacancy?only_with_salary=false&area=1&cl...

За perl платят больше, доходит до 150 тыс.

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

боишься осознать ненужность своих знаний?

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

Рвется пукан

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

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

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

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

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

«Вне маськвы жизни вообще нет?»

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

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

Муа-ха-ха, ты б сам читал, сучка, блядин сын, на что ты ссылаешься.

Они там нереляционные СУБД записали в вымирающую категорию (ага, года за два до начала бума NoSQL). Просто мега-аналитеги, как раз тебе, школолошке, под стать.

Дальше вообще божественно. Программирование на Си тоже записали в умирающий скилл.

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

«Они там нереляционные СУБД записали в вымирающую категорию (ага, года за два до начала бума NoSQL). Просто мега-аналитеги, как раз тебе, школолошке, под стать.»

Что тебя веселит то так? Нереляционные БД хороши только для данных, которых не жалко потерять навсегда. В продакшене они не вперлись.

«Дальше вообще божественно. Программирование на Си тоже записали в умирающий скилл. »

У тебя есть данные, что Си не умирает? У меня данные, что С++/С# давно вынесли Си на кладбище.

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

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

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

И по моим данным, на Си до сих пор написано почти все системное барахло. Никакими C++ там и не воняет.

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

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

«И по моим данным, на Си до сих пор написано почти все системное барахло»

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

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

«Насчет нереляционных БД - например, они используются практически во всех промышленных CAD-ах. »

Хранилища типа ключ-значение: недостатки

Ограничения в реляционных БД гарантируют целостность данных на самом низком уровне. Данные, которые не удовлетворяют ограничениям, физически не могут попасть в базу. В хранилищах типа ключ-значение таких ограничений нет, поэтому контроль целостности данных полностью лежит на приложениях. Однако в любом коде есть ошибки. Если ошибки в правильно спроектированной реляционной БД обычно не ведут к проблемам целостности данных, то ошибки в хранилищах типа ключ-значение обычно приводят к таким проблемам. http://habrahabr.ru/post/103021/

В общем, как я и сказал, нереляционные базы данных неспособны обеспечить сохранность данных.

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