- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
Del1 = fun(K,[A|B],F,Acc) ->
if
not(is_list(A)) and (B==[]) and (A rem K == 0) -> Acc;
not(is_list(A)) and (B==[]) -> [A|Acc];
not(is_list(A)) and is_list(B) and (A rem K == 0) -> F(K,B,F,Acc);
not(is_list(A)) and is_list(B) -> F(K,B,F,[A|Acc])
end
end.
D=[10,22,34,45,52,60,75].
Del1(5,D,Del1,[]).
И почему не в модуле?
-module(test).
-compile(export_all).
f1(_, []) -> [];
f1(E, [H|T]) when H rem E /= 0 -> [H|f1(E,T)];
f1(E, [_|T]) -> f1(E,T);
f1(_,_) -> {error, bad_args}.
Чтобы функция не потребляла стек пропорционально размеру списка (в худшем случае), очевидно.
Или у вас модифицированный, ленивый эрланг?
всё, якобы, тогда деаллоцируется разом, в то время как хвостовая функция оставит больше мусора на некоторое время, которое может привести к фризу VM, если дёргать подобные вещи периодически
поскольку я модель управления памятью в эрланге представляю себе очень плохо, не могу сказать, правда это или вымысел
Но таки юзают именно хвостовую в бесконечных циклах рекурсиях обработки сообщений.
Вообще оба метода имеют право на жизнь, но в случае сложной рекурсии хвостовой пользоваться проблематично.
Странный выбор.
эрланг убог, крив и не нужен
ну а мне за его готовку деньги платят, родной
в основном для контроля низлежащего сишкоблядского кода и высокоуровневых вещей
самое ужасное -- это вау-эффект от лёгковесных процессов, приводящий к https://my.mixtape.moe/vdjgii.png
А вообще да: каждый чих должен быть в отдельном акторе
Какой багор )))
Именно поэтому я за «HSTS».
Domain cock.li
Decision 27-31-2019/ИД1139-19 made on 2020-02-06 by Генпрокуратура.
This block affects IPs 185.100.85.212, 2a06:1700:0:b::c0c, domain cock.li and URL https://cock.li.
IP 37.120.193.123
Decision 27-31-2018/Ид2971-18 made on 2018-04-16 by Генпрокуратура.
This block affects IP 37.120.193.123.
Decision 27-31-2019/ИД1139-19 made on 2020-02-06 by Генпрокуратура.
This block affects IP 37.120.193.123.
Русня соснула.
Обожруся — и помру молодой!
https://i.imgur.com/G4ns3dX.png
Это она?
define GCL
Gnu Common Lisp?
Guarded Command Language?
Generic Configuration Language?
> Старался поживее язык дать.
Кмк, Scheme - отличная альтернатива. Как минимум есть сносная IDE в лице Racket. И отличная книга с отличным переводом в лице SICP. Ну и Guile - стандарт для расширений в мире GNU, на нём сейчас Guix пишут.
> взгляды субъективны
Не знаю, чего вы ждёте от своих учеников, если сами вместо объективной аргументации аппелируете к субъективности взглядов.
Я свои аргументы привёл, дальше дело ваше.
Мы не рассматриваем ФП, а язык, на котором удобнее всего иллюстрировать использование ФП.
Я и на C++ могу применять идеи ФП (и применяю), и C++ вполне себе "жив", но это не значит, что C++ - хороший язык для изучения ФП.
Да, наличие легко настраиваемой среды разработки - хороший довод в пользу выбора ЯЗЫКА для обучения, причём достаточно важный.
Наличие хорошей документации и литературы - ещё один довод в пользу ЯЗЫКА.
Наличие активных проектов с открытым исходным кодом - тоже неоспоримый плюс. Кроме того, схема имеет довольно много общего с Clojure, который тоже вполне "жив".
В (стандартной) Scheme, конечно, нет сопостовления с образцом и некоторых других функциональных вкусностей (вроде мощных систем типов), но для обучения азам ФП она подходит неплохо.
Недавно видел курсы Кичалеса на EDX, где использовалась схема:
https://www.edx.org/xseries/systematic-program-design-0
По среде. Моя основная рабочая среда (в зависимости от обстоятельств):
1) vim
2) mcedit
3) notepad++
Ну никаких проблем с ней нет за много лет работы.
По Erlang есть в достаточном объеме литература. Документация аналогично, нареканий не вызывает. Что касается среды, то она не ключевой момент с моей точки зрения, и иногда больше вредит.
По с++ - этот язык изначально ООП и только потом ФП, в отличие от Erl (или Scheme).
Я не сильно намерен холиварить. Дело каждого - по среде выбирать языку, по количеству книг или еще по чему то.
В каком году в пхп классы и лямбды появились?
Зайчатки ООП - 4.0 (~2000 год)
Приват и протектед - 5.0 (2004 год)
Неймспейсы, лямбды - 5.3 (2010 год)
2015-й год. С главной страницы php.net удалили ссылки на выпуски старше, чем 5.5. Т. е. официально поддерживаются только 5.5, 5.6 и 7.0.
На говнохостингах до сих пор зачастую 5.2 без лямбд и без неймспейсов.
Если взять какой нибудь Битрикс то там по моему и нейм спейсов нет.
нахуя они нужны при наличии копеечных VPS?
2. Как они держат пиковую нагрузку?
Опять ты за свое. Ты пойми наконец: ни для кого кроме тебя и еще пары школьников "настраивать апаче" не является проблемой.
Хотя на некоторых VPS сейчас из коробки есть cPanel/ISPmanager/ещё-какая-нибудь-панелька, c помощью которых залить сайт не сложнее, чем на шаред хостинг.
совершено верно.
Поэтому нет никакого смысла юзать шаред хостинг тем более за него платить.
Что это такое?
https://ru.wikipedia.org/wiki/Сравнение_панелей_управления_веб-хостингом
Такие панели хороши, когда они предустановлены. Ставить самому есть смысл, только если ты собираешься поднять не один сайт (т. е. если ожидается, что трудоёмкость установки потом окупится), потому что панель управления сразу может и не завестись. Пхпмайадмин заводится сразу, потому что ему нужны только координаты подключения к базе и больше ничего, а тут в разных сборках ОС могут не совпадать пути к файлам и набор программного обеспечения, так что придётся сидеть и править конфиги.
>К тому же на шаред хостингах бывает услуга установки этих ваших Джумлы или Друпала в один клик (т. е. даже самому качать и копировать не нужно).
1. Простой синтаксис (вотличие от Хаскеля, например).
2. Теория типов, которая исторически связана с функциональными языками освещена в деталях (вотличие от Схемы, например). Более того, запись типов в диалектах МЛ очень похожа на их математическую запись (что не обязательно хорошо, но поможет студентам сориентироваться), например, тип списка записывается так же как свободный моноид из алфавита элементов списка, тип функции, или коретжа выглядит очень похоже на математическую запись типа функции или кортежа и т.д.
Лолчто? В OCaml гораздо больше (раз в 4-5) различных синтаксических конструкций и их комбинаций. Ещё и ООП сбоку прикручено, правда, им мало кто пользуется.
У меня есть персональная лакмусовая бумажка простого синтаксиса: если я через полгода перерыва могу спокойно писать на языке код, не заглядывая в книжку для уточнения синтаксиса - синтаксис простой. Если не могу - синтаксис сложный.
Так вот, на Haskell и Go после перерыва (мне) писать легко, а на OCaml и Scala - очень сложно (если это не хелло-ворд, конечно). Я вот даже сейчас с трудом могу вспомнить, как в OCaml правильно записываются полиморфные типы с несколькими параметрами, нужно в доку лезть.
1. Нужно прочитать очень много контекста, чтобы понять то, что написано. Например, чтобы догадаться, что какие-то закорючки внутри строковых литералов будут особенным образом интерпретироваться нужно найти соответствующую {-# ... #-} инструкцию где-то х.з. где.
2. Грамматика очень свободная. Например: а б ц д - это код на Хаскеле, но можно только догадываться, имеется ли в виду ((а б) (ц д)), (а (б (ц д))) и т.д.
3. Программисты очень часто используют сложные / ненужные возможности языка (например, в Лиспе есть ридер макросы и символ макросы, но используют их крайне редко). Аналогично С++, где программисты любят использовать ненужные возможности языка просто потому, что они в нем есть.
А субъективно - ну вот я не пишу много на ОКамле, очень редко, когда мне нужно дать пример типичного функционального подхода - и я не испытываю сложностей при чтении программы. И в то же время чтение программы на Хаскеле для меня - это то же самое, что решать судоку, т.е. мне ее нужно переписать на что-то вменяемое, чтобы понять.
Все языковые расширения всегда пишутся в начале файла.
> Например: а б ц д - это код на Хаскеле, но можно только догадываться, имеется ли в виду ((а б) (ц д)), (а (б (ц д))) и т.д.
Это всегда означает применить функцию а к параметрам б, ц и д. Синтаксис вызова функций в OCaml такой же.
Ну разве что один из аргументов в обратных кавычках - тогда он работает как оператор с дефолтным приоритетом 7.
> Нужно прочитать очень много контекста
Когда я читал чужие исходники, сложнее всего было понять, откуда появляются функции, потому что люди почему-то не любят квалифицированные импорты. Но это не синтаксическая проблема, а семантическая. В OCaml тоже так можно навредить, переборщив с open Module
Для себя эту проблему решил явной квалификацией всех импортов во всём коде, который пишу.
Не согласен.
У меня есть теория - когда люди пишут на "красивом" (не важно, что они понимают под этим словом) языке, они зачастую ожидают, что почти у всех задач есть "красивое" решение на этом языке.
Проблема в том, что это не всегда так. Иногда "красивого" решения с читаемым компактным кодом не существует. Нужно писать хаки и прятать их за вменяемыми интерфейсами. Нужно разбираться в тонкостях линковки или писать клиентов для паршиво спроектированных апишек, обрабатывать сложные ошибки, ловить и реагировать на сигналы, etc.
И вот тут начинается когнитивный диссонанс - люди не знают, как сделать "красиво", а "некрасиво" им мешает убеждённость во врождённом превосходстве инструмента. Добавьте сюда относительную изоляцию разработчиков (вероятность встретить хаскелиста-единомышленника довольно мала), и станет понятно, почему большинство хаскелистов только ходят по форумам и рассказывают, как офигенен их язык, вместо того, чтобы писать реальные полезные программы.
Когда люди пишут на хаскеле на работе за деньги, они, безусловно, сталкиваются с множеством проблем, но в целом очень довольны выбором языка.
Хм, т.е. PHP, по сути, идеальный язык. Никто не ждёт от кода на PHP чего-то красивого, поэтому на нём можно написать сложный проект.
You've got the idea.
Да, что-то вроде этого. Никто не ищет красоты, просто намазывает тёплый функционал слой за слоем, в итоге получая что-то более-менее работающее, потом щедро сдабривает костылями и выставляет наружу модный РЕСТАПИ.
Так что в каждой шутке есть доля шутки
Я имел ввиду другое, на имиджбордах одни говноеды.
Потому что я лоханулся, привык к доброчановским /lor/ и /lisp/.
Што?