>
> это С, да.

И что? Ну вон там из си++ вообще какой-то 1С сделали. Поматерился полдня - вот тебе и программа. Они на си++ не пишут, они им разговаривают. Просто #define'ы правильные воткнуть надо :)

Тем не менее, одно дело программа на повы...ться, а другое - программа писаная всерьез. У лиспа как-то сильно дохрена совершенно одинаковых скобок. Авторам си в этом плане респект - они осознали что в природе есть минимум 3 типа скобок. А у лисперов на все одни и те же. Мне такое не доставляет.

> У лиспа как-то сильно дохрена совершенно одинаковых скобок. Авторам
> си в этом плане респект — они осознали что в природе
> есть минимум 3 типа скобок. А у лисперов на все одни
> и те же. Мне такое не доставляет.

это всего лишь значит, что ты не умеешь писать на лиспе, вот и всё. а потому совершенно не понимаешь, отчего многочисленные попытки «сделать лисп понятней» закономерно фэйлили. на лиспе не пишут программ, на лиспе пишут dsl-и для решения задач. на других языках это или сложно, или невозможно вовсе.

>> и те же. Мне такое не доставляет.
> это всего лишь значит, что ты не умеешь писать на лиспе, вот и всё.

Да, и _не_ _хочу_ уметь программить на языке с _таким_ синтаксисом. Я не считаю его для себя удобным и хорошо читаемым. Поэтому у меня не лежит к оному душа. Вроде бы логично что я не умею и не собираюсь уметь на нем программировать.

> а потому совершенно не понимаешь, отчего многочисленные попытки «сделать
> лисп понятней» закономерно фэйлили. на лиспе не пишут программ, на лиспе
> пишут dsl-и для решения задач. на других языках это или сложно,
> или невозможно вовсе.

Ну, пусть пишут. А мне мои задачи явно проще реализовать на чем-то еще.

упрощу: «я не хочу учиться ездить на велосипеде! каждый раз как я на него садился — падал. мне говорили, что я что-то не так делаю, но я уже привык к самокату.»

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

> У лиспа как-то сильно дохрена совершенно одинаковых скобок. Авторам си в этом плане
> респект - они осознали что в природе есть минимум 3 типа скобок. А у лисперов на все
> одни и те же.

А это палка о двух концах: такой код заодно является данными, его удобно и разбирать, и порождать, причём макросы N-го порядка ещё остаётся шанс применять и анализировать, в отличие от.

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

> переключаться между
> императивными и функциональными языками быстро мало кому получается -- у меня
> вообще дня три занимает...

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

> Этот бедный синтаксис -- он помудрей многих засахареных по самое некогда.  

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

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

Я на такую кучу скобочек вообще переключаться не хочу. Мне не нравится такой синтаксис. Можно конечно и при помощи одной команды subleq написать любую программу. Сущностей будет минимум, синтаксис доступен даже обезьяне, но вот только программить будет очень геморройно. Как раз потому что 100500 одинаковых сущностей подряд мало чего говорят о логике программы пока не отпарсишь лично все 100500 своим взглядом. ИМХО, разные типы скобок придают программе более читаемый и структурированный вид, так что предназначение конструкции быстрее определяется чисто визуально.

> когда пять уровней одинаковых скобок рядом но их предназначение напрочь разное

какое такое «разное»? O_O алё, марсианцы, у вас там свой, самостийный лисп?

p.s. специально для удобства парзер некоторых Схем допускает использование [] вместо ().

p.p.s. и ещё раз удивлюсь: зачем же писать на «чистом лиспе»? просто потому, что его возможности метапрограммирования очень непривычны? так это повод вникнуть в концепцию и начать ней пользоваться. хотя есть и недостаток: потом на других языках дико выбешивает отсутствие таких фич.

> какое такое «разное»? O_O алё, марсианцы, у вас там свой, самостийный лисп?

Ну на первый взгляд выглядит как будто там вообще все одними скобками делается. Что в объявлениях, что в отделениях блоков кода, етц. Или я что-то не понял?

> p.s. специально для удобства парзер некоторых Схем допускает использование [] вместо ().

Ну я рад за них.

> p.p.s. и ещё раз удивлюсь: зачем же писать на «чистом лиспе»? просто
> потому, что его возможности метапрограммирования очень непривычны? так это повод вникнуть
> в концепцию и начать ней пользоваться. хотя есть и недостаток: потом
> на других языках дико выбешивает отсутствие таких фич.

Тут наверно разница в подходе. Если я беру в лапы компилер - то это не потому что мне приспичило подр^W на высокие концепции, а потому что я всего лишь хочу разрулить какую-то свою практическую задачку которая показалась мне интересной. При этом я шкурно заинтересован чтобы от того как это работает прежде всего не проблевался я сам, для начала. Всякие там си хороши тем что генерят достаточно резвый код. Еще они позволяют программировать системы очень разного калибра. Ну вот например микроконтроллер ценой в доллар на си программируется на ура. Это законченная система с процессором, флеш-памятью и оперативой на борту и масса периферии. И оно может здорово расширить мои возможности. Позволив измерять кучу величин, отмерять микросекунды, управлять в реальном времени различными процессами или реализуя некий прибор аналогов которого может тупо не существовать в природе(или только по неразумной цене). Что мне там ловить с этим вашим лиспом? Его для таких применений элементарно нет. А изучать 100500 синтаксисов всерьез?  А смысл? Я ленивый бастард и не ставлю целью подр^W на концепции сами по себе, уж извините :)

> Ну на первый взгляд выглядит как будто там вообще все одними скобками
> делается. Что в объявлениях, что в отделениях блоков кода, етц. Или
> я что-то не понял?

в общем-то да, не понял. по сути, программа на лиспе — это прямая запись AST (что и даёт возможность метапрограммирования). отсюда и логичное единообразное представление. опять же, code is data.

> Тут наверно разница в подходе.

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

> Его для таких применений элементарно нет.

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

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

Так есть вполне сложившаяся традиция записи, и оба редактора её прекрасно умеют.  При этом между гирляндами вполне можно поместить комментарии.  Вот пример вида ужас-ужас -- думаю, сгодится проиллюстрировать, что при аккуратном написании всё вообще хорошо: http://tinyurl.com/crmuyaq

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

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

Да и дело не только (и не столько) в удобстве машины, а в другом _подходе_.

> Я на такую кучу скобочек вообще переключаться не хочу.

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

> ИМХО, разные типы скобок придают программе более читаемый и структурированный вид,
> так что предназначение конструкции быстрее определяется чисто визуально.

Если в Вас когда-то был математик, то когда-нибудь Вы будете на себя в обиде за такие фразы. :)

http://www.altlinux.org/Scheme/Tutorial

PS: каюсь, это злейший офтопик в теме про си. :)

> http://www.altlinux.org/Scheme/Tutorial

вай, даже так. плюсадинвкарму альту.

> Так есть вполне сложившаяся традиция записи,

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

> и оба редактора её прекрасно умеют.

А я не собираюсь ограничиваться двумя редакторами, когда на планете есть сотни. Если вы про vim и emacs, можете меня закидать ссаными тряпками, но они мне оба не понравились. Если уж говорить о консольных редакторах, вменяемым лично мне показался nano для простого редактирования (1 конфиг по мелочи) или fte как "консольный програмерский редактор". Иногда по мелочи сгодится встроенный редактор mc, если надо отредактировать немного, быстро и "по месту" в конкретной локации файловой системы.

> При этом между гирляндами вполне можно поместить комментарии.  

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

> Вот пример вида ужас-ужас

Действительно, ужас.

Например:
------
> term))))))

------
Какой улыбчивый язык :)). Всего 6 одинаковых скобок в ряд?! Правда вот такой смайлик можно и задолбаться парсить глазами. Даже в эдиторе "с костылями" (умеющем фолдинг блоков и поиск парных скобок) на глаз такие конструкции схватываются как-то не очень, а их "парсинг" для понимания "а что это и зачем?" имхо довольно неудобен. Привыкнуть конечно можно ко всему, но после "сишного" синтаксиса (curly bracket) мне к такому привыкать как-то не очень то и хочется. В curly bracket такие конструкции читабельнее получаются.

> -- думаю, сгодится проиллюстрировать, что при аккуратном написании
> всё вообще хорошо: http://tinyurl.com/crmuyaq

Угу. Взгляд упал на 6-уровневое закрытие скобок. Не хочу ничего сказать но в curly bracket столь невкусные конструкции встречаются куда реже. А разный вид скобок подчеркивает их разное предназначение, что сложно назвать неправильным.

>> А когда пять уровней одинаковых скобок рядом но их предназначение напрочь разное
>> - меня это напрягает.
> Вы это уже озвучили, а я понял.  Попробуйте из программы с сиобразным
> синтаксисом распарсить или сгенерить кусок кода программы с сиобразным синтаксисом,
> а потом сравните со скобочками, в которых всё уже разложено.

Я не писатель компиляторов и прочих кодогенераторов, поэтому данные неудобства как-то более-менее пролетают мимо меня. И вообще я туго представляю себе зачем мне это нужно. А еще я не умею стоять на голове и ходить на руках. Но каких-то фатальных неудобств от этого я не испытываю. Да, некоторые это умеют. Ну и пусть себе умеют, отсюда не следует что мне надо бросить все и учиться ходить на руках.

> Да и дело не только (и не столько) в удобстве машины, а в другом _подходе_.

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

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

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

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

Ничего не имею против пайпов, пользуюсь. Удобно временами, факт. Хоть это и называется решением "из г-на и палок", но когда оно надо на 1-2 раза или раз в год - вполне себе вариант. А таких ситуаций почему-то как раз оказывается предостаточно.

>> ИМХО, разные типы скобок придают программе более читаемый и структурированный вид,
>> так что предназначение конструкции быстрее определяется чисто визуально.
> Если в Вас когда-то был математик, то когда-нибудь Вы будете на себя
> в обиде за такие фразы. :)

Я скорее инженер чем математик. Матаппарат для меня - средство, инструмент, а не самоцель. Тем не менее, замечу что математики кажется и придумали использовать разные по форме скобки. В навороченных выражениях они применяют минимум 3 типа скобок чтобы сделать сие более читаемым. Иначе когда у вас 6 уровней одинаковых скобок в ряд - вы очень даже можете запутаться в их иерархии и накосячить. А вот пересчитывать вычисления или преобразования на тетрадный лист размером - любителей мало.

> http://www.altlinux.org/Scheme/Tutorial
> PS: каюсь, это злейший офтопик в теме про си. :)

О, еще какой-то язык для любителей смайликов :))

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

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

> Действительно, ужас. Например:
>> term))))))

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

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

Так всё-таки задолбаться или костылями?  Определитесь, что ли.  Да что там, даже в mcedit хотя бы подсветка парных скобок есть (в vim по ним ещё и удобно прыгать %-ом).

> а их "парсинг" для понимания "а что это и зачем?" имхо довольно неудобен.

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

Впрочем, о вкусах не спорят и утверждать, что именно мой правилен -- глупо. :)

> Угу. Взгляд упал на 6-уровневое закрытие скобок. Не хочу ничего сказать но
> в curly bracket столь невкусные конструкции встречаются куда реже.

Да ну.  Просто занимает больше строк в явном или неявном виде.

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

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

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

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

>> Если в Вас когда-то был математик, то когда-нибудь Вы будете на себя
>> в обиде за такие фразы. :)
> Я скорее инженер чем математик.

Это заметно (не наезд!).  Но одни инженеры предпочитают "на глазок", другие всё же заморачиваются расчётами, а то и матмоделями.  Чтобы сгородить нетривиальное и оно не развалилось под своим весом, приходится заморачиваться.

> в curly bracket столь невкусные конструкции встречаются куда реже

if (a) {
  if (b) {
    if (c) {
      …
    }
  }
}
(if a
  (if b
    (if c
      …
    )
  )
)

если уж так нравиться тратить целую строку ни на что. где разница?
при этом лисповый исходник элементарно реформатируется во что угодно простейшей программой на лиспе — потому что он одновременно и данные. а сишный с трудом жуётся огромным indent'ом.

> если уж так нравиться тратить целую строку ни на что.

На читаемость. Потому что 6 скобок в ряд совершенно не рулят, ИМХО. Чтобы понять к чему они относятся, в них надо нудно тыкать.

> где разница?

А разница будет например если еще и в логическом условии if'а захотеть несколько скобок, например. Ну или в определениях и прочая. В curly bracket это более сносно, потому что скобки разные.

> при этом лисповый исходник элементарно реформатируется во что угодно простейшей программой
> на лиспе — потому что он одновременно и данные. а сишный
> с трудом жуётся огромным indent'ом.

Программ для переформатирования исходников в мире придумано уже достаточно, в том числе и для сишных сырцов. Честное пионерское, у меня ни разу не возникало даже желание заняться построением велосипедов (а зачем мне делать то что уже сделано?). Проще сказать apt-get install, блин. Грубо говоря, у меня нет цели окостылить все вокруг своим персональным велосипедом. А еще я например фиг с два напишу gcc. Но мне это не страшно - потому что он уже есть и намного лучше работает чем то что написал бы сам за какое-то разумное время. Отсюда кстати не следует что его сырцы мне бесполезны, как минимум я могу пересобрать его с потребными мне кастомными опциями, кросскомпиля на платформе типа "шило" под платформу типа "мыло", при том что общего у них чуть менее чем ничего, кроме того факта что и там и там компилируется си :).

а вот кстати если хочешь немного взрыва мозга, то (уж не помню, сам я это родил, или спёр где; не суть):

(define-macro (fluid-let xexe . body)
    (let ((xx (map car xexe))
          (ee (map cadr xexe))
          (old-xx (map (lambda (ig) (gensym)) xexe))
          (result (gensym)))
      `(let ,(map (lambda (old-x x) `(,old-x ,x))
                  old-xx xx)
         ,@(map (lambda (x e)
                  `(set! ,x ,e))
                xx ee)
         (let ((,result (begin ,@body)))
           ,@(map (lambda (x old-x)
                    `(set! ,x ,old-x))
                  xx old-xx)
           ,result))))

не пытайтесь повторить это дома, да. но тем не менее, с языками, где нельзя генерировать куски программы в процессе компиляции, такой финт не пройдёт.

на самом деле ничего сложного тут нет -- это не сложнее сей. а где-то даже понятней.

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

p.s. надеюсь, я достаточно тебя напугал, чтобы в ближайшие лет 20 даже с испугу тебя не посетила мысль разобраться с лиспом?

>> макроассемблер да, а хороший то почему?
> а чем он плох?

описывать все недостатки сил не хватит. но из простейших - нет массивов и строк, нет цикла с заданным числом повторений, нет булева типа (отсюда вообще куча анекдотов типа if(i=1)) или
for(i=0;i<10;i++)  for(i<10; i=0;i++) for(i++;i<10;i<10) что все синтаксически правильны

вообще такие вопросы (вы ведь не просто тролль?) говорят либо о том что человек не просто одного языка кроме ц не видел, но и совершенно лишен критического взгляда, ну или уже что-то не по моей части

> описывать все недостатки сил не хватит. но из простейших - нет массивов

Это точно про си?!

> и строк,

Кто украл у си строки?!

> нет цикла с заданным числом повторений, нет булева типа
> (отсюда вообще куча анекдотов типа if(i=1)) или
> for(i=0;i<10;i++)  for(i<10; i=0;i++) for(i++;i<10;i<10) что все синтаксически правильны

Хаха, на сях просто цикл относительно честно выглядит. Примерно так оно и отправится в процессор - с инкрементом/декрементом и проверкой условия выхода.

> вообще такие вопросы (вы ведь не просто тролль?) говорят либо о том
> что человек не просто одного языка кроме ц не видел, но
> и совершенно лишен критического взгляда, ну или уже что-то не по моей части

Вы забыли сущую фигню: покажите что-то лучше пригодное для системного программирования?!

>> описывать все недостатки сил не хватит. но из простейших — нет массивов
> Это точно про си?!
>> и строк,
> Кто украл у си строки?!

на самом деле нет *типов* таких. в понимании «тип + операции над ним как одно целое». только в виде «давайте вот этот участок памяти как бы будет строкой».

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

> на самом деле нет *типов* таких.

Типов "нет", а операции над ними - есть.

> в понимании «тип + операции над  ним как одно целое». только в виде «давайте вот этот участок
> памяти как бы будет строкой».

Ну и договоренности что кончается нулем, тогда уж. Спорный вопрос баг это или фича. В других языках можно натрахаьться с всякой там сериализацией-десереализацией когда захочется суперпуперобъект в файло слить или там по сетке передать. А тут все просто и понятно как раз.

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

Да я заметил - дай волю некоторым урюкам они и демоны на питоне или яве напишут запросто. И ядро бы написали, да кишка тонка.

>> на самом деле нет *типов* таких.
> Типов "нет", а операции над ними - есть.

всё в стиле "вот этот деревянный меч кагбэ Дюрандаль".

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

не всегда. зависит от библиотеки же.

> Спорный вопрос баг это или фича.

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

> всё в стиле "вот этот деревянный меч кагбэ Дюрандаль".

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

>> всё в стиле «вот этот деревянный меч кагбэ Дюрандаль».
> Да и хрен бы с ним :) свое дело делает же.

делает. просто всегда находится удивительный человек, который начинает с умным видом Вещать: «вас обманули, это не Дюрандаль, это обычная деревянная чурка!» а когда ему говорят: «да, мы знаем. и что?» так забавно начинает подпрыгивать и что-то лопотать…

> ему говорят: «да, мы знаем. и что?» так забавно начинает подпрыгивать
> и что-то лопотать…

Какое эпичное описание шаблона :))

> цпп — да. а ц — хороший макроассемблер.

Главное портабельный и высокоуровневый ;-]

> В жабе же (как и в ц++) есть ссылки, поэтому танцев с бубном не надо.  

А знаешь, указатели иногда не лишние, если хочется получить настоящий, неподдельный zero copy во всей красе.  Ну вот висит в памяти чушка, мегабайтов так эн. Пусть мы хотим треть из нее заадресовать. А чтоб без копирования, и только треть? Адресной арифметикой как делать нехрен. А как с этим в яве?

> А как с этим в яве?

Ну так разберитесь как и покритикуйте сравнительно с еще парой языков.

> Ну так разберитесь как и покритикуйте сравнительно с еще парой языков.

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

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

Ну а я ц пользовался. И еще много чем. В этом и разница.

> Ну а я ц пользовался. И еще много чем. В этом и разница.

Судя по тому какую чепуху вы про 100-мерные массивы втерли - быдлокодерствовать в принципе можно даже на си. Только он категорически неудобен для быдлокодинга, поэтому быдлокодеры его не жалуют :)

> Судя по тому какую чепуху вы про 100-мерные массивы втерли

так что ж вы правду то скрывате, поделитесь с цшниками, а то мне созерцать вещи типа int ***array3D = malloc(x * sizeof(int **)) надоело уже

в ц++ хоть можно a[] использовать, но вот a[][] уже нельзя

> в ц++ хоть можно a[] использовать, но вот a[][] уже нельзя

Вазап?! А как же я ими тогда пользуюсь?!?

В гольном си:
uint8_t array[2][3][4][5] - вполне себе 4-мерный массив. Вполне себе валидный. И  sizeof(array) вполне ожидаемый и логичный - 120.

Передается сие _одним_ указателем совершенно без проблем. Потому что физически сие есть одна 120-байтовая структура, которую если хочется можно рассматривать как 4-мерный массив.

А то что вы привели - это указатель на массив указателей. За коим хреном именно так - ну спросите у того кто это придумал, да?

не стоит метать бисер: си оно не знает. подозреваю, что остальных языков, которыми размахивало, тоже.

> В гольном си:  uint8_t array[2][3][4][5] - вполне себе 4-мерный массив. Вполне себе валидный. И  sizeof(array) вполне ожидаемый и логичный - 120.

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

Чисто из жалости даю ссылку
Dynamic Three Dimensional Arrays in C\C++\C#\Java
http://mycodelog.com/2010/05/21/array3d/

>> в ц++ хоть можно a[] использовать, но вот a[][] уже нельзя
> Вазап?! А как же я ими тогда пользуюсь?!?

Естественно a[][] не пользуетесь поскольку язык не позволяет (а я вообще начинаю сомневаится что вы ц когда нибудь видели). И естественно опять не видите элементарного - разницы между пустой скобочкой и с цифиркой внутри. Вы все таки учебник то почитайте. Вместе с коллегами.

Опять только из жалости
http://c-faq.com/~scs/cclass/int/sx9a.html
That is, if we want to leave out any dimensions, we can only leave out the first one:
    func(int a[][7])
    {
    ...
    }
The second dimension is still required. (For a three- or more dimensional array, all but the first dimension are required; again, only the first dimension may be omitted.)

Ну и как последний пост в обучении продвинутых дошкольников

рекомендую сравнить работу с динамическими массива в этих языках

Dynamic Three Dimensional Arrays in C\C++\C#\Java
http://mycodelog.com/2010/05/21/array3d/

с тем как это делается в языках для людей

...
a: array of array of array of data;
SetLength(a, x, y, z);
...

о! ВНИЗАПНА! из рукава добыли «динамические массивы», о которых ранее речь не шла. какой следующий шулерский трюк нас ожидает?

> о! ВНИЗАПНА! из рукава добыли «динамические массивы», о которых ранее речь не  шла. какой следующий шулерский трюк нас ожидает?

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

>uint8_t array[2][3][4][5] - вполне себе 4-мерный массив. Вполне себе валидный. И  sizeof(array) вполне ожидаемый и логичный - 120.

раз вы думаете что в ц sizeof имеет такое уж прямое отношение к типу то будете приятно удивлены (в ц логика видимо неевклидова). Попробуем посмотреть какого типа это образование на самом деле. Делаем присвоение (ц ведь язык типизированный и левое присвоение не сделает, так?)

void* parray = array;

(заметим - не &array а просто array но это если кто понимает разницу, а самое забавное теперь сделать  cout << sizeof(parray) << endl; и сравнить с cout << sizeof(array) << endl и поискать логику)

ну и, вполне ожидаемо и логично (для тех кто ц знает), оказывается что array это такой слегка замаскированный  указатель. А что же sizeof? Ну это костыль такой, и спасибо авторам замечательного языка хоть за него, да. Но кто видел нормальную реализацию массивов тому печально. sizeof ведь тут показывает только полный размер массива, а размер по каждому индексу узнать нельзя увы. такой вот статический "многомерный массив" получается.

> То есть вы с коллегой никогда не имели дела с динамическим массивами,

Это вы, сэр, облажались. В вашем тексте предъяв исходно слово "динамический" нигде не фигурирует. Вы просто обгадили все массивы без разбора, сделав вид что так и надо. А получив контрпример как демонстрацию что вы гонщик - резко вытащили карту из рукава. Нормально придумано!

> но искренне полагаете что с пониманием статических (псевдо)массивов в ц у
> вас все в порядке. Ну что ж посмотрим
>>uint8_t array[2][3][4][5] - вполне себе 4-мерный массив. Вполне себе валидный. И  sizeof(array) вполне ожидаемый и логичный - 120.
> раз вы думаете что в ц sizeof имеет такое уж прямое отношение к типу

Я по-моему не делал таких громких заявлений. sizeof имеет отношение к фактическому размеру некоей сущности в памяти.

> то будете приятно удивлены (в ц логика видимо неевклидова).

???

> Попробуем посмотреть какого типа это образование на самом деле.

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

> Делаем присвоение (ц ведь язык типизированный и левое присвоение не сделает, так?)

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

> void* parray = array;

А тип нового указателя "void" совершенно случайно выбран, а вовсе не для того чтобы всех успешно нае...ть, ну конечно же :)

> (заметим - не &array а просто array но это если кто понимает
> разницу, а самое забавное теперь сделать  cout << sizeof(parray) <<
> endl; и сравнить с cout << sizeof(array) << endl и поискать логику)

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

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

А вы оказывается тоже Капитан?!

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

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

> sizeof ведь тут показывает только полный размер массива, а размер по
> каждому индексу узнать нельзя увы. такой вот статический "многомерный массив" получается.

Зачем искать проблемы на ровном месте там где их нет? Да, на си можно создать себе проблемы если задаться такой целью. Си не защищен от идиотов и никогда таковым не планировался даже в проекте. Приколитесь?! Вы еще в ассемблере защиту от идиотов для самых маленьких потребуйте! Для полного эффекта клоунады.

>> То есть вы с коллегой никогда не имели дела с динамическим массивами,  Это вы, сэр, облажались. В вашем тексте предъяв исходно слово "динамический" нигде  не фигурирует.

в ответ на мой пост 127

>мне созерцать вещи типа int ***array3D = malloc(x * sizeof(int **)) надоело уже

и
>.в ц++ хоть можно a[] использовать, но вот a[][] уже нельзя

Я получаю пост 143

>uint8_t array[2][3][4][5] - вполне себе 4-мерный массив

т.е. очередной цшник не понимает что значат и где применяются абсолютно стандартные вещи типа int ***array3D = malloc(x * sizeof(int **)) или a[] и a[][] ???

>Вы просто обгадили все массивы без разбора, сделав вид  что так и надо. А получив контрпример как демонстрацию что вы  гонщик - резко вытащили карту из рукава. Нормально придумано!

Чего там в примере хорошего. Как ваш массив передать в функцию? Надо передать указатель и ДОПОЛНИТЕЛЬНО размеры массива. Вот и оказывается что массив то не массив, информации для работы с ним в нем недостаточно.

> Я по-моему не делал таких громких заявлений. sizeof имеет отношение к фактическому  размеру некоей сущности в памяти.

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

>> то будете приятно удивлены (в ц логика видимо неевклидова).
> ???

Специально для вас поясню - это шутка юмора.

>> Попробуем посмотреть какого типа это образование на самом деле.
> На самом деле это тупо 120 байтов лежащих в памяти.

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

>При желании повы...ться их можно трансформировать во что угодно и в половине случаев накосячить, если ж-а просит приключений. Вот только зачем это делать?

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

>Нормально, из сей уже без предупреждения получились плюсы,

Да уж cout вместо printf совершенно поменял дело

>> void* parray = array;
> А тип нового указателя "void" совершенно случайно выбран, а вовсе не для  того чтобы всех успешно нае...ть, ну конечно же :)

Да ладно, попробуйте любопытства ради то же не с массивом
int a=5;
void* pa = a;
Что получилось? Ну да это все не баги а фичи конечно же. Чтобы конкурсы устраивать.

> Бухахаха, возможности си по откалыванию подобных фокусов - это не баг, это

О чем и речь. Язык для откалывания фокусов да. Целиком согласен. И в заголовке новости то же самое. Хотелось бы еще чего нибудь для удобного и приятного программирования. Например жаба хоть и вобрала в себя многие недостатки ц, но кое что и исправила. Жаль компилятор к ней так и не написали толком. Ну и алголоподобные языки конечно вещь.

>Си не защищен от идиотов и никогда таковым не планировался даже в проекте. Вы еще в ассемблере защиту от идиотов для самых маленьких потребуйте!

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

>>мне созерцать вещи типа int ***array3D = malloc(x * sizeof(int **)) надоело уже
> и
>>.в ц++ хоть можно a[] использовать, но вот a[][] уже нельзя
> Я получаю пост 143
>>uint8_t array[2][3][4][5] - вполне себе 4-мерный массив

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

> т.е. очередной цшник не понимает что значат и где применяются абсолютно стандартные
> вещи типа int ***array3D = malloc(x * sizeof(int **)) или a[] и a[][] ???

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

> Чего там в примере хорошего. Как ваш массив передать в функцию? Надо
> передать указатель и ДОПОЛНИТЕЛЬНО размеры массива. Вот и оказывается что массив
> то не массив, информации для работы с ним в нем недостаточно.

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

>> Я по-моему не делал таких громких заявлений. sizeof имеет отношение к фактическому  размеру некоей сущности в памяти.
> Некоей сущности. Тогда при чем здесь массив.

Только при том что он тоже сущность и для него sizeof вполне имеет физический смысл.

> Это же должна быть не некая сущность а структура данных с известными параметрами.
> Вся ось это тоже некотрая сущность в памяти.

На самом деле никаких проблем нет. Если некто ведет себя не так как хочется - нет никаких проблем добавить определения и доделать до нужного поведения за 2 минуты и забыть о проблеме как таковой. ИМХО, некоторая "топорность" имеет свои плюсы. Когда структуры простые - их проще сериализовать-десереализовать и это не требует длительного факания мозга вещами типа "размер массива? А какой у него тип, порядок байтов и сколько там вообще байтов надо для описания без потери точности? А сие стандарт или зависит от имплементации языка? Будет ли оно одинаковым на разных системах?".

> Специально для вас поясню - это шутка юмора.

Пятый туз из рукава видимо тоже был своеобразным юмором =)

>>> Попробуем посмотреть какого типа это образование на самом деле.
>> На самом деле это тупо 120 байтов лежащих в памяти.
> О чем и речь. В ц натурально да, массив это не массив а область памяти

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

> (причем даже размер ее не всегда можно определить в принципе).

Ну блин, возьмем и передадим его явно. Если уж приспичило. А вы попробуйте 100-мерный массив в файл слить? Так чтобы было портабельно, компактно и работало везде? В этом случае вы пожалуй еще и спасибо скажете, если все размеры будут не только явно указаны но еще и с явным типом а не какими-то имплементационными допущениями, например - их будет проще в файл заталкивать, заранее понимая - что же мы туда собираемся записать все-таки :)

> Как и строка (что будет если там 0 забудут поставить).

О, я как знал что вы расскажете нам про деревянный меч еще раз. Ну елки, не нравятся тебе строки по дефолту? Сделал свои с шахматами и явной передачей длины, например.
//Кстати arisu получает +5 к скиллу телепатии :)))

> В многих других языках уже давно нет. В той же жабе например.

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

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

Ну так удачи вам написать на яве мультимедиа библы, ядра операционок, системные демоны, программы для сжатия и шифрования и прочее. Особенно прикольно когда рантайм-проверки в тугом цикле все сажают минимум раза в три на ровном месте. А бывает и больше. Достаточно посмотреть как жабист на хабре боролся за скорость. Сплошное садо-мазо по борьбе с зело умным рантаймом и его медвежьими услугами, на фоне которых какая-то там передача длины строки отдельно сбоку - так, мелочь. Товарисч просадил _намного_ _больше_ времени на свои супероптимизации и изучение как этот монстрятник внутри работает чем потребуется для костылирования дописки длины к строке в си. Но у жабабыдлокодеров (не того который с таким ником, тот как раз редкое исключение из правил, а более типичные фрукты типа изена) - брейнфак с дрюканием в профайлере неделями считается "нормальным".

[...]
> Да ладно, попробуйте любопытства ради то же не с массивом
> int a=5;
> void* pa = a;
> Что получилось? Ну да это все не баги а фичи конечно же.

Что получилось? Вы поюзали конструкцию предназначенную как раз для оверрайда типов и нае...лова окружающих (void). Сделали хитровыгнутую операцию. И получили именно нае...лово. Какая неожиданность! А если взять молоток, положить палец на ровную твердую поверхность и как следует е%$#уть по нему молотком - будет больно. Но отсюда не следует что это баг в конструкции молотка. Отсюда следует лишь то что обладатель молотка - дурак, если не способен осознать простейшую причинно-следственную связь между своими действиями и их результатами. А еще иногда и опытный человек может себе по пальцу попасть. Но случайно, редко, и даже не потому что так задумано. И странно из этого делать далеко идущий вывод что молоток - плохой инструмент.

> Чтобы конкурсы устраивать.

Хм, ну если вы не способны придумать более полезных применений - кто ж вам доктор?

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

>> Бухахаха, возможности си по откалыванию подобных фокусов - это не баг, это
> О чем и речь. Язык для откалывания фокусов да. Целиком согласен. И
> в заголовке новости то же самое. Хотелось бы еще чего нибудь
> для удобного и приятного программирования.

Вы так говорите как будто к вам пришел надзиратель и под страхом расстрела запретил вам использовать ЯП кроме си.

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

Только я никогда не смогу ее попросить "запиши мне байт X в адрес Y. А теперь байт Z в адрес K. А теперь вот так. А теперь шлем в флешку по адресу N блок данных ращмером M, потому что режим программирования - активирован!". На яве такое сделать тупо нельзя. Как максимум через нативные костыли (на презренном си, лол).

> Жаль компилятор к ней так и не написали толком.

На ней еще и программ толком нет. Несколько энтерпрайзных хреновин для серверов за многие килобаксы. И ... все.

> Ну и алголоподобные языки конечно вещь.

Вообще-то, си вполне хорош в энном количестве ниш и лучше просто не смогли сделать. Вот в этих алголоподобных без этой указательной арифметики - можно сделать не абстрактное оперирование с массивом, а вполне конкретный доступ к памяти по конкретному адресу, например? Если нет - так это вообще не проканает как ЯП для системного программирования, embedded и прочая, например.

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

...которые в половине случаев фичи а не баги :)

> говорю где они устранены.

Угу. В той же яве устранены указатели и работа с ними. Только вот иногда фича превращается в эпик фэйл. Поэтому вы никогда не сможете инициировать магическую последовательность байтов в флешку обеспечивающих стирание сектора и его перепрограммирование на яве без изобретения дичайших костылей, например. Поэтому яве в принципе не светит стать ЯП для системных применений, например. От нее там один гемор будет и никакого профита. А на асме такое выписывать - тоже не очень то прикольно, да?

> И сам стараюсь ц не пользоваться по мере сил.

Who the f...ly cares? Если вы тупой, объясняю: в некоторых случаях _единственной_ альтернативой является гвоздеж на чистокровном асме. А сие не портабельно и довольно утомительно. И никакая ява не является в этом случае эквивалентной заменой, да?

> Вот в этих алголоподобных без этой указательной арифметики - можно сделать не абстрактное оперирование с массивом, а вполне конкретный доступ к памяти по конкретному адресу, например? Если нет - так это вообще не проканает как ЯП для системного программирования, embedded и прочая, например.

Модула 3

> Модула 3

Угу, ну допустим я хочу собрать программу под микроконтроллер, допустим, STM32. Мои действия?

> Ну и алголоподобные языки конечно вещь.
>Вообще-то, си вполне хорош в энном количестве ниш и лучше просто не смогли сделать. Вот в этих алголоподобных без этой указательной арифметики - можно сделать не абстрактное оперирование с массивом, а вполне конкретный доступ к памяти по конкретному адресу, например? Если нет - так это вообще не проканает как ЯП для системного программирования, embedded и прочая, например.

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

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

>> В жабе же (как и в ц++) есть ссылки, поэтому танцев с бубном не надо.
> А знаешь, указатели иногда не лишние, если хочется получить настоящий, неподдельный zero
> copy во всей красе.  Ну вот висит в памяти чушка,
> мегабайтов так эн. Пусть мы хотим треть из нее заадресовать. А
> чтоб без копирования, и только треть? Адресной арифметикой как делать нехрен.
> А как с этим в яве?

Вот, висит в памяти чушка типа java.util.BitSet, мегабайтов так эн.
Дальше сами: http://download.oracle.com/javase/6/docs/api/java/util/BitSe...

> Вот, висит в памяти чушка типа java.util.BitSet, мегабайтов так эн.

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

если правильно класс сделан - просто

> Да и мозг уже поражен.

Мужики, вам не надоело ещё кидалиями фекаться, сравнивая торпеду с бульдозером?

> Почему? Java - прямой потомок C по синтаксису.

Только по самым примитивным (и неудачным) конструкциям.

К сожалению, - да.

> жабакодер в состоянии разобраться в коде на C

в 90% случаев у него взрывается череп, как только дело доходит до указателей. а уж если там хитрые преобразования типов и указатели-на-указатели-на — то смерть почти гарантирована. проверено электричеством^w личным 10-летним опытом собеседований с укушеными жабой.

> указателей. а уж если там хитрые преобразования типов

Да уж преобразования типов это атас - 1 поделить на 3 по умолчанию равно 0. Ну всем же понятно что не в 1/3 это же преобразовывать надо.

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

>  а в том, что жабисты  опупевают.

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

> (а что, в жабе деление двух интов не инт даёт разве?

А чего мне жаба то. Они там многие ц глупости старательно повторили.

> А чего мне жаба то. Они там многие ц глупости старательно повторили.

можно посмотреть хотя бы на concept твоего крутого языка без «глупостей»? действительно, интересно. хотя бы концепт, без реализации.

> можно посмотреть хотя бы на concept твоего крутого языка без «глупостей»? действительно,  интересно. хотя бы концепт, без реализации.

Концепты правильного подхода к программированию были реализованы в Алголе. Но потом линия ц подобных языков получила большее распространение. А алголоподобные языки затормозились в развитии, практически остался только объектный паскаль. В результате имеем что имеем. 99% Багов рапортуемых на опеннете на совести плохих языков.

ясно. «бла-бла-бла» и императивщина. скука. я думал, интересней будет.

> ясно. «бла-бла-бла» и императивщина. скука. я думал, интересней будет.

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

а так типа вот сейчас заменим ц хаскелем да? и будем теперь получать удовольствие от ситнтаксиса типа   inc :: Integer -> Integer или take n (x:xs) = x : take (n-1) xs

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

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

> 99% Багов рапортуемых на опеннете на совести плохих языков.

Плохим танцорам почему-то всегда что-то мешает :). Можно подумать что дай другой язык - ошибок бы не стало. Агащазблинужетрираза. Ну вон веб взять. что, нет переполнений буфера? Зато sql injection, xss, csrf, php-injection и прочее. И по-моему, левый платеж через пэйпэл на штуку баксов за счет XSS - пострашнее иного buffer overflow, пожалуй...  

>> 99% Багов рапортуемых на опеннете на совести плохих языков.
> Плохим танцорам почему-то всегда что-то мешает :). Можно подумать что дай другой
> язык - ошибок бы не стало. Агащазблинужетрираза.

ну естественно стало бы меньше, откуда сомнения то?

>Ну вон веб взять.  что, нет переполнений буфера? Зато sql injection, xss, csrf, php-injection и  прочее. И по-моему, левый платеж через пэйпэл на штуку баксов за

счет XSS - пострашнее иного buffer overflow, пожалуй...

ну так вы веб языки то видели? жабоскрипт и то страшнее жабы, а уж пых

> жабоскрипт и то страшнее жабы

…потому что я его не знаю.

> ну естественно стало бы меньше, откуда сомнения то?

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

>> счет XSS - пострашнее иного buffer overflow, пожалуй...
> ну так вы веб языки то видели? жабоскрипт и то страшнее жабы, а уж пых

Да какой ни дай обезьянам в руки - результат будет одинаковый. Ну вон борландпаскальские проги любили валиться с рантайм еррор 200 - как серпом по йайцам. Это было чем-то лучше?

> Да какой ни дай обезьянам в руки - результат будет одинаковый. Ну вон борландпаскальские проги любили валиться с рантайм еррор 200 - как серпом по йайцам. Это было чем-то лучше?

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

> Т.е. это и не ошибка даже, а просто отсутствие машины времени у разаботчиков.

Слышал, но уже не интересовался, в чём именно было дело.  Тем не менее как внедренец считаю, что это именно ошибка разработчиков, думавших в стиле "да какая разница".

> Думаете через 10 лет все нынешние программы заработают?

Думаю, что у меня специально с 2002 года захолдена сборка yacas, которая до сих пор работает.  Также и приличный рантайм вроде тиклёвого не позволял себе таких развалов, не говоря уже вот про тот самый с круглыми скобочками (где из конфузов сходу припоминается разве что исходно жёстко 32-битный picolisp). :)

Просто в досово-виндовом мире культура думать про послезавтра не наработана в сравнении с приличным миром: или "640k хватит всем", или вообще "да что чинить, наступят -- новую версию придут покупать"... вот в итоге и получаются то массово прибитые в структуры данных и логику 32 бита, то предположения о том, что раз в win95 разрешено всё, то и всегда так будет.  Понятно, что шишки учат, но эффективность процесса удручающе низка.

>> Т.е. это и не ошибка даже, а просто отсутствие машины времени у разаботчиков.
> Просто в досово-виндовом мире культура думать про послезавтра не наработана в сравнении

с приличным миром: или "640k хватит всем"

Когда писался дос единственным доступным по цене приличным процом был 8086/88 адресовавший 1МБ (а реально на машинках было не более 64-256К) и то 64КБ сегментами, и с 16 разрядными регистрами. Они что должны были в ДОС программную виртуальную 32-разрядную адресацию заложить что ли? И с какой скоростью бы это все работало на 4.77 МГц? Не мне такого не надо было. Причем мелкомягкие как раз много лет пытались пропихнуть юникс на писи http://en.wikipedia.org/wiki/Xenix и что?

>Понятно, что шишки учат, но эффективность процесса удручающе низка.

Не хотелось бы разводить очередной красноглазый флейм. А так про эффективность много где можно много чего сказать.

>>> Т.е. это и не ошибка даже, а просто отсутствие машины времени у разаботчиков.
>> Просто в досово-виндовом мире культура думать про послезавтра не наработана
>> в сравнении с приличным миром: или "640k хватит всем"
> Когда писался дос

Напомню, в девичестве -- QDOS, quick and dirty OS.  На деле тоже ни разу не OS, а скорее монитор файловой системы навроде того же CP/M (одним из частичных следствий этого является то, что софт был вынужден таскать драйвера к оборудованию свои и с собой).

> единственным доступным по цене приличным процом был 8086/88 адресовавший 1МБ
> (а реально на машинках было не более 64-256К) и то 64КБ сегментами,
> и с 16 разрядными регистрами. Они что должны были в ДОС программную виртуальную
> 32-разрядную адресацию заложить что ли?  И с какой скоростью бы это все работало
> на 4.77 МГц?

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

Вопрос не в том.  Если задуматься, то PDP-11 были намного слабее железом, чем даже ЕС1841 (с 512К и если верно помню замеры -- то двумя мегагерцами тактовой).  Но там люди думали надолго, а не чтоб только конкуренцию шкафам не создать (одни) и впарить быстрей-быстрей, пока про мамочку не передумали (вторые).

> Причем мелкомягкие как раз много лет пытались пропихнуть юникс на писи [...] и что?

Ну они и ФП в CLR попытались запихнуть с не менее слоновьей грацией.

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

Похвально, вот и не разводите.

> Вопрос не в том.  Если задуматься, то PDP-11 были намного слабее  железом, чем даже ЕС1841 (с 512К и если верно помню замеры - то двумя мегагерцами тактовой).

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

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

Результат их раздумий известен. Результат раздумий других тоже. Вы на нем сейчас их же и критикуете. Это тоже для красноглазых типично.

>> Не хотелось бы разводить очередной красноглазый флейм.
> Похвально, вот и не разводите.

Я не могу разводить красноглазый флейм. Это по вашей части.

>> Вопрос не в том.  Если задуматься, то PDP-11 были намного слабее  железом,
>> чем даже ЕС1841 (с 512К и если верно помню замеры - то двумя мегагерцами тактовой).
> Да были слабее. Потому их и выкинули на помойку как только появилась альтернатива.

На минуточку: сколько у Вас на хозяйстве кода, унаследованного от разработок для вот тех (не 386-х даже) писишек, и сколько -- от тех PDP-шек?  У меня с ощутимым перевесом последний берёт, IMHO.

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

Промахнулись, рост писишек как платформы всё-таки в существенной мере определялся открытостью архитектуры.  Интересно, если бы IBM решила правдами или неправдами замочить тот реверс-инжиниринг BIOS -- что бы получилось? (по PS/2 судить сложно, их и одна закрытая MCA могла угробить)

>>> Не хотелось бы разводить очередной красноглазый флейм.
>> Похвально, вот и не разводите.
> Я не могу разводить красноглазый флейм.

Тем вульгарней, когда разводите.

Спокойной ночи :)

> На минуточку: сколько у Вас на хозяйстве кода, унаследованного от разработок для  вот тех (не 386-х даже) писишек, и сколько -- от тех PDP-шек?  У меня с ощутимым перевесом последний берёт, IMHO.

О чем вы? Если код на ЯВУ то откуда и куда он наследуется?

> Промахнулись, рост писишек как платформы всё-таки в существенной мере определялся открытостью  архитектуры.  Интересно, если бы IBM решила правдами или неправдами замочить  тот реверс-инжиниринг BIOS -- что бы получилось? (по PS/2 судить сложно,  их и одна закрытая MCA могла угробить)

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

А дос сделал эти процы общедоступными с программной точки зрения.

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

> Слышал, но уже не интересовался, в чём именно было дело.  Тем
> не менее как внедренец считаю, что это именно ошибка разработчиков, думавших
> в стиле "да какая разница".

Это был эпичный по тупизне баг. Господа не думали бошкой и мысли не допускали что процессоры бывают с разной производительностью. Поэтому они, если не ошибаюсь, вычисляя задержку для калибровки функции delay() - делили на величину которая уменьшается по мере увеличения скорости процессора. И вот однажды, когда процессоры стали достаочно быстрые, величина стала достигать нуля и конечно же случалось деление на ноль, известное как runtime error 200. На самом деле - тупейший баг разработчиков и просто стратегическая недальновидность в алгоритме.

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

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

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

> а уж как тупы были авторы юникса, выделяя на время всего 32 бита!

Я думаю что мы еще ощутим это на своей шкурке. С IPv4 кстати уже ощущаем - адресов на всех не стало хватать.

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

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

> а то, что народ умудрился понаписывать софта, который перестал сопровождать
> и не дал исходников — это тем более никак не проблемы борланда.

Я что-то не помню, а сам борланд то давал сорц на этот модуль? Что-то я не припоминаю сырцов служебных модулей в дефолтной поставке компилера.

> что они станут. Т.е. это и не ошибка даже, а просто
> отсутствие машины времени у разаботчиков.

Ага, вполне предсказуемое деление на ноль - это ну совсем не баг. Наверное, фича.

> Думаете через 10 лет все нынешние программы заработают?

Я вот тут LZ на сях из каких-то древних 80-х скомпилил. Заработало.

> Кстати библиотека потом была выпущена подправленая. И достаточно было перекомпилировать.

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

> Но это уже никого особо не интересовало т.к. досовские
> программы к тому времени уже были малопопулярны.

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

> Да уж преобразования типов это атас - 1 поделить на 3 по
> умолчанию равно 0.

Не, конечно, пусть нам флоатов без спроса воткнут. Особенно в какихнить микроконтроллерах где и FPU то нету. Си это системный язык. Поэтому он предсказуем, бл. А не как ява - 2 запуска из 5 сглючило? Идем сдавать заказчику!

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

>утечки памяти

Ты полагаешь, что в Яве нет утечек памяти?

> Ты полагаешь, что в Яве нет утечек памяти?

он их не видит — значит, нет.

> он их не видит — значит, нет.

Там можно иногда отбрехаться что это все сборщик мусора виноват :)))

>> он их не видит — значит, нет.
> Там можно иногда отбрехаться что это все сборщик мусора виноват :)))

ага. не умеет, падла, телепатически определять, что эта куча заякорена, но уже никому не нужна.

> ага. не умеет, падла, телепатически определять, что эта куча заякорена, но уже
> никому не нужна.

Ну вот как-то так у них обычно и получается. А потом они неделями дрюкаются с профилированием,  пытаясь понять где же случилась Ж, когда кастомер (окружение которого конечно же не соответствует тому что представлял себе программист) начинает срать кирпичами когда на супермощном сервере вдруг каким-то хреном все-равно кончается память, несмотря на то что GC умный и все дела.

это, кстати, отчасти вина мифотворцов жабы. которые убедили обезьян, что «в жабе памятью управлять не надо, а освобождать — тем более!» в итоге обезьянки и не освобождают, оставляя висеть никому не нужные заякореные объекты, заместо аккуратно чистить за собой ссылки. пропаганда такая пропаганда.

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

> это, кстати, отчасти вина мифотворцов жабы. которые убедили обезьян, что «в жабе
> памятью управлять не надо, а освобождать — тем более!» в итоге
> обезьянки и не освобождают, оставляя висеть никому не нужные заякореные объекты,
> заместо аккуратно чистить за собой ссылки. пропаганда такая пропаганда.

Даже хуже - эти обезьяны искренне полагают что думать за них должен рантайм. А им можно программить абы как. Что получается на выходе - несложно догадаться. Лютейший энтерпрайз. Которому какиенить там 8 ядер и 64Г оперативы - вообще не сервер! Replace and press any key when ready!

зато их пучок за пятачок. заартачатся — можно всех скопом выгнать и набрать новых, всё равно сакральным знанием о системе обладает один Гуру на всю контору. а code monkeys на любом углу за досирак готовы драться до смерти. в принципе, как раз нормальный цикл работы для жабоконторы, видел неоднократно.

> Да, конечно. Не подскажете, заодно, где есть переполнение строк, утечки памяти и
> неверная адресация, а где нет?

В ява программах утечек памяти - как грязи. И в C# - тоже. Просто они становятся настолько неочевидны, а программы и сами по себе жрут столько что бороться с ними вообще не считают нужным. Просят докупить оперативы, это у жабистов традиционно :). Ну и иногда перезапускайте, дескать, наш кульный ынтерпрайз. Видели мы такие поделия. И старательно обходим эти отходы мозговой деятельности за километр.

>> Да, конечно. Не подскажете, заодно, где есть переполнение строк, утечки памяти и
>> неверная адресация, а где нет?
> В ява программах утечек памяти - как грязи. И в C# -
> тоже. Просто они становятся настолько неочевидны, а программы и сами по
> себе жрут столько что бороться с ними вообще не считают нужным.

Бред. Для отслеживания утечек памяти в Java давно используют профилировщики, а кто не использует, те "Просят докупить оперативы, это у [горе-]жабистов традиционно :). Ну и иногда перезапускайте, дескать, наш кульный ынтерпрайз."

> Видели мы такие поделия. И старательно обходим эти отходы мозговой деятельности за километр.

Мы тоже. Обжегшись на молоке — дуют на воду.

> Бред. Для отслеживания утечек памяти в Java давно используют профилировщики

…а в си профилировщики используют по назначению: для построения профилей и оптимизации. опять в жабе всё не через то отверстие.

кстати, для си есть valgrind, например.

>> Бред. Для отслеживания утечек памяти в Java давно используют профилировщики
> …а в си профилировщики используют по назначению: для построения профилей и оптимизации.
> опять в жабе всё не через то отверстие.
> кстати, для си есть valgrind, например.

http://habrahabr.ru/blogs/java/61857/
http://www.ibm.com/developerworks/ru/edu/os-ecl-tptp/index.html

http://www.youtube.com/watch?v=b-Cr0EWwaTk

и в чём это должно было меня убедить? в том, что жабисты cannot into термины? так это давно уже не новость. у них и место, откуда их руки растут, до сих пор «плечи» называется.

> Бред. Для отслеживания утечек памяти в Java давно используют профилировщики,

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

> а кто не использует, те "Просят докупить оперативы, это у [горе-]жабистов традиционно :).
> Ну и иногда перезапускайте, дескать, наш кульный ынтерпрайз."

Ну да, ну да, конечно же. А чем это все лучше валгриндинга сишной проги, интересно? "Потому что ява", да? :)))

> Мы тоже. Обжегшись на молоке — дуют на воду.

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

> Ну да, ну да, конечно же. А чем это все лучше валгриндинга
> сишной проги, интересно?

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

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

В этом месте жабисты по сценарию орут "Это не нужно!!!111" ;)

у них это есть

> у них это есть

rotfl.

Между прочим, практически все современные дистрибутивы проводят аналогичное соревнование для языка bash/sh среди своих разработчиков.
Конкурсные работы хаотично разбрасываются по ФС, но лучшие среди них (финалисты) обычно собраны в специальном каталоге /etc/rc./init.d

> каталоге /etc/rc./init.d

То ли я очепятался, то ли движок букву d сожрал =(

>> каталоге /etc/rc./init.d
> То ли я очепятался, то ли движок букву d сожрал =(

Да нет, как Вы могли опечататься.  Конечно, это всё движок, httpd, браузер, клавиатура и хромая память.

А локальные финалисты скорее в /opt и /usr/local у тех, кто занимается научным софтом -- в инитскриптах извраты бывают, но дистрибутивов с систематически особо жестокими пока не встречал вроде.

Но сравнивать языки с автоматическим и прямым управлением памятью тут и впрямь некорректно...

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

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

Это где?

% cat /usr/local/etc/rc.d/hald
#!/bin/sh
#
# $FreeBSD: ports/sysutils/hal/files/hald.in,v 1.11 2010/05/10 21:18:39 kwm Exp $
#   $MCom: ports/sysutils/hal/files/hald.in,v 1.22 2010/04/17 19:05:10 marcus Exp $
#
# PROVIDE: hald
# REQUIRE: DAEMON usbd devd dbus moused webcamd
#
# Add the following line to /etc/rc.conf to enable the HAL daemon:
#
# hald_enable="YES"
#

. /etc/rc.subr
. /usr/local/etc/gnome.subr

hald_enable=${hald_enable-${gnome_enable}}
hald_flags=${hald_flags-""}

name=hald
rcvar=`set_rcvar`

command="/usr/local/sbin/hald"
pidfile="/var/run/${name}/${name}.pid"

stop_postcmd="hald_postcmd"
start_precmd="hald_precmd"
start_cmd="hald_start"

local_force_depend()
{
    _depend="$1"
    if [ -f /usr/local/etc/rc.d/${_depend}.sh ]; then
    _depend="${_depend}.sh"
    fi

    if ! /usr/local/etc/rc.d/${_depend} forcestatus 1>/dev/null 2>&1 &&
       ! /usr/local/etc/rc.d/${_depend} forcestart; then
       return 1
   fi
   return 0
}

hald_precmd()
{
    if ! checkyesno dbus_enable
    then
    local_force_depend dbus || return 1
    fi

    chmod 0755 /var/cache

    mkdir -p $(dirname $pidfile)
}

hald_postcmd()
{
    rm -f $pidfile
}

hald_start()
{
    if ! checkyesno hald_enable ; then
    return 0
    fi
    echo "Starting ${name}."

    ( iter=0
    while ! ps -axoargs | grep "^/usr/libexec/getty " | grep -qv grep >/dev/null 2>&1; do
    if [ ${iter} -eq 60 ]; then
        break
    fi
    sleep 1
    iter=$(expr ${iter} + 1)
    done
    ${command} ${hald_flags} ) &
}

load_rc_config ${name}
run_rc_command "$1"

М-де, уныло выглядит.
Особенно на фоне моего конфиг-файла для апстарта где в целых ~7 строк уместилось:
1) Рестарт сервиса при внезапном завершении.
2) Лимитирование числа рестартов в единицу времени.
3) Старт только после того как появилась сеть.
4) Сервису выставляется приоритет повыше фоновых задач т.к. с именно оным юзер и работает и его время отклика роялит.

> Особенно на фоне моего конфиг-файла для апстарта

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

>> Особенно на фоне моего конфиг-файла для апстарта
> Нехорошо смеяться над паровозом, едучи на "сапсане". Другой век, другие технологии.
> Управление службами через init-скрипты сейчас осталось лишь темной тенью прошлого.
> Но тогда, тридцать-сорок лет назад, это был самый простой и логичный путь.

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

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

Если человек в 2011 году гордится init-скриптами, то это со всей очевидностью означает, что он сильно отстал от реалий нашей жизни. Смотрели такой старый французско-итальянский фильм - "Замороженный"?
Нехорошо над такими людьми смеяться.

Пока вы так говорите Fedora допиливают до состояния Unix v6(недавняя ссылка про /usr/bin и прочие), а гном - в отдельную ОС

> старый французско-итальянский фильм - "Замороженный"?

Только вот тут никого не замораживали, поэтому политкорректнее будет термин "заторможенный".

мы уж как-нибудь пешком постоим, без монстрософта.

> самый аццкий тип инитскриптов ...

Пока самый ацкий я виде в VMware Server 1.0.2

> Да нет, как Вы могли опечататься.  Конечно, это всё движок, httpd, браузер, клавиатура и хромая память.

Спасибо, зело утешили старого дурака...

> А локальные финалисты скорее в /opt и /usr/local у тех, кто занимается научным софтом

Где вы такой софт берете? Глянул стартовый скрипт матлаба - вполне себе красиво написано, с исчерпывающими комментариями.
А вот ловля багов в init-скриптах и сочинение новых по образцу, в свое время немало нервных клеток отняли, что в рхеле, что в дебиане.

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

> На шелле можно вполне себе структурно писать. С комментами и подпрограммами. А  не как обдолбавшийся упоротый упырь из Бхопала.

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

> На шелле можно вполне себе структурно писать. С комментами и подпрограммами.

Можно, не спорю.
Но использовать shell для управления службами - это все равно что пытаться впихнуть PHP там, где нужен Prolog. Поэтому init-скрипты практически всегда выглядят ужасно.

> Но использовать shell для управления службами - это все равно что пытаться
> впихнуть PHP там, где нужен Prolog. Поэтому init-скрипты практически всегда выглядят
> ужасно.

может быть, ты просто писать их не умеешь?

#!/bin/sh
RCL_SHORTNAME="pop3 daemon"
RCL_LONGNAME="POP3 mail service daemon"
RCL_START="S:/usr/local/sbin/popa3d -D"
RCL_STOP="K:popa3d"
RCL_STATUSCHECK="F:popa3d"
. /etc/rc.d/rc.util/rclib.sh

вот что тут ужасного? вся рутина делается одной библиотекой, которой достаточно скормить параметры. я это написал лет пять назад или даже больше, и с тех пор библиотеку не трогал. при этом на любую мою новую систему библиотека накатывается путём копирования /etc/rc.d/rc.util/. не требует ничего, кроме sh и стандартных утилит. ЧЯДНТ?

> инит-скрипты можно так писать.

Угу, глядя как 2 страницы текста делают то же что 5-7 тривиальных строк в конфиге запускалки сервисов, понимаешь что можно != нужно.

>> А локальные финалисты скорее в /opt и /usr/local у тех, кто занимается научным софтом
> Где вы такой софт берете?

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

> Глянул стартовый скрипт матлаба - вполне себе красиво написано

Видимо, всё-таки математика и годы дают знать. :)

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

>(взято из википедии) Ларри Уолл (англ. Larry Wall) — американский программист. Знаменит как создатель языка программирования Perl. Лингвист по образованию. Уолл — автор клиента Usenet и широкоиспользуемой программы patch. Он дважды побеждал в международном конкурсе запутанного кода на языке программирования Си (IOCCC) и был лауреатом первой награды Free Software Foundation за продвижение свободного программного обеспечения (Free Software Foundation Award for the Advancement of Free Software) в 1998 году.

Надо быть каким-то особенным чтобы делать особенные вещи. Ларри Уолл и его детище в виде ЯП Perl тому пример. Где-то рядом есть смысл конкурса IOCCC.

Ларри, кстати, был участником. и по-моему, даже неоднократно.

Кому-то не дает покоя слава однострочника на перл? Это шанс проявить себя :)))

Вот кстати годный номинант на премию накопался:
http://habrahabr.ru/blogs/compilers/116301/#comment_3773449

Правда байтов на 200 не влазит в лимит вроде, но при желании это видимо решаемо.

Варнинг: чтение таких сырцов не рекомендуется людям со слабой психикой.

удалить ряд дефайнов и пробелов...

> удалить ряд дефайнов и пробелов...

Переписать в английский вариант. Хотя на русском честно говоря лучше смотрится. Этакий 1С из си++ сделали :)

> удалить ряд дефайнов и пробелов...

пробелы там не считают.

Где-то видел вариант про Ленина и революцию. Такой код вставляет гораздо сильнее.

> Где-то видел вариант про Ленина и революцию. Такой код вставляет гораздо сильнее.

Кейворды для поиска?!

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

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

Песочницы и отладчики никто не отменял.

> Песочницы и отладчики никто не отменял.

А прикинь неочевидный кусок срабатывает чисто рандомно и не чаще раза в 2 месяца? Упухнешь же ожидать такого счастья :)

> 1991 ant    compressed vi-like editor
> 1993 ant    egrep utility with Posix-like documentation
> 1996 august    Subset of C compiler and byte code interpreter
> 1998 banks    A flight simulator!
> 2001 anonymous    optimizing dynamic binary translator, x86 progs on any host
> 2004 anonymous    Rendering of a stroked font

4 килобайта вы говорите?

>> 1991 ant    compressed vi-like editor
>> 1993 ant    egrep utility with Posix-like documentation
>> 1996 august    Subset of C compiler and byte code interpreter
>> 1998 banks    A flight simulator!
>> 2001 anonymous    optimizing dynamic binary translator, x86 progs on any host
>> 2004 anonymous    Rendering of a stroked font
> 4 килобайта вы говорите?

Это вам не интерпретируемые языки, с сборщиками мусора, байткодами и виртуальными машинами.
Особо упоротые^W упорные делают на assembler программы с 3d роликами, которые весят 75 кб.

>>> 1991 ant    compressed vi-like editor
>>> 1993 ant    egrep utility with Posix-like documentation
>>> 1996 august    Subset of C compiler and byte code interpreter
>>> 1998 banks    A flight simulator!
>>> 2001 anonymous    optimizing dynamic binary translator, x86 progs on any host
>>> 2004 anonymous    Rendering of a stroked font
>> 4 килобайта вы говорите?
> Это вам не интерпретируемые языки, с сборщиками мусора, байткодами и виртуальными машинами.
> Особо упоротые^W упорные делают на assembler программы с 3d роликами, которые весят
> 75 кб.

Особо упоротые^W упорные на Assembly-91 и в 5Кбайт демки впихивали.

"Мне не хватало байта. Всего одного. Да, да. Того самого, что из восьми бит состоит. Что? Hет, я не псих, хотя одному богу известно, сколь тонкой была граница отделявшая меня от этого состояния. Hо все по порядку..."
Читать далее: http://wasm.ru/article.php?article=onebyte

> Читать далее: http://wasm.ru/article.php?article=onebyte

Ты, овощ, никогда не испытывал этого ощущения. А я вот однажды ощутил это на себе, пытаясь реализовать не совсем тупой алгоритм в 254 байтах (больше передавать протокол не позволяет).

>> Читать далее: http://wasm.ru/article.php?article=onebyte
> Ты, овощ, никогда не испытывал этого ощущения.

Это ты телепатически обнаружил?

Успокойся — я на «Электроника МК 61» делал то, чему не хватало жалких двух-трёх "шагов программы". :) Но каждый раз испытывать оргазм от решения очередной "проблемы одного байта" — ни сил, ни времени, ни желания на это уже НЕ_ХОЧЕТСЯ тратить. :)) Память больше не ресурс — и точка!

> В 1992 году Java не было по объективным причинам. Пришлось осваивать обратную
> польскую запись и вычисления на стеке. ;)

Что-то поздно ты ручник отпустил. В 1992 году уже были нормальные компьютеры, доступные простым смертным. Даже IBM PC совместимые уже были, хоть и дорогие, падлы.

> Успокойся — я на «Электроника МК 61» делал то, чему не хватало
> жалких двух-трёх "шагов программы". :)

На совецком программируемом пепелаце^W планетоходе 16 шагов программы вообще почему-то по жини не хватало. Правда он был не полным по тюрингу - переходов не было, поэтому условия отработать было низзя ;(

>> Успокойся — я на «Электроника МК 61» делал то, чему не хватало
>> жалких двух-трёх "шагов программы". :)
> На совецком программируемом пепелаце^W планетоходе 16 шагов программы вообще почему-то
> по жини не хватало. Правда он был не полным по тюрингу
> - переходов не было, поэтому условия отработать было низзя ;(

Ты действительно понимаешь, о чём говоришь?
«Электроника МК 61» это вот: http://ru.wikipedia.org/wiki/Электроника_МК-61
Всё там было: и безусловные переходы, и условные переходы, и косвенные переходы.

> Ты действительно понимаешь, о чём говоришь?

Да, я понимаю. Совеццкая промышленность где-то в 80х каким-то чудом освоила выпуск вот такого архиэпичного (для промышленности СССР) пепелаца: http://abandongames.ru/images/articles/big_track/02.jpg

У него внутри был какой-то довольно самобытный проц с масочным ROM, но главное - оно позволяло напрограммить 16 шагов программы в RAM. И далее эта хрень могла их отпедалить, спокойно заложив маршрут из комнаты в комнату под управлением свеженаписанной программы без участия в процессе человеков, что вызывало у впервые видящих этот пепелац неслабый а**й :). В комплект также входил "типа дебагер", как то возможность пошагового теста программы и стирания последнего шага, если результат его тестирования не доставил. Так можно было отладить пошагово программу и далее вполне эпично запускать девайс по заданному маршруту.

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

Из наиболее очевидных упущений:
1) У "системы команд" не было условий. Совсем. И замер передвижений был крайне тупой - мерялись обороты колес герконами, а не сколько фактически проехал этот пепелац. Поэтому любопытный субъект возжелавший посмотреть "что это за фигня? само ездит без участия человека?!" и схапавший пепелац под мышку - портил всю логику программы %(
2) В 16 шагов сложная программа не лезла - пичаль для любителя сгонять в соседнюю комнату, посигналить и вернуться назад. Вот там была оптимизация, да.  
3) Совеццкие моторчики то еще г-но и такую дуру катали с большим напрягом.
4) Зато батарейки жрались хорошо и много. Управляющая электроника с удовольствием гробила убогенькие советские "кроны", да и огроменных 373 в ходовой части не так уж и надолго хватало. А покупать столько батареек (4 х "373" aka size D + "крона") - сплошной разор. Не говоря о том что сам пепелац стоил диковато, но даже это не смущало - урвать его было редким везением. Страна инженеров любила неведомые программируемые пепелацы. Даже за дикую цену, впрочем, в ссср вообще любая электроника стоила диковато :)

> «Электроника МК 61» это вот: http://ru.wikipedia.org/wiki/Электроника_МК-61
> Всё там было: и безусловные переходы, и условные переходы, и косвенные переходы.

Зато там 105 шагов программы аж. После 16 - это вообще шикарно, я бы сказал :))). Система команд у МК-61 и правда довольно шибанутая. А еще он жрал батарейки как свинья помои (спасибо вакуумно-люминесцентному индикатору) а энергонезависимой памяти или хотя-бы режима сна - не имел. Был конечно еще и блок питания (кстати, импульсные БП в ссср тоже не умели делать и схема БП была весьма ламерской) но на нем постоянно то сидеть не будешь же - мобильность теряется (впрочем с учетом галимости советских батареек запас оной измерялся единицами часов за которые надлежало вбить и отладить программу и что-то еще и успеть посчитать, что было еще той попаболью).

Но HDTV, HDTV то хоть было или тоже нет? И с сесом как? Был доступен избранным, кто был дипломатом?

Специально для тебя, шибанутый побаболь луркосос обыкновенный, есть гугл. Набери там "Попасть в "бейсбольный мяч" в космосе" или система A135.

> в "бейсбольный мяч" в космосе" или система A135.

Мы уже не попали в Фобос, который покрупнее бейсбольного мяча раз так в эн ;(

>> в "бейсбольный мяч" в космосе" или система A135.
> Мы уже не попали в Фобос, который покрупнее бейсбольного мяча раз так
> в эн ;(

А это уже как раз к СССР и не относится, а касается нынешних засранцев...

> Да, я понимаю. Совеццкая промышленность где-то в 80х каким-то чудом освоила выпуск
> вот такого архиэпичного (для промышленности СССР) пепелаца:

Да ладно опускательством-то заниматься.  Пепелац стоил рублей двести IIRC, правда...

> 3) Совеццкие моторчики то еще г-но и такую дуру катали с большим напрягом.

Ну конечно, а авиамоделисты и прочие пилившие да разгонявшие ДП-3 (или МП-3? цилиндрик металлический, штатное напряжение 3В, штатные обороты что-то около 3000/мин) до чуть ли не 12В и дикой тяги?  Во, порылся в старых запасах -- ДИ1-2, 5000 ОБ/МИН, 1Р-22К.

> 4) Зато батарейки жрались хорошо и много. Управляющая электроника с удовольствием
> гробила убогенькие советские "кроны"

Нормальные солевые батарейки, eastpower рядом не валялся.

> А покупать столько батареек (4 х "373" aka size D + "крона") - сплошной разор.

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

> Был конечно еще и блок питания (кстати, импульсные БП в ссср
> тоже не умели делать и схема БП была весьма ламерской)

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

>> Да, я понимаю. Совеццкая промышленность где-то в 80х каким-то чудом освоила выпуск
>> вот такого архиэпичного (для промышленности СССР) пепелаца:
> Да ладно опускательством-то заниматься.

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

>   Пепелац стоил рублей двести IIRC, правда...

А мне что-то казалось что рублей 40, что впрочем тоже было о-го-го (около 1/5 зарплаты отличного советского инженера).

>> 3) Совеццкие моторчики то еще г-но и такую дуру катали с большим напрягом.
> Ну конечно, а авиамоделисты и прочие пилившие да разгонявшие ДП-3 (или МП-3?
> цилиндрик металлический, штатное напряжение 3В, штатные обороты что-то около 3000/мин)
> до чуть ли не 12В и дикой тяги?  Во, порылся в старых запасах -- ДИ1-2, 5000 ОБ/МИН, 1Р-22К.

Рекомендую посмотреть сколько ваттов и в каких габаритах нынче выжимает даже всякая недорогая китайчатина. И сразу станет понятно что прогресс безнадежно ушел вперед. За счет редкоземельных магнитов, низкоомных обмоток, отсутствия коллектора и не шибко тупого управления обмотками, вплоть до микроконтроллерной регулировки и коммутации (в времена СССР такое не светило, не было силовой электроники потребной, особенно у СССР и для простых смертных, да и проц ставить в какой-то там преобразователь было неслыханной роскошью) - даже мелкая фигулина размерами почти как мотор советских игрушек - может выжать чуть ли не полкиловатта (подозреваю что планетоход с такой штукой стал бы гоночным джипом). А фигулина более-менее умещающаяся в руке может осилить киловаттов этак 5-6, по поводу чего ходят слухи что из толи 8, толи 12 таких эпичных моторов (довольно технологичная и красивая штукенция, показывающая что более 100 лет улучшения констуркции движков не прошли даром) какой-то фрукт сделал мультикоптер способный поднять в воздух самого создателя конструкции. Такие вот моторчики "для моделек" нынче.

>> 4) Зато батарейки жрались хорошо и много. Управляющая электроника с удовольствием
>> гробила убогенькие советские "кроны"
> Нормальные солевые батарейки, eastpower рядом не валялся.

Не знаю насчет eastpower но выдыхались советские кроны удивительно быстро. Какой-то буржуйский ATC (или как их там) покупаемый в 90е - держал нагрузку не в пример дольше при прочих равных. У меня мультиметр питался от 9 вольт, кушал более-менее постоянно и довольно много, так что я на своей шкурке прекрасно ощущал кто и чего, меняя эти самые кроны пачками и потом искренне удивившись что это буржуйское нечто живет наверное как 2-3 кроны аж.

>> А покупать столько батареек (4 х "373" aka size D + "крона") - сплошной разор.
> Не столько разор, столько дефицит.  Вот уж на что-что, а на батарейки карманных
> денег завсегда хватало.

И то и другое. Все-таки комплект в сумме стоил заметно а выдыхался быстро. И не всегда был прост в добывании.

>> Был конечно еще и блок питания (кстати, импульсные БП в ссср
>> тоже не умели делать и схема БП была весьма ламерской)
> Ещё как умели (даже я спаял двухсотваттный),

А БП у МК-61 это жалкая пародия на буржуйские БП-вилки. Только вместо мелкого импульсника (требующего всего одну, но все-таки специализированную микросхему управления, с чем в СССР было "как обычно") там собран обычный сетевой транс на 50 гц и совершенно дубовый и тривиальный стабилизатор напряжения в стиле "пионер в радиокружке спаяет лучше". Ну то-есть 4 диода, кондер и стабилитрон. Пионеры для тренировки позабористее паяют. В принципе оно работало и даже было корпусом вилка. Претензия только к тому что вилка вышла довольно большая при крайне хилой мощности. Хотя относительно осмысленная конструкция корпуса не сильно мешалась в тройниках и поэтому несмотря на общий пещерный уровень конструкции оно в общем то работало и серьезно предъявить ему можно разве что то что при сильных нагрузках на электросеть (~170-180 вольт вечером в старых домах было не то чтобы редкостью) оно попросту не осиливало стартануть калькулятор. Что временами портило карму любителям вычислений.

> а схема стабилизированного трансформаторного блока проста как
> двери -- предохранитель, трансформатор, мостик, кондёр, силовой транзистор,

IIRC там на транзистор забили. Тупо стабилитрон через который сливается избыток "just in case". Вторичка очень высокоомная и потому охотно просаживает напряжение при малейшей нагрузке, так что видимо за счет ее сопротивления ток через стабилитрон вполне вменяемый выходит и столь пионерского решения - хватает.

> резистор (или делитель?), стабилитрон, кондёр и по-хорошему второй предохранитель.

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

>  Нокиевский "кубик", которым сейчас проверял эти два движка (похоже, сжёг оба ещё
> тогда) -- тоже вон трансформаторный, зато западный и можно поидолопоклонничать, так?

Не знаю что такое "нокиевский кубик", у меня от нокии есть аж 3 зарядки, и все 3 - это такие прямоугольнички характерные, хоть и немного разных моделей. И все 3 разумеется импульсные. Самый мощный (для n900, который при заряде жрет как трактор) выдает 5V@1200mA, что раз в ~6 больше того что можно в принципе выжать из советской вилки. При том что габариты поменьше и поудобнее (хотя в некоторых тройниках может быть и ровно наоборот). Не говоря о том что там 5 вольт - это 5 вольт. А не так что при малейшем росте нагрузки - напряжение стремительно летит вниз. И да, такое не то что от 170, но и от 150 вольт нормально работает. Современные импульсники обычно жрут все, от 90 до 250 вольт. Чтоб не надо было паять разные схемы для разных стран. Сие дает оным большую фору в местности где электричество занижено по напряжению или нестабильное. А вот БП от мк-61 мог вечером малость огорчить, если напряжение упало ниже номинала. Формально это конечно энергетики уроды что напряжение в доме вышло за номинал, но это слабое утешение.

>>   Пепелац стоил рублей двести IIRC, правда...
> А мне что-то казалось что рублей 40

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

>> Во, порылся в старых запасах -- ДИ1-2, 5000 ОБ/МИН, 1Р-22К.
> Рекомендую посмотреть сколько ваттов и в каких габаритах нынче выжимает
> даже всякая недорогая китайчатина.

Ну супербрайты с АЛ-307 тоже не сравниваю -- хотя как раз на упомянутом движке магниты, кажется, были не совсем обычные.  Вот с коллектором да, долго на таких перегрузках не жил даже при замене штатных "усиков" на пластинчатые контакты...

> За счет редкоземельных магнитов, низкоомных обмоток, отсутствия коллектора
> и не шибко тупого управления обмотками, вплоть до микроконтроллерной регулировки
> и коммутации (в времена СССР такое не светило, не было силовой электроники потребной,
> особенно у СССР и для простых смертных

Да ладно, П213 (или ГТ?) и КТ805 у этих самых простых смертных вполне водились. :)

> да и проц ставить в какой-то там преобразователь было неслыханной роскошью)

*Проц*-то там зачем?

> Такие вот моторчики "для моделек" нынче.

Спасибо за ликбез, слышал совсем краем уха про результаты, но не компоненты.

>>  Нокиевский "кубик" [...] -- тоже вон трансформаторный, зато западный
> Не знаю что такое "нокиевский кубик"

Старая зарядка на толстый штекер, валялась тут от 6230i.  Кстати, "дальнобойщики" во время смены на импульсники упорно придерживались мнения, что "кубик заряжает плотнее"...

> Современные импульсники обычно жрут все, от 90 до 250 вольт.

Это да.

PS: надо попросить Максима организовать отдельный старпёрский уголок :)

> Ба, так это вообще четыре болгарских дискеты (или всё же пять? не помню уж точно).

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

[..]
> Ну супербрайты с АЛ-307 тоже не сравниваю --

С светодиодами я особого отставания у СССР не вижу: это были чисто индикационные приборы, а потому улучшались мало и медленно.

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

Сдается мне что нынче магниты все-таки сильнее. Кстати в пепелаце были похожие круглые металлические моторчики. Если верить гуглу, то что там было, называлось видимо ДИ1-3.

> Вот с коллектором да, долго на таких перегрузках не жил даже при замене
> штатных "усиков" на пластинчатые контакты...

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

[..]
> Да ладно, П213 (или ГТ?) и КТ805 у этих самых простых смертных вполне водились. :)

Тем не менее,
1) Аналоговой техникой 3-фазную последовательность генерить геморно и получится очень уж дофига электроники. Да и на дискретной цифре - начинание так себе (если надо регулировку, например).
2) П213 огромный, много весит (не для летунов), саморазгоняем по температуре (чревато FAILом при перегреве) и коэфф. усиления никакой. Чтобы его раскачать - надо постараться. Кт805 простым смертным стал доступен не так уж давно. И к тому же кремниевый, на нем падение напряжения в полностью открытом виде еще больше. На мало мальски серьезном токе он перегреется.

Нынче все намного проще. Цепляем logic level FET к микроконтроллеру (или что там у нас) еще и генерим себе программно все что душе угодно прямо на мощную нагрузку. Просто в плане схемы, бесконечно гибко в плане выдаваемых сигналов и фич. Power MOSFET с низким управляющим напряжением - лютый win, но в СССР их делать не умели.

>> да и проц ставить в какой-то там преобразователь было неслыханной роскошью)
> *Проц*-то там зачем?

1) Регулировать обороты. В синхроннике недостаточно рулить только мощщой как в коллекторнике. Надо еще и частоту менять. Делать это без умных элементов схемы крайне геморройно. По этой самой причине в СССРовских книжках бывало упоминание что регулировать обороты асинхронников (которые по принципу работы похожи) - сложно. Потому что на дискретных компонентах делать схему преобразующую то что есть в 3-фазную последовательность с регулируемой пропорционально желаемым оборотам частотой получается действительно невкусно ;)
2) Достаточно удобно когда процу реализующему основную логику досточно кинуть понекоему протоколу команду вида "а выдай ка нам вот столько!" и дальше предоставить процу в моторном отсеке заниматься стабилизацией частоты вращения, регулировкой, мониторингом состояния дел и прочая. Некое разделение труда.
3) В совсем наглом варианте такая схема являет собой logic level FET прицепленные влобовую на GPIO лапки микроконтроллера. Более простое и нахальное схемотехническое решение придумать сложно. А такое может что угодно. И грамотный разгон, и стабилизация скорости, и адаптация к внешним условиям, и диагностика/умная защита.

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

Ну вот еще порция. Даже наверное не совсем оффтоп: писать управление обмотками мотора на си вполне можно и это пожалуй сойдет за сабж в каком-то роде. Кстати в результате при столь ядреном управлении можно получить что-нибудь необычное. Наиболее ярким примером является segway. Попробуйте сделать такое без реалтаймного управления моторов фирмварой, а я на это посмотрю. Раньше такой агрегат соорудить было проблематично.

[..]
>> Не знаю что такое "нокиевский кубик"
> Старая зарядка на толстый штекер, валялась тут от 6230i.  Кстати, "дальнобойщики"
> во время смены на импульсники упорно придерживались мнения, что "кубик заряжает
> плотнее"...

На современных телефонах с литий-ионниками это маловероятно. LiIon капризная и опасная штука, очень чувствительная к перезаряду и переразряду.  По этому поводу стоит неглупый чип контролирующий процесс заряда от и до. Он прекращает заряд по вполне конкретным критериям и сам делает из того что есть то что надо (данный процесс называется CC/CV и критерии его завершения от зарядного устройства вообще не зависят).

> PS: надо попросить Максима организовать отдельный старпёрский уголок :)

И переносить некоторый флуд туда. Я только за :). Тем не менее, на самом деле это не старперство а просто применение все тех же знаний на новом уровне.

> Но каждый раз испытывать оргазм от
> решения очередной "проблемы одного байта" — ни сил, ни времени, ни
> желания на это уже НЕ_ХОЧЕТСЯ тратить. :)) Память больше не ресурс
> — и точка!

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

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

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

Когда работаешь в коллективе, от "хакерского трюка" будет не по себе многим программистам, которым придётся по работе сопровождать его. Если они его не поймут (что в 95% случаев так и есть), то тебя не оценят и в дальнейшем просто не будут с тобой работать.

> поймут (что в 95% случаев так и есть),

Ага. Читаем лурк на предмет того что за нафиг с 95% такой и понимаем что программирование и быдло плохо совмещаются. Но поскольку бизнес-хрены всегда хотят на чем-нибудь сэкономить и чтобы еще вчера - за клавиатуру сажается стадо специально дрессированых обезьян, которых положительными и отрицательными стимулами натаскивают чтобы они выдавали какое-то подобие программ :)))

А вот статья почти про izen'а: http://habrahabr.ru/blogs/htranslations/132600/

Кусок заявки :)

int l(){int l=1;l=(l<<1)<<1>>!1<<!1<<!1>>1^11>>!1^11<<!1<<1^11<<1>>!1;}

Вот это им не побороть:

#include <stdio.h>
int main(int t,int _,char*a)
{return!0<t?t<3?main(-79,-13,a+main(-87,1-_,
main(-86, 0, a+1 )+a)):1,t<_?main(t+1, _, a ):3,main ( -94, -27+t, a
)&&t == 2 ?_<13 ?main ( 2, _+1, "%s %d %d\n" ):9:16:t<0?t<-72?main(_,
t,"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+\
,/+#n+,/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/\
+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){n\
l]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#\
n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;\
#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/")
:t<-50?_==*a ?putchar(a[31]):main(-65,_,a+1):main((*a == '/')+t,_,a\
+1 ):0<t?main ( 2, 2 , "%s"):*a=='/'||main(0,main(-61,*a, "!ek;dc \
i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}

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

Я был знаком с челом, который участвовал в этом конкурсе и даже занял там призовое место. Помню, я сразу и не поверил, что он написал на C шахматную программу с размером исходного кода 4Кб. Был в шоке, когда сам скомпилировал ее, и она даже заработала. Правда, шок прошел, когда я дал ей мат в районе 20-го хода.

> Правда, шок прошел, когда я дал ей мат в районе 20-го хода.

Так настоящий fmax4_8w.c всё же 34K весит.  Правда, пара килобайт там одних комментариев...

> Я был знаком с челом, который участвовал в этом конкурсе и даже
> занял там призовое место. Помню, я сразу и не поверил, что
> он написал на C шахматную программу с размером исходного кода 4Кб.
> Был в шоке, когда сам скомпилировал ее, и она даже заработала.
> Правда, шок прошел, когда я дал ей мат в районе 20-го
> хода.

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