Мы об обучении, а не о конкретной разработке.

Тогда почему не Lua например? Почти паскаль по синтаксису, но не такое говно мамонта и реально полезно в жизни.

Видимо, ты не в курсе про strict aliasing.

Пока ты писал, я про него уже прочитал. Моё мнение, что C кака укрепилось. Я считаю, что язык с нормальным дизайном в принципе не должен включать UB, если он предназначен для того, чтобы на нём писали люди, а не компиляторы. А есть языки не хуже C по производительности собранного кода, но чтобы без UB?

Тогда почему не Lua например? Почти паскаль по синтаксису, но не такое говно мамонта и реально полезно в жизни.

Это другая под-тема. Про Паскаль в программе обучения я ничего не говорил, ни за ни против.

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

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

Спорно. Зависит от целей. Нельзя сделать подобный Си язык с четко определенной семантикой во всех случаях, но при этом формирующий эффективный код для столь разнообразных архитектур. Мы тут же получим необходимость что-то делать определенным образом на случай если конкретная программа от этого зависит, даже если в большинстве случаев это не так. Возьмем тот же пример со сдвигом на количество бит, которое может оказаться вне пределов от 0 до размера исходного типа в битах минус 1. На разных процессорных архитектурах (или даже, например, для скалярных vs. SIMD инструкций одного и того же процессора) этот случай определен по-разному (или оставлен неопределенным). И что же, компилятору придется генерировать код из многих инструкций вместо одной ради того, чтобы эта операция стала четко определена? Другое дело что, в том числе в этом примере, это может быть не undefined, а что-то ближе к unspecified behavior в Си - т.е. неопределенным оставить лишь получаемое число, а не поведение программы в целом. Так что я согласен, что Си оставляет желать лучшего, и что это лучшее возможно, но, думаю, не до степени сочетания полной определенности и не меньшей эффективности, при этом не ориентируясь на конкретную архитектуру.

А есть языки не хуже C по производительности собранного кода, но чтобы без UB?

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

К сожалению, я почти не знаю эти языки и не знаю насколько полно они определены на данный момент (Си к его нынешнему возрасту по крайней мере дорос до того, что случаи UB и т.п. описаны явно, тогда как для молодых языков не исключено что их придется определять позже), чтобы всерьез комментировать, но в качестве альтернатив можно рассмотреть Rust, Nim, Swift, D.

А в пруфах на хедхантере зарплату Senior C Programmer, или там C++/HLSL 3D Graphics Developer не пишут. Такая вот пищалька. Но могу сказать, что в конце 2013 года для российских контор была актуальна цифра в 200-250 тысяч деревянных, причём привязанная к доллару. То есть ЗП индексировалась автоматически по курсу нацбанка на день выплаты.

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

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

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

Кстати, почему раздел операнда минус 1? По идее шифт в любую сторону с размером, равным размеру операнда должен давать или 0, или само число если это циклический шифт.

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

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

Видимо старшие биты сдвига игнорируются. А если размер операнда + 1 — то это будет как сдвиг на 1?

А как тогда 0 получить?

У автора

Что такое компьютер

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

Звенигородский Г.А. Первые уроки программирования, 1985:

Каждая ЭВМ должна уметь принимать, хранить, обрабатывать и выдавать информацию.

и далее

...числовая информация - это всего лишь один из видов её обработки. Около 90% всей информации, обрабатываемой современными ЭВМ, составляет информация нечисловая: тексты, рисунки, графики, разнообразные списки и таблицы, так что на долю арифметических вычислений приходится лишь десятая часть рабочего времени вычислительных машин. Правильнее было бы называть их не вычислительными, а информационными машинами (точнее, машинами для обработки информации), но к старому названию уже давно привыкли и вряд ли стоит его менять.

так кто прав? компьютер - это калькулятор или устройство для обработки информации?

Может имеет смысл включить в книжку ещё небольшой опыт использования yasm? Он компактен и вполне юзабелен. Есть под Windows, Linux.

соседний - это мехмат, что-ли?

зайди на соседний факультет,

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

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

Так что знаю я прекрасно, что там на Мехмате происходит. А ещё я знаю, как Си в качестве первого языка действует на неокрепшие мозги. А сверх того я знаю, насколько просто рассказать Си человеку, который знает Паскаль (как нынче говорят, задача чуть сложнее, чем пареная репа), и насколько сложно (практически невозможно) АДЕКВАТНО объяснить Си человеку, который Паскаля не знает. И уж что я знаю совершенно точно, так это то, что если на выходе нужен программист, умеющий адекватно обращаться с Си, то гораздо эффективнее получается сначала научить его Паскалю, дойти до указателей, научить жонглировать списками и деревьями, а потом буквально за два-три занятия перетащить на Си.

Конечно, когда отстающий студент с того же Мехмата или с «нашего» ВМКшного первого потока (где тоже Си первым языком) приползает на частный урок, времени сначала учить его Паскалю уже просто нет, и приходится — таки да — рассказывать Си первым языком. Так что да, я и это умею, и много раз делал, только на выходе целью было уже не «научиться программировать», а «сдать зачёт и забыть всё как страшный сон». Большего в этом режиме достичь очень сложно.

так кто прав? компьютер - это калькулятор или устройство для обработки информации?

Полагаю, права Ада Лавлейс:

Суть и предназначение машины изменятся от того, какую информацию мы в нее вложим. Машина сможет писать музыку, рисовать картины и покажет науке такие пути, которые мы никогда и нигде не видели

Написано за почти сто лет до появления первых работающих программируемых компьютеров — в качестве комментария к знаменитой программе вычисления чисел Бернулли. Вот это был Мозг, а вы мне тут каким-то Звенигородским тычете. А если серьёзно, то вот мой ответ на этот вопрос (из текста рукописи):

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

А макросом?Формировать «%19s» из (sizeof(buf)-1)

А не получится. Во время работы макропроцессора buf ещё не определён, так что sizeof(buf), соответственно, тоже — просто ошибку выдаст и до свиданья. Операция sizeof в выражениях препроцессора может применяться только к встроенным типам и типовыражениям вроде void*. И, если мне склероз не изменяет, это только начиная с C11 закреплено, хотя работало и раньше.

Иной вопрос, что можно сначала

#define BUFSIZE1 19

а потом

char buf[BUFSIZE1+1];

ну и строку для scanf, соответственно, через #BUFSIZE1 сформировать. А потом прикинуть, сколько из читателей программы вообще смогут вспомнить, что #x в макротелах превращает значение x в строковый литерал.

Croco, рад тебя здесь видеть. Удачи с проектом! Но я всё же придерусь (может быть, это поможет твоей книге):

Ой, сам SolarDiz :-) привет.

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

Но вопрос «что делать» от этого никуда не девается. Если, к примеру, добавить в часть, посвящённую Си, отдельную главу про все эти неочевидные подводные камни, решит ли это проблему?

Но вопрос «что делать» от этого никуда не девается. Если, к примеру, добавить в часть, посвящённую Си, отдельную главу про все эти неочевидные подводные камни, решит ли это проблему?

Очевидно, нет: таких камней много, потянет на отдельную книгу[1].

[1] Peter van der Linden. Expert C programming. http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp/0131774298

Это уже не для начинающих явно. В том и проблема, что чайник в этой книге попросту ничего не поймёт.

с «нашего» ВМКшного первого потока (где тоже Си первым языком)

Почему убрали Паскаль на первом курсе ВМК? Иванников ушел с чтения лекций?

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

Во-вторых, при чём тут Иванников? Иванников как раз протолкал «эксперимент», идущий сейчас на одном из трёх потоков, где учат сразу на Си, а на выходе получается, естественно, чёрт знает что.

Во-вторых, при чём тут Иванников?

В 1995-1996'м Иванников читал Паскаль, а Пильщиков - ассемблер. Просто Иванников очень доходчиво и старательно объяснял синтаксис Паскаля. Так, что не составляло труда по блок-схемам написать неоптимизирующий транслятор-интерпретатор.

Я думал, что Иванников - фанат Паскаля. Что было после 2000-го года ... не знаю. Паскаль я учил еще с 1992-го, у С.М.Окулова, наряду с TASM/i286 и inline asm/Turbo Pascal 5.5,6.0, на олимпиадных задачах.

Изучение Паскаля, синтаксического анализа и алгорифмов Маркова гармонично объединялось на втором курсе с написанием транслятора в байт-код для SQL.

вопрос тут такой — а что делать-то (в смысле с книгой)? Для начинающего слова про UB останутся тёмным лесом, то есть начинать с этого нельзя

Мне легче ответить что не делать: с первой же главы не подавать Си исключительно как «почти ассемблер». А «что делать» тогда получается: с первой же главы подавать Си как противоречивый язык, позволяющий эффективно работать с «железом», но при этом дающий лишь некоторый неочевидный набор гарантий, отличный от того, который дает ассемблер. Пояснить чем это хорошо (переносимость программ между непохожими архитектурами, при этом сохраняя широкие возможности для оптимизации компилятором), и чем плохо. На примерах. Выбор примеров важен и сложен. Многое из этого останется тёмным лесом, но по крайней мере о его наличии будут знать.

Когда на втором курсе после Паскаля у нас начался C/C++ это был, как глоток свежего воздуха. Первой моей мыслью было: «Какого хрена нас мучили этим Паскалем недоделанным??!!!». Что мешает при обучении, если не хочется забивать голову include/указателями/... просто не давать их ученикам, а показать только несколько функций: длинна массива, массивы, объявление переменных и т.д.?

Бррр

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

При всём моём уважении, всё это может быть хорошо, может быть плохо, но определяющим является совсем другое: на Си можно (в смысле, возможно, ну вот есть такая физическая возможность) решить почти что любую вставшую на практике задачу ВМЕСТО того, чтобы делать это на асме, а «можно» в данном случае неотвратимо само собой превращается в «обязательно» из-за различия по трудозатратам едва ли не на порядок. Причём на других языках это сделать нельзя (то есть вообще, ну не годятся), а на Си вот можно, пусть и со всеми сопутствующими ужасами и элементами порнохоррора.

То есть ниша Си — заменять ассемблер, пусть плохонько, но выигрыш в трудозатратах всё покрывает. Это просто факт, тут можно ничего не придумывать. Вопрос, на мой взгляд, теперь в том, как раскрыть это вот «плохонько». Что язык сам по себе как был наколенной поделкой, так ею же и остался — этот момент я и так, на мой взгляд, достаточно внятно показываю, а вот насчёт всех этих UB и прочих — пока что нет. Опять же, «с самого начала» это не получится, потому что обучаемого в самом начале не волнуют тонкости и сложности, он такой материал в лучшем случае механически прочитает и не запомнит, а в худшем — просто пропустит и проигнорирует.

Я думал, что Иванников - фанат Паскаля.

Вот уж чего нет, того нет.

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

В данном случае не «кто», а «что»: мешает сам язык Си. Попросту говоря, его невозможно так «избирательно» показывать — в отличие, кстати, от того же Паскаля.

Подробнее тут: http://www.stolyarov.info/pvt/anti_c

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

Недавно читал «Маятник Фуко», там гг — полный гуманитарий и журналист — писал скрипт на бейсике, пермутирующий имя Иеговы. Ну про отца perl и анестезиолога, пишущего ядро, тут все и так знают.

В XXI веке базовая компьютерная грамотность — норма, а она включает в себя в первую очередь не набивание писем в ворде, а как раз скриптовые языки, знать скриптовый язык в начале XXI века то же самое, что уметь писать в начале века XX. Школьников в первую очередь должны учить писать скрипты на каком-нибудь питоне для своих простых нужд: сортировки музыки, файлов, пакетной обработки файлов и тому подобное.

определяющим является совсем другое: на Си можно (в смысле, возможно, ну вот есть такая физическая возможность) решить почти что любую вставшую на практике задачу ВМЕСТО того, чтобы делать это на асме, а «можно» в данном случае неотвратимо само собой превращается в «обязательно» из-за различия по трудозатратам едва ли не на порядок. Причём на других языках это сделать нельзя

По-моему, ты преувеличиваешь этот аспект отличия Си от других языков. Как видишь, например, на Обероне вполне себе реализуются системные программы, а Turbo/Borland Pascal был в своё время очень популярен на демо-сцене, где эффективность очень важна (а среды разработки Си под DOS оставляли желать лучшего, особенно из-за неумения выкидывать dead code из .obj при линковке, в отличие от .tpu). Конкретный диалект и компилятор Паскаля обычно даже ближе к ассемблеру, чем абстрактный Си. Вот, например, моя замена RTL для Turbo Pascal (чуть больше чем 20-летней давности), превращающая его в структурированный ассемблер («begin end.» дает 96-байтный .exe):

http://pascal.sources.ru/misc/bpc-trtl.htm

Оказывается, к ней еще был какой-то интерес 10 лет спустя:

http://compgroups.net/comp.lang.pascal.borland/tp-code-compiling/2637281

Подробнее тут: http://www.stolyarov.info/pvt/anti_c

Кстати, годно. Я сам как-то пытался объяснить чем именно Паскаль хорош для обучения, но честно говоря не осилил. А с этим эссе согласен практически по всем пунктам.

Всё-таки понятный синтаксис при обучении первому языку программирования - это очень важно

Когда на втором курсе после Паскаля у нас начался C/C++ это был, как глоток свежего воздуха. Первой моей мыслью было: «Какого хрена нас мучили этим Паскалем недоделанным??!!!».

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

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

А как ты представляешь написание РАБОТАЮЩЕЙ и что-то выводящей программы на Си без include? Нет, точнее, написать такую можно, но она точно будет не для начинающих.

Без указателей обойтись чуть попроще, но опять-таки, они вовсю используются в стандартной библиотеке. Даже strlen ты без char* не вызовешь.

Паскаль хорош в том числе тем, что указатели там есть, но в простейших случаях там можно обойтись и без них. И модульность на уровне unit/uses - гораздо более аккуратная штука, чем раздельная компиляция + #include.

По-моему, ты преувеличиваешь этот аспект отличия Си от других языков.

Упс. Зная твой уровень, начинаю сомневаться в правильности собственной картины мира.

Тем не менее, прочитав тред по второй ссылке, э....

You lose pretty much everything... Most of the LongInt operators *, /, shr, shl (Integer works, though)... Virtual methods (if you do OOP)

Ну то есть после такой замены это уже не тот язык. Рискну предположить, что компилятор при этом совершенно не в курсе, какие возможности поддерживать ещё можно, а какие уже нельзя (сорри, проверять не буду, разворачивать турбо-паскаль в досбоксе — долгая история). Иначе говоря, корректно отстричь от TP его библиотеку невозможно.

В случае Си ничего подобного не происходит, имеется чёткое разграничение, вот тут язык, вон там библиотека, библиотеку можно взять другую, язык при этом никуда не денется. Собственно, это и есть тот самый zero runtime, которого больше нигде нет и который я как раз и считаю — таки да — определяющим фактором, без которого использовать Си (кривой как российская дорога и жуткий как три фредди крюгера) было бы делом вообще бессмысленным.

(«begin end.» дает 96-байтный .exe)

Фу, виндузятник.

Упс. Зная твой уровень, начинаю сомневаться в правильности собственной картины мира.

Да хватит уже заискивать, противно смотреть.

Подробнее тут: http://www.stolyarov.info/pvt/anti_c

Читали-читали. Лень даже опровергать такую чепуху.

Most of the LongInt operators *, /, shr, shl (Integer works, though)...

Ты почему-то процитировал из того списка вещи, которые вообще отсутствуют в классическом Паскале. Ну, теряем эти расширения языка, и что же. Сборка-то идет под 16-битный режим, и для него мы получаем вполне себе структурированный ассемблер, способный компилировать выражения (в том числе с упомянутыми выше операциями), условия, циклы, процедуры/функции и их вызовы, понимать массивы и... как их там... записи. Да, и указатели, конечно. Включая доступ по физическим адресам, хотя формирование таких указателей или привязка переменных к адресам — это тоже из области расширений конкретного диалекта Паскаля (но эти продолжают работать и без RTL). Да, теряются еще такие вещи как WriteLn, но аналогично в Си без рантайма теряется printf.

Рискну предположить, что компилятор при этом совершенно не в курсе, какие возможности поддерживать ещё можно, а какие уже нельзя

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

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

OK, в Си это более чётко, да. И всё же, бывает, что какое-нибудь умножение или деление повышенной разрядности (аналогично примеру с LongInt выше) или неявный memcpy() для присвоения структур (или передачи структуры в функцию по значению) окажется в библиотеке. Есть опции компиляторов вроде «gcc -ffreestanding», которые такие вещи отключают/ломают. Аналогичные опции могут быть у компиляторов других языков. Вот, например, про операционные системы на Паскале:

http://wiki.freepascal.org/Operating_Systems_written_in_FPC
http://wiki.osdev.org/Pascal
http://wiki.osdev.org/Pascal_Bare_Bones

Есть опции компиляторов вроде «gcc -ffreestanding», которые такие вещи отключают/ломают.

Похоже, я не прав: «gcc -ffreestanding» отключает предположения gcc об определенной семантике функций вроде memcpy(), позволяя их аналогам в ядре отсутствовать или вести себя необычно, но не отключает/ломает использование служебных функций самого gcc (эта поломка остается на этап линковки):

$ cat ll.c
long long f(long long a, long long b)
{
        return a / b;
}
$ gcc -S -O2 -ffreestanding ll.c
$ grep div ll.s
        .globl  __divdi3
        call    __divdi3
$ gcc --version | head -1; uname -ms
gcc (GCC) 4.6.3
Linux i686

Здесь хоть указывай -ffreestanding, хоть нет — одинаково используется внешняя функция, тело которой в формируемый код не добавляется. Это 64-битное деление на 32-битной платформе — аналогия с TP'шным 32-битным LongInt на 16-битной платформе. И то и другое может ломаться без RTL.

неявный memcpy() для присвоения структур

$ cat structcopy.c
typedef struct {
        char data[1111];
} st;

st b;

void f(st a)
{
        b = a;
}
$ gcc -S -O2 -ffreestanding structcopy.c
$ grep memcpy structcopy.s
        call    memcpy
$ gcc --version | head -1; uname -ms
gcc (GCC) 3.4.5
Linux i686

Свежий gcc в этом плане лучше, но если говорить о Си в целом...

«gcc -ffreestanding» отключает предположения gcc об определенной семантике функций вроде memcpy()

Похоже, я и в этом ошибся. Сейчас вспомнил контрпример: когда-то код vdso в Linux был завязан на предположение, что gcc 4 заменяет тамошний явный memcpy() соответствующим inline-кодом (из-за этого vdso ломался при сборке такого ядра gcc 3), так что, получается, gcc продолжает считать memcpy() особым и при сборке ядра. См. __vdso_gettimeofday() в https://lkml.org/lkml/2006/11/17/43

Тем более, из texinfo документации на gcc:

«GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'.»

«GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'.»

Позорники :( Что-то я был лучшего мнения об авторах gcc.

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

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

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

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

Позорники :( Что-то я был лучшего мнения об авторах gcc.

Думаю, у них на почти всё спорное есть причины, основанные на многолетнем опыте. Как и у тебя. ;-) Таков мир.

Нормальным людям нужен нормальный софт, в котором не надо писать собственные скрипты на питоне

Ага, а потом мы наблюдаем какую-нибудь девочку из бухгалтерии, которой прислали, к примеру, список товаров в виде текстового файла, а она его несколько часов загоняет в 1С по одному пункту, вдобавок делая ошибки. То, что в норме на это должна была уйти одна команда, на написание которой ушло бы от силы две-три минуты, просто чтобы сообразить, как скомбинировать фильтры — этого она не знает. И этому есть две причины: (1) её никто не учил в школе программировать и (2) 1С — это «нормальный софт», у которого, разумеется, из интерфейсов только GUI, ведь «нормальным людям» командная строка не нужна, им нужен только «нормальный софт».

Предвидя возражения относительно языка программирования, имеющегося в 1С: я ни разу не видел, чтобы бухгалтеры умели им пользоваться или чтобы в бухгалтерии сидел свой 1С-программист; ну а приглашать стороннего 1С-программиста и платить ему хренову прорву бабок за то, чтобы он придумал, как не потратить эн часов на ввод очередной ведомости — это дорого и глупо (и вдобавок может не дать результата, особенно если знать, какой квалификацией обычно обладают пресловутые 1С-программисты). Вот, стало быть, и сидят девочки, теряя целые дни на работу, с которой скрипт справился бы за считанные секунды.

Компьютеризация такая компьютеризация, автоматизация такая автоматизация, ага.

Думаю, у них на почти всё спорное есть причины,

Может, оно и так, но мне, увы, видится иное: там просто нет людей, которые понимают, что этот момент вообще «спорный». А если и есть, то им лень тратить силы на объяснение этого окружающим.

Какой выигрыш даёт использование memcpy — очевидно: объём кода меньше. А вот почему его НЕЛЬЗЯ использовать для реализации возможности из базового языка — это требует существенно более пространных объяснений. Вот эти вот все мои слова про Zero Runtime — я их тоже не сразу придумал, то есть печёнкой чуял, что что-то тут нужно сказать, но отнюдь не сразу понял, что именно. И, главное, на все такие аргументы у «них» найдётся ответ вида «да ладно, очевидно же, как это обойти, чтобы не мешалось». А всякая там «эстетика» принципиально игнорируется.

Индокод захватывает мир.

> На x86, сдвиг (и не только циклический) на размер операнда сохраняет его неизменным.
Видимо старшие биты сдвига игнорируются. А если размер операнда + 1 — то это будет как сдвиг на 1?

Да. Да.

А как тогда 0 получить?

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

Удачи, надеюсь что у вас всё получится, проект очень интересный. Но я не думаю, что у вас получиться продать 1000 книг так, как вы позиционируете её на linux.

Но я не думаю, что у вас получиться продать 1000 книг

Я абсолютно уверен, что не получится :-) хотя и по совершенно иным причинам. Тираж в 1000 экземпляров мог бы состояться в двух случаях — если бы была собрана расчётная сумма (а она собрана явно не будет) или если бы нашлось издательство или кто-то ещё, кто готов разделить риски и задействовать свои каналы сбыта (а этого тоже, скорее всего, не будет). А так, скорее всего, тираж будет гораздо скромнее. Число 1000 было упомянуто просто по той причине, что это минимальный тираж, при котором осмысленно применение офсетной печати.

не дай автору денег - спаси дерево

http://blog.regehr.org/archives/47

«One of the great innovations of the past 50 years of programming language research was to separate the semantics of a language from its implementation. This permits the correctness of an implementation to be judged solely by how closely it conforms to the standard, and it also permits programs to be reasoned about as mathematical objects. C is not the most suited to mathematical reasoning, but there are some excellent research projects that do exactly this. For example [...]»

При всей твой нелюбви к стандартам, и нашем общем недовольстве тем как именно некоторые аспекты Си стандартизованы, как раз наличие таких устоявшихся с годами (и количеством реализаций) стандартов в том числе и положительно (я согласен, и отрицательно тоже) выделяет Си. Язык «not the most suited to mathematical reasoning», но пригодный для этого и при этом очень распространенный.

Да, многое оставлено implementation-defined, но, для сравнения, в Паскале даже не гарантируется ни наличие, ни отсутствие short-circuit evaluation («ISO Pascal allows but does not require short-circuiting»), а это по-моему будет похуже, чем неопределенный порядок вычисления параметров при вызове функции. И в реализациях:

http://www.gnu-pascal.de/gpc/Compiler-Directives.html

     --[no-]short-circuit   $B+ $B- like in Borland Pascal:
                                    $B- means short-circuit Boolean
                                    operators; $B+ complete evaluation

На Паскаль просто нет действующего стандарта, в смысле такого, на который кто-то бы реально оглядывался при изготовлении очередной реализации. Де-факто исходники на Паскале намертво привязаны к каждой конкретной реализации, что бы там ни пытались с этим сделать. То есть ситуация совершенно иная, чем с Си. Да и с количеством этих реализаций... откровенно говоря, я бы сказал, что вот Free Pascal есть и живой, а есть ли что-то ещё — сомневаюсь. GNU Pascal какой-то уже не очень живой. А современные изделия от Embarkadero — это уже давно вообще не Паскаль.

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

А чем плох Basic для обучения? Свободные реализации под GNU/Linux вроде есть.

А если LOGO?

А Scratch?

Да лучше всего Dart! Почему не Dart, А.В.?

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

Вы же преподаватель, зачем вы приводите единичные примеры которые ничего не доказывают? Вы сами где-то (возможно, здесь, уже не помню) писали что существуют студенты, поступившие на ВМК, которые испытывают трудности с программированием. А вы хотите чтобы девочка из бухгалтерии сваяла скрипт на _____ (язык подставьте сами, хоть питон, хоть 1с) за две-три минуты? Да не смешите мои тапочки.

Гораздо чаще приходится наблюдать такую картину: приходите вы в любую контору, а клерк (от девочки и до старушки) вас обслуживает, глядя в свой компьютер и тыкая в клавиатуру двумя указательными пальцами. И вы стоите у окошка не две-три минуты, а пятнадцать-двадцать. Добавьте сюда время, потраченное на ожидание свободного клерка, и в результате получается, что на посещение одного присутственного места надо убить полдня. Потому что девочку в школе учили программированию (а так же интегралам; но не научили ни тому, ни другому), вместо того чтобы научить её печатать на клавиатуре вслепую, быстро и безошибочно.

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

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

Чушь. Нормальный руководитель ставит перед подчинённым задачу, а не программирует. Да и программировать людей бессмысленно — всё равно сделают не так. Они ж не роботы.