http://www.roesler-ac.de/wolfram/hello.htm
:)

S_T_A_S_
Да, ваша правда. Пришлось ставить linux и проверять.
Ой, а это еще зачем? :о) Питон и под Виндовс есть.

Shift

Получается, по стандарту LF всё же положен? Я вообще, думал про EOF.
CR&LF, afaik справедливо только для ДОСа, виндос переваривает и один байт..


Anonimka

Моё условие было такое - стандартные средства оси.
А так можно написать и свой "интерпретатор", у которого Hello World будет весить 2 байта или меньше :).

S_T_A_S_
А фиг его знает, вроде положено, но вообще это не ошибка.Кто выдаёт ворнинги - а кто и нет.sh не выдал ворнинга на отсутствие конца строки. gcc - выдаёт. Демоны: бывают ругаются, бывают - нет

Если в UNIX симовл EOF (код 26) является обычным символом, который вполне корректно читается оператором read и входит в прочитанную этим оператором знаковую последовательность, то в Windows 9x/NT операция чтения файла оператором read безусловно завершается при достижении EOF. Это бывает достаточно неудобно, когда символ EOF является не признаком конца файла, а байтом двоичного числа, записанного в файл. Обработка символа "конец файла" (EOF) в двоичном файле

Вообще EOF - это просто удобно :) Но иногда можно обойтись и без него:)
Насчёт CR&LF - нуууу.....Файл с LF лучше в блокноте не открывать :)

bogrus дал ссылку на сие:

This is how things work in Information Technology.

Любой русский программист после пары минут чтения кода, обязательно вскочит
и произнесет обращаясь к себе: переписать это все нафиг.
Потом в нем шевельнется сомнение в том, сколько времени это займет, и
остаток дня русский программист потратит на то, что будет доказывать самому
себе, что это только кажется, что переписать это много работы. А если
взяться и посидеть немного, то все получится. Зато код будет красивый и
правильный. На следующее утро русский программист свеж, доволен собой и без
единой запинки докладывает начальству, что переписать этот кусок займет один
день, не больше. Да, не больше. Ну, в крайнем случае, два, если учесть все
риски. В итоге начальство даст ему неделю и через полгода процесс будет
успешно завершен. До той поры, пока этот код не увидит другой русский
программист.
А в это время, в соседних четырех кубиках, будет ни на секунду не утихать
работа китайских программистов, непостижимым образом умудряющихся прийти
раньше русского программиста, уйти позже, и при этом сделать примерно втрое
меньше. Эта четверка, давно не пишет никакого кода, а только поддерживает
код написанный, в свое время индусом и дважды переписанный двумя разными
русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо
постоянно воспроизводит себя при помощи любимой китайской технологии
реиспользования кода - copy/paste. Отсюда баги расползаются в разные стороны
посредством статических переменных и переменных переданных по ссылке
(поскольку, китайский программист не может смириться с неудобствами
вызванными тем, что он не может изменить значение внешней переменной
переданной в его функцию модулями, которые переписывает русский
программист). Вспоминая об этой функции русский программист, как правило на
время теряет дар английской речи, и переходит к какой-то помеси русского и
китайского. Он давно мечтает переписать весь кусок, над которым работают
китайцы, но у него нет времени.
На китайцах висят серьезные баги, о которых знает начальство и постоянно их
торопит. Китайцы торопливо перевешивают баги друг на друга, поскольку знают,
что попытки их починить приведут к появлению новых, еще худших. И в этом они
правы. Разобраться в том, в каком порядке меняются статические переменные, и
как приобретают свои значения, способен только один человек на фирме -
индус. Но он пребывает в медитации.
Поэтому, когда всю четверку уволят во время сокращения... А кого еще
увольнять? Русский - еще не переписал свой кусок, а индус - главная ценность
фирмы - он редко обращает внимание на проект, но когда обращает, все
понимают, что так как он, архитектуру никто не знает. Так вот, когда
китайцев увольняют, у их кода возможны две основные судьбы. Первая - он
попадет к русским и его перепишут. Вторая - он попадет к местному,
канадскому программисту.
О, канадский программист это особый тип. Он ни на минуту не задумываясь, как
рыцарь без страха и упрека, бросится фиксить самый свирепый баг китайского
кода. Этот Баг живет там уже три года, и китайцы уже четырежды (каждый по
разу) сообщали начальству, что он пофиксен. Но Баг каждый раз возвращался,
как Бетмен в свой Готхем.
Итак, канадский программист сделает то, чего китайцы не рисковали делать в
течении трех долгих лет. Он, при помощи дебагера, отследит место, где
статическая переменная приняла значение -1 вместо правильного 0, и
решительным движением заведет рядом вторую переменную с правильным
значением. Баг погибнет в неравной схватке с канадским программистом. Но
победа будет достигнута тяжелой ценой. Работать перестанет все, включая
только что переписанный русским программистом код. Это повергнет русского
программиста в задумчивость на целых два дня, после чего он сделает, в
общем-то, предсказуемый вывод о том, что дизайн с самого начала был
неправильным, и все надо переписать. На это нам нужна неделя. Да, неделя, не
больше.
Канадский программист смело бросится налаживать все, и станет еще хуже, хотя
казалось бы... Эта суета выведет из медитации индуса, который придумает и
вовсе гениальное решение - отбранчить код. Согласно его плану, мы теперь
будем поддерживать две версии одного и того же кода - одну работающую но с
Багом, другую без Бага, но не работающую. Русский программист услышав об
этом плане, сломает линейку об стол и дома обзовет жену дурой, но на митинге
возразить не решится.
К счастью, все это не сильно влияет на дела фирмы, поскольку продукт
продается и так. Поэтому менеджмент ходит в целом довольный и не устает
напоминать всем, что они отобраны как лучшие среди лучших. И что мы давно
доказали свою способность выпускать продукт тем, что выпускаем его иногда.

volodya
Это расписан рабочий день сотрудников мелкософта? :)))

volodya bogrus дал ссылку на сие:

О ! Когда это я дал ссылку ? Cам первый раз вижу .
added: А , теперь понял . Ссылка в ссылке :)

Toxic

На это похож и мой рабочий день :))))

bogrus

Дал, дал. Помнишь документ по CRC? Я его поглядел. А там, в самом начале, ссылочка на сие. Господи, вот это кто-то выстрадал... Святая правда. Все так и есть. Подписаться готов :)

volodya
Надеюсь, ты ассоциируешь себя с русским программистом а не с канадским? :)))

:)))))))) Нет, с индусом :))))))))))))

Высоко взял :)))

Дык я же лидер проекта :)
Кроме меня, архитектуру системы больше никто и не знает. Знаешь, что такое job-proofing код?
Это когда в программе (нужной!) есть только одна функция - main :) В этой main должна быть минимум пара тысяч строк кода, желательно посложнее и без комментариев. Баги правятся просто - методом канадского программиста. Ищем место где упала программа, ставим падч :) Все работает. :) Недолго. До следующего падения и падча. Зато, если автора программы нет, падает все к херам и никто не может понять, что там такое написано :)))

:)))

Ага, один мой знакомый фокс-прошник 4 года поддерживал (очень важную) прогу в одном гос. учреждении, поддерживал методом канадского программиста, в итоге в программе этой я не знаю сколько строчек, но в каталоге ее файлов (в основном батники, которые друг с другом завязаны) около 1,5!!! тысяч!!! так он уже давно уволился, а программу эту за дополнительную плату, и не малую, так и ведет, тк кроме него никто в ней разобраться не может... :)))))

Резюмируем. Все эти design patterns, концепцию классов, наследование это, полиморфизм гребаный - все это придумали очень смелые люди. Пользоваться этим НЕ НАДО. А программу надо писать так:
1) Пишем код на лету, предварительный дизайн - это херня.
2) Комментарии придумали трусы, настоящие мужчины комментарии не пишут. А алгоритм надо дополнительно как следует оптимизировать, что сделает его нечитаемым. Дополнительно, если в ходе поддержки программы необходимо что-то поправить, то делать это надо ТОЛЬКО методом падча aka канадского программиста.
3) Ошибки вылавливаются компиляцией. Падчить прямо в месте ошибки.
4) Потом программа запускается и тут же падает. Ошибку находить в отладчике, ни в коем случае не использовать перетряску исходников. Место ошибки падчить. Причем желательно оставить место для будущих ошибок.

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