Почему считается, что CL подходит только для мегасложных проектов?

Он практически ничего не умеет в области проверки типов (разве что за последние год-два резко научился).

Ну или написать тулзу, к-я анализирует питонячий код;-)

Что-то никто не пишет :/

да потому что не нужна такая тулза, как и статика для бидона

Смысл - в статической проверке.

может тогда просто заюзать Cython?

А 3-мерный массив как индексировать как плоский? Или плоский как 3-мерный? Или, к примеру, 5-мерный как 3-мерный и наоборот?

Нормальные массивы это например такие. А в си работать с многомерными массивами действительно неудобно (C FAQ: 6.16, 6.18, 6.19, 6.20; SO: 1, 2, 3, 4, 5).

и кстати расположение данных в памяти для такого случая ЕМНИП прописано в стандарте

Для T[] - да, про T[][] - http://stackoverflow.com/questions/2832970/does-c99-guarantee-that-arrays-are.... Не для динамических T** (нам ведь нужны матрицы в куче? Можно делать непрерывные матрицы в куче с помощью T* и arr[i * m + k], но это 1-dimentional array, oops).

Если верить ЛОР

ЛОР-у кажется вообще ни в чём верить нельзя.

ЛОР-у кажется вообще ни в чём верить нельзя.

Ну почему же... ЛОР крайне полезен, но доля разумного скептицизма никогда не вредит.

А 3-мерный массив как индексировать как плоский? Или плоский как 3-мерный? Или, к примеру, 5-мерный как 3-мерный и наоборот?

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

С-но я уже давно написал либу на С++ с привязкой к питону, которая все это реализует + много чего еще. Я тут ес-но не первый (gmm++ например есть), но у нас двольно специфические требования. В частности, данные упорядочиваются не как в обычном многомерном массиве а рекурсивно. Поэтому читать Ваши пассажи про отсутствие/неудобство работы с многомерными массивами в С++ довольно забавно... даже вспоминается встреча Воланда с Берлиозом;-)

PS по просьбам некоторых трудящихся, не верящих в Ъ многомерные массивы в С++:

template <typename T, int I, int J, int K> class array3D {
    T p[I][J][K];
public:
    T& operator ()( int i, int j, int k ){ return p[i][j][k]; }
};

Массивы, размер которых неизвестен на момент компиляции - чуть сложнее, поскольку там уже начинается всякая адресная арифметика.

Во-во. Почему-то на SO про CL нет таких глубокомысленных ответов на простые вопросы о том как создавать массивы, как их передавать в функции и как их из функций возвращать. Потому что это делается элементарно и тут нет никаких тонкостей. И на вопрос о том как индексировать массив одной размерности как массив другой может быть дан простой ответ и приведены две строчки кода. В си же есть несовместимость между T** и T[][], массивы вообще не доживают до рантайма, доживают только указатели, да и то, типы тоже стираются, остаются только адреса (в стандарте прописано, что T[] преобразуется в T*, а T[][] в указатель на T[]). В большинстве же виртуальных машин массивы продолжают жить и в рантайме - объекты часто тегированы и содержат разного рода информацию, например, размеры массива, ранг, тип элемента - об объекте всё можно узнать во время исполнения. Я не говорю что это единственно хорошо и правильно, просто тут есть некая разница, чтобы достичь такого в си нужно оборачивать VLA в структуру и писать нормальный API с конструкторами, деструктивными и геттерами с сеттерами. Вот в С++ это действительно удобнее делать.

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

Претензии у меня в основном к Си, а не к С++. У последнего есть, например, Boost.MultiArray.

Поэтому читать Ваши пассажи про отсутствие/неудобство работы с многомерными массивами в С++ довольно забавно...

А мне забавно, что вы приводите код с UB и засчитываете мне за это «слив» :) (gcc молчит, но clang ворнинг показывает).

Вот в С++ это действительно удобнее делать.

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

Во-во. Почему-то на SO про CL нет таких глубокомысленных ответов на простые вопросы о том как создавать массивы, как их передавать в функции и как их из функций возвращать.

А с какой скоростью будет работать код на SO и CL с такими массивами? Которые живут в памяти долго и тд? А какая локальность данных у таких массивов? Чудес не бывает, за все надо платить. На С/С++ я укладываю данные в памяти так, как мне хочется. Да, в каких то нетривиальных случаях мне может и понадобится написать лишнюю строчку кода, но зато я точно знаю как машина будет это обрабатывать, и я могу точно объяснить машине что от нее нужно.

А что, CL изкоробочными средствами может мне построить срез от массива, и сделать это без потери производительности? Сможет работать с рекурсивными структурами данных, причем не причесывать все дерево а сразу переходить к элементу вычисляя его адрес? Что в С, что в CL это придется писать рукам, причем это требует примерно одинакового числа букв (наск я видел примеры кода на CL), но на С/С++ оно хоть работать будет быстро;-)

Что в С, что в CL это придется писать рукам, причем это требует примерно одинакового числа букв (наск я видел примеры кода на CL), но на С/С++ оно хоть работать будет быстро;-)

Кто тебе ржавой сковородкой вбил в голову чушь, что в CL для всех случаев жизни кода будет меньше?

Кто тебе ржавой сковородкой вбил в голову чушь, что в CL для всех случаев жизни кода будет меньше?

А где я такое говорил? Откуда такие ассоциации вааще, тебя что, папа в детстве этой самой самой сковородкой колотил и тебе теперь она везде мерещится?;-)

А где я такое говорил?

Тогда зачем вообще апеллировать к размеру кода и скорости выполнения? Не надоело сравнивать хер с пальцем?

Тогда зачем вообще апеллировать к размеру кода и скорости выполнения? Не надоело сравнивать хер с пальцем?

Тогда приведите другие объективные критерии, позволяющие сказать что это вот хороший ЯП, а это плохой.

А есть «хорошие и плохие»? О_о

А мы забыли «язык под задачу»? Писать «ядерные драйвера» на CL? Или писать на си[++] всяких монстров а-ля расширяемые IDE/сервера приложений/прочую муть?

А в «пограничной зоне» выбор всё равно будет зависеть от субъективных факторов - так зачем «устраивать тёрки»?

И вообще, при выборе языка мне больше нравится подход «выбор по ограничениям», нежели «выбор по фичам». У CL ограничений «выше крыши»: большое ядро, не так много «батареек» как у других, скорость даже у компиляторов явно не «сишная» или надо писать низкоуровневый код (вплоть до модификации компилятора если речь об SBCL) для её оптимизации (но всё равно будет не «сишная» :)), у интерпретаторов со скоростью ещё хуже, и так далее... Если что-либо из этих ограничений неприемлемо - зачем вообще заводить разговор о фичах?

В современном «мульти-технологичном/протокольном/интерфейсном» мире часто отсутствие поддержки в виде либы чего-либо требуемого может практически свести на нет преимущества CL, если только не разрабатывать всё самому. А для «вещей в себе» без экстраординарных требований по скорости выполнения и памяти CL идеален ;)

Всё, завязываю. Мир-дружба-жвачка

А есть «хорошие и плохие»? О_о

Туше;-) Ок, я говорил об объективных критериях сравнения ЯП. Понятно, что вообще то все пользуются субъективными критериями (нарвится-не нравится), и лавсанчег может и драйвер на CL напишет, а mv даже хороший драйвер напишет;-)

Мир-дружба-жвачка

Не жую, остальное принимается;-)

лавсанчег может и драйвер на CL напишет

Не напишет.

mv даже хороший драйвер напишет;-)

Но к нему будет прилагаться userspace driver framework на Си :)

Я думал mv напишет DSL, на котором напишет драйвер, который будет транслироваться лиспом в С-код;-)))

dsl красивше квазимото пишет :)

Там было не жлобье постсоветское, а люди, которые понимали важность публикаций. Где миллиарды баксов, заработанные этими фирмами?

http://web.mit.edu/6.933/www/Symbolics.pdf на третьей и четвёртой странице есть няшные графики

http://danweinreb.org/blog/why-did-symbolics-fail альтернативное мнение от cотрудника http://lemonodor.com/archives/2007/11/why_did_symbolics_fail.html есть ссылка на научную работу про AI winter, социолого-археологическую (наподобие «failure of heterogenous engineering»). ещё в эту же тему — дилемма инноватора, http://web.mit.edu/6.933/www/Fall2000/teradyne/clay.html http://www.2ndbn5thmar.com/change/The Innovators.pdf

Под лисп вон даже железяки делать пытались... толку то?

в «Why did Symbolics failed» (PDF) есть ссылка на это.. толк был, буквально лет 5, когда свой особенный микрокод, тегированная архитектура и аппаратный GC имели смысл.. но вся эта радость стоила $30..100k. а лет через 5 уже подтянулись и sun workstation, которые стоили всего каких-то $15k, были достаточно хорошими и более универсальными. а ещё через лет 2-3 толк окончательно пропал. ну да, другой микрокод, который почему-то лисп.. ничего особенного по тем временам

ЭЭХ, другое дело кабы новую Сетунь, с троичной системой, с материальной импликацией, да на новой аппаратной базе, на мемристорах каких-нибудь.. и на лиспе =)))

Там было не жлобье постсоветское, а люди, которые понимали важность публикаций. Где миллиарды баксов, заработанные этими фирмами?

http://web.mit.edu/6.933/www/Symbolics.pdf на третьей и четвёртой странице есть няшные графики

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

Остальные материалы я читал раньше - ни намека на чудеса там нето.

Написал программист прогу, а потом на горшок и в люльку! [Logo]

Всяко лучше, чем на дотнете офшорным программером в бодишопе http://www.newtechusa.com/ppi/talent.asp

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

ну не мильярды, вполне себе скромные миллионы.. у одной фирмы

ни намека на чудеса там нето.

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

И где там «мегаохуительные языки», которыми «не поделились»?

а из-за чего вообще Столлман начал свой велосипед изобретать? из-за того, что кафедра, где он работал разбежалась: половина в LMI, половина в Symbolics, а то что бог делиться завещал, уже и забывать начали

где языки? а где сейчас, к примеру Flavors?

И где там «мегаохуительные языки», которыми «не поделились»?

а из-за чего вообще Столлман начал свой велосипед изобретать?

Какой из многочисленных?

Еще раз...

lovesan> Да потому что нахуя блять этой конторе/программисту делиться этим мегаохуительным языком программирования, или, тем более, реализацией, если они в условиях жесткого капитализма могут использовать его выгоды?

так вот, Symbolics _продавала_ свои продукты (т.е. всё, что они сделали, известно), и об их «мегаохуительности» («миллионы LOC, на него переносятся максимум в десятки тысяч») речь просто не идет.

где языки?

Куча диалектов Лиспа, существовавших к концу 70-х, объединилась в CL. Или о каких языках речь?

а где сейчас, к примеру Flavors?

Это экзамен на знание истории CL? Flavors (и LOOPS) сейчас в CLOS.

Станет ли такой мегаязык популярным в течении месяцев, ну или максимум года? Заменит ли он все остальные языки в этот срок? Да или нет?

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

Да или нет? Вопрос, почему?

нет, потому что из того факта, что вдруг ВНЕЗАПНО такой язык появился ещё не следует, что нужно все остальные забросить (т.е., на «рынке языков программирования» отбираем кусок пирога от остальных), и на этом языке переписать (вступать и конпелировать).

во-первых, технологический цикл, S-образная кривая (закон Гарварда, кажется) — там где плато продуктивности уже потом (в конце, когда наступает катарсис), и крутая обучающая курва (вначале, когда надо ещё помучаться). во-вторых, disruptive и supportive инновации из «дилеммы инноватора» — когда нужна не одна технология сама по себе, а нужно выстроить технологический стек, платформу — не только язык, реализацию, стд. библиотеку, CPAN для библиотек, и известные решения известных проблем «на стыке» своей и чужой технологии. что требует зрелости реализации, а не технологии на уровне концепции.

cюда же: есть какой-то психологический закон, когда просто для того чтобы перестать по привычке мучаться, и захотеть поменяться/научиться/найти новое решение своей проблемы, пациент должен преодолеть похожую S-образную кривую в своей голове (а то иначе лень), и кроме того — соотношение ПРОФИТ(катарсис) на затраты должно быть ну прям на порядок больше, иначе быдлу лень напрягаться именно таким способом, когда есть более привычне.

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

Будет ли он популярным тогда, через 20 лет? Да или нет? Почему?

ну да, тут приходим к рассуждениям о генотипе и фенотипе языка от автора Qi/QiII/Shen

так вот, Symbolics _продавала_ свои продукты (т.е. всё, что они сделали, известно

да, с полной документацией, исходниками и копирайтами . Столлмана же троллили за то, что ему этого не хватало (есть исходники, но не под богоугодной лицензией), и он начал свой велосипед (то есть, движение GNU)

и об их «мегаохуительности» («миллионы LOC, на него переносятся максимум в десятки тысяч») речь просто не идет.

для того времени — вполне себе охуительно. И соотношение kLOC примерно похожее.

где языки?

Куча диалектов Лиспа, существовавших к концу 70-х, объединилась в CL. Или о каких языках речь?

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

а из-за чего вообще Столлман начал свой велосипед изобретать?

Какой из многочисленных?

да манифезд свой, антиграмоцнасци

инкрементальный сборщик мусора, вполне себе охуителен

так вот, Symbolics _продавала_ свои продукты (т.е. всё, что они сделали, известно

да, с полной документацией, исходниками и копирайтами

Т.е. посыл «не поделились» опровергнут.

об их «мегаохуительности» («миллионы LOC, на него переносятся максимум в десятки тысяч») речь просто не идет.

для того времени — вполне себе охуительно. И соотношение kLOC примерно похожее.

«Примерно похожее» - это 20-кратный выигрыш (миллионы против десятков тысяч) у любой тогдашней workstation-технологии на широком круге задач (не только knowledge engineering)? Пруфы в студию.

значит, то что в стандарт не вошло — и есть сабж, те самые языки, которыми не поделились. логично?

Нет. То, что от стандартизации _утаили_ - вот то, чем не поделились. Но, исходя из того, что я читал о стандартизации CL, предлагали туда больше, чем стандарт мог вместить.

Убил бы ради статически типизированного Питона %)

держи: http://gcc.gnu.org/wiki/PythonFrontEnd http://code.redbrain.co.uk/cgit.cgi/gccpy/

Т.е. посыл «не поделились» опровергнут.

именно они — они делились. Поэтому я Столлмена не очень понимаю, у него ж была под боком лисп-машина за каких-то $100k :)) Но были же и более другие лисперы.

Пруфы в студию.

свой микрокод, тегированная архитектура, сборщик мусора на лиспе (он же микрокод и он же ассемблер), ну и исходники ZetaC покомпактнее будут чем gcc :)

у любой тогдашней workstation-технологии на широком круге задач

а кто говорит про «широкий круг задач»?

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

вот ISLISP, cтандарт ISO Lisp стандартизировался гораздо более вменяемо. или схема — видно проектирование языка, а не kitchen sync и design by commite, как в С++

SO это http://stackoverflow.com/ же.

свой микрокод, тегированная архитектура, сборщик мусора на лиспе (он же микрокод и он же ассемблер)

Ну тегированная архитектура и ЯВУ в роли ассемблера - это B5500, микрокод тоже не LispM изобрели.

у и исходники ZetaC покомпактнее будут чем gcc :)

Какой версии? %)

у любой тогдашней workstation-технологии на широком круге задач

а кто говорит про «широкий круг задач»?

Ловсанчег говорит. Пойми, я не спорю, что Лисп-машины были передним краем IT и всё такое - но они были _не настолько_ хороши, как их считают некоторые фанаты.

Убил бы ради статически типизированного Питона %)

держи: http://gcc.gnu.org/wiki/PythonFrontEnd http://code.redbrain.co.uk/cgit.cgi/gccpy/

Это всё не то...

http://gcc.gnu.org/wiki/PythonFrontEnd

«we had to wrap every type within python code into a gpy_object_t similar to how cpython works»

IIUC, они не делают статический контроль.

http://code.redbrain.co.uk/cgit.cgi/gccpy/

Это вроде еще один репозиторий PythonFrontend

Самое близкое к тому, что я хочу - это http://code.google.com/p/pyntch, но он умер :/

Убил бы ради статически типизированного Питона

Проблема решается очень просто. Нужно найти/написать статический анализатор, по аналогии с ерлангом.

Кстати, а кто-нибудь пытался использовать theorem proof'еры в качестве языка системной интеграции?

Я бы вот убил бы за Схему (нативную, а не в виде реализации на JS) в браузерах.

Убил бы ради статически типизированного Питона %)

Ну так напиши сам. Какие трудности?

Убил бы ради статически типизированного Питона %)

Ну так напиши сам

Проще кого-нибудь убить %)

Какие трудности?

Ума не хватает.

Проще кого-нибудь убить %)

Может и проще, но это к результату не приведет. Пробовал уже, но так до сих пор типизированного Питона и не увидел.

Ума не хватает.

А на кой там ум? Гвидо тот же явно умом не пользовался.

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

Fail, потом интел выпустит очередной Нехалем, и вылизанный алгоритма начнёт работать с диким необъяснимым просёром. Только вылижешь и под Нехалем - бац!, нате, Сэнди Бридж со своими тонкостями.

А что, CL изкоробочными средствами может мне построить срез от массива, и сделать это без потери производительности?

Если вы про displaced array говорите, то конечно.

Сможет работать с рекурсивными структурами данных,

Может

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

Как ты себе это представляешь? Вычисли адрес элемента ацикличного графа, не траверся сам граф.

Fail, потом интел выпустит очередной Нехалем, и вылизанный алгоритма начнёт работать с диким необъяснимым просёром. Только вылижешь и под Нехалем - бац!, нате, Сэнди Бридж со своими тонкостями.

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

Как ты себе это представляешь? Вычисли адрес элемента ацикличного графа, не траверся сам граф.

Если расстояние от корня до листьев одинаковое, и число ветвлений в каждому узле одинаковое, то лехко - см. числа Мортона. Скажем вот для такого массива (числами показано смещение от начала вектора):

0  1   4 5 ...
2  3   6 7 ...
8  9   .     ...
10 11  .   ...
...

но вся эта радость стоила $30..100k.

Дёшево же! В s/390 в 1990:

Basic purchase prices for the air-cooled processors of ES/9000 ranged from approximately $70,500 to $3.12 million. Basic purchase prices for the water-cooled models ranged from $2.45 million to $22.8 million.

которая по дефолту весьма эффективно работает на любой шелесяке

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

и лехко оптимизируется под любую новую шелесяку

Если в алгоритме нет элементов ИИ и возможности самомодификации, то «легко оптимизируется под новую шелесяку» каждый раз превращается в тикет от клиента, когда он миграцию на новый сервер производит.

Мы с Вами разными задачами занимаемся. Поскольку наши задачи считаются часы (в лучшем случае) то 700нс рояля не играет, а при достижении 50% от теор. предела производительности работа по оптимизации прекращается и посылается гонец за шампанским ;-)

Неоптимизированный код считает с эффективностью 10-ки процентов, и это на порядок лучше чем у конкурентов (пока они не сваливаются в своп - тогда разница на неск порядков).

А улучшение в 2-3 раза... после улучшения на порядок не представляет большого интересу, поверьте;-)

Если расстояние от корня до листьев одинаковое, и число ветвлений в каждому узле одинаковоето лехко - см. числа Мортона. Скажем вот для такого массива

Откуда выплыло требование к compile time статичности структуры? И представлению их в виде массива.

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

нет, катающихся в свободное время на велике