Язык для обучения программированию

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

Ага, теперь уже «обычно»? То есть, ты начинаешь понимать, что CLOS может быть определён НЕ с помощью CLOS?

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

Да, и ещё он может подключиться к квантвому устройству, тогда код (с макросами) уже не будет иметь классическую семантику :)

Ну и определение макроса эквивалентно внесению нового варианта в BNF, как если бы в хаскеле можно было добавить вариант к типу Core/HsSyn и тут же дописать семантику преобразования Core/HsSyn к своим кодоменам.

Нет.

Graphic Lisp. CL, реализованный на ANSI C. Дохлый, правда, но это другой разговор.

Да то что чтобы скомпилировать лисп тебе уже нужен скомпилированный лисп.

Нет. Для того, чтобы скомпилировать Graphic Lisp, мне не нужен никакой лисп. Мне нужен только gcc.

Сильно урезанный CLOS может реализоваться не в виде метациклического вычислителя. Но это будет сильно урезанный CLOS без MOP. Все полные реализации CLOS метацикличны.

Дохлый, правда, но это другой разговор.

Никогда о нем не слышал. Вероятно, сильно урезанный и неполный.

Я о чем и говорю, что ее нет.

Но обосновать это утверждение отказываешься. Поня-атно.

«Мета» приставка в «циклический» в применении к вычислителям означает что сами правила вычисления могут меняться в процессе вычисления.

Нет. Это называется «тьюринг-полнота».

И?

И если в момент времени t_0 у меня есть BNF с 26-ю вариантами и 26-ю семантическими правилами, то, после определения макроса, в момент времени t_1 у меня будет BNF с 27-ю вариантами и 27-ю семантическими правилами. При этом добавляемое для варианта семантическое преобразование работает так, как написано в макросе, а в макросе любой лиспо-код в том числе I/O, т.е. в том числе и по-настоящему индетерминированные значения. Поэтому в момент t_0 у нас один формальный синтаксис + семантика, а в момент t_1 - другие, не обязательно формальные (если мы не умеем формализировать то что делает макрос).

Значит они не полны.

Ты всерьёз утверждаешь, что любой учебник по форту неполон?

Но это будет сильно урезанный CLOS без MOP.

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

Никогда о нем не слышал.

Ну, если все твои знания о лиспе сводятся к знанию нескольких основных реализаций...

И если в момент времени t_0 у меня есть BNF с 26-ю вариантами и 26-ю семантическими правилами, то, после определения макроса, в момент времени t_1 у меня будет BNF с 27-ю вариантами и 27-ю семантическими правилами.

Да бога ради. Что ты всё сводишь к этим убогим BNF?

Нет. Тьюринг-машина не может изменить правила по которым она работает сама. Она может изменить код программы, но не может код самой себя.

Но метациклические вычислители на тьюринг машинах, естественно, реализуемы, чему пример CL и форт.

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

Про CLOS долго рассказывать. Почитай AMOP, и/или попробуй сам реализовать.

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

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

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

Во-первых, машина Тьюринга не может изменить код программы. Учи матчасть.

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

Про CLOS долго рассказывать.

Может, ты сделаешь хоть какое-то утверждение, которое не сольёшь столь бездарно?

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

Такого утверждения в учебниках не бывает, разумеется. Бывают утверждения «вот это можно изменить так-то, и тогда будет то-то».

Советую Processing.

Да бога ради.

Т.е. ок? Нет формальной семантики у CL? А то тогда она будет включать все те макросы которые *в будущем* напишут все пользователи CL.

Что ты всё сводишь к этим убогим BNF?

Метаязык BNF (для задания языков) эквивалентен метаязыку ADT (для задания типов). В haskell-е вон синтаксисы языков обычно задаются как ADT, так что вовсе не такие они и убогие. Чему эквивалентны ADT мы знаем (о ужас! :D).

В данном случае я подразумевал, что аналог Core (из GHC, например) в CL расширяется вариантами и семанитическими преобразованиями самим пользователем.

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

UTM может менять код программы. Собственно все современные процессоры это UTM, а конкретно - RASP.

Ок, не «что угодно», но в плане переопределения стандартных процедур - они дальше одного шага вперед в описании последующего не заходят.

Да вот пример тебе - обобщенная функция обращения к слотам требует обращения к слотам класса сначала. Но слот «слотов» класса это слот метакласса. А метаклассы это тоже классы, да. Соответственно, ее реализация, и реализация классов, требует бутстрапа. Более того, вообще определение любой обобщенной функции(defgeneric или еще как) тоже требует использования этой функции(slot-value-using-class). А она сама обобщенная, как я уже сказал.

Нет формальной семантики у CL?

«Нет» в смысле никто не написал? Конечно. Как и почти у всех остальных языков программирования.

А то тогда она будет включать все те макросы которые *в будущем* напишут все пользователи CL.

Макросы к операционной семантике не относятся. За вычетом разве что команды eval.

В haskell-е вон синтаксисы языков обычно задаются как ADT, так что вовсе не такие они и убогие.

Опять «обычно»?

А зачем лиспу менять физику процессора?

Низачем. Как и машина Тьюринга не меняет свою программу.

UTM может менять код программы.

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

Платиновые треды лора.

нужно распечатать его на А4 и в рамочку на стенку, каждый лист )

Ок, не «что угодно», но в плане переопределения стандартных процедур - они дальше одного шага вперед в описании последующего не заходят.

В Форте дальше одного шага и нет ничего, он простой и тупой.

Да вот пример тебе - обобщенная функция обращения к слотам требует обращения к слотам класса сначала. Но слот «слотов» класса это слот метакласса. А метаклассы это тоже классы, да. Соответственно, ее реализация, и реализация классов, требует бутстрапа.

Ты отдаёшь себе отчёт, что описываешь сейчас бесконечный цикл?

Естественно, работает всё несколько иначе (бесконечные циклы за конечное время только в Хаскеле выполняются).

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

Я говорю о том, что язык С практически идеальный вариант для такого рода задач, т.к. он легко позволяет как высокоуровневый код писать, так и низкоуровневый. Вместе с тем задача оптимизации методов компьютерных вычислений является не менее важно частью программирования. Именно поэтому программист, еще до того как он станет ООП(и другое нынче модное) юзер, должен изучить более низкоуровневые механизмы работы, а так же принципы оптимизации именно компьютерных алгоритмов(тех которые являются «конечной» имплементацией мат алгоритмов в программном виде).

Я клоню немного к другому. Тут у меня есть несколько поинтов. Во-первых, реализация любой более менее сложной абстракции на С - это как ебля в гамаке. С математикой вообще - сплошные рыдания, а не решение проблем. К примеру, мне необходимо было замоделировать некоторые вещи с эллиптическими кривыми. На лиспе запрототипировал, потом на темлейтах С++ набросал общий алгоритм, и натянул это на произвольные группы, которые предоставляют необходимые мне операции типа + и *. Результат получился примерно на 10% медленнее эталона — openssl, причем я вообще не заморачивался производительностью. Если бы я это делал на С, одни и те же алгоритмы я бы реализовывал 4-8 раз по разному. Или танцевал с макросами/void *, что является адом само по себе. Что я тут хочу сказать? С - не самое хорошее решние, что бы моделировать абстрактные штуки. Вместо абстракций мы занимаемся частностями - чернухой, изобретением колеса. Второй поинт - низкоуровневость. Но что это значит? Хотите использовать специфические операции? Или используйте intrin, или ассемблерные вставки. Хотите SMP, atomic? Или используйте pthreads, или ассемблерные вставки, или openmp (это DSL, а не С). Хотите NEON? Ассемблерные вставки. CUDA? А там вообще C? По большому счету куча всяких финтов поставляется как набор расширений без какой либо стандартизации. Как мне на низкоуровневом С объяснить, что вот тут я хочу ROR? Ассемблер это не С. Хотите что бы результат жизнедеятельности был оптимальным и быстро работал? Расслабьтесь и отдайтесь компилятору. Оптимизация конкретной реализации (не алгоритмическая), часто сводится к шаманствам, дабы лучше объяснить компилятору, что и как ему следует оптимизировать. То что получается на выходе современного gcc совершенно отлично от того, что выдавал старый добрый tcc. Чего низкоуровнего есть в С на данный момент? Возможность писать по произвольному адресу? То что делает С низкоуровневым в глазах Списцев - возможность отсутствия рантайма и абсолютно убогий функционал. Не стоит забывать, если вы пишите хитрый загрузчик на С, у вас не будет ни куды, ни тредов, ни неона — ничего. Даже printf из стандарта не будет, пока вы не напишите свой рантайм. Но чем это отличается от реализации любого другого рантайма? Плюс, не стоит обманывать себя - умение «эффективно» писать на С это не более чем умение эффективно писать на С. Это не какое то общее знание, применимое ко всем остальным системам. Даже в ++ с этим знанием лезть, пожалуй, не стоит. Не то что бы куда то еще. Конечно, кто-то этим должен заниматься, но причем тут студенты, профиль занятий котрых совершенно иной?

Как то так

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

P.S. Регулярно сталкиваюсь с погромистами, которые даже не замечают какой медленный и ужасный код они пишут. Меня это очень сильно поражает.

P.P.S. Зато они пишут используя ООП, кучу абстракций и все очень модульно и динамично...

Ууу какая портянка. Хотя бы абзацами разбавил.

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

«Нет» в смысле никто не написал?

«Нет» - всмысле ее нету у CL. Семантика есть у _ данной конкретной лисп-машины_ в _данный конкретный момент времени_. У CL _в общем_ семантики нет. Другими словами, если у нас есть кусок кода вне контекста конкретной лисп-машины - то мы не имеем никакого способа определить, что делает этот код. Более того - мы даже не сможем сказать, является ли этот код корректным лисп-кодом. Потому что любая последовательность символов является некоторой программой для некоторой лисп-машины. Причем программой она может являться любой (достаточно подобрать нужную лисп-машину). Да и не только последовательность символов - например, найдется лисп-машина, для которой запись «лунной сонаты» задает функцию, вычисляющую факториал. Если формально - CL есть отображение из прямого произведения совокупности лисп-машин на совокупность состояний нашей вселенной в совокупность семантик.

Неконтролируемое разрастание треда (до восьми страниц за сутки) - признак злокачественного поражения.

В данном случае поражающим фактором является недовыпизженный со второго курса СГАУ студент-шизофреник, а подпёздывающими (отягощяющими) факторами - апологеты зигохистоморфных препроморфизмов, аппликативных комонад и прочих моноидов в категориях эндофункторов.

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

Если формально - CL есть отображение из прямого произведения совокупности лисп-машин на совокупность состояний нашей вселенной в совокупность семантик.

Даже небо, даже аллах.

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

s/спиральности/хиральности/ же!

нет, имелась ввиду именно спиральность

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

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

Выдыхай, бобёр, и вали спать. Рассуждать о перспективах в таком состоянии - метациклическая самонаёбка.

Ну. Просто же касается. Нет смысла учить программировать на С :)

Макросы больше чем на 5 строк в С лучше не использовать

Макросы больше чем на 5 строк в С лучше не использовать

куда ты денешся красавица посмотри это и скажи как сделать без макросов и сохранить typesafety

http://fxr.watson.org/fxr/source/stdlib/rb.h?v=FREEBSD7-LIBC

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

Чистый питон, даже с учётом NumPy не будет достаточно быстр, а тяжелые вещи на С писать времени не будет скорей всего.

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

Это мнение дилетанта, который никогда не преподавал.

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

мелькают, но слово ООП я не упоминал.
На самом деле на моём уровне проекты имеют размер порядка 3к-5к строк, ООП конечно уже может и нужно, но не это главное, структурная парадигма сойдёт.

Разнообразие это хорошо, да.
А что, всякие p2c и f2 уже хорошо работают, предыдущая попытка с фортрана перевести на С не была успешной.