LINUX.ORG.RU
решено ФорумTalks

Lisp и современность

 , ,


0

4

Привет, ЛОР.
Создал тему не срача ради, а потому что действительно хочется разобраться.
Уже которую неделю ковыряю emacs с его elisp-ом и параллельно читаю околопопсовые статьи по машинному обучению и, собственно, возник вопрос, а почему современная индустрия машинного обучения использует python, а не lisp? Ведь, если мне не изменяет память, lisp довольно продолжительное время удерживал первенство в этой сфере, особенно в области символического искусственного интеллекта и области экспертных систем. Но, видимо, после прошлой «AI winter» что-то изменилось и я не могу понять что именно. Были ли это причины, связанные с самим языком или «просто так получилось»?

Теперь немного наброса(куда же без этого). Можете пропустить эту часть.
Расскажите о ПО, написанном, на lisp-е, которое вы используете. Лично для меня это: emacs и иногда maxima.
Ну и хотелось бы услышать ваше мнение о перспективах lisp в будущем, страричку пора на покой или у него еще появится возможность проявить себя?


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

Тут как с графическими интерфейсами. Новичкам удобно одно, опытном пользователям — совсем иное. Очевидно, что запись cdaddr гораздо понятнее, нежели нечитаемая простыня текста (comp left-branch right-branch left-branch left-branch ехал-грека через-реку я-забыл что-там в-начале right-branch).

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

Это традиция, освящённая десятилетиями.

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

В clojure тоже начинаешь с того, что делаешь обёртки subvector, trim-right, trim-left, source-function, print-stack-trace

Зачем? Это не уровень прикладного кода. У меня нет задачи заново реализовать стандартную библиотеку, я её просто использую в своём прикладном коде.

вообще ни хрена не понятно, что они делают

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

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

Очевидно, что запись cdaddr гораздо понятнее

Когда речь идёт о бинарном дереве (детали реализации которого в общем случае неизвестны, известен и документирован только интерфейс), то вообще ни разу не понятно, что применительно к нему значит кададр. С (comp left-branch right-branch left-branch) хотя бы можно понять, что происходит, именно в терминах деревьев.

Хотя, конечно, наружу это всё торчать тоже не должно — в интерфейсе дерева (узла дерева) для этой задачи должна быть простая для понимания функция, скажем, minimal-value (которая использует разные кададры под капотом, если нужно).

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

Оно мертво

Дедушка умер, но дело живёт, хехе. А если присмотреться, то вроде как и не умер даже, слегка пошевеливается.

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

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

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

которая использует разные кададры под капотом, если нужно

Недавно узнал, что в юникоде есть специальный символ ∎, используемый в качестве знака «Что и Требовалось Доказать».

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

Недавно узнал, что в юникоде есть специальный символ ∎, используемый в качестве знака «Что и Требовалось Доказать».

Рад за вас. Но кададр всё равно ненужен, есть comp %)

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

питон надёжно занимает несколько экологических ниш

Динозавры, родственники питона, тоже себя до поры отлично чувствовали.

ugoday ★★★★★
()

This:

...или «просто так получилось»?

Пользуюсь emacs.

Lisp? Ну, мы живём в такую эпоху, когда всё (или почти всё) определяется чьим-то интересом. У меня был случай, когда я писал свои поделки по ИИ на Си, с использованием библиотеки OVL. Было это оч. давно, на Windows NT 4.0 с Borland'ом C++. Я к тому, что под задачи эмуляции ИИ, сгодится любой инструмент.

Было бы желание.

Моя поделка сейчас называется ИИ, а тогда никак не называлось.

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

...естественный отбор в ИТ технологиях...

Нету никакого отбора, забудь про это. Просто. Забудь.

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

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

Может быть. Соглашусь пожалуй. Но вот в конктексте темы, а занафига, например, датасайентисту дальше в программировании развиваться? Его питон устраивает. Ну может ещё С++ немного изучит или знал уже. Чтобы писать что-то побыстрее работающее.

Про вот это вот бешеное количество, не надо мне заливать. У Питона все плохо даже с вебом. Все вот эти библиотеки и фреймворки, в подавляющем своем большинстве - абсолютно всратое неюзабельное дерьмо.

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

Все там есть, что надо. А с моей библиотекой, у лиспа есть доступ к инфраструктуре дотнета. (а у ABCL, скажем - к Java; к тому же еще и существуют библиотеки для вызова того же питона)

Есть аналог PyTorch или сам PyTorch? Вот чтобы легко нейросетки задавать и главное проводить их обучение с обратным распространением ошибок (back propagation) и тд. Причём на GPU, причём даже на AMD-ном, а не Nvidia?

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

Для ML-задач, кстати, у .Net-а инфраструктура хуже, чем у Питона. Мне Питон не слишком нравится, я было попробовал на дотнете что-то писать ML и понял, что нет, это разве что для деплоя готовых обученных решений, но для них и либы под C++ есть.

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

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

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

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

Куры являются самой распространённой домашней птицей в мире: в 2003 году их популяция составила 24 млрд особей

А людей всего 7 миллиардов, в 3 раза меньше. Я ни на что не намекаю, так просто.

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

Я ни на что не намекаю

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

FishHook
()

Для ИИ сейчас ценится автоматическое неявное (без изменения синтаксиса) преобразование типов. Так, что, lisp пока отдыхает.

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

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

ugoday ★★★★★
()

lisp довольно продолжительное время удерживал первенство в этой сфере, особенно в области символического искусственного интеллекта и области экспертных систем. Но, видимо, после прошлой «AI winter» что-то изменилось и я не могу понять что именно. Были ли это причины, связанные с самим языком или «просто так получилось»?

AI имеют разный вид. В прошлом, это были symbolic AI, т.е. символьные ИИ которые оперировали символами и концепциями/утверждениями. Lisp отлично подходит для подобных ИИ, но со временем выяснилось что этого мало, системы упираются в свой потолок и чтобы двигаться дальше нужна работа с данными, много работы с большими данными. А технические возможности 20 века (железо) не позволяли на тот момент эффективно (параллельно) минимизировать ошибку. Вот это вот ожидание пока железо станет способным переваривать данные для ML и есть «AI winter». Вообще, цепное правило Лейбница известно с 17 века, но его практическое применение в виде метода обратного распространения ошибки стало возможно только в 21 веке.

Современные AI полностью полагаются на методы обучения на основе данных - Machine Learning. Это другие по структуре AI и вся выразительность Lisp тут просто нахер никому не нужна чтобы там не пел @lovesan. Нужна простота работы с данными, преобразование типов и биндинги к С/С++ библиотекам разработанными производителями видеокарт. Сейчас на первый план выходит скорость практической проверки гипотез какая из конфигураций сети оптимальнее, когда на одну задачу может создаваться 3-5-7 сетей с разной конфигурацией, обучаться на одном и том же наборе данных и затем оставляется наиболее удачная конфигурация. Lisp не нужен в Machine Learning еще и потому что в ИИ основанных на изучении данных важную роль играет структура самой сети, те самые гиперпараметры которые подбирают эмпирически и исходя «из предыдущего опыта».

Именно поэтому взяли Python т.к. он конечно имеет кучу минусов как и любой другой язык, но отлично удовлетворяет требованиям именно Machine Learning подхода. Поэтому на нем столько программ и библиотек под ML создано что он стал де факто стандартом в ML отрасли. Но если вдруг понадобиться разработать ИИ который проверяет леммы и пытается строить доказательства, то конечно сюда лучше подойдет Symbolic AI + Lisp, а не Machine Learning AI + Python.

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)

Ну и хотелось бы услышать ваше мнение о перспективах lisp в будущем, страричку пора на покой или у него еще появится возможность проявить себя?

Вынес ответ на этот вопрос отдельным постом. Давайте немного поднимемся над срачем в комментариях и окинем поляну целиком. Что мы имеем?

У нас был символьный ИИ на лиспе который худо бедно мог доказывать и перепроверять, эдакий прокаченный метод конечных автоматов/цепей Маркова. Сейчас у нас есть ИИ на машинном обучении который ищет и запоминает закономерности в больших объемах данных обучаясь минимизируя свою ошибку используя различные параметры-метрики (среднеквадратичное отклонение и тд).

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

Чтобы там не рассказывали журналистам про «мы боимся своего ИИ, человечество опасносте !!1» это все хайп и маркетинг. Мы в тупике. У нас есть аппаратные мощности, но ни символьный ИИ ни ИИ на базе данных очевидно не привели к появлению «сильного» ИИ. Да, у нас теплится надежда что вот мы еще засунем десяток другой экзабайт в нейронку и уж тогда ух заживем и она осознает себя, но всем кто реально в теме и своими руками создает сети понятно что сколько данных не суй, самопроверки выводов у сети не появится.

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

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

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

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

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

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

На диком западе давно уже это делается и очень многое достигнуто на языке c. Например, система hydra канадского здравоохранения. У нас почему-то ИИ - это только персептроны (нейросети), но это не так.

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

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

Уже сделали без всякого лиспа. Автоматический подбор/оптимизация гиперпарамтеров и структуры сети в пакете Keras. Называется Keras Tuner.

Символьные вычисления могут «выстрелить» еще в одном месте, это еще не сами сети, а подготовка обучающих данных - разведочный анализ данных (EDA). Все сети используют подготовленный набор данных с заполненными пропусками, удаленными дублями и т.д. Сейчас эти данные подготавливаются вручную из сырых данных. Берется в одну руку, например, seaborn, во вторую - pandas/numpy, вычищается мусор, находятся фичи и их взаимная корреляция, неважные фичи выкидываются чтобы сеть не отвлекалась на них и тд. Все это делает человек. Отдать этот подготовительный этап символьному ИИ вполне себе идея.

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

Я вижу проблему так: вот, приходишь к врачу^W оператору медицинской нейросети, а она и говорит, надо вам, голубчик, отрезать ногу. И фиг поймёшь с чего это она так решила.

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

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

Вы видели ее исходный код? Я - нет, но более чем уверен что там конечные автоматы + экспертная система иначе мы бы все читали о «революции в ИИ».

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

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

Там в постпроцессинге добавлено:

if (отрезать ногу) then {
   print("Выписать таблетки аспирина. Пить больше воды и покой. Само пройдет.");
}
Obezyan
()
Ответ на: комментарий от Obezyan

Ядро hydra - докторская работа бывшего русского , он мне ее высылал около 10 л назад. Он ее соединил с БД для целей канадского здравоохранеия и бригада в основном ихних студентов делала морду на яве. Ядро продолжают усиливать уже другие математики , которые могут и на с писать. Автор ядра - его бывший научный руководитель. «революции в ИИ» - у них уже давно.

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

Поделитесь ссылкой на научную работу, она же опубликована, верно?

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

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

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

у нас засекречена секретная система голубойслон, которая вообще околонуля…

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

Но ты-то ведь тут не список реализуешь, а зоопарк, дом или бинарное дерево.

В компьютере я реализую описание зоопарка или дома.

Откуда и зачем в их публичных интерфейсах кары с кададрами?

AST в лиспе = бинарное дерево. В публичном интерфейсе кары и кададры из стандарта. Используются чаще всего для реализации макросов (когда надо вытащить второй элемент второй группы параметров, например).

Зачем? Это не уровень прикладного кода.

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

У меня нет задачи заново реализовать стандартную библиотеку, я её просто использую в своём прикладном коде.

Кададры это тоже стандартная (причём в смысле ANSI) библиотека.

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

Также как и у кададров. Причём там лучше придумать сложно. cadadr всё-таки читается легче, чем left-right-left-right-branch.

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

Тогда лучше пропустить промежуточные стадии:

(defun health-assistance (location list-of-symptoms)
  (let*
      ((fees-multiplier (if (eq location 'usa) 1000 100))
       (base-fee (random (length list-of-symptoms)))
       (fees (* fees-multiplier base-fee)))
    (format t
	    "Пейте аспирин, меньше волнуйтесь и чаще выходите на свежий воздух. С вас $~a.~%"
	    fees)))

CL-USER> (health-assistance 'canada '(кашель насморк температура стрела-в-колене))
Пейте аспирин, меньше волнуйтесь и чаще выходите на свежий воздух. С вас $200.
NIL

CL-USER> (health-assistance 'usa '(кашель температура боль-в-боку кошмары желание-отрезать-себе-чего-нибудь))
Пейте аспирин, меньше волнуйтесь и чаще выходите на свежий воздух. С вас $4000.
NIL
ugoday ★★★★★
()
Ответ на: комментарий от monk

описание зоопарка или дома

Естесьно.

AST в лиспе = бинарное дерево

Бинарное? Правда?

Впрочем, какая разница. Мы тут не AST описываем, а зоопарк.

ты же настаиваешь, что вокруг car надо сделать синоним left-branch, потому что нечитаемо.

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

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

Это другие по структуре AI и вся выразительность Lisp тут просто нахер никому не нужна чтобы там не пел @lovesan. Нужна простота работы с данными, преобразование типов и биндинги к С/С++ библиотекам разработанными производителями видеокарт.

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

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

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

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

Сейчас акцент сместился, можно сразу пробовать кучу гипотез и выбирать наиболее оптимальную под задачу. Выразительность уступила место скорости создания прототипа и его проверки. Современные фреймворки типа Tensorflow позволяют создать сеть в 10-20 строк кода на Python, а тот же Pandas закрывает все манипуляции с данными перед загрузкой в сеть.

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

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

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

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

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

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

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

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

если возраст человека описан числом, то интерфейсом этого возраста будут всё операции с числом

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

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

Скорее у многих мертв межушной нервный узел

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

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

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

А зачем гугль начал пейсать хромиум, если уже были другие браузеры?

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

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

А зачем? Обработка всех видов животных или всех животных предоставленного вида на хэшмапе будет только медленнее. Добавление нового животного — тоже. Поиск животного или вида по какому-то ключу? Можно добавить дополнительный хэшмап для этого клиента, которым будет пользоваться только он.

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

Нет ничего легче, чем пропустить/перепутать случайно одну буковку в cdaddadr

Так надо тогда и от арифметических операторов отказаться. Нет ничего проще, чем пропустить/перепутать символ в «+=», например.

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

@mv нормальный был но выпилился отседова

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

Писать словами: некоторое ненулевое количество символов из множества цифр, затем точка, затем ещё некоторое количество цифр, потом ещё точка, наконец снова цифры и снова точка, а затем ещё цифры, вместо \d+.\d+.\d+.\d+.

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

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

Я говорю — к примеру, суть не в хэшмапах. Пока у тебя кададры вместо интерфейса — ты никуда от списков не денешься, хэшмапы или не хэшмапы.

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

Так надо тогда и от арифметических операторов отказаться.

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

Впрочем, похоже, что некоторые вещи сложно понять просто из чьих-то объяснений, они лучше доходят, так сказать, the hard way. На собственном горьком опыте %)

Скажем, что лучше программировать в терминах абстракций (интерфейсов), а не конкретных реализаций/представлений (структур данных); что лучше не позволять низкоуровневым деталям реализации торчать через высокоуровневый публичный интерфейс; что лучше не смешивать уровни абстракции (дома с cons-ячейками) до получения однородной неструктурированной кашицы.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 2)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)