LINUX.ORG.RU

Джентельменский набор ЯП


1

0

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

А вообще какие языки и в какой последовательности было бы неплохо поучить?


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

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

Разве в жабе и дотнете основные библиотеки платформы не релизятся точно вместе с новой версией платформы?

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


Tcl, Erlang

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

> Ну и брось его, програмь на чем-нибудь, что в состоянии осилить. Не понял, откуда у тебя впечатление, что я не в состоянии.

Я осилил и давно пользуюсь. Просто у меня наконец открылись глаза на то, что потенциальные возможости и доступные уже сейчас возможности - это разные вещи. Да, можно начать от Адама и попробовать переписать всю вселенную с нуля. Но просто не успеешь. Будешь всё время отставать от индустрии и в итоге окажешься в нищете и умрёшь под забором. Пока я делал всякие вещи на лиспе для себя, можно было этого не заметить. Теперь я вышел на более широкие просторы и это стало очевидно. Соответственно, нужно поставить знак "кирпич", чтобы туда никто больше не ходил.

Можно осилить разные навыки, например, как трусы через голову одевать. Но нужно ли это? Я, освоив лисп в достаточной степени, могу сказать - нет. Не нужно. Отдельные идеи лиспа хороши, и даже их сочетания хороши. Но недостатки фатальны. Даже если бы сам язык был плохим, но было бы сильное сообщество, можно было бы мириться с этим. Но слабо также и сообщество. Не найдёшь работу - тяжело получить прибыль с вложенных усилий. Не найдешь специалистов - тяжело поднять свой бизнес. Итоговый вывод: common lisp не стоит труда.

Должен появиться какой-то новый язык на тех же идеях, менее грязный и бардачный, чем Common Lisp. Возможно, это уже появившаяся clojure. Возможно, Nemerle. Возможно, C# дорастёт до этого уровня. Не знаю. А сами идеи лучше изучать на более простых и явных примерах. Мысль о том, что эти идеи могут сочетаться в одном языке, может дойти до разумного человека и без изучения Common Lisp.

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

>> Ну и брось его, програмь на чем-нибудь, что в состоянии осилить.
> Не понял, откуда у тебя впечатление, что я не в состоянии.


Следи, кому отвечаешь.

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

> Разве в жабе и дотнете основные библиотеки платформы не релизятся точно вместе с новой версией платформы?

Основные библиотеки и в Lisp'е вместе с платформой. Претензии-то не к ним, а ко всяким CL-SQL (не нравится, бери Postmodern или CL-RDBMS), alexandria и прочим 3rd party libraries. В таком контексте я сейчас и для Java и для .Net накопаю полсотни условно работающего хлама (неоторый хлам даже за деньги(!) предлагают). Это что-то докажет?

А вопрос был про "все-все библиотеки". К слову, один такой язык я знаю: C + Debian repository :-) хотя в этом контексте Lisp + Debian работает не хуже.

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

> А вопрос был про "все-все библиотеки". К слову, один такой язык я знаю: C + Debian repository :-)

Сам же понимаешь, что это утопия.

> К слову, один такой язык я знаю: C + Debian repository :-) хотя в этом контексте Lisp + Debian работает не хуже.


Никогда не вставал на грабли с dev-пакетами? Ну ничего, ещё не вечер.

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

> Никогда не вставал на грабли с dev-пакетами? Ну ничего, ещё не вечер.

А ты встречал грабли с dev-пакетами в Debian-stable? Можно пример? Я всегда думал, что если они следят за стабильностью, то это глобально.

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

>> Никогда не вставал на грабли с dev-пакетами? Ну ничего, ещё не вечер.
> А ты встречал грабли с dev-пакетами в Debian-stable? Можно пример? Я всегда думал, что если они следят за стабильностью, то это глобально.


Безопасность(за которой действительно следят)!=стабильность. Кроме того, интересный тебе пакет может просто не оказаться в дистрибутиве.

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

> Основные библиотеки и в Lisp'е вместе с платформой

Cлушай, не смеши меня. Что там есть:
#+sbcl sb-ext:quit #+(or ccl lispworks) quit

Как минимум, в стандарте нет переносимой функции "выйти из лиспа". Также там нет:

- возможности узнать список аргументов функции (есть, но стандарт позволяет возвращать nil, что реализации радостно и делают)

- возможность узнать список полей структуры, хотя язык динамический и вроде бы рефлексивный. Только не надо меня лечить, что вместо структур надо пользоваться классами. Классы работают в 6-20 раз медленнее структур в нескольких реализациях, где я это проверял. Определение класса обычно втрое более объёмное, чем определение структуры. При этом, из-за своей гибкости, код с классами менее однозначен и, тем самым, более сложен для чтения. Кроме того, MOP тоже не стандартизован.

И ещё один перл:
в ccl #p"c:/systems/foo.asd.lnk" ->"c:/systems/foo'.asd.lnk"
при внимательном чтении стандарта выясняется, что physical pathnames - это implementation dependent вещь. Но нигде в стандарте не написано, что physical pathname - это имя файла, которое понимает операционная система. В ccl есть специальная (специфичная для реализации) функция для того, чтобы сделать понятное операционной системе имя файла из physical-pathname. Это нужно, например, для запуска внешней программы.

Т.е., в common lisp нету даже переносимого способа обращения к файлам!

Далее. Если попытаться сделать совершенно элементарную вещь - вызвать команду операционной системы и прочитать то, что она выводит, то и тут будут проблемы. Некоторые реализации не позволяют перенаправить выходной поток, некоторые - сливают вместе stdin и stderr. Я видел попытки сделать слой переносимости в asdf и в clsql, но нигде эта работа не доделана до конца. Под win32 всегда приходилось что-то патчить. Ну и, конечно, нет развязки по версиям реализаций.

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

В общем, это - полная помойка, а не среда разработки!

> Postmodern или CL-RDBMS

Я боюсь тратить своё время. Почему-то мне кажется, что они будут ещё кривее, чем CLSQL. Который, вроде бы, всё же удалось приучить к работе.

К слову, про "все" библиотеки лично я речи никогда не вёл. Это был демагогический приём моих оппонентов :)

> накопаю полсотни условно работающего хлама

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

Но если говорить не про библиотеки, а про "стандартную библиотеку", то здесь есть ужасные пробелы. Например, нет полного набора коротких имён функций для работы с a-списками. Например, сравним получение элемента a-списка в лиспе:
(cdr (assoc key list)) - чтение
(setf (cdr (assoc key list)) new-value) - чтение
и в том же Object Pascal
list[key] - чтение
list[key]:=new_value;

да, я вру в том, что на самом деле, есть ещё &key и т.п., но почему всё же основная форма записи так длинна? Лисповый текст примерно вдвое длиннее паскалевого. Вдвое длиннее - это значит, что глазу нужно совершить вдвое больше работы для просмотра этой строки. А у меня есть такое предположение, что распознование изображений букв - это одна из наиболее трудоёмких (хотя и не осознаваемых) частей работы по чтению кода, если сам код достаточно прост. Во всяком случае, скомпилировать страницу кода на самом забористом С++ и распознать страницу кода со сканера - это задачи, отличающиеся по вычислительным ресурсам, наверное, раз в 500. Конечно, у мозга другая архитектура и задача распознавания, видимо, решается быстро за счёт параллельности. Но даже если этот коэффициент у человека равен просто единице, то всё равно потеря велика. Также нужно учесть и то, что и в мозгу есть разные кеши. Например, при чтении взглядом можно охватить только довольно небольшой кусок текста, что вызовет "атомарный акт понимания" и этот объём - это просто определённое количество букв. Если паскалевский/явовский/питоновский текст вдвое компактнее лиспового, то лисповый код может оказаться в 10 раз труднее для понимания из-за выпадения информации из кеша. Я на самом деле, думаю, что основная проблема лиспа - именно в этом. Просто, поскольку это тяжело выявить вне рамок специального исследования, мало кто из лисперов способен это заметить.

Если я прав, то какой вывод? Лисп плохо сказывается на производительности труда.

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

Также нет таких функций, как "заменить кусок строки на строку большей длины", "взять хвост строки". Да, всё это пишется. Но при этом каждый пишет такую функцию для себя. И при чтении нового кода нужно каждый раз потратить время на изучение новых соглашений об именах и нового синтаксического сахара. Например, есть такие, удобные, но не общепринятые вещи: length=, awhen, aif. Они нужны исключительно из-за гротескной непрактичности основного синтаксиса CL. Когда работаешь над разными проектами (особенно чужими), тебе нужно постоянно тратить ресурс мозга на то, чтобы помнить, какими конструкциями можно пользоваться, а какими нельзя. Когда ты напишешь свою функцию (например, я написал sequence-last), скорее всего, со временем возникнет конфликт имён с чьей-нибудь ещё одноимённой функцией (например, у меня возник конфликт с clsql:sequence-last). Заранее это не предугадать.

В общем, лисп - это гениальная, но несколько недоделанная среда разработки. Моя задача - зарабатывать деньги, а не бороться с последствиями того, что кто-то поленился доделать 20 лет назад (хотя это было легко доделать тогда). Теперь болезнь запущена и я бы прописал этому языку эвтаназию. Из гуманизма.

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

> (cdr (assoc key list)) - чтение
(setf (cdr (assoc key list)) new-value)
и в том же Object Pascal
list[key] - чтение
list[key]:=new_value;

А в С++
list.find(key)->second - чтение
list.find(key)->second = new_value

что не менее громоздко, чем Lisp. Наличие в Pascal синтакического сахара из коробки -- не аргумент

> Например, есть такие, удобные, но не общепринятые вещи...

реально они общеприняты. Также как CFFI, ASDF и прочие соглашения. Иначе можно считать, что ODBC в C/C++ тоже удобная, не общепринятая вещь :-)

> В общем, лисп - это гениальная, но несколько недоделанная среда разработки.


Если лисп = Common Lisp как стандарт, то видимо да. Нет MOP, нет потоков, нет FFI. Если Lisp как SBCL + Linux + например, библиотеки с http://common-lisp.net/project/cl-dwim/, то язык + платформа получаются достаточно мощные и удобные для использования.

Набор библиотек, конечно раздробляет сообщество, но ведь C++ как-то живёт с Qt, std, MSVC и ещё полудюжиной несовместимых реализаций, в которых даже строки по разному представлены... :-)

Ergo, Lisp лучше C++ как язык и как платформа, по сравнению с Java, .Net проигрывает как переносимая платформа, но языковых возможностей всё равно больше.

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

> А в С++
> list.find(key)->second - чтение

> list.find(key)->second = new_value


Я тебя, наверно, удивлю, но в c++ можно писать и list[key] для обоих случаев.
Первое время в языкам с не c-like синтаксисом раздражает отсутствие подобного сахарка. А потом понимаешь, что запись в виде [ dict get .. ], [ array get ... ], [ something get ... ] куда более единообразна.

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

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

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

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

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

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

> лисп <...> Теперь болезнь запущена и я бы прописал этому языку эвтаназию. Из гуманизма.

согласен, хотя может какие-то идеи оттуда взять можно

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