Закапывателям лиспа

Да какой смысл читерить?

Ex, Ey, Ez = mk_vars()  #компоненты электрического поля

Кстати, как ты оцениваешь

2 2 +

?

Они должны знать, как их зовут. Так что тогда уж

Ex, Ey, Ez = mk_vars( 'Ex Ey Ez',  'компоненты электрического поля' )

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

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

И кстати как Вы планируете устроить mk_vars? Оно ж не знает скока элементов выдавать...

причём под Линукс

Забавное примечание. Я уже давно забыл, что можно писать под что-то другое :)

на C++ видел кучу проектов
А на лисп не видел ни проектов, ни вакансий.

Ну и какой из этого можно сделать вывод? Я много писал на C++/Python/Javascript/XSLT (и по не много на некоторых других) и проблема подобрать вакансию меня как бы давно не интересует, но мне больше нравится писать на C. Естественно, я стремлюсь увеличить удовольствие (т.е. писать на CL) и уменьшить боль (т.е. не писать не C++).

Так и я умею... я то думал там есть какой то трюк.

Про «под линукс» я к тому, что пора винду закапывать :-)

А вывод простой, не нужен.

я то думал там есть какой то трюк.

Зачем? O_o Трюк - это возвращать значения через _getframe и locals.

А вывод простой, не нужен.

Вам не нужен, а мне нужен, вот и весь результат многостраничного обсуждения :).

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

Это вынужденная мера. Иначе придется дублировать имена переменных при задании, а это черевато гораздо более серьезными последствиями. Конечно, можно было задавать переменные, потом запускать какую нить ф-ю которая аналищирует пр-во имен и на основе id восстанавливает имена... но это уже содомия. На самом деле можно конечно задавать переменные и обычным образом, есть класс var - но это неудобно.

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

CL-USER> {1 + 2}
3
CL-USER> {2 - 3}
-1
CL-USER> {2 expt 3}
8
CL-USER> (sqrt {{2 expt 6} + 5})
8.306623

Ленина тоже никак не закопают.

в перспективе вброс на все 4 дня праздников

в перспективе вброс на все 4 дня праздников

Не-е, оно уже сейчас затихает...почти до нулевой активности. :)

C: с боями выбил себе нишу низкоуровневого программирования и окуклился.

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

Lisp: ничего не заметил.

PERL выкинут на свалку истории

Отсыпьте мне такой травы...

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

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

Он что-то предлагает взамен?

Lisp, Lisp. Objective-C вот что сейчас рулит http://lenta.ru/news/2012/05/05/messenger/

Краткая и неполная хроника лопатных походов на Lisp:

КГ/АМ. Другого в голову ничего не пришло. :) Ну хрень же! Больше всего не люблю таких горе-мифологов и горе-воспевателей Лиспа.

Стоит. Хотя бы потому что Одерский (на практике!!) показал, что нет никакой «пропасти» между ООП и ФП, а значит межу ООП и формальными методами.

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

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

Ну, ты же в универе не Скалу изучал и, как мне думается, даже не Смаллтолк, CLOS, Эйфель. Скорее всего, ты изучал Единственно Верную и Правильную Модель. А вот там действительно изучать и обсуждать нечего.

о да!

C = A * B;

;;Умножение матриц(списков)
(defun multiply (A B)
(let ((res nil) (tores nil))
(dolist (a A)
(dolist (b (trans B))
(push (reduce #'+ (mapcar #'* a b)) tores))
(push (nreverse tores) res)
(setf tores nil))
(reverse res)))

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

Хотя автор темы тоже хорош. Не ожидал от него такого. Все про университеты, а тут, бац, такой вброс материала для переработки.

dave

Как я уже написал, у критиканствующих антилисперов довольно унылые сообщения.

не говори - без тентаклей уныло...

И да, если у кого-то C++ вызывает попоболь, то можно улицы подметать, или там каким-нибудь г-ном торговать... Эти занятия более востребованы, чем кодинг на LISP'е и прочей чашуе.

Слишком много любви к крестам. Есть же еще инструменты.

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

Воинствующий туповатый плюсоеб такой унылый

можно улицы подметать, или там каким-нибудь г-ном торговать...
Эти занятия более востребованы, чем кодинг на LISP'е

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

Слишком много любви к крестам. Есть же еще инструменты.

это хороший и годный инструмент. Если уметь им пользоваться.

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

проблема одна - за подметание улиц платят в разы меньше, чем за кодинг на плюсах. За кодинг на лиспе ВООБЩЕ не платят.

//thread

такой унылый

ну развесели...

За кодинг на лиспе ВООБЩЕ не платят.

Ты не поверишь...

Итог. C, С++, Java, Ruby, Python и даже Perl с окамлем более распространены чем LISP.

ну значит должна быть дока в формате odg где все разрисовано со стрелочками и как «соединять» кусочки api. с примерами, опять же.

если есть «объект» типа «конечный автомат» то граф состояний для него рисуем. если него несколько перекрывающихся состояний, но рулят цветные стрелки и кружки. типа ifstream есть в режиме А, Б, В, и плюс флажок Y={true/false} тогда у нас есть три кружка А Б В и стрелки между ними цветные синим для Y=true, красным для Y=false, фиолетовым или штриховкой попеременной - где пофиг.

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

Ты не поверишь...

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

ну значит должна быть

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

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

только это не ООП. а разбиение проекта на этапы и нормальные проектирование и разработка

странно. я готов платить за такой подход. потому что в 90% задач написание кода - это полная херня. больше времени тратится на проверку или оптимизацию, если что-то вроде sse пошло в ход.

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

вы, кстати, не сталкивались с задачей вида «нарисовать что-то силами core-image или cocoa на пихбуфе и засунуть его в кодек»? или «записать это все в avi»? ExportMovieFromProcedures тут вам не поможет :), несмотря на всю документацию: там забыли сказать, что она не работает. а понять сходу что вообще такое channellayout в coreaudio?

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

найди те комьюните где

ну значит должна быть

всё что для вас значимо и пилите свою вселенную.

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

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

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

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

Вот, уже ушибнутые Бучем подтягиваются.

Пока тут не ляпнули: «Готовьтесь потратить времени на проектирование, больше чем на реализацию» (хотя это и не Буч), это сделаю я.

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

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

У-я движения в классической механике, законы сохранения, у-я Максвелла, ГД, у-я физкинетики Вы тоже всегда в операторном виде пишете? И, главное, численные схемы (то, что непосредственно кодится) - тоже в операторном виде?

Но почему Вы выбрали в качестве эталона математику?

Математику все проходят в школе, и если есть эталон «общепонятности» - это именно школьная математическая нотация.

ну да, поделия говнокодеров вроде вас я видел уже порядочно.

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

И, главное, численные схемы (то, что непосредственно кодится) - тоже в операторном виде?

Одну работу сделал только фана ради на Lisp (простенькие вычисления). И сама идея (function bla bla) очень понравилась - действительно простая однотипная и (хотя вы оспариваете) самая что ни наесть естественная конструкция. Но могу согласиться, что Lisp мертв. И прежде всего из-за того что нет уймы библиотек, а те что есть оставляют желать лучшего.

простая и естественная конструкция

Конкатенативные программисты берут данные и преобразуют их в другие данные, когда же лисперы думают, что же натворить, и только затем берут данные.
На мой взгляд, 2 2 + намного естественнее, чем (+ 2 2). И уж тем более проще.
http://concatenative.org/wiki/view/Pipeline style