В ближайшее время будет серия постов (счас в черновиках частями лежит) про low-level в персональном блоге. Там и ссылки будут — упорядоченные и взаимосвязанные :)
Карму не стоит. Стоит только ей угрожающе подняться выше 2х, как тут же набИгают какие-то засЛанцы и в 1-2 дня сбивают. Причем я в это время обычно не пишу и не комментирую. Так что ваши труды пропадут зря — можете проверить сами как-нибудь :)
Блин, скока информации и вопросов в одном комменте :) Да простит меня хозяин блога :)
Я и не говорил про субъективное отношение к LISPу. Он продуман в том направлении, что в основном благодаря ему обеспечивается поддержка метапрограммирования, замыканий, bind и прочих штук, на которых построен LISP. И сказал так же, что нынешние среды реализуют эти возможности не за счет синтаксиса, а за счет более «умной» системы поддержки компиляции и выполнения.
Насчет Фон-Неймановской — таки не согласен. Связана с Тюринговской, и очень даже сильно.
Также доводило писать под гарвардскую и супергарвардскую архитектуру, на основе которой построено подавляющее большинство архитектур встраиваемых устройств. Да и самих встраиваемых вычислителей в мире по статистике на порядки больше, чем компьютеров общего назначения. Так что в целом Фон-Неймановская вряд ли рулит. Сам считаю, что идеологически гарвардская вернее :)
С LLVM знаком, Adobe и Mac ее с 2005 года раскручивают. Adobe на основе нее даже Alchemy сделал, по трансляции c++ -> avm (Adobe Virtual Machine). Вот и Google подтянулся.
Если вам интересно, есть подобная разработка под названием С-- :) Правда, там опять-таки, за счес соглашений языка обеспечивается портируемость. Ну и она не получила достаточного распространения. Кроме того, если посмотреть глубже во фронтенд GCC, можно увидеть, что тот опять-таки с давнего времени компилировал в p-code, который процессился бэкэндом, заточенным под конкретную архитектуру. Вот только под формальный стандарт это не было подведено.
Сорри за длинный пост — каков вопрос, таков ответ =)
Так-то оно так, но императивная модель — очень даже правильно с точки зрения дискретного исполнителя, чем на низком уровне является компьютер. Я не защищаю императивы, просто говорю, что исторически развитие шло от более низкоуровневого — выше; соответственно, низкоуровневую модель Тюринг-машины тащили снизу вверх, от ассемблера — к ЯВУ.
Здесь приятным исключением выступает LISP; правда, не в плане синтаксиса. Сейчас можно достичь того же и не пользуясь «универсальным синтаксисом», но время утеряно, и императивы прут вперед :)
Я в свою очередь рекомендую SICP (pdf) — творит чудеса с мировосприятием.
В общем, я Вас понял :)
«Лампа» не лучше, «лампа» проще, дешевле и неприхотливее (ну-ка, попробуйте выходной каскад на транзисторе перегрузить), и за счет этого имеет гандикап. С увеличением «хайовости» аппаратуры (и цены) различие стирается, но не все до него добираются.
По-моему, так.
Я вам про физику, вы мне про субъективное ощущение.
Давайте так: параметры лампового fuzz/distortion/overdrive можно замерить прецизионно? Можно. Сымитировать такой перегруз можно? Можно. В чем вопрос? :)
Я согласен, что из-за специфики транзисторов (в том числе нелинейности и собственных шумов, особенно у биполярных) сделать качественный каскад аналогичной мощности и характеристик на транзисторах гораздо сложнее, и стоить он будет больше.
Но проблема решаема. Без уличной магии и лампы. Хоть волшебной, хоть катодной :)
Тот же Rammstein не чурается цифры, которая, естественно, на транзисторах.
По ссылке очень много интересного материала. Например:
Ближе к концу фильма «Хозяин морей: на краю земли» есть сцена, где Матурин (Пол Беттани) взбирается через поток лавы на вершину холма для того, чтобы найти «бескрылого баклана» (и, конечно же, вместо этого он замечает Acheron). Через каждый имеющийся у меня в доме видео кабель – а у меня их великое множество – когда Матурин взбирается на вершину холма, он выглядит таким загорелым, как будто на него наложили слишком много грима. А при использовании обоих кабелей Nordost – и, как бы не забыть, проектора GTT Reference 9 – оттенки его кожи существенно меняются. Более ли менее коричневый цвет становится ярко-розовым, а плоское тело становится плотью и кровью. Разница действительно впечатляющая – и невероятно реалистичная.
Нет :) Есть именно отсутствие стиля, т.е. «каша»: из операторов, символов, скачущие строки, разнобой выравнивания, лишние пробелы и т.п.
Мой предыдущий начальник смотрел даже на количество пустых строк между объявлением методов, чтобы оно было одинаково для всего файла и всех файлов. Мотивация следующая: «как можно доверить что-то серьезное человеку, который даже не может вставить одинаковое количество переводов строки?»
В ближайшее время будет серия постов (счас в черновиках частями лежит) про low-level в персональном блоге. Там и ссылки будут — упорядоченные и взаимосвязанные :)
-meowth-.habrahabr.ru/
FFox > 3 делает это самостоятельно; как помочь остальным, даже не знаю
Я и не говорил про субъективное отношение к LISPу. Он продуман в том направлении, что в основном благодаря ему обеспечивается поддержка метапрограммирования, замыканий, bind и прочих штук, на которых построен LISP. И сказал так же, что нынешние среды реализуют эти возможности не за счет синтаксиса, а за счет более «умной» системы поддержки компиляции и выполнения.
Насчет Фон-Неймановской — таки не согласен. Связана с Тюринговской, и очень даже сильно.
Также доводило писать под гарвардскую и супергарвардскую архитектуру, на основе которой построено подавляющее большинство архитектур встраиваемых устройств. Да и самих встраиваемых вычислителей в мире по статистике на порядки больше, чем компьютеров общего назначения. Так что в целом Фон-Неймановская вряд ли рулит. Сам считаю, что идеологически гарвардская вернее :)
С LLVM знаком, Adobe и Mac ее с 2005 года раскручивают. Adobe на основе нее даже Alchemy сделал, по трансляции c++ -> avm (Adobe Virtual Machine). Вот и Google подтянулся.
Если вам интересно, есть подобная разработка под названием С-- :) Правда, там опять-таки, за счес соглашений языка обеспечивается портируемость. Ну и она не получила достаточного распространения. Кроме того, если посмотреть глубже во фронтенд GCC, можно увидеть, что тот опять-таки с давнего времени компилировал в p-code, который процессился бэкэндом, заточенным под конкретную архитектуру. Вот только под формальный стандарт это не было подведено.
Сорри за длинный пост — каков вопрос, таков ответ =)
Здесь приятным исключением выступает LISP; правда, не в плане синтаксиса. Сейчас можно достичь того же и не пользуясь «универсальным синтаксисом», но время утеряно, и императивы прут вперед :)
Я в свою очередь рекомендую SICP (pdf) — творит чудеса с мировосприятием.
«Лампа» не лучше, «лампа» проще, дешевле и неприхотливее (ну-ка, попробуйте выходной каскад на транзисторе перегрузить), и за счет этого имеет гандикап. С увеличением «хайовости» аппаратуры (и цены) различие стирается, но не все до него добираются.
По-моему, так.
Слава б-гу, никакой магии :)
Давайте так: параметры лампового fuzz/distortion/overdrive можно замерить прецизионно? Можно. Сымитировать такой перегруз можно? Можно. В чем вопрос? :)
Я согласен, что из-за специфики транзисторов (в том числе нелинейности и собственных шумов, особенно у биполярных) сделать качественный каскад аналогичной мощности и характеристик на транзисторах гораздо сложнее, и стоить он будет больше.
Но проблема решаема. Без уличной магии и лампы. Хоть волшебной, хоть катодной :)
Тот же Rammstein не чурается цифры, которая, естественно, на транзисторах.
Я плакалЪ…
Мой предыдущий начальник смотрел даже на количество пустых строк между объявлением методов, чтобы оно было одинаково для всего файла и всех файлов. Мотивация следующая: «как можно доверить что-то серьезное человеку, который даже не может вставить одинаковое количество переводов строки?»
:)
Печально.