Сперва было хотел задать...

... вполне очевидный вопрос, однако, дочитав до признания существования иммутабельных объектов в С, остановился. Наверное Вы хотели все-таки сказать не в С, а в С++?

В случае, если да, то я могу заметить что Вы правы. Но тогда программирование на С++ vs. программирование на Lisp в части эффективности рабочего кода по используемым ресурсам даже сравнивать грех.

Кстати, да. С необходимостью GC и кажущихся вкусных пирогов и плюшек от него, готов поспорить. Где-то в форуме была проблема (я под ником mr_noone отвечал в той теме, воспользуйтесь поиском, если интересно). Там у человека были сомнения в том, работает ли GC в похапе или нет. Весьма вероятно, что в его случае нет. Точнее, не совсем «не работает», скорее не всегда успевает срабатывать должным образом наверное.

Зачем нужен механизм, который вроде бы есть, но при ряде условий он не работает? Не честнее ли здесь подход, принятый в С и С++, при котором менеджер памяти прибирается в системе только после явного (и программистом) освобождения области памяти?

Да всем насрать на эффективность. У всех по сотни гигабайт стоят в серверах. А вот софт писать с возможностью быстрого изменения можно только на Lisp.

подход, принятый в С и С++, при котором менеджер памяти прибирается в системе только после явного (и программистом) освобождения области памяти

В больших системах с проблемой утечки памяти борются ГОДАМИ. Не зря используют яву для бизнес-приложений.

Вместо «Scala» можете подставить абсолютно любой язык (да-да, интеллектуальных усилий тоже требует освоение любого языка, что бы там ни говорило ваше ЧСВ и прочий илитизм) и оба утверждения останутся верными.

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

Но все должно быть в меру. Мне нравится гибридный стиль

А какие проблемы-то? Лисп - вообще не препятствует, как я понимаю. В Хаскеле есть FFI: попросил у сборщика мусора памяти, и сношай ее сколько тебе влезет. Не хочешь просить у сборщика мусора? Дык, бери из кучи или вообще проси напрямую у ОС!

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

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

Расстрелять...

... за ненадобностью этого кренделя.

Искренне Ваш, mr_noone. ))) Надеюсь, мои комменты отличаются по оформлению «во все поля» от этого позора рода анонимусов. )))

Ой, да я Вас умоляю! Ну право, ну сколько можно-то! Я некоторым образом знаком с тематикой «больших систем» (и «лет» в том числе). Могу заявить следующее:

Для С (с С++ во многом аналогично, но на С можно показать более очевидным образом) уже дааавным-давно разработаны рецепты решения такого рода проблем. Предположим, Вы выделили область через malloc(), поработали, а освободить ее забыли. Утечка же? Во-первых, чтобы от нее избавиться, написав malloc(), мы сразу пишем freez(). Почему freez()? Чуть дальше будет, а пока просто получаем то каждому выделению соответствует одно освобождение. Простым подсчетом пар malloc/freez по дереву сырцов можно провериться на банальные утечки.

А теперь почему freez, а не free. Потому что free(ptr) просто говорит менеджеру памяти что память свободна. Но на самом деле, это не так. Эта память свободна и доступна, т.е., можно ее (упс!) попробовать освободить вторично, можно туда писать и оттуда читать с полностью непредсказуемым результатом. Так что, окромя free(ptr); для вящей безопасности просто делаем ptr = 0; И это _самый_ простой, есть и посложнее варианты, способ избежать проблем с динамическим распределением. Вам просто gcc салазки загнет если Вы туда полезете в коде.

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

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

Нормально структурированный код можно быстро и качественно править безотносительно к языку. Только хочется чтобы в остальное время он просто работал и быстро.

В больших системах с проблемой утечки памяти борются ГОДАМИ.

Вранье. В больших, профессиональных системах «проблемы» утечки памяти нет. И ни один коммит в trunk не пустят, если все valgrind-тесты не проходятся.

Не зря используют яву для бизнес-приложений.

Не зря используют C, C++, Fortran для серьезных приложений. Java в real time, mission critical пока что как-то не часто встречается. А когда встречается, то обычно с самописным хипом (и, соответственно, malloc и free), а GC в таких приложениях отдыхает.

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

Не честнее ли здесь подход, принятый в С и С++, при котором менеджер памяти прибирается в системе только после явного (и программистом) освобождения области памяти?

Про RAII не слышал? «Явное» освобождение памяти - mauvais ton.

«динамический опердень на фортране» - почувствуй себя не таким как все.

А что тут особенного-то? В 80х бухгалтерию на ЕСах как раз на Фортране и херачили, и ничего, никто не жаловался.

а никто не пробовал под андройд юзать?

... вполне очевидный вопрос, однако, дочитав до признания существования иммутабельных объектов в С, остановился. Наверное Вы хотели все-таки сказать не в С, а в С++?

В случае, если да, то я могу заметить что Вы правы. Но тогда программирование на С++ vs. программирование на Lisp в части эффективности рабочего кода по используемым ресурсам даже сравнивать грех.

Давайте на «ты».

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

Про эффективность рабочего кода бабка надвое сказала. Сильно зависит от задачи. Распространено мнение, что программа на Си или С++ по умолчанию будет быстрее. На самом деле, это далеко не так. Как я написал, все зависит от задачи, и, разумеется, самого программиста.

real time, mission critical

Если вместе, то да, однако бывают mission-critical без жесткого реалтайма, где с gc проблем не бывает, в основном упирается в IO

... Слышал. Почему нет? Более того, для GCC есть нестандартное расширение на базе макроса, позволяющее в С определить переменную заданного типа, навесить на нее ф-ю, которая будет выполнена при выходе переменной из области видимости. Реализовано это на базе атрибута cleanup.

Этим можно пользоваться, а можно и воздержаться. Ни кто не настаивает. Но такая практика при ее «повсеместном» применении может (потенциально) привести к проблемам.

Вылезай из саркофага. RAII применяется повсеместно, а за new и delete в коде могут выпороть розгами на конюшне.

Очень хорошо, что новости по Лиспу выходят так часто. Пророчу этому языку великое будущее.

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

так что в нормальные новости он попасть не может в принципе.

Попадает же, в связи с этим боль?

Попадает же, в связи с этим боль?

Не попадает. Все новости с участием говнолиспа - про выход новых версий средств разработки на говнолиспе и публикацию говносектантских говнокнижонок про говнолисп. Ни одной новости о том, как на говнолиспе сделали что-то полезное за последние лет 50 не было.

ну как же. на лиспе как минимум сделан универсальный инструмент для добычи батхерта из олигофрегнов вроде тебя :)

... Смотрю на С-код. В упор не вижу ни RAII, ни new с delete. Код некоего сетевого демона. ЧЯДНТ? Осчасливьте мудростью? )))

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

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

Си не нужен. Есть C++. Забудь про голый старый Си.

И "да" и "нет"...

... По поводу перехода на «ты», согласен. Не вопрос.

А по поводу термина «объект» я не совсем согласен. По поводу очевидной тенденции с современных языках спорить не буду, однако замечу что для меня это не совсем правильный подход.

В ряде случаев ООП для меня выглядит вот так — Релиз ruby 2.0.0 preview2 (комментарий)

Что я от этого получаю? Да, у меня есть простые типы данных, которые основаны на архитектуре системы, в которой запускается мой код. Но кроме этого я еще могу создавать некоторые «объекты», которые позоляют мне более удобно записывать мой код. Этот подход не похож на подходы в современных языках? Да и фиг с ним. Как-нибудь переживу. Хотя могу заметить что в приведенном по ссылке коде, ни где не вышел за пределы использования стандартной библиотеки. И старого, доброго, местами уютного С.

По поводу говнокода так же соглашусь. Не важен язык, сговнокодить можно везде. Только, если скажем брать CGI/FastCGI на С и сравнивать говнокод с говнокодом на похапе, то получится что говнокод на С оторвет его создателю голову практически сразу. А похапе будет мужественно бороться с проблемами, пожирая все ресурсы, до которых сможет дотянуться. Лучше уж сразу, чтоб долго не мучался.

... А авторам апача/лайти/постфикса/постгреса/.../gtk/gnome об этом докладывали? Они в курсе?

По поводу «предложения» писать модули ядра на С++ и реакции Самого я напоминать не буду. И уж совсем постараюсь забыть о том, что по мнению господина Степанова, автора STL, с ООП все не так хорошо. Ну а после того, что я узрел в С++11, мне захотелось свалить С++ и пореже туда вообще заглядывать.

Попробую прояснить. Мне нравится лисповская терминология. Объект на связан с ООП. Любое значение является объектом, будь то число, функция или экземпляр класса. Объекты имеют тип. Класс ООП создает тип. Экземпляры класса являются объектами в понимании Java и такими же объектами в понимании лиспа как функции или векторы. Признаю, что не все готовы к такой терминологии ;)

Что касается сравнения си и php. Если основная задержка идет от ввода-вывода (сети), то не все ли равно, на чем написан скрипт cgi, только если он не стартует долго (java-апликуха поверх cgi).

Guide to Rich Hickey's Brain

Дальше не читал.

Рич Хикки - мерзкий говнюк. Само его существование оскорбляет наследие Лиспа, гений МакКарти и все те труды, которые Лисперы вложили в дело за последние годы. То, что Clojure работает на JVM - это мелочь по сравнению с прочими смертными грехами, каковых настолько много (и которые так меня бесят), что я здесь даже половины не перечислю.

Ну что, начнем со сваливания в кучу функций и значений? В нормальном Лиспе головные формы распознаются моментально, потому что они, блядь, идут в начале списка. Когда с этим облажались в Scheme, было уже довольно хреново; еще хуже стало, когда на те же грабли наступил Пол «Поглядите-я-даже-не-знаю-что-такое-интерактивная-разработка» Грэм. И что, никто ничему не научился на их ошибках? Ах, ну да, в Scheme попытались это вылечить так называемыми «гигиеническими макросами», которые были хотя бы юзабельны, несмотря на убогость. В Clojure даже того нет - это просто смешно.

Но это еще не самое плохое. В Clojure слишком много синтаксиса! Похоже, что Хикки в качестве модели выбирал Haskell. Я не припомню другого языка, в котором было бы столько синтаксиса. В виде Кложуры мы получили самый синтаксически тяжеловесный лисп-подобный язык на сегодняшний день. («Лисп-подобный» - потому что, за исключением самых поверхностных моментов, на самом деле в Кложуре нет ничего от Лиспа.) Самые обычные вещи, которые тривиально реализуются в терминах головных форм, в Clojure превращаются в мешанину из скобок и разделителей, даже в элементарнейших случаях. [foo] вместо (list foo), {:foo bar} вместо (dict :foo bar)...

Лямбда. Это слово пишется как «lambda», а не «fn». Не так уж и сложно набрать, правда, мистер Хикки? Что, руку вывихнул, пока дрочил на собственное дутое ЧСВ? Надеюсь, руки у тебя отсохнут и отвалятся, а сам ты сдохнешь. Потому что ты угробил Лисп для огромного количества людей. Ты даже не можешь напечатать «lambda»? Серьезно? Не верю.

И да, к слову об ABCL. Он уже есть и прекрасно работает на JVM. Нет никаких причин плодить еще один диалект.

[foo] вместо (list foo)

Не позорься, голуба моя. Если ты взялся брызгать слюнями, то хотябы потрудись минимально изучить предмет оплевывания. То, что ты не имеешь малейшего предствления о ленивости и зачем она нужна делает тебя полным клоуном. И да, «fn» лучше «lambda», потому что короче.

мир мутабелен по своей природе

Заряд у электрона поменяй, говнюк мутабельный.

А вот и хиккирасты подбежали. Успел утренний намаз Хиккарю совершить или сразу на ЛОР?

Да, и кстати, в отличие от тебя я не считаю, что ABCL не нужен.

Ну значит попробуем ;)

Рич Хикки - мерзкий говнюк. Само его существование оскорбляет наследие Лиспа, гений МакКарти и все те труды, которые Лисперы вложили в дело за последние годы.

Сам ты, бл$дь мерзкий недоносок. Чувак, МакКарти и понятия не имел про современные реалии. Скажи ему про хип в 512 гигабайта, и что у тебя 8192 ядра в задаче и как бы он отсосал со своим Lisp'ом.

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

бы отсосал со своим Lisp'ом.

Уж кого-кого, а Маккарти мы уважаем.

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

Заряд у электрона поменяй, говнюк мутабельный.

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

Что с «энергией»? У тебя кванты заряды стали менять, говна кусок?

Что с «энергией»?

А то, что энергия мутабельна, говнюк. Слив засчитан.

Феерия долбокретинизма. Сам слился - сам защитал.

/facepalm

Ясно...

... Пояснение понятно. Это, скажем так, из серии «плавали, знаем» (с той же Java и ея объектной моделью знаком достаточно предметно). Но у меня вопрос — а в чём здесь смысл? У тебя не возникает ощущения некой такой «искусственности» происходящего? Я признаю твою терминологию, но я не уверен в правильности подходов. И мне не важно что по данному поводу думает масса леммингов, которые, как известно, не могут ошибаться.

В работе N. Wirth. Modula-2 and Object-Oriented Programming // Proceedings of the First International Modula-2 Conference. Bled, Yugoslavia, 1989. p. 7-13., Вирт заметил что «мир информатики подвержен влиянию моды». Да, нониче подход «всё что угодно есть объект» моден. Но что из того? Что, объект Java из primitive data types и производные от него внезапно стали напрямую соответствовать представлению на конкретном процессоре? Или это некие абстракции JVM, которые напрямую от железого процессора не зависит? Всё верно — это абстракции. И они имеют предопределённые размеры (http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html), которые чисто теоретически покрывают _основные_ архитектуры. А что делать если мне нужна какая-то «неосновная» архитектура? Весьма вероятно, там это тоже будет работать, но насколько эффективно?

Далее. А вообще какие ресурсы машины/машин мы можем отдать на обеспечение функционирования JVM (или любой другой VM) и во имя чего? Если во имя переносимости «клиента», то да. Можно, в принципе. Когда клиент нажал на кнопочку в приложении, то вообще-то его интерфейс на современном железе отрисуется заведомо быстрее, чем произойдёт подгрузка данных по сети. И тут вообще-то похрену — swing/.../чего ещё изволите. Главное чтобы это работало на Linux/оффтоп/гейоси... Где угодно без переписываний.

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

Сравнение С и похапе здесь не столько в части латентости сети. Здесь проблема, на самом деле, в другом. Современный похапе с его Зенд-компиляторам-оптимизаторами и подобной ерундой просто крайне выраженный случай «модных» тенденций в программировании. Быдлокодится крайне быстро, «дёшеГо», есть какая-никакая объектная модель, правда при всех потугах хоть как-то всё это запустить в работу, внимательный наблюдатель фигеет от происходящего до такой степени, что пишет что-то навроде вот этого — http://developers.slashdot.org/story/09/12/20/1433257/the-environmental-impac... (рекомендую прочесть на досуге). Про то, что сам по себе похапе более чем наполовину просто обёртки над С, так об этом просто умолчим.

Вот и получается что терминология-то понятна, но вот смысл-то в её применении какой? ;)

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

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

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

Что не так?

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

Следовательно, тебе засчитывается слив.

Кложурокапец настал?!!!

Врядли.

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

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

Я конечно могу ошибаться в хронологии. Но clojure пошел в народ паралелльно с тем когда для CL начали делать что-то практически полезное типа parenscript или postmodern (чисто для примера). И хикки на белом коне нового вебдванольного мира утянул таки себе информационное одеяло.

Кококок падумаишь! А вот пацоны из быдлошараги скозали што материя изменится если ее папердолить бесколнечно малыми.

Замечательно. Все будет верно, как только 'жидоматематики' научатся оперировать частицами меньше планковской длины и временем меньше планковского, а пока, Отсос Отсосыч, вам слово...