90% не будут понимать

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

Вы кого-нибудь пробовали учить с нуля?

Нет. Я рассматриваю то, как хотел бы, чтобы в своё время учили меня.

Угу, дисциплина называется «надежность программно аппаратных комплексов» Ты не поверишь, ее преподавали, как там сейчас я даж хз, походу плохо, раз такие тут кривотолки

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

Они напишут тест и прогонят по всем версиям.

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

Автор вообще-то заставляет читателя

Что делает? Заставляет? А холодную манную кашу с комками он не заставляет есть :)

А мне почему-то показалось, что «рыбка» на обложке книги это пример множественного наследования :-D

Вопрос про алгоритмы

Вот автор пишет много про вычислимость, в связи с этим задам вопрос, который меня давно волнует:

Многие знают об оценке сложности алгоритмов через О большое Пусть есть алгоритм со сложностью О(n) Но при реализации в конкретной программе на конкретной машине случилась такая беда, что на каждом шаге внутри цикла происходит промах в кеше L2 (или L3 если есть), в результате данные забираются из оперативной памяти с вытекающим отсюда оверхедом. Какова реальная сложность алгоритма в терминах О большое?

P.S. немного на вентилятор: на стр.161 автор утверждает, что watchdog невозможен - это отрицание очевидного ?

О реальном мире.

Вы хоть раз пробовали работать в команде?

В один прекрасный момент всё это рискует не запуститься в операционке Х.

Шанс такой-же как не запустить ваш архиватор.

пользуясь гитом ты имеешь один архив программы

Сделайте 2 архива, 3 или 10, кто мешает, вопросы резервирования мы тут вообще не рассматриваем.

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

Звучит как: не читал, но осуждаю. Тут вы признались, что не понимаете работу git. На любое изменения создаётся отдельная ветка, туда заносятся изменения, потом подписывается заинтересованными людьми и после этого объединяется с основной.

и куча архивов *.tar.gz в корневом каталоге проекта

С этого момента начинается фееричный бред, поясните о чём вы.

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

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

Попробуйте объяснить дифференциальное исчисление первокласнику.

«почему в 2016 году вместо паскаля предлагают си, а не раст?»

Потому что в обществе сильна гомофобия:-)

Автор вообще-то заставляет читателя установить себе линукс

а вот этот автор вообще редкий негодяй:

Как запустить эту программу, зависит от системы, которую вы используете. Так, в операционной системе UNIX необходимо сформировать исходную программу в файле с именем, заканчивающимся символами ".c", например, в файле hello.c, который затем компилируется с помощью команды

CC hello.с

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

a.out

что на каждом шаге внутри цикла происходит промах в кеше

Это вы про Эльбрус говорите?

«Если вы теперь запустите этот файл на выполнение командой a.out»

То ничего не произойдет. Потому что надо запускать командой ./a.out

Хм, я всегда думал, что если main() возвращает что-то отличное от 0, то это говорит об ошибочном завершении программы (соответственно возвращается код ошибки). А тут какой-то «факап мозга».

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

всё та-же O(n)

Вы хоть раз пробовали работать в команде?

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

Шанс такой-же как не запустить ваш архиватор.

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

Сделайте 2 архива, 3 или 10, кто мешает, вопросы резервирования мы тут вообще не рассматриваем.

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

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

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

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

Просто магия какая-то, причём в ssl стабильно работающая не так как надо - все эти заинтересованные маги пропускают в основную ветку критичную лажу. В ядре линукса, также - вроде бы верховным заинтересованным магом является сам создатель гита, а постоянно «Смотрите, копируйте: в ядре обнаружена лажа, качайте следующее!» Что-то ваша волшебная подпись недостаточно волшебная чтобы объединять правильно и находить виновных.

и куча архивов *.tar.gz в корневом каталоге проекта

С этого момента начинается фееричный бред, поясните о чём вы.

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

Хм, я всегда думал, что если main() возвращает что-то отличное от 0, то это говорит об ошибочном завершении программы (соответственно возвращается код ошибки). А тут какой-то «факап мозга».

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

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

Многие знают об оценке сложности алгоритмов через О большое Пусть есть алгоритм со сложностью О(n) Но при реализации в конкретной программе на конкретной машине случилась такая беда, что на каждом шаге внутри цикла происходит промах в кеше L2 (или L3 если есть), в результате данные забираются из оперативной памяти с вытекающим отсюда оверхедом. Какова реальная сложность алгоритма в терминах О большое?

Кеш не влияет на оценку сложности алгоритма. Можешь считать, что кеша нет в принципе, это ничего не изменит.

P.S. немного на вентилятор: на стр.161 автор утверждает, что watchdog невозможен - это отрицание очевидного ?

Почему? Предполагаю, что имеется в виду, что watchdog может зависнуть точно так же, как всё остальное. За ним поставим следить второй watchdog?

Хм, я всегда думал, что если main() возвращает что-то отличное от 0, то это говорит об ошибочном завершении программы (соответственно возвращается код ошибки). А тут какой-то «факап мозга».

Код возврата программы это просто число. Как это число потом интерпретировать, это уже другой вопрос. Обычно да, 0 значит всё хорошо, не-0 значит, что-то не так. Но ничего принципиально не мешает, например, в коде возврата возвращать факториал переданного аргумента или что угодно ещё.

Я тоже часто пишу в одиночку и всегда использую git для этого. Git тоже можно запустить из под эмулятора. Результаты работы всегда сливаю на другой комп с помощью git pull. От ошибок git не защищает, он лишь упрощает работу с кодом.

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

Я до сих пор не понял зачем нужен GUI, кроме как отображать firefox, эмулятор терминала и графику (пуффыстых котиков или маньяков из outlast).

Уважаемый Napilnik Ваши выпады даже до троллоло не дотягивают.

Точно не помню что там было в первом классе, но помню что было что-то типа 5*6 = X, проверяем X/6=5 или X/5=6. Может быть не в первом классе, но где-то там...

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

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

Всё верно, и по идеологии Unix, о том как интерпретировать возвращаемый код необходимо читать в man-е. см. man(1) false

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

??? :))

// блин, кто бы видел...

Книгу писал не я (как в UNIX с этим дело не знаю). Если директория с исполняемым файлом добавлен в переменную PATH, то запустится и так (при заданных правах на исполнение).

«Книгу писал не я (как в UNIX с этим дело не знаю). Если директория с исполняемым файлом добавлен в переменную PATH, то запустится и так (при заданных правах на исполнение).»

Если другая директория с другим файлом a.out прописана, то он и запустится, а не текущий результат компиляции. Так и во всей остальной книге?

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

Что за бред школьника я сейчас прочитал?

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

В /dev/null, очевидно. Но особо одарённым никто не мешает сложить в гит и их.

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

С точки зрения программиста это просто число. С точки зрения пользователя у этого числа есть определённые принятые значения (точнее два множества: 0 и не-0). Командной оболочке на возвращаемое значение тоже пофиг, пока оно конкретно не используется каким-то образом.

В /dev/null, очевидно.

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

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

Реальность сиречь Индустрия формируется совершенно не Вами. Вы обязаны не более, чем подготовить новых ЮЗЕРОВ. Пора бы уже понять. Но как же - эго распухло и ничего низги :)

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

То обучение, которое обязано «не более, чем подготовить новых ЮЗЕРОВ» — это уровень профтехучилища, но никак не вуза.

Впрочем, вопрос глубоко философский. Лично моё мнение: индустрия не способна создать ничего нового, тогда как университетское исследование способно. Следовательно, индустрия вторична.

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

Тут Вы немного неправы. Почитайте man set, опция -e. Лично я очень часто использую её shell скриптах. Если нужно точно быть уверенным что блок кода выполнился без ошибок. Что то типо:

(
 set -ex
 blabla
 blabla
)

начал читать, пока нравится)

Если другая директория с другим файлом a.out прописана, то он и запустится, а не текущий результат компиляции. Так и во всей остальной книге?

Да они из под root в /bin/ каталоге собирали, чего ещё вам не понятно?

в то же время с момента их введения указатели в Паскале проявляют практически все свойства «настоящих» указателей, за исключением разве что адресной арифметики.

Адресная арифметика в FPC имеется.

С точки зрения программиста это просто число. С точки зрения пользователя у этого числа есть определённые принятые значения (точнее два множества: 0 и не-0). Командной оболочке на возвращаемое значение тоже пофиг, пока оно конкретно не используется каким-то образом.

Простите, но я не смог найти здесь осмысленную информацию.

Представьте, что кто-нибудь попросит например bash выполнить prog1 && prog2

Кеш не влияет на оценку сложности алгоритма. Можешь считать, что кеша нет в принципе, это ничего не изменит.

на теоретическую оценку не влияет, но это вопросы к теории, а вот по части фактической скорости выполнения очень даже повлияет

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

не значит ли это что оценки О большое в части случаев можно смело отправлять на помойку? (это я вопрос переформулировал изначальный)

на теоретическую оценку не влияет, но это вопросы к теории, а вот по части фактической скорости выполнения очень даже повлияет

Это верно.

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

И это верно.

не значит ли это что оценки О большое в части случаев можно смело отправлять на помойку? (это я вопрос переформулировал изначальный)

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

Я и на C могу написать f1() && f2() (или f1() == 0 && f2()). Это просто синтаксис. Вот выше привели пример с set -ex, это уже ближе к правде. Но опять же это не поведение по умолчанию, а опция для упрощения написания типичного кода.

Представьте, что кто-нибудь попросит например bash выполнить prog1 && prog2

Надо почитать ман на prog1, если это алиас на false, то

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

возможно вы неправильно понимаете эти оценки. Например, возьмём два алгоритма с одинаковой оценкой, допустим O(n). Значит ли это, что они работают с одинаковой скоростью? Нет, скорость их работы может отличаться в разы, главное, что этот множитель при скорости есть константа, не зависящая от n. Почему же эти оценки важны? Они важны при рассмотрении предельных случаев, когда n стремится к бесконечности. При таком предельном переходе всегда найдётся такое n, начиная с которого алгоритм O(n) будет работать быстрее любого алгоритма O(n*n) или O(n*log(n)).

читайте мануал на bash тогда уж

P.S. никогда не думал, что придётся давать такой совет на лоре

наверное, K&R. но там про запуск скорее только в начале.

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

функциональщиков

Отчасти из-за этого прочитал вступление книжки, не нашел ничего явного на эту тему.

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

Я не пойму, что вы пытаетесь доказать? Что программа не может возвращать ошибочные значения при нормальной работе? Я уже говорил про примеры и false и xmessage. Если это так, признайте уже свою ошибку и закройте тему.