В целом, мне нравится lisp - импонирует сама концепция lisp-a, я без особых проблем читаю s-выражения, нравиться его поддержка в emacs. И я использую emacs lisp как язык для всякой мелочевки.
С другой стороны простота концепции, когда первый аргумент s-выражения - функция, а остальные єлементы - параметры, имеет свой неприятный побочный эффект: огромное, неструктурированное пространство имен. Примерно за это я не люблю python - надо помнить кучу тонких особенностей и фич языка. А в lisp надо помнить кучу нужных функций. В книжке Грема их приблизительно 1000. В противопложность java - минимум ключевых слов, а вся функциональность вынесена в методы, которые выясняются по автодополнению и доктипу.
Второй нюанс, ХЗ, может зависит от конкретной реализации. Все функции из заргуженных пакетов валятся в одно пространство имен. Т.е. если Васян по глупости или злому умыслу перепишет стандартный car можно поиметь проблем, особенно если такой car подгружаю в составе какой-то библиотеки. Хотелось бы импорта a-la python import my-package as mp с последующим доступом типа (mp.foo).
Собственно, вопрос. Как борются с этими проблемами местные лисперы. Особенно с первой. Лично я запомнил около полусотни функций, примерно из списка снипеттов, к части прибавляю p и автоматом получаю знание новых. Может есть компактный список must know функций как перечень самых популярных коменд для emacs?
Вторая проблема больше для собственного кругозора, я сомневаюсь, что буду в большой команде использовать lisp, та и не годиться он для этого.

С пакетами вопрос решился. А с насышенным и неструктурированным пространством имен или с кратким справочником на манер такого - нет.

Уважаемые программисты!

Предлагаю порассуждать о продуктивности разработки на C++ по сравнению с так называемыми скриптовыми языками. Вот, принято считать, что языки на вроде Python позволяют работать программисту более продуктивно по сравнению с C++. И что, дескать, на C++ надо писать только узкие места и всё такое.

Мне же хочется четкого понимания. Может быть это миф? А может быть это просто инерция, потому что так вот принято считать и все тут. Вот сегодня в C++ уже не надо думать об освобождении памяти, так как есть умные указатели. Сегодня есть уже более-менее нормальные IDE для C++. Так? Так.

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python? Какие будут рассуждения? Может быть есть какие-то реальные обоснования на этот счёт, кроме как «в конторе Y так делают, значит смысл есть, они умные, им виднее». А может быть есть какие-то рецепты по продуктивности работы на C++?